University of Minnesota
Twin-SPIN
/

You are here

TwinSPIN Newsletter: Volume 2, Issue 3

Editor's Note

As you may have already noticed, this TwinSPIN Newsletter did not arrive
early in the month as it had for the first four issues. It is even a bit delayed
from the promised mid March distribution. Your harried but hopeful newsletter
editors have been swamped with their day jobs, delaying this issue and driving
us to a bi-monthly distribution schedule. This newsletter, as stated in the
title, satisfies the March - April 2000 issue. The next issue, covering May -
June, should be available in mid May. Thank you for all the support and
encouragement as we go above and beyond to bring you this newsletter.

Part of the reason for this delay was my (i.e. Pat Wegerson's) attendance at
the National SEPG 2000 Conference in Seattle, WA. The conference theme was
"2000 Ways to Make Software Better" and I'd say that it lived up to
its theme. This was my fourth National SEPG Conference and it was the best I've
attended. Nearly all of the presentations and tutorials I attended were well
done, thought provoking, and useful. If you've never been to an SEPG conference,
I highly recommend it. One of the biggest benefits of attending this conference
is a motivational shot-in-the-arm when you're surrounded by 2000+ other
professionals working on software process quality. Start planning now to attend
next year's National SEPG Conference on March 12-15, 2001 in New Orleans, LA.

As always, thanks to our contributors, and Pat O'Toole, for providing
articles to the TwinSPIN newsletter. Also thank you to Esther Derby for coming
through yet again to publish this newsletter.

Note: I received a request to have the
newsletter in a form more agreeble for printing individual articles. As a novice
HTML developer I'm still working on doing that (i.e. suggestions are welcomed!).
Until then, I suggest a "cut-and-paste" procedure to a document file.
The end-of-lines may not be where you'd like but it's the best I can offer right
now.

Send letters-to-the-editor, comments, questions, submissions, or anything
else relevant to Pat Wegerson at weger002@tc.umn.edu
or at 612-448-1335. Esther Derby can be reached at estherderby@worldnet.att.net
.

Back to Contents


Writers
Guidelines

The goal of the TwinSPIN Newsletter is to provide articles and information
with a real world perspective that will be useful to you, the readers. And who
could know more about real world software process improvement than the members
of a SPIN? If you've ever had the urge to be an author and have an insight you'd
like to share, consider writing an article for the Newsletter!

In general, articles should be fairly short, not more than 1000 words (since
the Newsletter is distributed electronically, we can't accommodate graphs and
figures at this time). We're looking for articles with a "how-to"
bias, and we also like to put a lighter piece in each issue. Articles that are
academic or commercial are less likely to be of interest.

If you have an interest in writing an article or contributing one that has
been previously published, please contact Pat Wegerson at weger002@tc.umn.edu
or at 612-448-1335.

Back to Contents


TwinSPIN
Meetings

March Meeting:
Topic: CMM compliant process guide for peer reviews
Speakers: Devi Vijayakumar and J (Vijay) Vijayakumar
When: Thursday, March 2, 2000
Where: University of MN, Electrical Eng/Computer Science Hall
Sponsor: FSI International, Dean Willson
Program Director: Jesse Freese

April Meeting:
Topic: Requirements Management: An Object-Oriented Approach
Speaker: Larry Boldt, Technology Builders
When: Thursday, April 6, 2000, from 6 - 8 P.M.
Where: University of MN, Electrical Eng/Computer Science Hall, Room EE/Csi
3-180 (Minneapolis, MN)
Sponsor: Technology Builders, Pam Davenport
Program Director: Pam Davenport

Meeting Directions:
Please check out the maps (see below) or contact Jesse Freese (612-882-0800 or Jesse_Freese@Fissure.com)
if you need additional directions.

For maps:
1. Browse to http://www1.umn.edu/tc/maps/EECSci/
2. See more detail in the "Close up view" at http://www1.umn.edu/tc/maps/EECSci/EECSci-map.html.

Back to Contents


Crisis Management
by Gary Robinson

Everyone has experienced a project crisis. Some have been hurt by crisis,
some enjoy it. Some managers enjoy it so much that they create it.
Regardless of feelings about crisis, the potential for good or bad consequences
is the same, depending on the manager's approach.

Crisis causes so many problems because it demands immediate attention. If the
day-to-day practices don't solve the issue quickly, the pressure to act becomes
strong. Those involved may feel pushed by the expectations of others to act too
quickly. Reacting without adequate information, or involving the right people,
results in poor solutions and increases stress, with no learning about
preventing future crisis.

Causes of crisis

Following are examples of causes identified by hundreds of
project teams:

lack of planning, risk analysis and contingencies

unrealistic goals

poor communications between groups involved in the project

insufficient resources

inadequate tracking

hiding mistakes or delays out of fear of consequences

scope changes

staff changes

acts of God (and other highly placed individuals).


A large percentage of causes are predictable. Many should have been apparent
before the project even started. If it is predictable then some action can be
taken to prevent it, or to reduce the impact if the expected occurs.

A typical crisis sequence with negative results

There is no one cause of crisis, but the following illustrates a common
series of events. Appreciating what the manager does wrong in this sequence can
help managers prevent or resolve crisis of any type.

a. An unrealistic deadline is imposed.

The initial pressure to get the job going is strong. People bury themselves
in immediate work without planning, understanding client needs, getting to know
each other, or developing the team.


b. The imposed schedule starts to slip.

The manager reacts negatively be-cause of the slippage. To protect
themselves, team members stop reporting slippages. Status is reported as
"fine" so the truth is hidden as long as possible.


c. The project manager figures it out and looks for the
person


responsible.

The manager is angry because information about the slippage was withheld, and
does not understand that it was withheld because of his/her negative reaction to
bad news.


d. Team members accuse each other.

Team members unwilling to accept all the blame naturally blame other team
members. The team starts to fall apart.

The real fault is with the project manager for imposing an unrealistic goal,
not openly acknowledging that it is unrealistic, and not offering support to the
team to achieve the impossible. Team members know this, but no one will
con-front the project manager even though they knew from the beginning there was
not enough time.


e. Everyone works overtime, without much improvement.

Pressure is put on the project manager to "do some-thing."
Interventions are often "put in more hours" and/or "new resources
to clean things up." This is demoralizing for the team.


f. Everyone scrambles on a day-to-day basis.

The feeling is "if we can get through the next month..." This is
management by crisis. Negative emotions increase and people may actively dislike
their work or leave.

The project manager may achieve apparent project success by pushing harder,
but has set the organization up for fail-ure in the future. His/her heroic,
pressure-cooker style has set the company up to repeat the same process on the
next project; they have not learned how to prevent crisis or resolve it
effectively.

A better model for crisis intervention

A major role for managers is to develop their team's problem-solving skills
so they become more self-dependent. To do this, the manager must resist the
temptation to take over. It is important to not panic, slow the process down,
and get the team involved.

The manager can resolve project issues more effectively, reduce stress, and
develop team skills by intervening in the following sequence. It is possible for
crisis to have a positive effect on the project, team morale, and client
relations if it is dealt with appropriately.

a. Acceptance

Provide an opportunity for team members to express their thoughts and
feelings.

Listen to people and reiterate the feelings you hear.


b. Conflict identification

Help the team identify the problem and establish priorities.

Ask probing questions that require people to think for themselves rather
than questions that can be answered with "yes" or "no."

Repeat what you hear to be sure you understand.


c. Alternatives

Be a facilitator, not a problem solver.

Help the team identify alternative solutions and discuss the possible
consequences of each alternative.

Ideally the team will freely choose a course of action without being told
what to do. Not only will they resolve the issue, they will increase their
problem-solving skills and become a stronger team.


d. Back off

The manager's involvement in the situation should be reduced as soon as
the team knows what actions it will take.

If it was stressful, the team may need emotional support for awhile. Don't
back away immediately. Ask the team "What do you want from me in the
next week?" Trust their response.

Acknowledge the teamwork that resolved the crisis.


What managers should NOT do

Panic and react.

Step in and solve the crisis. This confirms the team's inability to
resolve it without help. It is demoralizing and does not provide the
opportunity for learning and prevention of the next crisis. Team members
become more dependent on the manager and less willing to use the skills and
knowledge they have. This is a bureaucracy, the opposite of the
entrepreneurial climate where people are responsible for themselves.

Bring in outsiders, unless the team requests it.

Embarrass or criticize any team member.


Ideas to prevent crisis

Set realistic targets if possible; be honest and supportive when goals
must become unrealistic.

Involve the team in planning the whole project.

Do a risk analysis.

Develop contingency plans.

This article came from Software Productivity Center Inc.'s E-ssentials!,
a free, biweekly e-newsletter with how-to's for successful project
management and practical software development.

Back to Contents


Do's
and Don'ts of Software Process Improvement #3

by Pat O'Toole

[Editor's note: This is the third of several short articles on "Do's and
Don'ts" from Pat O'Toole's experience working in an SEPG. This is written
for managers and SEPG members who are implementing CMM-based improvements in
their organizations.]

DO: Take Time Getting Faster

Level 2 in the Capability Maturity Model is called "Repeatable," but even
Level 1 organizations exhibit repeatable behavior. For instance, many
Level 1 projects are scheduled to complete on the earliest date with a non-zero
probability of success. The thinking, which unfortunately appears to be
repeatable, is that if everyone works 60+ hours per week, and nobody gets sick
or takes weekends or holidays off, the project might just finish on time.

And now your senior management has proclaimed that the overarching goal of
the Process Improvement Program is to reduce cycle time. They are not
being unreasonable - it's hard to deny that for many software-intensive
products the primary competitive dimension is time to market. Customers,
whether internal or external, are always clambering to get new products and
features in an ever-decreasing time frame. But as a member of the SEPG you
fear that this edict simply gives the projects an excuse to circumvent any
existing processes and standards in order to get the job done any way they see
fit.

Customers apply schedule pressure as part of a "ritualistic dance.".
They get you to commit to delivering in twelve months in the desperate hope that
they will receive the full product in fifteen months, or alternatively, that
they will get 60% of the core functionality by the committed date. You
know it, they know it, and yet the charade plays out release after release.
It's just like budgeting's ritualistic dance - if you need $5M for your
project you request $7.5M, knowing that 1/3 of the budget will be cut back
through the approval cycle. We all know the tune and the dance continues!

So what do the customers REALLY want? They want to believe!
Customers want to know that when you commit to delivering a product on March 31
that it will be available for implementation on April 1 (an appropriate date?).
Although they claim they want the software faster, they really want it more
predictably.

As much as the customers want to believe, the software development staff
wants to be believed. They would like their managers to leave their
professional integrity intact by accepting and even defending their estimates.
They would like senior management to understand and mitigate the devastating
effects of golf course commitments and uncontrolled scope creep. They
would like their customers to realize that it is in their mutual best interest
to plan and execute projects in a disciplined manner. Finally, they would
like to see their spouses and children more often than Sunday evenings!

Rather than establishing a goal of becoming faster, the organization would be
better served initially with the goal of becoming more predictable. To
achieve this goal, the organization must:
1. Gather and analyze historical data to develop and calibrate estimation
models;
2. Codify good engineering and project management practices that lead to more
predictable results;
3. Establish the means to control the projects' requirements and configuration
baselines; and
4. Enjoy the strong support of leadership in achieving this goal.

Disciplined planning and execution significantly reduce the variability of
project results. It also establishes a solid foundation for getting
projects done faster, the organization's ultimate goal. Since you are
unlikely to achieve sustainable cycle time reductions without first achieving
reasonably predictable results, follow Steven Covey's advice and "put first
things first." The SEPG's challenge is to convince senior management
that generating more reliable estimates and predictable project performance is a
necessary prerequisite to reducing cycle time - and that once customers believe,
once estimation credibility has been established, the tune of the ritualistic
dance will be altered forever.

Copyright © Pat
O'Toole 2000

Pat O'Toole is one of the most active SEI authorized lead
assessors and is a Software Process Improvement Director at TeraQuest Metrics,
where he provides consulting, training, and assessment services to major
clients. He has conducted a number of formal and informal assessments,
including two Level 5 CBA IPIs.

With over 20 years of software development, project
management, and consulting experience to draw from, Mr. O'Toole works with all
different levels of management and SEPGs in establishing, evaluating, and
sustaining their process improvement initiatives. He is a popular
instructor who supplements standard training material with his vast array of
case studies and humorous examples.

Pat O'Toole can be reached at:
1316 Summit Oaks Dr.
Burnsville, MN 55337
Phone: (612) 432-0693
pat.otoole@teraquest.com

Back to Contents


Test Best Practices
By Dick Hedger

Following are the test best practices as determined by the attendees at the
January 4, 2000 TwinSPIN meeting. From the breakout group "Test Best
Practices" inputs, I have summarized the most often mentioned best
practices:

Traceability - from Business Objectives through requirements, coding and
test cases.

Early decisions on test exit criteria - plan coverage and/or
defect discovery rate.

"Comprehensive" unit testing.

Best personnel on test team - independent test team reporting from
development.

Plan tests as part of the original project plan.

Phased testing approach unit, integration and system types of tests
through the life cycle.

Good defect reporting, tracking and closure - measure test results.

Configuration management of test environment.

Test environments separate from development environment.

Have a test plan for each planned Test.

Have software engineers partner early with test team

Thoroughly test error paths.

Utilize test automation tools when appropriate.

Ensure requirements are testable.

Testing methodology should follow design methodology.

Defect analysis and feedback to development.

Regression test fixes.

Do defect causal analysis for process improvement.

 


Dick Hedger
Quality Software Technologies
Dickhedger@uswest.net

Back to Contents


Needs
& Leads

Editor's Note: Needs & Leads is a
feature of both the TwinSPIN newsletter and web site. Needs
& Leads
provides a forum for requesting and for offering SPI
related goods and services. This is offered as a benefit to TwinSPIN members. Needs
& Leads
may include commercial offerings if the item may benefit
the TwinSPIN membership. If, however, you find any offering inappropriate,
misleading, or a detriment to TwinSPIN, please contact Pat Wegerson at weger002@tc.umn.edu
or Mark Glewwe at glewwe@millcomm.com
and we will work to resolve or remove the questionable item.

Needs: No
new needs

Leads: No
new leads

Back to Contents


Announcements
& Calendar

Recent and upcoming U.S. SPIN meetings:


SPIN

Date

Topic

Presenter

Albuquerque
www.abqspin.org/

?

Interpreting the CMM for Diverse Software Environments

Sandia National Labs

Association for Software
Engineering Excellence (Dallas, TX)

4/4/00

TBA

 

Atlanta

4/18/00

Speaker not confirmed yet.

 

Austin

4/18/00

Rolling Out the SAS Solution Definition Methodology -
Real-world Lessons Learned

Maria Moore, Neera Talbert, Consulting Services
Division, SAS Institute

Bay Area Round Table
www.ics.uci.edu/IRUS/

4/9/00

Placeless Documents: A Document Management System ...
& Supporting Expertise Recommendations ...

Keith Edwards, Xerox PARC & David W. McDonald, UC,
Irvine

Boston
www.Boston-SPIN.org

3/16/00

Ensuring Clients Achieve Superior Value In the Digital
Economy

Jim Driscoll, EDS

Chicago

4/6/00

Lessons Learned from the SEPG 2000 Conference

Panel

Los Angeles
sunset.usc.edu/cse/pub/event/LASpin.htmll

3/29/00

Checklists and Scorecards for Project and Quality
Success

Dr. Arnold Goodman, UCI

New York CitySPIN
www.nycspin.org/main.html

3/6/00

Y2K - How we really did!!!

Panel

North Jersey

Managing For Quality Requirements

Richard Bender, TBI

Omaha
www.omahaspin.org/

3/21/00

An overview of Automated Testing tools

Steve Marek

Philadelphia
http://www.asqphilly.org

3/16/00

Earned Value and Risk Management

Richard Barboura, CISE

Phoenix SPIN/IEEE-CS/ACM
keith.favreau@juno.com

1/18/00

eXtreme
Programming (XP)

Linda Rising &
Norm Janoff

Pittsburgh

1/12/00

Using PSP/TSP to Build Successful Software Teams

Don McAndrews,
SEI

Research Triangle Park (NC)

 

No information

 

Rochester, NY

2/17/00

Greatest Hits of SPI - Exploring SEIR and Crosstalk

John Kerr, Xerox

San Antonio

3/15/00

"Quantifying The Qualitative: How to Avoid Vague
Requirements by Clear Specification Language"

Tom Gilb, Result Planning Limited

Silicon Valley

 

No information

 

Southern California
www.ics.uci.edu/IRUS/

3/26/00

Successes in Achieving High SEI Maturity Levels
A Customer Quality Focused Approach for Achievinug SEI
Level 4 (The Managed Level)

Linda A. Abelson, Peter G. Puchalski; Boeing
Leitha Purcell, Northrup Grumman

Toronto

1/20/00

Institutionalizing Risk Management

Dr. Patrick O'Brien, Rockwell Collins

Twin Cities Quality Assurance Association (TCQAA)
www.tcqaa.org

4/13/00

Automated Testing Life-cycle Methodology

Elfriede Dustin, BNA Software

Washington, D.C. SPIN

3/1/00

Improving the acquisition and development of DoD's
Software-Intensive Systems

Dr. Jack R. Ferguson, ODUSD

Washington, D.C. SSQ

 

No information

 

 

Back to Contents


About TwinSPIN
For the Minneapolis/St. Paul Regional Area

TwinSPIN Mission Statement
--------------------------------------------------------------------------------
The TwinSPIN software process improvement network (SPIN) is a regional
organization established in January of 1996 as a forum for the free and open
exchange of software process improvement experiences and ideas. Representatives
from industry, government, academia, other professional organizations, and
consultants are welcome to participate. Our mission is to help sustain
commitment and enhance skills in the area of software process improvement
through an active program of networking and mutual support. The organization
strives to serve as a source of educational and experiential information for its
members, other SPIN organizations, and the general community of software
professionals. (May 1996)
--------------------------------------------------------------------------------

Meetings are normally held on the 1st Thursday of each month from 6-8 PM.
TwinSPIN is a non-profit organization.
============================================================================

TwinSPIN web site:
http://homepage2.rconnect.com/glewwe/TwinSPIN/

All articles, reviews and commentaries are copyright by the authors, unless
otherwise noted. All rights are reserved to the authors. We encourage sharing
the TwinSPIN Newsletter in whole or in part if copyright and attribution are
always included.

Date: 
2000-03-01T00:00:00