WATTS HUMPHREY -- A Giant Passes from the Scene

This is a sad day for everyone who has been engaged at any level in the wonderful world of software. Watts Humphrey, who just died at 83, pioneered the development of many of the processes that assure and ensure software quality. He is probably best known as the father of the Capability Maturity Model -- an approach that has had more impact than any other. Watts understood all along that IT and software engineering aren't about technology; they are about people and processes making technology a tool for solving problems.


His official obit from his long-time base in the Software Engineering Institute at Carnegie Mellon University (http://tinyurl.com/2vffpgt) is headed: Watts Humphrey Succeeded in Changing the World of Software Engineering. "Changing the world of anything is an outrageous commitment," Humphrey said in an interview in early 2010, discussing his decision to come to the SEI. "I knew I couldn't do it alone, and I wanted to be in an environment where I could work with folks and do that."

As the pioneering innovator behind several important software development processes, Watts Humphrey more than met his promise to change the World of software engineering. His contributions go well beyond methodology and the many awards and accolades he received. For decades, his work inspired software engineers and his colleagues and friends worldwide. (Jared Cohon, president, Carnegie Mellon University.)

But Watts' legacy is not just for us techie types -- in fact, what made him so successful in "changing the world" was his strategic leadership, that is the ongoing focus of this blog. Watts embodied the qualities that any leader in any field can adopt.

Vision: After years of pioneering work at IBM as a leader of a mammoth, global software engineering group, Watts saw with great clarity what needed to be done to move developing software solutions to business problems from a black art to an engineering discipline. He believed in the power of harnessing technology in a disciplined way.

Translate vision to reality: Watts was not one of these leaders who float along at 30,000 feet on his visionary quest but whose feet never touch the ground. He could turn his vision into practical processes that gave individuals a clear road map to daily practice.

Inspiration: Because Watts' vision was so clear and because he could translate it into reality, he inspired generations of folks in the software field by making us want to implement his ideas. His style was easy going but compelling. I still have handwritten notes from the many times I heard him speak and lead seminars -- and I still pull them out and use them in my work.

Caring: At the end of any keynote, presenters like Watts are always mobbed by enthusiastic people. Some busy themselves with packing up their notes and computer, distractedly hand out a few cards, and slip away. Others believe they have a captive audience to continue pontificating or shamelessly trying to drum up consulting gigs. Watts was different. He talked with each person, no matter how new to the field and naive, as if he or she were the only person in the room. He shared. He was warm and encouraging. No matter how long the line, he was patient and engaged.

Commitment: His commitment to changing the world of software engineering was authentic and not grandiose. Many in the field believe they have the keys to better software solutions and don't mind telling you how great they are, how wrong others are, and how following them will get you to the promised land of zero defects. Watts simply told stories about how real people had succeeded in putting processes in place to improve results. His commitment was to the people that toil away in Cube Land day after day, trying to support their organizations with technology; the Dilberts of the world. Watts’ commitment was not to aggrandizing himself.

Great Management: Long before the Gallup organization published First Break All the Rules: What the World's Greatest Managers Do Differently (FBAR,) Watts wrote a little volume called Managing Technical Professionals. In it he lays out how to adapt and adopt our understanding of human psychology to bring out great performance in people. FBAR simply confirmed with extensive data what Watts had learned from his experience as a manager and leader. Whether you manage technical or non-technical people, it is still one of the best handbooks for day-to-day working with people. (Of course FBAR is a necessary resource too.)

So whether you're a techie who was touched directly or indirectly by Watts and his breakthroughs or whether you're just trying to be a good manager and leader, spend a little time investigating and learning from this giant...he did change the world for the better...and the world is a little diminished today with his passing. Luckily we can all access and learn from his legacy which will be with us a long time.

Farewell, Watts. We will miss you and we will never forget you and what you have done for us.

* * * * *
(C) Rebecca Staton-Reinstein, President, Advantage Leadership, Inc.
Author: Conventional Wisdom: How Today's Leaders Plan, Perform, and Progress Like the Founding Fathers

It's never to early to destroy a good thing!

You know the old cliche: A new broom sweeps clean.
It barely took a year for the new CIO to destroy a system that was generating millions of dollars in cost reductions and avoidance...
...You've heard the old joke:

The new CIO arrives to replace the departing one. The old CIO says, "Listen, I gotta go...but I left you 3 envelopes to guide you when you run into trouble. Good Luck!" Of course, the new CIO enjoys a little honeymoon and is busy over promising and under delivering. But a few months in, the CIO is in trouble until remembering the envelopes. So the CIO opens the first envelope and the message reads, "Blame your predecessor." So the CIO proceeds to demonstrate how every problem, issue, and complaint can be laid directly on the previous CIO. This works very well for about 6 months but pressure begins to build again. The CIO remembers the envelopes and decides to open the second one. "Reorganize." Great idea! So the reorgs begin and chaos reigns for another 6 months so nothing can be blamed on the current CIO -- after all, you expect a little disruption after a reorg and the new organization will be SOOOOO much better. Eventually the dust settles and complaints begin coming in from every direction. The CIO is in big trouble so opens the last envelope. "Prepare 3 envelopes."

This joke reflects reality all too often. Many studies show that the average lifespan of a CIO is about 18 months. I first observed this phenomenon over 20 years ago at a large company. where I worked. After putting in place a complete system to improve software results and reaping the benefits of demonstrable ROI, when the company hit a rough patch, he systematically dismantled everything that worked. A few months later he was gone and a few months after that other bad business decisions led to the company's demise and absorption by a competitor.

If this were an isolated story, I wouldn't bother to tell it. But I have seen it first hand and read about it over and over. Here's the most recent tale of woe. Beta Company assessed its situation and realized it needed some improvements in the way it tested software. It assigned an existing group to remedy the situation, which it did over the next two years. The results were major improvements to the bottom line. Testing effectiveness improved dramatically resulting in a significant drop in defects found in production. The difference was documented in the millions of dollars.

With effective dynamic testing firmly established, the team turned to static testing and began implementing Formal Inspections. Once again the results were dramatic. In one side-by-side comparison of two very similar projects (same Project Manager, similar scope, most of the same project team) the project with the Requirements Inspections not only came in at a dramatically lower price tag but avoided over $500,000 in defect costs. Overall, the

team's efforts demonstrated over $6 MILLION in savings.

So why doesn't this story have a happy ending? The New Broom Syndrome. In the midst of all this progress, the company got a new CIO and the economy took a nose dive. The team took some cuts like everyone else and lost a few key players...BUT it survived and continued making improvements and reporting consistent ROI and bottom-line results. The CIO of course blamed the economy and his predecessor for any and all problems. When that stopped working, he reorganized several times. The last one has these quality improvement functions reporting to the area in charge of the delinquent processes -- the fox is licking his chops as he saunters into the hen house.

The inevitable results will hit the papers just as they do in all these situations. Good people will be out on the streets. Quality will have a bad name around the company for a few years. A new CIO will enter the scene and get 3 envelopes from the departing one...

It doesn't have to be the same old story. Here's the secret: Leadership.

That's it. A leader will look at the data and the processes and manage by fact and process. A leader will face adversity and look at the true value each process contributes. A leader will make decisions strategically to fulfill a clear mission. Which are you? A strategic leader or a tactical firefighter? 18 months and 3 envelopes or...

***** ***** *****
Rebecca Staton-Reinstein, President, Advantage Leadership, Inc.

More on Strategic Planning, establishing QA, getting great requirements: http://www.advantageleadership.com/

More on Strategic Leaderhip: http://www.conventionalwisdomcenter.com/

Listen to a free webinar on how to turn defects into dollars: http://www.iist.org/freewebinars/descriptions/Testing_Improvement_Story_Turning_Defects_RebeccaStaton.php

Improving S/W Quality in 2008

A new year and time to plan for your success in 2008. No matter where you fit into the IT/SW world -- CIO, developer, tester, PM, QA manager, Director -- you know one thing: You are going to be asked to do even more in 2008 than in 2007 AND you're going to be asked to do it with even fewer resources. If the mantra used to be 'do more with less' it's become 'do EVEN MORE with EVEN LESS!'
So how do you deal with the escalating load without collapsing under the weight? Well, there's one formula that's worked for decades (or even millennia if you read Dr. Joseph Juran.) That's the simple directive to improve quality and you improve productivity. It's simple really. Spend less time on rework and you free up time to be more productive AND, here's the bonus, more creative.
Think about it. We get paid to do it wrong...we get paid to find the wrong stuff...and we get paid to fix it! Now this may sound like a formula for permanent employment for developers and testers but it's a false hope. Executives look at the escalating costs and broken promises and outsource to those who say they can do better. But then the cycle begins all over again...
Since the real problems lie in our chronic lack of robust processes that can guarantee good results, the outsourcers experience the same problems we do: unrealistic schedules and budgets finalized long before we understand the customers actual requirements and true scope of the work, lousy requirements gathering and planning skills, poor or non-existent robust design, development under these sub-optimal condition and constricted test cycles and inadequate use of test tools and automation. So the results are predictable...
No one is truly happy...In 2004 the Gartner Group reported that the world economy lost $500 Billion in failed software projects and of course it's only gotten worse since then. Oh, and that's the cost for the projects that went down in flames...it does NOT include all those sad projects that limp along, require heavy maintenance and burn trillions of dollars.
Not a happy picture to start the new year...very depressing...we've heard it over and over.
There is a better picture. You can make 2008 the year you start reversing these negative trends. Here are some simple steps that have proven themselves over and over.

STEP 1: Set a concrete quality policy and attendant goals for 2008.
These are not pie-in-the-sky or vague 'quality is good to have' types of goals. First you have to face the facts of what your current quality record actually is and base your policy and goal setting on that. What is your defect rate? What portion of your project budget is going towards actually finding and fixing defects (it's a lot more than just your testing budget and time.) What are your most expensive and frequent types of defects, consistently over the last year?
By the way, you can't just blame the developers. Studies show they produce less than 10% of the defects. Over half of the defects arise in the Requirements phase while the design process kicks in another 25%. Oh, and don't blame the testers for not finding them...Since schedules are usually unrealistic, test phase time is often cut so the testers do the best they can under very unfavorable conditions. Celebrate the fact that they find any defects at all!
As you continue your analysis, get to the root causes of the most pain-producing of your defects. Consistent root causes are found in flawed processes not flawed people who use the flawed processes.
Once you have found the root causes of the defects, you can now state some measurable goals for reducing them with concrete, measurable objectives with timetables to improve the processes and reduce the defects, thus reducing costs and increasing productivity.

STEP 2: Assign people to the analysis and improvement work and provide the time and money they need to do the job.
This is an investment that provides measurable ROI. You have the data from the analysis that shows the current situation. Compare that with the data once the processes are improved and in place. These types of improvement process do not have to be giant projects -- although they should be organized and tracked as projects. A knowledgeable team can often get things figured out quickly. What they need then is 'management support' -- that's a firm commitment to make the process changes that are necessary, authorize training on the new processes and enforce the use of the new processes.

STEP 3: Repeat.
The real secret is to take small chunks of work processes to improve -- don't strain your budget and resources with massive change efforts. Dr. W. Edwards Deming's formula for improved quality works: PLAN - DO - CHECK - ACT. Continuous improvement, one process at a time can fit into the tightest budget...IF THERE IS LEADERSHIP WILL.

That's the secret formula. I know you have seen and heard it before. It works...It has a track record...You can make it work in your organization.
Why not make 2008 the year that you finally break the back of those nasty defects that blow your schedule and budget and infuriate the customers? Secret number two? Once you start improving, don't stop. Keep the momentum going. That's the formula for long term success.

A final note: What if you're one of those folks near the bottom of the food chain and don't have the 'means' to improve your processes? Think again. Look at your individual processes. Write them down and look for ways you can make your own processes more efficient and predictable...things you have control over. Just keep track of your changes and results. Talk to your peers and show them how they can make their jobs easier...build a little momentum and demonstrate your results (in terms of money and time) and then you can get management's interest in doing something more formal. What's the alternative...more misery and frustration? Not the way you want to spend 2008? Continuous Improvement Rocks!