Using the CMMI as an Organizational Development Model

Transcription

1 Using the CMMI as an Organizational Development Model Abstract Jorge Luis Boria, M Eng SEI Authorized Lead Appraiser, Liveware Inc. [email protected] The CMMI (Capability Maturity Model Integration) has replaced the CMM as the defacto standard for process quality. Many people are looking in from the outside of the CMMI community trying to gauge the value of the model. In this short paper we describe where the CMMI adds value to the Software Development community and how to derive it. Introduction The software industry stands on three very important roles: research and creation, engineering and sustainance; however the engineering role is the one that defines operational and maintenance costs of the product. What makes this notable is that a fixed cost role sets the stage for the variable costs in the life of the product. In economic terms, this is a fantastic opportunity: You can manage your lifetime costs while understanding your investment completely! Hence the value of the investment in software engineering is measured in the quality of the product. A team that produces very high quality in its products merits a large investment, because it eliminates potential that would have raised the variable costs of the product during the life cycle. In spite of this, many software organizations refuse to invest in software engineering. The tendency, beaten in by years of practice, and the promotion to managerial positions of previous star programmers, is to hurry-up programming. We have the utmost respect for Agile Methods, we actually promote the adoption of Scrum with our customers, but we strongly reject the idea of hurrying up the process to the point that we no longer understand what we have to do. Many years ago, Glenford Myers quipped the often cited phrase We try to solve the problem by rushing through the design process so that enough time is left at the end of the project to uncover the errors that were made because we rushed through the design process. 1 This wonderfully coined statement sums up the main problems of our profession as Software Engineers: The quality paradox. 1 Glenford J. Myers, cited in "Code Complete: A Practical Handbook of Software Construction" by Steve C McConnell, ISBN: , page: 143

2 Focusing on the delivery date does not make a project on time. Actually, exclusive focus on the delivery date breeds poor practices, cutting corners and hurrying through important steps in the life cycle, as Myers quote describes. In turn, these bad practices beget poor quality in the product, expressed as defects. Defects (when found and acknowledged) force rework. Rework is usually concentrated on the end stages, when the project is often already late. Emphasis on delivery hurries developers through the correction process, instead of making them think about the nature of the beast. As a consequence, even more defects appear and the project is late. The paradox is evident when the organization focus shifts to quality. Focus on quality breeds good practices, which in turn consistently create quality products. Quality is mostly expressed in lack of defects, hence little or no rework is needed, and the end result is a timely delivery. For those of us with many years of profession, the Quality Paradox is self evident. For many managers, either previously technical heroes or newcomers to the profession, it is not. They need to be convinced by many projects gone awry. Just as many people do not change eating and work out habits until their health is seriously compromised, organizations find it hard to change their ways until their productivity is seriously compromised. Even then, recognizing the need to change is not the same as changing.

3 What does Focus on Quality Imply? The enemy of quality is rework. I still have to meet an engineer that enjoys rework as much as creating the original work. I haven t heard enthusiastic shouts while walking around the cubicles: Great! We have another defect to fix!. The main source of rework is to be found in Myers quote: We hurry. A pictorial representation of our hurried processes is what Joyce Statz calls The Chaos Zone The Chaos Zone appears in a project life cycle when all defect removal activities are delayed until the last phases. While defect injection takes place all along (define a defect as a departure from the product the client needs/wants/requests), defect removal is left to testing. Under such circumstances, it is no surprise that all hell breaks loose and working hours are undefined. Since testing has been already been delayed (and shortened in the plans), the project is already late when it reaches that stage. Late projects with defects that force rework are even later. As a stopgap measurement, management brings in fresh troops. All design considerations, if any had survived so far, are thrown out of the window. More defects, and more subtle ones, are introduced in the product. The spiral of death sets in. In one desperate effort, the product is shipped. Sometimes the wrong product, one that was not tested, is shipped, but after weeks of going home at 3 am not many people keep a clear head. What the organization needs is a control system that establishes a set of balanced controls and early checks. How to use CMMI in your organization The CMMI is a model that abstracts best practices from successful organizations and structures into a useable format. The CMMI is not a process, or a process kit. The CMMI is a model of what best processes cover. By looking at the CMMI you can infer what a superior process for your organization should look like. Of course, having the best

4 processes is only a part of the answer, since even the best process, if not followed, is useless. The CMMI does not guarantee that compliance with its practices brings success, only that many successful organizations are, for the most part, compliant with many or all of the model s practices. The deceiving simplicity of the model hides the fact that a static view cannot reap all the benefits. If you look at the CMMI as a checklist, your attitude is bound to be somewhat Pollyanna-ish. Usually people that have a superficial approach to the model build processes following the Field Of Dreams motto: If you build them, they will come. It is not so. Processes need to be built to solve real life problems and have to be carefully introduced to the organization. The resulting organization is not just the arithmetical sum of the practices. It could be less, if you force compliance without commitment, or more, if the commitment nurtures the processes. People that treat the model as a checklist tend to underestimate the value of good practices, placing their faith in the magical properties of the model. They incorrectly arrive to the conclusion that the smaller possible implementation of each practice is better, without giving extra thought to the business needs. As a consequence, progress is made, but it is a far cry from the promises of the model and what it can really deliver. By treating the CMMI as a system, the organization benefits much more from its adoption. The CMMI can then be seen as what it does best: a model to build a system of controls and balanced checks that detects defects early and allows for their removal. The organization that chooses to view the model through this lens will find that the information components of the model, that what is left after you remove the goals and practices, convey the true message. These organizations usually look for and find the best implementation for each practice, the one that maximizes the return on the investment. They think these implementations through in the context of the culture and the business needs. Their business goals guide their selection of improvements, and establish the parameters of what improvement is. This, in turn, allows them to have clean criteria to select between alternative implementations. These organizations manage to find the synergy that the collection of practices of the model have, and put it to good use. Of course, there is a price to pay for this, and it is paid in effort to build this correctly, but the payoff is a world-class organization. World class organizations are agile, effective and efficient. They can compete with the best in their business and win. They understand to perfection their cost structure and their capabilities, and they put this knowledge to good use. An organization that reaches the highest maturity level in the model, and reaches it well, is a world class organization.

5 How to Fit in Cultural Aspects The five maturity levels of the CMMI in the staged representation actually describe the model as an Organizational Development model, one that allows you to understand the sequence of implementation of your improvement initiatives. For example, the typical ladder drawing has less information than you might want to understand how to shift the culture in order to achieve the benefits of the level. In the initial level, the organization usually exhibits a clique culture. The success or failure of a project is based on the chemistry that the team members can muster. Good chemistry means success, poor chemistry means failure. There is a perpetual risk that any reshuffling of resources will brew a failure. What is much worse, success stories cannot be duplicated without using the same team. The organization therefore, not only does not learn from its mistakes, it does not even really understand how it succeeds. At maturity level 1, the managerial tool par excellence is blood, sweat, tears and a great deal of hope. At maturity level 2, the culture is one of commitment per project. Meetings (bloody meetings) are scheduled to establish and renew commitments. Any other means of establishing commitments are equally valuable, so you can outgrow the meetings when you achieve higher maturity. The focus is on what. The managerial tool of choice is meetings.

6 At level 3, the culture shifts to one of communities of interest. The different groups share best practices and capture them so that they can be improved. They concurrently build a process asset library that forms the framework to all work. The focus shifts to how. The managerial tool of choice is assets that concentrate knowledge. At level 4, the culture progresses from best practices to nurturing precision and quality. The assets now include statistical models and people shift from how to qualitatively understanding matters to building a quantitative understanding. The focus shifts to how many or how much. The managerial tool of choice is statistical process control. Finally, the organization ends building for itself the six-sigma skills when it achieves level 5. At level 5, the culture is focused on continual improvement. The managerial tool of choice is system dynamic models. Conclusions The CMMI does concentrate an inordinate amount of good practices, but they alone do not guarantee success. It can be viewed as a static checklist, and become a blunt tool, or it can be viewed as a dynamic system of early checks set on detecting and eliminating defects. To obtain the most of the model, attention to culture is required. Without changing culture it is very difficult to move forward in maturity. Austin, June 2006