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
- to determine how software work should be done
- 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
To address these personal and team issues, we next developed the PSP
and TSP, and the results have been truly extraordinary. Consider the
- 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
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.
- 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.
- 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.
- 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
- 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
- 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.
R. Callison and M. MacDonald. Bibliography of the Personal Software Process (PSP) and the Team Software Process (TSP), SEI Special Report, 2008.
Mary Beth Chrissis, Mike Konrad, and Sandy Shrum. Guidelines for Process Integration and Product Improvement, 2nd Edition
Reading, MA: Addison Wesley, 2007, p. 278.
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.
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
This article is intended
to stimulate further
discussion about this