New Priorities



Watts S. Humphrey

This library item is related to the following area(s) of work:

Process Improvement

This article was originally published in News at SEI on: July 1, 2008

This column has now run for 10 years, and I have decided that it is time to change its focus. I have enjoyed the privilege of sharing my thoughts with you but have concluded that 10 years is long enough for this particular way of discussing software issues and feel that now is the right time to present new ideas and different viewpoints. I say more about my specific ideas and plans at the end of this column.

In reviewing the 40-some columns I have produced for SEI Interactive and later news@sei in the last 10 years and the 17  monthly columns I produce for an on-line journal (ObjectCurrents ) run by Bob Hathaway in 1996 and 1997, I have been struck by several thoughts. The first and most obvious reaction is how little has changed. My very first column in January 1996 was titled the “The Changing World of Software.” It talked about the truly abysmal state of software practice and how our customers seem to tolerate this poor performance without a whimper. What disturbs me the most about this first column is that I could have written it 30 years ago or last week. While a lot has changed for software technology, and we have learned a great deal about software processes and how effective they can be if properly designed and used, our performance as an industry is still just about as bad as ever. Further, the way we teach our computer professionals has not materially changed, at least not by enough to improve industrial performance.

After my initial column on the changing world of software, the next four were anecdotes about software issues followed by an 11-column series on the PSP PROBE estimating method. At the time I had just completed my PSP research and was planning to devote my subsequent columns to describing the various PSP methods. Unfortunately, the ObjectCurrents journal shut down in May of 1997, so that ended my first series of 17 columns.

About a year later, in June 1998, the SEI asked me to write  a quarterly column for a new on-line publication, SEI Interactive, with the column to be called “Watts New.” I have now completed 10 years of these columns and have covered a lot of territory. In reading them over, I find that they are all just as pertinent today as they were when I wrote them. The only significant difference is that, during much of this time, we were just developing the Personal Software Process (PSP) and Team Software Process (TSP) and gathering data on their use in industry. While I was convinced that these methods were revolutionary, I couldn’t prove it, so my columns tended to be more abstract with a primary emphasis on principles and methods.

We now face a different situation. Ten years ago, the PSP and TSP methods were new and little was known about them. While the PSP and TSP are not yet widely used, their use is growing and there is now a substantial body of literature about them [Callison 2008]. In this 10-year period, I have published many  technical papers, 57 columns, and 7 books [Humphrey 2008]. There is also a growing literature by industrial and academic users who describe their experiences and findings regarding TSP use. Now that a lot has been written about the subject and there is a growing body of evidence that they are highly effective, at least when properly used, it is time to reassess the situation and decide what is needed next.

When I retired from IBM 22 years ago, I was concerned about the poor state of the software industry, and I decided to dedicate my efforts to transforming the world of software. I made what I called an outrageous commitment to fix the world’s software problems. I then joined the SEI and formed the Process Program. At that time, we faced two major challenges:

  1. to       determine how software work should be done
  2. to get       the world to do software work that way

In the intervening years, we have made a great deal of progress with the first challenge and a modest amount of headway with the second. Regarding the first challenge, we have come a long way, but it would be presumptuous to say that we now have the last word on how software work should be done. However, we do know enough to enable software organizations to consistently and predictably deliver quality software products. That is an enormous advance. With CMMI, we have shown that management has a key role to play in the software process and that, when management issues are properly addressed, organizational performance improves. As a by-product of the CMMI work, however, we have also learned that changing the practices and behavior of the managers is not enough. Unless we address the way the individual software developers and their teams work, we cannot achieve our long-term objectives.

To address these personal and team issues, we next developed the PSP and TSP, and the results have been truly extraordinary. Consider the following facts.

  • Microsoft has invested about $3,000,000 to introduce TSP into its IT organization. Microsoft has trained about 1,000 software developers in PSP and now has data on more 200 TSP projects. Because of improved product quality and more predictable schedules and costs, Microsoft estimates that TSP has saved them a total of $84,000,000 to date.
  • Intuit has introduced TSP into its largest division and currently does about 60% of its development work with this method. Because of improved product quality, they report that the number of customer calls to their help lines has declined by 30%. This is a reduction of 800,000 calls a year, and each call costs them $25. The total saving from this source alone is thus $20 million a year.
  • Vicarious Visions, a division of Activision, introduced TSP because the quality of engineering work life had declined so much that turnover reached 17% a year. They now report that their experienced engineers, once they have worked on a TSP project, refuse to work any other way.
  • Softtek, the largest software company in Latin America, reports that the engineering turnover on their TSP teams is one quarter of that on their other teams.

With results like these, you would think that everybody would be jumping onto the TSP bandwagon, but that is not the case. For example, even though Microsoft’s IT organization has shown that they can save $84 million from a $3 million investment in TSP, none of Microsoft’s product development groups have adopted TSP. How can this be?

Lest I sound critical of Microsoft, I assure you that they are not unique. Every major corporation that has introduced TSP has had a similar experience. Unless the introduction effort started at the top of the organization, adoption did not spread. Somehow, everybody seems blind to innovations made by other people or groups, even within the same company. What is most surprising is that this includes many of the large Department of Defense contractors and other organizations that have been rated at CMMI Maturity Level 5.

This is most surprising because one of the two principal requirements to be rated at CMMI Level 5 is the Organization Innovation and Deployment (OID) process area. This area requires that Level-5 organizations look for promising incremental and revolutionary improvement opportunities both within and outside of their organizations, and that they quantitatively evaluate these opportunities for potential use within their organizations. To quote from CMMI [Chrissis 2007]:

The purpose of the Identify and Analyze Innovations specific practice is to actively search for and locate innovative improvements. The search primarily involves looking outside the organization.

In all the years that we have been working on TSP, we have yet to have any CMMI Level-5 organization come to us for the data needed to conduct such an evaluation. This can’t be because they have never heard of TSP. I routinely give talks at major conferences, including the SEPG conferences in the United States and other parts of the world, and I often ask how many people have heard of TSP. While 10 years ago, very few hands went up, today more than half of the people in the audience have heard of TSP. This includes audiences in Australia, Chile, China, Hungary, India, and all over the United States. Clearly, the major software process-improvement issue faced today is the second challenge.

Getting the world to do software  work in the best known way.

Based on the data we have seen to date, that means using TSP. Depending on whom you talk to, this statement will likely get reactions like the following.

  • We are only at CMMI Level 2 and need to get to Level  3 before trying TSP.
  • We use Agile methods so we can’t adopt TSP.
  • We just started to use RUP so TSP is not  appropriate for us.
  • We use Function Points and TSP only uses LOC, so  we can’t change.

These views are all based in misinformation. TSP has been used successfully by organizations at every CMMI maturity level, and TSP is used by many groups that use Agile methods, including Scrum and XP. Similarly, RUP is completely consistent with TSP, and there is no reason not to use Function Points in estimating TSP jobs. TSP was designed to be language, method, and environment independent. It adds a family of measurement, planning, tracking, and quality-management practices that are not currently used by any of the popular software methods, so it does not conflict with any of them. It merely requires that the developers and their teams do some things that they do not now do.

Based on the results we have seen to date, it is clear that TSP use will grow but that the rate of this growth will be very slow. While we certainly have to continue doing what we have been doing, when you get to be my age, you would like to see results in less than the 10 to 20 years that our current rate of progress implies. This problem, however, is not new. W.E. Deming struggled for years to convince U.S. industry to adopt his well-demonstrated quality methods. Unfortunately for the U.S. auto industry, the Japanese adopted Deming’s methods first. Now, Toyota is within a hair of becoming the largest automaker in the world, and it is already the most profitable.

So is there any hope that we can accelerate the rate of TSP  adoption? I believe that there are five possible avenues.

  1. Convince the computer science and software engineering academic communities of the effectiveness and essential nature of TSP methods. While this community could be enormously helpful in convincing the world that TSP is the right way to go, I give this strategy very low odds. Based on what we have seen to date, the academic community changes even more slowly than industry. This does not mean that it could not change, but that it is not likely to happen soon.
  2. Get the customers to demand that their software suppliers adopt TSP. While this would be nice, it is not likely to happen until a very large number of customers have experience with TSP, and it is obvious to everyone that it is the right way to go.
  3. Convince the government to establish a software industrial improvement program based on TSP. In the United States, such a strategy is a non-starter, at least for now. Outside of the United States, however, the situation is quite different. When organizations are hungry for business, they are much more receptive to innovative new methods.
  4. Get the U.S. government to mandate TSP use, at least as a prerequisite for DoD software development contracts. While this approach was very effective in getting CMMI adopted by the major DoD suppliers, it has a serious downside. The problem is that if the government mandated TSP as a prerequisite for software development contracts, that would be motivating organizations to do something they didn’t believe in (adopt the TSP), in order to get something they wanted (a DoD contract). While this approach can work when you have a foolproof way to determine if someone is using TSP properly, there is an enormous motivation to cheat, which could easily lead to complications.
  5. Find some better way to communicate the benefits of TSP to senior corporate executives. While I do not now see a clear way to do this, I do have ideas about possible avenues to explore.

In summary, I have concluded that the most important thing to do right now is to broaden the understanding of  TSP’s capabilities and benefits. The approach I have selected is to continue editing these columns but to invite members of the TSP team at the SEI to contribute the material. Also, where there are opportunities, I hope that some of the columns will be co-authored by TSP users. We have learned a great deal over the last 15-plus years, and these columns can provide a convenient and easy way to quickly communicate significant new results to the broader software community. So, in conclusion, that is why I have decided to refocus this column. Please stay tuned, and continue to drop me notes on TSP-related topics you would like to see addressed.


[Callison 2008]
R. Callison and M. MacDonald. Bibliography of the Personal Software Process (PSP) and the Team  Software Process (TSP), SEI Special Report, 2008.

[Chrissis 2007]
Mary Beth Chrissis,  Mike Konrad, and Sandy Shrum. Guidelines for Process Integration and Product Improvement, 2nd Edition  Reading, MA: Addison Wesley, 2007, p. 278.

[Humphrey 2008]
Watts Humphrey. Watts  New, the Collected Columns of Watts Humphrey, SEI Special Report, 2008.


About the Author


Watts S. Humphrey founded the Software Process Program at the SEI. He is a fellow of the institute and is a research scientist on its staff. From 1959 to 1986, he was associated with IBM Corporation, where he was director of programming quality and process. His publications include many technical papers and 11 books. His most recent books are Winning   with Software:  An Executive Strategy (2002), PSP: A Self-Improvement   Process for Software Engineers (2005), TSP, Leading a Development   Team (2006), and TSP: Coaching Development Teams (2006). He holds five U.S. patents. He is a member of the Association for Computing Machinery, a fellow of the Institute for Electrical and Electronics Engineers, and a past member of the Malcolm Baldrige National Quality Award Board of Examiners. He holds a BS in physics from the University of Chicago, an MS in physics from the Illinois Institute of Technology, and an MBA from the University of Chicago. In a White House ceremony in 2005, President George W. Bush awarded him the National Medal of Technology.


The         views expressed in         this article are the         author's only and do         not represent directly         or imply any official         position or view of         the Software Engineering         Institute or Carnegie         Mellon University.         This article is intended         to stimulate further         discussion about this         topic.

Please note that current and future CMMI research, training, and information has been transitioned to the CMMI Institute, a wholly-owned subsidiary of Carnegie Mellon University.

Find Us Here

Find us on Youtube  Find us on LinkedIn  Find us on twitter  Find us on Facebook

Share This Page

Share on Facebook  Send to your Twitter page  Save to  Save to LinkedIn  Digg this  Stumble this page.  Add to Technorati favorites  Save this page on your Google Home Page 

For more information

Contact Us


Help us improve

Visitor feedback helps us continually improve our site.

Please tell us what you
think with this short
(< 5 minute) survey.