improvement. These methods worked for or-ganizations and for large projects, but it was not clear how they would work for individ-uals, particularly those doing creative engi-neering work. While the principles seemed applicable, I was trained as an experimental physicist and thus needed to understand how a process worked at the atomic level before I could feel I really understood it.
During my early PSP research, I was sur-prised by the insight I gained from using a defined, planned, and measured personal process, not only for routine work, but for creative work as well. After completing my initial PSP research some years ago, I have devoted the ensuing years to getting these principles adopted by individual engineers, software organizations, and the academic community. The four articles on the PSP in this issue examine the topic from various perspectives, but the fundamental question they all address is essentially the same:
focus
The Personal
Software Process:
Status and Trends
Watts S. Humphrey, The Software Engineering Institute
W
hen I started to develop SEI’s Personal Software Process, I was
both looking for new processes and methods and trying to
satisfy my curiosity. I wanted to answer this question: Would
process improvement principles work for individual software
professionals? I had spent over 30 years in engineering and engineering
management before I started working on software quality and process
How can process improvement help indi-viduals be more effective while doing intel-lectual work?
PSP Overview
PSP development is based in part on the quality management principles of W. Ed-wards Deming and Joseph M. Juran.1,2In a
more general sense, these methods follow principles that Frederick Winslow Taylor in-troduced over 100 years ago.3 Taylor
in-vented what has been variously called task analysis, scientific management, or indus-trial engineering. He was the first to view manual work as something to analyze and improve, and the first to gather and analyze data to improve the performance of manual tasks. Peter Drucker asserts that Taylor’s methods made factories possible and that they were largely responsible for the 50-fold increase in labor productivity over the last 100-plus years.4
In his insightful book, Management
Challenges for the 21st Century, Drucker
describes the similarities and differences between manual and intellectual work.4
The principal similarity is that both kinds of work involve sequences of tasks. Even though manual and intellectual tasks are significantly different, we can measure, ana-lyze, and optimize both and thus apply Tay-lor’s principles equally well.
The principal difference between manual and intellectual work is that the knowledge worker is essentially autonomous. That is, in addition to deciding how to do tasks, he or she must also decide what tasks to do and the order in which to do them. The manual worker commonly follows a rela-tively fixed task order, es-sentially prescribed by the production line. So studying and improving the performance of intel-lectual work must not only address the most ef-ficient way to do each task but also consider how to select and order these tasks. This is essen-tially the role of a defined process and a detailed plan. The process defines the tasks, task order, and task measures, while the
plan sizes the tasks and defines the task schedule for the job being done.
Besides Taylor’s principles, the PSP also considers task selection, planning, and or-dering. It shows engineers how to use a de-fined, measured, planned, and quality-controlled process to improve personal per-formance. When they use the PSP, engineers plan their work, measure the work as they do it, and when done, analyze the measures to improve their performance.
We use a course and a textbook to teach engineers the PSP methods.5 The course
guides software professionals through 10 pro-gramming exercises that demonstrate how to apply project, process, and quality man-agement methods when writing module-sized programs. By completing the exercises and analyzing their data, the engineers can see how a defined and measured process helps them do better work. They cannot ar-gue that the PSP methods do not work for them, because they can see from their own data that they do.
In the PSP course, engineers learn what a defined process is and how to use one. They learn how to make estimates and plans, what data to gather, how to gather data, and how to use data. They also learn how to plan, measure, and manage the quality of their work. The PSP is not only designed for writing module-sized programs, it also teaches general skills that software engi-neers can use in most aspects of their work, from the initial requirements and system de-sign phases all the way through to final sys-tem test and delivery.
PSP Course Results
Because of the nature of the PSP course, the earliest evidence of its impact is from class data.6–8 In using these data, we must
know whether results are due to the course environment or the PSP material itself. Sev-eral published reports now show the PSP’s benefits. One study showed that students’ improvements during the PSP courses were large and statistically significant.6 Two
other articles showed that when engineers were PSP trained, their job performance im-proved substantially.9,10The four articles in
this issue add to this body of evidence. These data come from multiple studies, multiple PSP instructors, industrial and aca-demic courses, and a broad mix of
lan-One of the
most important
factors in
improving
worker
performance
is prompt
and explicit
feedback.
guages and engineering environments. One of the most important factors in im-proving worker performance is prompt and explicit feedback.11–13We designed the PSP
to provide this as an inherent part of the process. In fact, PSP practitioners often cite feedback as the reason for their conviction that the methods help them. So it is fair to say that the performance improvement shown by the PSP is at least partly due to the feedback the engineers get from their own data. Thus, the most pertinent ques-tions are, Are these results unique to PSP courses, are they general, and does the effect persist? So far, as the articles in this issue and other experience show, the answer to all three questions is yes.
Introducing the PSP
The Green–Hevner article provides useful guidance on introducing almost any new technology. It shows how to improve the ac-ceptance of new methods and indicates dam-aging actions to avoid. For example, they
note that practitioners will readily accept and adopt methods that help them reduce the complexity of their working processes. Further, for intellectual work like software, people will resist any attempt to force changes in the way they work. Finally, even new and attractive methods can be rejected if introduced in the wrong way or at the wrong time. The key message here is that software professionals are thinking people; they resent being ordered to do almost any-thing. If they are treated with respect and have a say in the changes that involve them, the results will be more successful.
More specifically on PSP introduction, there are various ways to attack the transi-tion problem. The approach taken by Mari-sio was to change the PSP process and train-ing to better fit what the particular organi-zation was willing to do. Although this approach has the advantage of initially overcoming user resistance, it has the disad-vantage of allowing the desires of unin-formed users to drive process design.
Be-The article by Xiamong Zhong, Nazim Madhavji, and Khaled El Emam, “Critical Factors Affecting Personal Software Processes,” examines the detailed behavior of the PSP process. The authors measured the performance of 53 students and used regression methods to identify the variables responsible for the productivity and quality results obtained. As far as I know, this is the first article to examine the detailed relationships among the many variables involved in software work. It demonstrates the opportunity for important research with students or profes-sionals who use the PSP. For example, by conducting studies of design methods, review techniques, language features, or tool functions, we could better understand how to develop software processes, tools, or methods to improve the performance of working engineers.
Two of the articles address the PSP’s use in industry. “An Ex-perience Report on the Personal Software Process” by Ja-gadish Kamatar and Will Hayes shows that the PSP, when properly used, can result in substantial improvements. On the first reported project, Kamatar and three PSP-trained col-leagues had only three system test defects for a product with 40,000 lines of code. Typical industrial system-test defect lev-els for such products range from 200 to 400. Kamatar also de-scribes the feedback provided by the PSP data and how he used it to improve product quality and estimating accuracy.
“Applying the PSP in Industry” by Maurizio Morisio describes the introduction of the PSP to an industrial organization. The
problems he encountered concerned training, process design, data privacy, paperwork, and data gathering. In addition, he faced a problem common to almost all technology transition ef-forts: management’s unwillingness to interrupt projects for long enough to completely train the engineers. In addressing these concerns, Marisio significantly changed the PSP process and course. As a result, the engineers used part of the PSP methods and obtained only limited benefits. However, the experiment provided useful insights, and the modified process appeared to provide some benefits. At least the engineers seemed to like the process, and the organization continues to use it.
“The Successful Diffusion of Innovations: A Guide for Soft-ware Development Organizations” by Gina Green and Alan Hevner examines the introduction of innovative IT technologies, using the PSP as an example. The authors find, not surprisingly, that engineers are more satisfied with a technology and are more likely to use it when they have a choice in selecting it. En-gineers also more readily accept technologies that improve their ability to predict the results of their work. In addition, the authors found that when programmers feel increasingly able to control the methods they use, their satisfaction and use of the methods actually decline. On reflection, this finding is consistent with PSP and the SEI’s Team Software Process experience: engi-neers will readily accept and use a precisely defined process as long as it reduces workplace confusion and helps them do their jobs.
cause users almost certainly do not have the training or experience to design a software process and its introduction method, poor results are likely.
Several other organizations have objected to the full 14 days of PSP training required for industrial introduction and have devised their own special four- to six-day courses. As Kamatar reports, when engineers receive only limited PSP training, they do not learn the methods sufficiently well to use them in practice. Similarly, several organizations have tried to use the PSP with little or no guidance or adaptation. While this has worked in two cases that I am aware of, generally the engineers soon stop using the PSP. The stated reasons were that the envi-ronment didn’t encourage PSP use, manage-ment didn’t support it, and the other engi-neers were not using it. Under these condi-tions, engineers generally find it difficult to continue to use the PSP.
We at the SEI have worked for the last five years on PSP introduction and have found results similar to those reported by Marisio and by Kamatar and Hayes. The training required is substantial, and organi-zations are often reluctant to make that large an investment. However, without proper training and support, the PSP methods gen-erally will not be used. Where PSP introduc-tion has failed, the fundamental problem has been that it was viewed as an engineering training program rather than as an organi-zation-wide process change.
PSP Training
Since training is such an important part of PSP introduction, it would be helpful to know how much training is required. While devel-oping and learning the PSP, I wrote 62 programs in Pascal, Object Pascal, and C++. I then devel-oped a course to teach these personal-process methods to others. I had hoped that others would learn much more rapidly than I had, so I only used 10 programming exer-cises in the PSP course. To date, our data show that the full PSP course
with 10 exercise programs has been effec-tive in teaching both students and working engineers how to use the PSP. From avail-able course data, however, it is also clear that the high rate of improvement during the course continues right up through pro-gram 10. Thus, additional exercises could be beneficial. Although some experienced PSP instructors have concluded that more exercises would help, we do not have data to support this conclusion.
At the opposite extreme, when engineers only complete six or seven PSP exercises, they generally do not learn the methods or use them afterwards. Perhaps most impor-tant, because partially trained engineers do not use the method properly, they cannot complete PSP learning on the job. However, as the three articles in this issue and others have found, even modest use of the PSP methods can be beneficial.9,14
Learning the PSP process appears to be fundamentally different from the way peo-ple learn other topics. With program-ming languages, for example, introductory courses usually teach programmers enough so they can start using the language. Then they can continue learning the more subtle aspects of the language as they use it on the job. We need to identify the level of fluency required before engineers will properly use the PSP in practice. Then they would pre-sumably become more competent with ex-perience. While the critical point where learning will continue is likely to be differ-ent for differdiffer-ent people, we at the SEI expect it will probably be at or very near the 10 ex-ercise programs in the current PSP course.
Another factor tends to help people learn a programming language but not the PSP. After taking an initial language course, working engineers generally have no choice but to use that language in their work. With the PSP, they can always choose to revert to their previous practices. This is a key chal-lenge of industrial PSP introduction and one of the reasons for the development of the Team Software Process.
Some Thoughts on the Future
Based on results to date, using a defined, planned, and measured personal process ap-pears to offer many benefits. Assuming that further experience confirms these early re-sults, we can expect the PSP to be widely
Where PSP
introduction
has failed, the
fundamental
problem has
been that
it was viewed
as an
engineering
training
program rather
than as an
organization-wide process
change.
adopted and used. From the experiments re-ported here and elsewhere, it is also clear that industrial introduction of the PSP will not be easy. To guide organizations through such a comprehensive change program and to facilitate industrial transition to and use of PSP practices, the SEI has developed the Team Software Process.10,15–17We at the SEI
have concluded that a team-based training and introduction strategy is both easiest to implement and most frequently effective for industrial organizations.
Presuming that the demand for skilled software professionals continues to increase, the most appropriate way to introduce the PSP would be through the educational sys-tem, just as with other professional disci-plines. Rather than having students first learn undisciplined practices and then un-learn them, we should introduce disciplined methods at the beginning of the curriculum. Some universities have started offering such courses, and preliminary results are promising.18–20 While several universities
are also teaching an introductory TSP course to student teams, no published re-sults are available. Additional informa-tion on the PSP and TSP is available at www.sei.cmu.edu.
Acknowledgments
I thank Dan Burton, Noopur Davis, Will Hayes, Don McAndrews, Julie Mullaney, and Bill Peterson for their helpful comments and suggestions during the preparation of this article.
References
1. W.E. Deming, Out of the Crisis, MIT Center for Ad-vanced Engineering Study, Cambridge, Mass., 1982. 2. J.M. Juran and F.M. Gryna, Juran’s Quality Control
Handbook, 4th ed., McGraw-Hill, New York, 1988.
3. F.W. Taylor, The Principles of Scientific Management, Harper and Row, New York, 1911.
4. P.F. Drucker, Management Challenges for the 21st
Cen-tury, HarperCollins, New York, 1999.
5. W.S. Humphrey, A Discipline for Software Engineering, Addison-Wesley, Reading, Mass., 1995.
6. W. Hayes and J.W. Over, “The Personal Software Process: An Empirical Study of the Impact of PSP on In-dividual Engineers,” Tech. Report CMU/SEI-97-TR-001, Carnegie Mellon Univ., Pittsburgh, 1997. 7. W.S. Humphrey, “Using a Defined and Measured
Per-sonal Software Process,” IEEE Software, Vol. 13, No. 3, May 1996, pp. 77–88.
8. P.M. Johnson and A.M. Disney, “The Personal Software Process: A Cautionary Case Study,” IEEE Software, Vol. 15, No. 6, Nov./Dec. 1998, pp. 85–88. 9. P. Ferguson et al., “Introducing the Personal Software
Process: Three Industry Case Studies,” Computer, Vol. 30, No. 5, May 1997, pp. 24-31.
10. D. Webb and W.S. Humphrey, “Using the TSP on the TaskView Project,” Crosstalk, Vol. 12, No. 2, Feb. 1999, pp. 3–10.
11. J.L. Dyer, “Team Research and Team Training: A State-of-the-Art Review,” Human Factors Rev., The Human Factors Soc., Santa Monica, Calif., 1984, pp. 286, 309. 12. H.M. Parsons, “What Happened at Hawthorne?”
Sci-ence, Vol. 183, Mar. 8, 1974, pp. 922–932.
13. R.W. Swezey and E. Salas, eds., Teams: Their Training
and Performance, Ablex Publishing Corp., Norwood,
N.J., 1992.
14. L. Prechelt and B. Unger, “An Experiment Measuring the Effects of Personal Process (PSP) Training,” IEEE
Trans. Software Eng., in press.
15. W.S. Humphrey, “Three Dimensions of Process Im-provement, Part III: The Team Process,” Crosstalk, Vol. 11, No. 4, Apr. 1998, pp. 14–17.
16. W.S. Humphrey, Introduction to the Team Software
Process, Addison-Wesley, Reading, Mass., 2000.
17. W.S. Humphrey, “The Team Software Process (TSP),” Tech. Report CMU/SEI-2000-TR-023, Software Eng. Inst., Carnegie Mellon Univ., Pittsburgh, Oct. 2000. 18. T.B. Hilburn, “PSP in Academia and Training,” Forum
for Academic Software Eng., www.cs.ttu.edu/fase. 19. L. Hou and J. Tomayko, “Applying the Personal
Soft-ware Process in CS1: An Experiment,” Proc. 29th
SIGCSE Tech. Symp. Computer Science Education,
ACM, New York, 1998, pp. 322–325.
20. W.S. Humphrey, Introduction to the Personal Software
Process, Addison-Wesley, Reading, Mass., 1997.
About the Editor
Watts S. Humphreyjoined the Software Engineering Institute (SEI) of Carnegie Mel-lon University in 1986 after 27 years at IBM. At the SEI, he established the Process Program, led initial development of the Software Capability Maturity Model, and introduced the concepts of Software Process Assessment Software Capability Evaluation, the Personal Software Process, and the Team Software Process. This year, the Watts Humphrey Software Quality Institute in Chennai, India, was named in his honor, and the Boeing Corporation presented him with an award for innovation and leadership in software process improvement. He holds five US patents and has published seven books, including A Discipline for Software Engineering;
Man-aging Technical People—Innovation, Teamwork, and the Software Process; Introduction to the Personal Software Process; and Introduction to the Team Software Process.
Humphrey holds graduate degrees in physics from the Illinois Institute of Technology and in business administration from the University of Chicago. He was also awarded an honorary PhD in software engineering by Embry Riddle Aeronau-tical University in 1998. He is an SEI fellow, a member of the ACM, an IEEE fellow, and a past member of the Malcolm Baldrige National Quality Award Board of Examiners.
