The misconception among many commercial software developers is that process discipline in software development (such as the CMM) is incompatible with fast-moving development processes such as XP. A similar misconception among many process-oriented people—CMM or otherwise—is that developing software quickly is tantamount to chaos. If these two views persist, they will keep excellent development teams from realizing the benefits of structured process improvement, and likewise keep larger organizations from looking at alternative development methods. [Glazer 2001]
The Capability Maturity Model (CMM) was developed by the Software Engineering Institute as a way to describe the maturity of a software organization’s development practices. People who practice agile development view the CMM as being the opposite of agile: ponderous, cumbersome, and antiquated. Process-oriented people look upon agile methods as being undisciplined and chaotic. However, from the standpoint of sustainable development, there is actually a great deal to learn from and draw on from both agile development and the CMM. As pointed out in the quote above, people who dismiss agile are missing the benefits of simple and powerful development methods, and people who dismiss the CMM are limiting their ability to implement organizational process improvements. In this Appendix, I will briefly describe the CMM and then show how the CMM and agile development complement each other.
The Software CMM [Paulk et al 1993] is a five-level model that describes good engineering and management practices and prescribes improvement priorities for software organizations [Paulk 2001]. The intent of the CMM is to provide areas of focus (called Key Process Areas or KPAs) for software organizations that have proven in many software organizations to lead to excellence in software development. The Software Engineering Institute also provides standard guidelines for assessment, so that a third-party assessor can evaluate an organization and produce a report that outlines the maturity of the organization’s processes. The combination of the CMM model and objective third-party assessments means that an organization can at any time have an understanding of its current capabilities plus the types of activities it must focus on to move to the next level. Hence, the CMM is intended to provide a general framework for planning and measuring the capability of a software organization. The CMM does not specify or mandate actual development processes, it merely specifies what to do in general terms.
The five maturity levels of the CMM and the KPAs associated with each level of maturity are shown in Table A3-1. CMM level 1 organizations are characterized by chaotic processes that require heroism to complete software projects. At the other extreme, CMM level 5 organizations have competence in all the KPAs, established processes, and are continually improving their processes.
Because the CMM does not specify the actual processes that should be used in software development, CMM 5 maturity does not necessarily equate with software quality or sustainability. It usually does, but that is more the result of the methods put in place by the people who designed the processes and their hard work. Also, in my experience at any large company, there is a great deal of variability in the quality of work between teams. Hence, CMM 5 is not a guarantee that the traditional code-then-fix method not used. I have worked with CMM 5 companies as subcontractors, and my experience is that while the majority of them produced excellent work, there were some groups that frankly shocked me with the poor quality of the work they produced.
Table A3-1. The Five Maturity Levels of the CMM and the KPAs Associated with Each Level of Maturity
Level | Focus | Key Process Areas |
|---|---|---|
5 Optimizing | Continual process improvement | Defect Prevention Technology Change Management Process Change Management |
4 Managed | Product and process quality | Quantitative Process Management Software Quality Management |
3 Defined | Engineering processes and organizational support | Organization Process Focus Organization Process Definition Training Program Integrated Software Management Software Product Engineering Intergroup Coordination Peer Reviews |
2 Repeatable | Project management processes | Requirements Management Software Project Planning Software Project Tracking & Oversight Software Subcontract Management Software Quality Assurance Software Configuration Management |
1 Initial | Competent people and heroics | |
Agile development and the CMM can co-exist. Since the CMM specifies the what (in terms of the KPAs) and is methodology neutral, agile development methods can be used as the method (the how) to achieve much of CMM process maturity. Also, if you’ve gotten this far in this book, it should be obvious that the claim that agile development does not require discipline is very much false. Agile development is hard work and requires a great deal of discipline.
The practices of extreme programming have been contrasted with the CMM KPAs in various articles [Glazer 2001] [Paulk 2001] [Bandaru 2004]. If you are interested, I highly recommend reading them. The conclusion reached by all these sources is that the extreme programming practices do offer a solution to most of the KPAs. Of the eighteen KPAs, six are largely addressed in XP, and five are partially addressed. In this book, I have consciously added practices such as configuration management, professional development, and business knowledge because they are implied in the agile literature, but required for sustainable development. As a bonus, they happen to also be called out as KPAs. Likewise, the principles of continual refinement and defect prevention turn out to be level 5 KPAs, and are thus of extremely high value to software organizations.
What I find particularly intriguing with agile development and the CMM is the role of the agile mindset in the implementation of development processes. As I have personally discovered, an organization can only be as agile as its least agile part. Furthermore, since software teams must by their nature be cross-functional, if one functional part of the team is not agile, then the entire team will feel the effects. Here are some examples that I have personally seen:
Product management and/or engineering management that wants to completely specify all the features that make up the next software release before any code is written. Sometimes it is really hard for people to accept that they can’t predict what the next release will contain, even if that release date is a year out or more. If these feature lists are followed religiously, there is no room for agility.
A marketing department that needs a large amount of lead time to write the marketing material for the next release. This means it will be hard to add features that are important to users late in a release cycle, and this limits agility.
A documentation group that is used to working on documentation after all the features are done. If it takes a long time to write the documentation, then documentation is going to continually lag development and slow it down.
A software testing team that is heavily relied upon by developers to find defects (i.e., a defect detection culture). Invariably, the testing group will become a bottleneck and will also be frustrated by the poor quality of the product given to them to test.
Bizarre manufacturing policies that dictate, for example, that physical CDs must be produced for all releases, that a minimum inventory must be maintained, and that every new release must involve new CDs for example, electronic distribution and the Internet are not utilized or are thought of as secondary to the CDs. Agile products must ship regularly; if each shipment costs money, it may be easier to question the frequent releases than to question the silly practices that cause the high costs . . .
Each of above examples illustrates the problem with process improvement in an organization. If you choose to become an agile organization, then agile can start in software teams, but it had better spread, or overall the positive effects of agile development will not be as noticeable as they should be. This is where the principles of agile development come in because they must be applied across the entire organization. The practices will largely differ depending on the function (i.e., software developers will have different practices than documentation people or marketing people), but the mindset must be similar to maximize overall agility.
The topic of an agile enterprise is one that could easily occupy a book of its own. As an exercise to interested readers, I would recommend that you read through the principles in the Agile Manifesto (www.agilemanifesto.org) and reflect on the role of each in all the functional areas of your software teams. In terms of the principles of sustainability outlined in this book and some of the select practices, I believe that there is a great deal of applicability to CMM maturity:
Continual refinement in how the team works through frequent retrospectives and tuning of processes is a level 5 KPA.
Having a working product every day, even if it is not functionally complete, makes Software Quality Management (a level 4 KPA) attainable. The goals of SQM are to plan the SQM goals (in this case: it works), make them measurable, and to quantify and manage the goals.
Defect prevention is a level 5 KPA.
The notion of minimal documentation applies to many of the KPAs. However, most notable is how it applies to Organization Process Definition (a level 3 KPA). There’s nothing wrong with creating a diagram and short description of your agile process as is done in [Highsmith 2004a] and accompanying that with a list of best practices and lessons learned. Such a document would be useful in a large organization, especially if it’s continually updated and it’s only as long as it needs to be. A 50-page document can often convey the same information as a 500-page document. Besides, in the agile way, what’s wrong with leaving some things open to experimentation as long as teams are using the agile principles?
The CMM and agile development aren’t opposites. There is value to understanding the CMM and applying it to an organization’s process improvement initiatives, even if the organization wishes to be agile. The CMM outlines best practices that are not covered by agile development, such as the areas of management and process management, and these are vital to the overall organization. Agile development provides principles, or mindset, plus additional practices that are equally important to avoid a bureaucratic approach. Hence, the CMM and agile can coexist.