Analysis of the CMM, PSP, and TSP

This post is part of my series on organizing “between and beyond.” Other posts are here. The purpose of this post is to explore the history and key assumptions of Watts Humphrey’s Capability Maturity Model (CMM)^®,¹ Personal Software Process (PSP)^SM,² and Team Software Process (TSP)^SM.³ The analysis is summarized here.

Background
My first encounter with the CMM and the PSP was in 1996. I subsequently became an authorized PSP instructor and certified TSP coach in 2002. I presented a paper⁴ at the 2004 (Second Annual) TSP Users Group Conference in September 2004. This means that I have personal experience of both the PSP and TSP.

History
The development of the CMM started in the mid 1980s with the development of the first SEI process maturity questionnaire. CMM v1.0 was released in the early 1990s. Watts Humphrey developed the PSP in the mid 1990s, followed by the development of the TSP at the end of the 1990s. Three Process Perspectives: Organizations, Teams, and People is a very interesting paper by Watts Humphrey,⁵ where he provides his personal views and perspectives on process improvement during 20 years. This includes the original design of the CMM, and the introduction of the PSP and TSP. I review this paper in this post with a focus on Watts Humphrey’s key assumptions.

Objectives
Watts Humphrey’s original objective with the CMM was “to build disciplined and motivated software teams that could consistently and predictably produce large and complex programs that were essentially defect free.”⁶ Humphrey’s objective with the PSP was “to see how engineers would work if they applied all the principles of CMM level 5 to their personal work.”⁷ The PSP shows “[software] engineers how to define processes; how to use a defined process; how to plan, measure, and track their work; and how to measure and manage quality.”⁸ And, finally, Watts Humphrey’s objective with the TSP was to provide “the environment needed for teams to consistently follow the PSP disciplines.”⁹

Assumptions
Here are the assumptions which I have identified in Watts Humphrey’s paper (in italics) together with my comments:

1. Quality can only be improved by improving the process that produces that product. This assumption is based on experiences from IBM’s semiconductor facility in Burlington. Quality has to be built in during development and production, since it’s not possible to test and repair chips at the end of the line. The IBM Burlington facility would have been closed unless it could show significant cost improvements. A take away, real improvements happen if something important is at stake.
2. Software development is to precisely define human problems so that they can be solved by machines. If we don’t master the technology, industrial growth will be stunted and human progress constrained.¹¹ My question is whether human problems really can be “precisely” defined? We live in a complex world. And as Kenneth E. Boulding once said, “Anyone who believes in indefinite growth in anything physical, on a physically finite planet, is either mad or an economist.”¹²
3. The principal assumption is that the process an organization uses in the future is much like what has been done in the past. If the organization plans to change the process, it should describe it.¹³ This is based on the assumption that defined processes leads to product quality. It is also based on the assumption that the organization controls personal practices with its processes.
4. The first step in managing an operation is to develop plans and only make commitments when you have plans and the staff to do the work.¹⁴ This sounds as, and is, upfront planning, but the TSP also acknowledges the need for re-planning as needed. The re-planning is done together with the staff doing the work. The first TSP team I coached ended up doing a long-term detailed plan in their first TSP launch. This was wasted effort, but the team was afraid of making a commitment unless it had done a thorough planning. The management in the organization was based on fear. However, this is not a process problem, but a question of values. Management by fear is very destructive!¹⁵
5. Teamwork practices and personal disciplines required for quality work are almost entirely issues of how.¹⁶ I’d say “personal disciplines” almost entirely are an issue of motivation. Why are we doing this? Is it really important?
6. Engineers will not change the way they work without very specific guidance.¹⁷ I think that engineers will change without “very specific guidance” if they have very good reasons to do so.
7. People need to use a defined process and plan, track, and measure their work.¹⁸ What if the “defined process” is dynamic and the process steps are dynamic, i.e., repeating the step will not produce exactly the same result? I will come back to this.
8. Using a defined process makes it possible to consistently produce quality products on predictable schedules.¹⁹ What if the process which produces quality products isn’t a “defined process”? Again, I will come back to this.
9. Early defect reductions reduce project test times.²⁰ This is my experience too!
10. The PSP is not just a couple of new techniques, it changes the way engineers develop programs.²¹ This is both true and false. PSP strengthened some of my good habits. I got, for example, data on how effective it was to print the code, take a cup of coffee, and review the code. But I never changed my personal coding guidelines to make it easier to automatically count the lines of code.
11. Disciplined behavior is not normal or natural for most people.²² It depends on what is meant by disciplined. I think this statement is related to process discipline. I don’t consider CMM level 5 behavior “normal”. It’s most unnatural. The point isn’t process discipline (this is heresy from a former TSP coach), but to get early feedback on the work being done. This enhances learning and also enables early defect removal.
12. The team is the most powerful tool mankind has devised for doing large-scale intellectual work.²³ Yes, teamwork is powerful, but I don’t view it as a “tool” devised by mankind. It’s part of being human.
13. Teams need to make their own plans, manage their own work, and be committed to producing quality products.²⁴ Absolutely! Those who are doing the work need to plan and manage it themselves. And producing non-quality products is demoralizing.
14. Managers need to know how to guide, support, and motivate teamwork.²⁵ People motivate themselves! Managers need to know how to avoid demotivating teamwork.
15. For teams to use the TSP managers must require that they do so.²⁶ This sounds coercive. Why don’t people use the TSP? Is it because they are “undisciplined” or is it for some other reason?
16. To do quality work, people need detailed plans and defined processes.²⁷ People are rarely willing to take the time to define a complex process, even when they know how to do so.²⁸ There must be a reason why people don’t do what “they know how to do.” A “complex process” is not a “defined process”. I’ll come back to this.
17. The biggest single problem with the TSP is training.²⁹ No, I don’t think training is the problem. There are deeper problems.
18. Method is critical and the disciplined practice of sound methods is the only way to learn to do consistently high quality work.³⁰ It takes time to overcome years of bad habits and to provide compelling evidence that sound methods work.³¹ Is it really true that people avoid using “sound methods” because they are “undisciplined” and have “bad habits”? What if the “sound methods” are not so “sound”? What if the key assumptions are incompatible with the reality?

Incompatibilities
I have, as already mentioned, personal experience of both the PSP and TSP. Initially, I took Watts Humphrey’s arguments at face value. Over the years I became increasingly uncomfortable. It’s a process which took several years and continues to this day. Here are the two main incompatibilities, as I see it, in the CMM, PSP, and TSP:

• Personal practices are largely independent of organizational processes: High process maturity (level 5) is said to produce major quality and productivity benefits.³² But Watts Humphrey also says that “personal practice” doesn’t change “appreciably between [CMM] levels 1 and 5.”³³ Humphrey writes that, “Personal practices are largely independent of maturity level.”³⁴ He has “seen sound personal practices in low maturity organizations and poor personal practices in high maturity organizations.”³⁵ In other words, organizational processes are largely irrelevant to what people actually do.
• Defined processes are not appropriate for intellectually intensive work: Ken Schwaber tells the story about how he met process theory experts at DuPont in 1995:
  • They told him that “systems development had so much complexity and unpredictability that it had to be managed by a process control model they referred to as “empirical.””³⁶
  • They said that systems development is “an intellectually intensive business that required too much thinking and creativity to be a good candidate for the defined approach.”³⁷
  • They were “particularly amused that the tasks were linked together with dependencies, as though they could predictably start and finish just like a well defined industrial process.”³⁸
  • They told him that the “empirical model of process control, on the other hand, expects the unexpected. It provides and exercises control through frequent inspection and adaptation for processes that are imperfectly defined and generate unpredictable and unrepeatable outputs.”³⁹
  • They thought that we, as systems developers, were “wasting our time trying to control our work by thinking we had an assembly line when the only proper control was frequent and first-hand inspection, followed by immediate adjustments.”⁴⁰

Conclusions
I find these two statements by Watts Humphrey and Ken Schwaber truly remarkable! And I think these two statements hold clues to the search for a “deeper order” or an “organizing beyond.” Here are my own observations:

• The CMMI is a successor of the CMM. I participated in a CMMI appraisal in 2012. The CMMI requires policies. My observation was that only one third of the people asked could answer whether there were any policies, although the department manager had communicated the policies at several department meetings. The policies were also put on a wall. In other words, the policies were largely irrelevant – and yet, people did their work!
• The PSP uses statistical process control, but I don’t think my personal software process ever was under statistical process control. I took the PSP training a second time to become a PSP trainer. Although I knew what to expect, and did my very best, I really didn’t have full control. I suspect my PSP students felt the same. I remember thinking when I saw some student data: Oh, that blew your statistics into pieces!

As a former PSP trainer, I’d like to propose an experiment. It would have been really interesting to let software engineers solve the ten exercises in the PSP training, but without using the PSP. The only thing required would be to measure how much time is spent in fixing the defects, and the total development time per exercise. My hypothesis is that the course participants would show similar improvements during the training as in the ordinary PSP training. Especially, if the participants were invited to use code reviews!

Notes:
¹ Capability Maturity Model and CMM are registered in the US Patent and Trademark Office. The Capability Maturity Model (CMM) is a development model. The term “maturity” relates to the degree of formality and optimization of processes, from ad hoc practices, to formally defined steps, to managed result metrics, to active optimization of the processes. The CMM was first published in 1988 and as a book in 1989. See Watts S. Humphrey, Managing the Software Process (SEI, 1989-01-01).
² Personal Software Process and PSP are registered service marks of the Carnegie Mellon University. The Personal Software Process (PSP) is a structured software development process that is intended (planned) to help software engineers better understand and improve their performance by tracking their predicted and actual development of code. The PSP was created by Watts Humphrey to apply the underlying principles of the CMM to the software development practices of a single developer. The PSP gives software engineers the process skills necessary to work on a TSP team. See Watts S. Humphrey, A Discipline for Software Engineering (SEI, 1994-12-31).
³ Team Software Process and TSP are registered service marks of the Carnegie Mellon University. The Team Software Process (TSP) provides a defined operational process framework that is designed to help teams of managers and engineers organize projects. The TSP is intended to improve the levels of quality and productivity of a team’s software development project, and to help them meet cost and schedule commitments. See Watts S. Humphrey, Technical Report: The Team Software Process (TSP) (SEI, November 200), (accessed 2016-08-02).
⁴ Karen Smiley, Jan Höglund, Laurie Williams, TSP-EF Proposal: A Team Software Process^SM Evaluation Framework (September 2004).
⁵ Watts S. Humphrey, Three Process Perspectives: Organizations, teams, and People (Kluwer Academic Publishers, Annals of Software Engineering 14, 2002), pp. 39–72.
⁶ Ibid., p. 52.
⁷ Ibid., p. 54.
⁸ Ibid., p. 58.
⁹ Ibid., p. 59–60.
¹⁰ Ibid., p. 43.
¹¹ Ibid., p. 45.
¹² See quote by Kenneth E. Boulding, Goodreads, (accessed 2016-08-02).
¹³ Watts S. Humphrey, Three Process Perspectives: Organizations, teams, and People (Kluwer Academic Publishers, Annals of Software Engineering 14, 2002), p. 46.
¹⁴ Ibid., p. 47.
¹⁵ The senior manager of this TSP team managed by fear. He had a global role in an international organization. I later learned that the ‘best’ project manager in another country resigned because of him.
¹⁶ Watts S. Humphrey, Three Process Perspectives: Organizations, teams, and People, (Kluwer Academic Publishers, Annals of Software Engineering 14, 2002), p. 52.
¹⁷ Ibid., p. 53
¹⁸ Ibid., p. 54.
¹⁹ Ibid..
²⁰ Ibid., p. 58.
²¹ Ibid..
²² Ibid., p. 59.
²³ Ibid., p. 60.
²⁴ Ibid..
²⁵ Ibid..
²⁶ Ibid., p. 61.
²⁷ Ibid., p. 62.
²⁸ Ibid..
²⁹ Ibid., p. 63.
³⁰ Ibid., p. 66.
³¹ Ibid..
³² Watts S. Humphrey, Managing the Software Process (SEI, 1989-01-01), p. 11.
³³ Watts S. Humphrey, Three Process Perspectives: Organizations, teams, and People, (Kluwer Academic Publishers, Annals of Software Engineering 14, 2002), p. 53.
³⁴ Ibid..
³⁵ Ibid..
³⁶ Ken Schwaber & Mike Beedle, Agile Software Development with Scrum (Prentice Hall, 2002), p. 24.
³⁷ Ibid., p. 25.
³⁸ Ibid..
³⁹ Ibid..
⁴⁰ Ibid..

Related posts:
Organizing in between and beyond posts