Issue 3, March 1995
Newsletter of the Boston Software Process Improvement Network
APR 11 (second Tue), 7-9 pm -- Monthly BCS/SQG (Software Quality Group) meeting -- "Problems in Testing", conducted by Don Willett -- BCS office, Waltham -- Info: Adam Sacks, 617-951-6057 (w), 617-648-3643 (h)
APR 17 (third Tue), 630-830 pm -- Monthly SPIN meeting: "Process Improvement + Metrics = Performance Improvement", by Dr. Howard Rubin. GTE Building 5, 77 A St, Needham
APR 14 (Fri) -- Deadline for early registration for SEPG Workshop
APR-JUN -- BCS/SQG Saturday PDS series conducted by Johanna Rothman -- Info: Adam Sacks, 617-951-6057 (w) -- Registration ($195/$244): BCS, 617-290-5700
MAY 22-25 (Mon-Thu) -- PROCESS AT WORK, the 1995 SEPG Workshop, Boston Sheraton -- Annual national conference for software process improvement, this year sponsored by SEI and Boston SPIN -- Info: 412-268-6467, 412-268-7388
To reach Joe Farinello:
ESC/ENS (Bldg 1704)
5 Eglin Street
Hanscom AFB, MA 01731-2116
Work Phone: 617-377-8561
email:
farinelloj@hanscom.af.mil
Any help you can provide is greatly appreciated.
Jim Trusselle
Liberty Mutual Ins. Co.
225 Borthwick Ave.
Portsmouth, NH 03801
(603) 431-8400 x 53217
msmail.trusselj@tsod.lmig.com
THANK YOU to all who have volunteered to help at the SEPG Workshop or who submitted logo ideas for SPIN or for the Workshop. The SPIN logo decision is still in the works.
Presentation: RISK MANAGEMENT -- LIMITATIONS OF THE REARVIEW MIRROR, by Clyde Chittester (SEI Risk Management Program Director)
The presentation was focused around a new program at the SEI that addresses risk management in the context of software acquisition. This work, like most of the SEI work, is influenced by the model of a single purchaser of a large computer system. The goal is that organizations consciously assess what can go wrong and what the severity of the impact would be by continuously identifying, communicating, and resolving risks.
I found this to be one of the more interesting talks that I have seen at a SPIN.
The SEI suggests that software projects put an explicit risk management plan in place that includes iterations of: identification, analysis, planning, tracking, and controlling. Most of the discussion involved identification, analysis, and planning. The process he described has been piloted on about 45 projects (industry and government sectors). He described these steps as follows:
He described a Risk Repository that the SEI would maintain that organizations could populate with their own risk information and could access for help in their own risk management activities. This data would be anonymous and would be categorized by the type of business.
To accompany this work, the SEI will be publishing a Software Acquisition Maturity Model (SAMM), that will be complimentary to the CMM but be focused more on the customer. A central piece of the SAMM has to do with managing risks. It will be in the same format as the CMM (levels, key process areas, key practices,...) and will be integrated with an Improvement Method Description and a Pilot Usage Report that will include data from all the pilots.
Presentation: AN INTRODUCTION TO THE PEOPLE CMM (P-CMM), by Bill Hefley (SEI)
The intent of this model is to provide assistance in:
The P-CMM is being developed as an acknowledgment to the widely- held belief that the SEI work in general, and the CMM in particular, has been flawed because it did not pay enough attention to people.
There seems to be no disagreement on the significance that personnel capabilities can have to the success of an engineering organization;
In addition, the SEI has noticed in their dealings with many different software engineering organizations that:
The meeting had an interesting digression after he put up a supporting slide representing "What Vice Presidents think". The gist of the slide was that VPs recognize people as being the most important aspect of their organization (not process, not tools, not technology, etc.). This led to a discussion around a belief by many that senior management often says things like that as a way to avoid process improvement and as a way to pander to their employees.
Another belief that came out in discussion is that many senior managers think that they have great people (and do not need process) because they see effective fire-fighters and do not recognize the equal or greater value of people who prevent fires
Getting back to the topic at hand -- Once this need was recognized, the obvious solution was for them to apply what they knew about a maturity model (from their experience with the CMM) to the people factors domain.
The basic framework of the P-CMM is similar to the CMM; there are Key Process Areas (KPAs) and Maturity Levels. The KPAs are organized by maturity level and the maturity level indicates staff capability.
The people management functions that they explicitly address are;
What follows is a brief description of the five maturity levels along with the names of the associated key process areas:
Level 1 is the "herded" level (as with the CMM, there are no Level 1 KPAs). A Level 1 organization treats people management as overhead. Managers are not generally trained in how to manage people, and there is little analysis done on the effectiveness of the people management activities. In a P-CMM Level 1 organization, there is a lot of time spent on personal agendas and there is usually a high turnover rate.
At Level 2, management feels responsible for the people and there are people management activities that focus on individual contribution. The level 2 P-CMM key process areas are:
At Level 3, the organization is more formally developing its knowledge and skills. It has identified its primary competencies and the people are aligned with them. People management activities are planned. The Level 3 P-CMM key process areas are:
At level 4 the organization is measuring its knowledge, skills and performance. It is quantitatively managing organization growth in people management capabilities, and establishing competency-based teams. The Level 4 P-CMM key process areas are:
At Level 5 there is continuous improvement of the methods which are used to develop personnel and organizational competence. The Level 5 P-CMM key process areas are:
Just as with the CMM, they are planning on having a process for assessing an organization against the P-CMM. This is in the preliminary stages. There will be two purposes for this assessment; Identify people management strengths and weaknesses and then align them for improvement Identify the readiness of a team for a specific project.
He said that assessments against the P-CMM would be similar to CMM-based Assessments, but that they may introduce some new concepts. The use of a widely distributed survey form was the only new concept mentioned.
Some questions that came up:
Ed Maher works for Digital Equipment Corporation within the Open VMS Engineering organization.
[ Information update: V0.3 of the P-CMM is due at end of April; V1
this fall. Validation pilots are planned for 1996-97.
For more information contact Marlene MacDonald, SEI, Carnegie Mellon
U, Pittsburgh PA 15213-3890, 412-268-7701,
mtm@sei.cmu.edu
P-CMM can be ftped in a variety of formats from
ftp.sei.cmu.edu/pub/pm-cmm.]
Al's winning description of the application of TQM to achieve process improvements in the OSF/1 project is summarized below:
Excellence in Quality at the Open Software Foundation
OSF/1 is a large, complex software product, consisting of over 2 million lines of source code. In developing and maintaining OSF/1, we faced a series of problems, including these:
Our engineering team met these challenges by using TQM methods, including:
Implementing the basic improvements led to measurable benefits, including:
If you've got access to the World-Wide Web, you've probably enjoyed the wealth of software process information that's available if you go looking. Here are some shortcuts to places with useful information or collections of links.
Drilling down to a couple of specific software process topics, design patterns and collaborative work have lots of information available on the Web.
I'd love to write a longer column on the Web for a future SPIN issue. Send me, rachel@world.std.com, your favorite links, and I'll write up all the links that fit.
Where do you want to work next? Figuring out what potential employers are really offering can be an uncertain proposition. Paul Morris of Paul Morris Personnel (paul@pmorris.com) suggests that the professional software developer may well want to take advantage of the CMM scale to characterize the kind of working environment they'd like to have. "Look for a level 3, mature object-based software environment," he said in a telephone interview. "Beware of companies who claim C++ and object-oriented software but haven't yet shown a commitment to software process."
He went on to explain that companies in the early stages of conversion to C++ and object oriented systems may get discouraged when O-O technology alone does not make a dramatic or quick difference in productivity. They may underestimate the time needed to retrain existing staff and rework their existing code base.
"Identify the software culture you want to work in," Morris said. "Most engineers would like to work where people do things right." He believes that attention to the level of software capability you've worked at can be professionally important. "You only have one career. Be aware of what you are getting for your time."
The software culture question is applicable in both the defense and commercial software industries. While most commercial companies do not characterize themselves on the CMM scale, the criteria of having a track record with object-oriented technology and of undergoing a natural evolution of the corporate software process can be just as valuable. Asking interview questions with these issues in mind can reveal important information about the organization.
One of the software process improvement tools available to us is studying other companies to find role models and inspiration. Finding the best practices, benchmarking them, and starting a disciplined program to influence an organization toward them, can be a long-term project for a large organization.
Tom Peters, in _The Pursuit of WOW!_, comes up with a more intuitive approach:
Suppose you commit to achieving new heights in quality or service here and how. In your own mind, you're an instant Nordstrom (retail) or Motorola (manufacturing). But your next task ... is to go through your boring in-basket.
What an opportunity! Respond to the first item that turns up as you imagine a Nordstrom or Motorola exec would.
In pursuit of process improvement, you can't get more direct than that.
My personal inspiration is PureCoverage from Pure Software. Other coverage tools I'd worked with had been clumsy and hard to get the information I needed. In some cases, they'd required complete recompilation, a long process with a large system. When I installed PureCoverage, I got useful results within a couple of hours.
The user interface put the information I needed to know right at my fingertips. And most surprising of all, this was happening with a 1.0 release of the software.
So, who is your role model in the software field? And what experience did you have with their product or service to inspire you? Mail to rachel@ontos.com. Your replies will be the basis for a future In the SPIN article.
by Judi Brodman
Vernal Equinox Greetings!
As I took out the computer to begin this column, I thought of how many advances the hardware community has made in the last 10 years. My notebook is smaller than my handbag and more powerful than my office computer! I can take it with me when I travel and answer your letters, via the built-in modem, from anywhere in the world. Because of its interfaces, I can hook up my color printer to it, add a CD ROM, change the screen.... This is all so terrific and yet their advancements only serve to highlight how slowly the software field is advancing in comparison to the hardware field. I found proof of our "inch" step advances in my office last week while I was doing some Spring cleaning.
First, Spring cleaning in my office means "weeding" through the volumes of information that I accumulate on a yearly basis ... technical reports, journals, magazines, etc. This spring, I attacked my beloved IEEE journals; for me, their life span is about 10 years! And even then, I can't just throw them out; I have to check the table of contents and sections like "Quality Time", and tear out and file articles that I feel are still timely. What I found shocking was that we are still "talking" about the same software issues that authors were writing about in 1985... measurement (metrics) and software quality! Why do we continue to struggle in these areas? Why can't we find solutions to these problems? We continue to collect metrics that our customers IMPOSE on us.
Twenty years ago, these same metrics didn't help us manage on- going software projects; they didn't help us estimate size, schedule and costs for new projects; and they still don't help us to manage or estimate now! Why can't we decide for ourselves what data benefits each of our organizations ... and then, having done that, look at the data collectively as a group and define metrics that really work for management and estimation of projects? Jum Nunnally, in his fascinating book _Psychometrics Theory_ (McGraw- Hill, 1967), stated that before a science can move forward, a measurement method is needed ("In fact it seems that major advances in... all sciences, are preceded by breakthroughs in measurement methods"). How long are we going to "wait" for these breakthroughs to happen in software??
Because of my impatience, I propose that we dedicate this column for the next few months to open discussion of the underlying issues that are hampering our "breakthrough". If you are making advancements, let us hear from you; if you have found a particular metric(s) or quality "booster" that works for your organization, share it with us; if you are struggling with these areas, write and describe the problem. Let us use this column as a way to BEGIN THE BREAKTHROUGH!!
Now to our letters...
TO KEVIN IN TUCSON: [see last month's In the SPIN]
I sent your letter along with my answer to MARK PAULK (SEI) and asked him to add any thoughts he might have on your problem, and here is what he had to say...
"These are good comments, but I think I would add that the driver for change is usually dissatisfaction with the status quo. If things are working well now, there's no incentive for the discomfort of change -- and we always wonder whether it's just change or really improvement.
"Some leaders envision challenges in the future and are proactive in attacking the future. In that environment, there's a perpetual `dissatisfaction' with the status quo and a feeling that `we're leading edge, the pioneers.'
"The far more common circumstance is to have noticeable problems (sometimes the problem is that your customer isn't happy with functionality, quality, cost, or schedule and is insisting on an SCE to "qualify" their suppliers!). This discomfort - hopefully in terms of measurable business objectives - is translated into management commitment.
"Frequently the staff in the trenches doing the work have been struggling to "work around the system" to get useful work done are well aware of the problems! Sometimes their view of the sources of the problems is somewhat different from management's :-). Getting their buy-in may be a matter of overcoming entrenched cynicism and changing processes that have evolved to `work' a dysfunctional system. This is the challenge of organizational change!
"You need management sponsorship to build ORGANIZATIONAL capability. You need staff and middle-management buy-in to actually do the improvement. You don't need 100% participation to get the journey started, but to drive to world-class software organization, you'll eventually have to get pretty close to 100% deployment - and that means everyone affected needs to see the net benefits."
Kevin, I hope both of these perspectives -- mine last month and Mark's this month -- have helped you approach your problems in a new way. Let us know what works and what doesn't....
I also received a letter from someone struggling with a way to introduce quality into an organization that never had to worry about quality before. Because I wanted to get comments that were pertinent to his situation, I sent his letter off to HERB KRASNER, one of my quality "experts" for R & D.
First, the letter:
Dear SPIN doctor:
Until about two years back, we used to think of ourselves here at the Research Institute as people who do research and develop newer and better algorithms. We are now interested in developing, selling and even supporting products. Because of this history, people have no experience in really supporting products. For example, they have never seen a thick pile of bug reports. How do I sell Quality to people who have never faced Quality problems - I need some tips.
Searching for Quality in R to D
Now, Herb's response:
"Dear Mr. Searching for Quality in R to D:
"The blunt answer from my experiences with both research and product development organizations, is that you cannot "sell" quality in this situation because the current culture isn't even aware that quality is an issue.
"However, there are several things that you can do to speed up the process of creating an awareness of software quality issues.
- The `Q' word means little to quality-impaired researchers, so start giving basic software quality 101 talks at lunchtime to introduce concepts, establish terminology and raise issues.
- Find out more about current quality attitudes and the level of consensus about quality issues without using the `Q' word. I would recommend you start with a face-to-face interview of a few selected staff opinion leaders that focuses on what they think the major challenges will be in going from a research to product delivery organization.
- After you have determined what the issues are in the current lexicon/culture, then you can begin to seek the level of consensus through a more broadly distributed survey form with more focused questions. Once again, defining quality in terms that the organization will understand, is the challenge. The real trick is to start the discussions about software quality without using the term `Quality' because that concept will be rejected by the current paradigm.
"Try the following - go into the office of one of your reasonably friendly researchers and say: `I am concerned about our ability to develop, sell and support software products -- and I would like to learn more about what you think our major challenges are for delivering good products - but since I don't even know what to ask you, perhaps you can help me out by telling me what questions you would ask if you were me'. Once you have the questions, ask them. I'll bet you will learn a lot more this way.
"Yours truly,
"The SPIN Doctor (Software Quality Improvement Network)"
This column is for you; let's make a difference!! Send your comments and questions to "Dear SPIN Doctor" at brodman@tiac.net or directly to the editor.
Question of the month: If you could change one thing about your organization, what would it be??!! Give me a quick answer and I'll post the results next month!
The SPIN Doctor
The only rule I have in management is to ensure that I have good people -- real good people -- and that I grow good people, and that I provide an environment where good people can produce.
--A corporate Vice President quoted by Curtis, Krasner & Iscoe in _Communications of the ACM_, Nov. 1988, and requoted by Bill Hefley at our March meeting (contributed by Johanna Rothman)
It is recommended that organizations monitor the performance evaluation process to include more objective measures of job performance and ensure that the performance appraisal process is administered fairly.
--Magid Igbaria and Wayne Wormley, in a study report finding differences in the way "black" and "white" IS staff within one large company were performance rated, _Communications of the ACM_, March 1995
...[S]taff members' assessment of their project's coordination strongly coordinates with customers' satisfaction with the software development company and the software it produces.... [S]enior management's assessment of the quality of projects is unrelated to other measures of project success....
--Robert Kraut and Lynne Streeter, in a study report finding that both formal and informal communications are needed for successful projects and recommending avenues of exploration to improve current practices, _Communications of the ACM_, March 1995
If the code and the comments disagree, then both are probably
wrong.
--attributed to Norm Schryer
(If anyone knows who Norm Schryer is, it would be nice to know.)
The Boston SPIN is a forum for the free and open exchange of software process improvement experiences and ideas. Meetings are held on third Tuesdays, September->June.
We thank our sponsors: GTE and BULL INFORMATION SYSTEMS.
For information about SPINs in general, including ***HOW TO START
A SPIN***, contact:
DAWNA BAIRD of SEI, (412) 268-5539,
dbaird@sei.cmm.edu
Boston SPIN welcomes volunteers and new sponsors. For more
information about our programs and events contact:
CHARLIE RYAN, Technical Assessments, Inc.,
ESC/ENS (Bldg 1704), 5 Eglin St, Hanscom AFB MA 01731-2116;
(617) 377-8324; FAX (617) 377-8325;
ryan@sei.cmu.edu
IN THE SPIN is published monthly September->June. Letters, notices (including job postings), and contributed articles are welcomed. Articles do not necessarily represent the opinions of anyone besides their authors.
IN THE SPIN is available only by email.
TO SUBSCRIBE send email address to Ron Price
rprice@ma.ultranet.com
SEND letters-to-editor, notices (including job postings but not advertisements), calendar entries, quips, quotes, anecdotes, articles, offers, and general correspondence to Sallie Hoffman, (508) 369-2365,