Software process improvement: it's a journey, not a destination

Reviewer: Raghvinder S Sangwan

It is desirable to reduce variation in a process, as it results in higher quality products. Improving a process, however, is a continual cycle; a process is defined, executed, measured, and improved iteratively. Hardgrave and Armstrong sum this up very nicely in the title of their article, suggesting that process improvement is a journey. We learn along the way, and, at each step, identify the shortcomings of our process, improve it, and continue with this cycle. The Software Engineering Institute (SEI) has created a capability maturity model (CMM) that acts as a framework, providing guidance for improving a software development process and measuring improvements using five different levels; each higher level represents the increasing capability of an organization to produce high-quality software products following its process. The authors, however, point out that 70 percent of the companies using the CMM framework abandon their efforts before realizing its potential benefits. This may be largely due to the misguided focus on achieving a maturity level rather than on creating a culture of continual improvement. They present a case for AA Company (AAC), which almost became one of those 70 percent, but had the foresight to continue with the software process improvement (SPI) initiative, learning along the way the most valuable lesson of all?SPI is a journey, not a destination. Through their study of AAC, the authors provide many nuggets of wisdom, some of which appear to be common sense, but are often overlooked. First, they suggest that you provide guidance to your organization regarding the use of the CMM framework. Second, there needs to be a commitment to the SPI initiative throughout the organization, starting at the very top. Third, engage all members of the organization in this effort. Fourth, use well-respected team members to lead the effort. Fifth, measure your success. The authors also discuss other lessons learned, and provide valuable guidance for realizing the benefits of continuous SPI. Those engaged in SPI initiatives will find that this article serves as a beacon on their journey, steering them away from the common pitfalls to which 70 percent of companies succumb. Online Computing Reviews Service

Reviewer: Coskun Bayrak

This article describes AA Company's (AAC's) initial discouragement, and eventual success, in implementing a software process improvement (SPI) program. The authors examine why the initial goal of advancing one level in a Capability Maturity Model (CMM) self-assessment proved to be a daunting endeavor that could not be completed on schedule. After AAC took a fresh approach to the SPI project, they found that the destination of CMM level advancement was distant, but the journey through SPI was rewarding. Hardgrave and Armstrong explain that AAC's early tasks focused on documenting existing processes rather than improving them. After AAC and their advisor reorganized the project, established leadership, and made high-level support visible, a new methodology for software development resulted. The project continued with stewardship of this methodology, and extensive training of developers in its application. CMM Level 2 was achieved, but only after the development and acceptance of the new methodology. The article assesses nine lessons learned through AAC's experience. Three lessons focus on top management, indicating that guidance is needed from the beginning, management support is needed throughout, and well-respected members must lead the effort. Three lessons look at the core of the organization, pointing out the need to engage organizational members, unfreeze behaviors, and tailor the initiative to the needs of the organization. Two more involve project management principles, citing the need for measurement throughout the process, and provision of resources. A single lesson sums up the article: an SPI project must have a process improvement focus. The daily rewards of continuous improvement far exceed the celebration of an individual goal. Online Computing Reviews Service

Reviewer: Phillip A. Laplante

An old saying goes, "When you don't know where you are going, all roads will take you there." The authors would have you reinterpret that saying as follows: "If you know where you are going, regardless of how much time and money you waste, how many accidents you have, and how much you hate the ride, all that matters is that you became a better driver." In short, this piece seems intended to salvage the reputations of those who led a disastrous software process improvement (SPI) initiative. This technical opinion column reports the lessons learned by an anonymous company (AAC) in its quest to improve its software development processes using the capability maturity model (CMM) as a vehicle. In particular, AAC desired to advance from a CMM level one organization to a CMM level two in ten months. Although it is not stated explicitly, a reader infers that the stated objective was based on a dictum from the chief information officer (CIO). It eventually took almost four years to achieve the goal. The paper does not analyze the causes of this disaster. Rather, it proceeds to apply the most positive spin possible. All we are told about AAC is that it is a $2.3 billion publicly held service organization of 12,000 employees, with 185 in the application development group. Such details as development staff characteristics, organizational structure, and tools used are left to the reader's imagination. It would have been helpful to know much more about the company in order to put the study in perspective. Apparently, after a first abortive attempt to reach level two, AAC restarted its initiative with the help of a consultant and developed a new set of processes. The CIO then issued a formal written policy statement that the new methodology would be used by all developers. Subsequently, the appropriate training was delivered. About two years later, "almost as an afterthought," the company reassessed itself and discovered it had reached level two. Although employee surveys were used extensively during the initiative to solicit feedback, we don't know much about this feedback (though we are told there were "no major problems with the methodology or with reluctance by the developers in using it"). But it is hard to believe that the response was overwhelmingly positive. In any case, it seems that a serious flaw in this approach was that no appropriate buy-in or input was obtained from developers prior to the mandate-only after its pursuit was a fait accompli. The authors cite nine lessons learned on this "joy ride" from level one to two: (1) Provide guidance from the beginning of the process. (2) Management support is needed throughout the organization. (3) Engage organization members. (4) Use well-respected team members to lead the SPI effort. (5) Take measurements throughout the process. (6) "Unfreeze" behavior. (7) Treat the SPI initiative as a project, and provide necessary resources. (8) Have an SPI/continuous improvement focus. (9) Tailor SPI initiatives to the needs of the organization. None of these is new or profound. Somewhere along the way, "the original goal of reaching level [two] no longer became the driving force. Rather, the company began to realize the benefits of continuous SPI. AAC used the CMM truly for what it is-a framework for improvement, not a clear-cut guide to development as viewed by some." This sounds like the CIO's damage control statement to the board and shareholders. And, although the authors allude to the benefits that were achieved by the attainment of level two (in the areas of customer satisfaction, number of days of deviation from scheduled delivery date, and the percentage of deviation from the proposed budget), we are given no data. Indeed, from the way the narrative is written, it is unclear that any of these measures improved at all. What we don't know is stunning. We don't know what lost opportunity costs there were for this failed initiative; how many employees left in frustration; or which projects were delayed as a result. We certainly don't know the estimated and actual costs of the initiative, but it is clear that an honest accounting would show a multimillion-dollar disaster. All we are told is that some lessons were learned through the spectacular failure. If AAC needed to spend nearly four years and millions of dollars to learn these well-known lessons, then the CIO who commissioned this journey should be fired. The authors conclude that "software process improvement is a journey, not a destination." Although this sentiment is correct, it shouldn't be used as an excuse for a failed initiative, particularly when the cost of learning such obvious lessons is so high. By choosing to act as apologists for the CIO of AAC, the authors miss the real lesson of this case. Using their metaphor of a journey, "when it comes to making the long and arduous trip toward SPI, it is much better to get agreement from the passengers about the destination and purpose of the trip, and only then pick the vehicle and plan the route." Certainly letting a CIO shanghai passengers into the back of a darkened trailer marked "CMM" is no way to start a journey. Go ahead and read the paper if you want to see how to spin a failure. Online Computing Reviews Service