NEWS AT SEI
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:
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.
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.
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.
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.
R. Callison and M. MacDonald. Bibliography of the Personal Software Process (PSP) and the Team Software Process (TSP), SEI Special Report, 2008.
Watts Humphrey. Watts New, the Collected Columns of Watts Humphrey, SEI Special Report, 2008.
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.
For more information
Please tell us what you
think with this short
(< 5 minute) survey.