DeMarko T.Peopleware.Productive projects and teams.1999

188 PEOPLEWARE

uct—how it interfaces with its corresponding parts—but nothing about the process for building that product. It would still be a AA battery whether you built it underwater or using robots or trained monkeys, provided that it lived up to its end of the standard interface bargain (with its size, shape, tolerances, electrical characteristics, and so on). To extrapolate from the success of interface standards to the need for process standards is a bit of a stretch.

Still, there is enormous appeal in the identification of an ideal process. The work of Humphrey, Palk, and others at the SEI is thoughtful, competent, ambitious, and sincere:

When Tim and I edited the collection called Software State-of-the-Art: Selected Papers [Dorset House, 1990], we set out to pick the most influential papers of the 1980s. "Characterizing the Software Process," by Watts Humphrey, was among the first that we chose. In an article that I wrote for American Programmer later that year, I committed myself as to which of the thirtyone papers was the very best. Without hesitation, I chose Humphrey's. The impact of Humphrey's work in the years that followed has, I think, confirmed this selection.

—TDM

Identifying an ideal practice, or at least a candidate ideal practice, is a useful endeavor. But the programs that mandate such a practice are something else entirely.

The paradox of the CMM is that process improvement is good, but process improvement programs aren't, or at least they often aren't. Competent people are involved in process improvement all the time: They take pride in progress and growth, and these can only come from getting more proficient at what they do. This kind of low-level process refinement is the basic hygiene of knowledge work, but formal process improvement moves responsibility up from the individual to the organization. The individual may strive for, practice, and/or promote good skills, but the organization can only institutionalize them. It is in this institutionalization that the danger lies.

To understand the problem with the institutional approach to process improvement, you have to take your eye off the projects that get done while the process level is being lifted, and focus instead on the ones that aren't getting done.

PROCESS IMPROVEMENT PROGRAMS 189

It'sAbouttheBenefit,Stupid

Organizations that build products with the most value to their customers win. Those that build products that make the world yawn lose, even though they build them very, very efficiently. Even those who stumble while building products of high value win over the efficient yawners. Process isn't worth a rip unless it's applied to projects that are worth doing.

/ gave a talk to a local professional society about the conflict of benefit and process. After it was over, a software manager told me about a project that had finished earlier that year. They had added several new transactions to an on-line customer inquiry and order system. At installation, they put in visit counters to find out how often the new features were used. After six months, they downloaded the counters. The manager knew how much it had cost his company to build the software, and he divided the visit count into the cost to arrive at a cost-per-transaction figure for the six months. The cost-per-transaction was $53,000! The benefit of each visit was probably measured in pennies. The great irony was that this was a CMM Level 2 organization, slated to be assessed for Level 3 within a few months. Gee, if they had only been a Level 3 organization before this project started, they could probably have gotten that cost down to $45,000 per transaction.

_TRL

When process improvement (as in "Level 3 by the end of the year!") becomes the goal, the scary projects get put onto the back burner. It's those scary projects, unfortunately, that are probably the ones worth doing.

All the projects that carry real benefit carry real risks along with them. It is the project that has some novelty, some innovation or invention, that might grab the customer's imagination and wallet. It's even possible your company's most famous disaster project—the one that came in a year over schedule, at 3.5 times the cost, had loads of problems getting through system test, and still needs engineers standing around with code defibrillators just

190 PEOPLEWARE

to keep it running—is still the best project your organization has done in years.

One of the strongest justifications for the CMM is that it will raise quality and productivity while decreasing risk:

Level

Optimising

4

Managed

3

Defined

Repeatable

1

Initial

Key Process

Statistical Evidence of Process

Effectiveness

Continuous Process Improvement Focus

Rigorous Defect Causa) Analysis and

Oafect Prevention

Productivity and Quality are Measured Process Operates within Acceptable Limit: Predictable Process and Product Quality

Documented Managerial/Engineering

Process

Organisational Software Process Focus

Project Activities Under Control, Quality

Tracked

• Disciplined Management Control Prcces«

Project Management Policies/Procedures

•Project Activities Under Control, Duality

Tracked

Absence of Sound Management Practices Software Process is Ad Hoc, Unstable Software Development Results are

Unpredictable

	Key Actions	Results
	Software Control Office	Measure/
		Improve
	Measure Process Change
	Defect Prevention	Process

Product!vit

Software Control Office

[Meet Management & Quality

Process iteasurement/Analysis

Software Control Office Integrated S/W Management biter-group Co-ordination Education Program

Software Control Office

Project Estimating/Control

Subcontractor Management

Tender Evaluation/Control

Education Program

	Education Program	Quantify/
		Reduce
	Pfocenn nf03stjtemeftt
	Project Control/Planning	RISK

Figure 29.1. The SEI Capability Maturity Model.

The chart suggests that the same work can be undertaken at higher levels with lower risk. But there is another interpretation that strikes us as more likely: Organizations become more and more averse to risk as they "mature." An organization under the gun to demonstrate increased CMM level is not going to go looking for real challenge.

While we're at it, higher proficiency is unlikely to reduce risk anyway. . . .

A New Indoor/Outdoor World Record

Let's say you work for a medium-size company that builds shrink-wrapped business software. The officers of the corporation believe that the CMM does not come from Pittsburgh, but from God's own lips. They have brought in the SEI to assess the company's maturity level. The assessment is complete, and you are all gathered in the corporate auditorium where the SEFs Head

jAt* -f «•

PROCESS IMPROVEMENT PROGRAMS 191

Assessor steps up to the podium to announce the findings. There

is a hush in the hall....

"Ladies and gentlemen, we have some remarkable news. We have completed our assessment, and determined your CMM level on the five-level scheme. The result is that this organization has proved itself to be...

Level 6! That's right, Level 6. We didn't even know there was a Level 6 until we came here. This is a remarkable day for all of us. We feel as if we have found a new element for the periodic table. You are the finest software development organization now known to mankind. Thank you. Have a nice day."

Good news, huh? Now, what are you going to do with it? The more strongly you believe in the meaningfulness of the assessment, the more inclined you are to take on ever more difficult work. Raise the bar. You might as well put your people to work on software that other, lesser organizations couldn't possibly build. If you are the finest software development organization now known to mankind, it makes no sense at all to give your people the same work that any average palooka could do. Much better to torture your competition by taking on only great challenges. And if you fail now and again, so what? Sometimes you will succeed, and then you'll know you have a product worthy of a Level 6 organization. If some run-of-the-mill work has to be done, you might as well send it off-shore. There are plenty of merely competent organizations to take on the easy ones.

Raising the bar means that risk will increase. The more proficient you are, the more risk you take on. You'd be crazy not to.

The more you improve the way you go about your work, the harder the work will be. This happens for two reasons: First, by improving our methods, we typically move the more mundane work either into the machine (for example, software now generates SQL statements; people used to do that job) or out of the project entirely (for example, the invention of the spreadsheet moved a huge pile of work out of the software development group and into the business lines). The work that remains is more intellectually dense; it takes greater skill and experience to do it. As we make real progress in process improvement, we need more talented and more experienced people to do the work.

192 PEOPLEWARE

The second reason is that improved methods allow you to

take on more difficult challenges. And you will take them on ...

unless you've been turned to the dark side....

Process Improvement: Is It Turning .Us to the Dark Side?

[Note to reader: Read this section aloud in your best Darth Vader voice.]

"Luke, look into your heart. You know the great financial gain that can be yours if you can reach Level 4. (Remember, only the Emperor is allowed to be at Level 5.) Let nothing stand in your way, Luke. Turn to the Dark Side. . . . Here is our plan: We will undertake only projects that are clones of past efforts. We will work on only what we know we are good at. We will define a process that works beautifully for these vanilla situations. We will document everything that moves. When the Pan-Galactic Process Police arrive, they will be completely seduced by our seamless implementation of a perfectly managed software process. You will attain that promised massive bonus for software process improvement, but then you must act quickly. Cash that bonus check before your organization goes right down the tubes." [Evil laugh.]

Organizations everywhere are under pressure to climb the CMM. In the extreme, they are hell-bent for Current Level+1 by tomorrow, or else. This is the Dark Side, for it entices the play-it- safe behavior of low-risk, and therefore low-benefit, projects.

The Great Process Improvement Contradiction

You need as much proficiency as you can possibly build into your organization. You need that in order to take on ever-more risky projects. The Key Process Areas, as identified by the SEI, will be useful to you in building proficiency; they define sets of skills that ought to be on any good software manager's wish list. Focus on the KPA skills, but do whatever you can to turn off the institutional score-keeping.

PROCESS IMPROVEMENT PROGRAMS 193

If you are already a CMM Level 2 or higher organization, remember this:

Theprojectsmostworthdoingarethe ones that will moveyou DOWN one fulllevelonyour process scale

Maybe those are the only ones you can afford to do.

Chapter 30

MAKING CHANGE POSSIBLE

People hate change . . .

and that's because people hate change. . . .

I want to be sure that you get my point. People really hate change.

They really, really do.

—Steve McMenamin The Atlantic Systems Guild London (1996)

Steve's quote is taken from a presentation to an audience of IT managers who were more than a little troubled by his view. At first, they were pretty comfortable with rejecting it: "Hey, we build systems that change how people work and play. We try hard to make sure that the changes will be for the better. We explain how the new way will be better; sometimes, we even use precise geometric logic. Why would any rational person resist any change for the better?" To the protesters, Steve retorted, "You don't get it. I'm sorry, but people really, truly hate change. That's the problem: They're not rejecting a particular change on its merits; they're rejecting any change. And that's because people hate change." The examples he offered were devastating. Little by little the message got through, and the crisis counselors had to be called in.

We need to talk about change because it is our business. More than being just system builders, we are change agents.

194

" ""

•

MAKING CHANGE POSSIBLE 195

Every time we deliver a new system, we ar& forcing people to change the way they do their work; we might be redefining their jobs entirely. We are demanding that they change, and while we're at it, our own organizations are demanding that we change, too. The emerging technologies and the building cycle-time pressures are forcing us to change how we build our products.

And Now, a Few Words from Another Famous Consultant

And it should be considered that nothing is more difficult to handle, more doubtful of success, nor more dangerous to manage, than to put oneself at the head of introducing new orders. For the introducer has all those who benefit from the old orders as enemies, and he has lukewarm defenders in all those who might benefit from the new orders.

—Niccolo Machiavelli, The Prince (1513)

We tend to think of Machiavelli as a cynic, but he almost certainly fancied himself a realist. He didn't set out to cast mankind in the most unflattering light, only to state the bald truth as he saw it. He wrote The Prince as a primer for the young Lorenzo de' Medici, who was ascending to govern the city-state of Florence. (The de' Medici family built an enclosed elevated walkway over the Arno, connecting their castle with the government building, to minimize the chances for assassination. Look for the walkway when you visit Florence; it's still there.) The book's purpose was to acquaint the young prince with reality, however pleasant or un-.

"For the introducer has all those who benefit from the old orders as enemies, and he has lukewarm defenders in all those who might benefit from the new orders." Notice the equation is unbalanced against change. While you risk making enemies of those who have mastered the old ways—you are forcing them back to the uncomfortable position of novice—you receive only minor support from those who would gain. Why is that? Why are those who stand most to gain from the change still half-hearted in their support? That's because people hate change. When we start out to change, it is never certain that we will succeed. And the uncertainty is more compelling than the potential for gain.

196 PEOPLEWARE

In 1991, 1992, and 1993, I was the Chair of the National Software Methods Conference, held each spring in Florida. The first year, I made some opening remarks and handed out a questionnaire for all the participants to complete. I asked all sorts of questions about what methods and tools they used to build software. One question I asked was, "What method or tool has been seriously introduced in your organization but has failed to become common practice?" I collected the responses, to report the results back to the attendees by the close of the conference. I started making a list of failed methods and tools, but stopped when I noticed something much simpler and clearer: Everything had failed, at least somewhere. The real irony is that when I did report back, I took the list of failures and asked if anybody was using those methods or tools regularly. I got a positive response on every single one. Everything works, and everything fails. What is going on here?

—TRL

That's a Swell Idea, Boss. Pll Get Right On It.

Whenever you attempt to instigate a change, you can expect a variety of responses. Jerry Johnson, of the Menninger Business Institute, has proposed that there is a pattern to this variety, something he calls the "Resistance-to-Change Continuum." It looks like this:

1.Blindly Loyal (Ask no questions)

2.Believers but Questioners

a.	Skeptics ("Show me.")	increasing
b.	Passive Observers ("What's in it forme?")	resistance

c.Opposed (Fear of Change)

d.Opposed (Fear of Loss of Power)

3.Militantly Opposed (Will Undermine and Destroy)

Figure 30.1. Resistance-to-Change Continuum.

Everyone falls someplace on the continuum in the way he or she will respond to a change.

MAKING CHANGE POSSIBLE 197

Looking at the continuum, ask yourself, Who of these are my potential enemies, and who are my possible supporters? Clearly, the Militantly Opposed are dangerous; they will seek to return to the old status quo at any cost. You might conclude that the Blindly Loyal are good guys and the others are whiners, that the Blindly Loyal are allies and the other groups are enemies.

Jerry pointed out that this view is all wrong. For example, we need to be aware of the danger posed by the Blindly Loyal. They are probably fairly powerless, and they will jump onto whatever appears hot. They follow le fad du jour: "We gotta stop the accounting package installation right now because we can do it better ourselves with an Intranet-based system using Java Decaf. Wait. Hold the Decaf. I just saw an ad on the Computing This Nanosecond website for Double-Java latte with foamy applets." They will withdraw their support as quickly as they give it in order to hop on some new bandwagon.

Johnson asserts that the Believers but Questioners are the only meaningful potential allies of any change. The two extremes, Blindly Loyal and Militantly Opposed, are the real enemies. The success of your change will depend on how you manage the Believers but Questioners. Don't count on logic, by the way, as your trump card: These on-the-fence, maybe-baby allies are never going to be swayed solely by a rational discussion of why the proposed new way will be so much better than the current situation. Here is something to repeat to yourself whenever you set out to ask people to change:

MANTRA: The fundamental response to change is not logical, but emotional.

As systems developers, we have selected ourselves into the world of cool, calming, rational thought. Either our code compiles, or it doesn't. The compiler is never happy for us, nor mad at us. Perhaps this is why we tend to apply logic as our main device for resolving disputes.

You may catch yourself patiently explaining to your kid: "I know you want a bike, but it is neither your birthday nor is it Christmas, the cultural dates upon which gifts may reasonably be expected. If you have accumulated sufficient allowance, you may proceed with the purchase yourself." And you may be frustrated by a not-very-logical response like, "But I want a bike! I want it right now."