Create a list of issues facing Hardcore Financial Bank (list at least 3 issues) For each issues decide whether CMM or Agile ca

9 – 6 0 7 – 0 8 4 R E V : S E P T E M B E R 1 0 , 2 0 0 8

________________________________________________________________________________________________________________ Professor Robert D. Austin prepared this case. HBS cases are developed solely as the basis for class discussion. The company mentioned in the case is fictional. Cases are not intended to serve as endorsements, sources of primary data, or illustrations of effective or ineffective management. Copyright © 2007, 2008 President and Fellows of Harvard College. To order copies or request permission to reproduce materials, call 1-800-545- 7685, write Harvard Business School Publishing, Boston, MA 02163, or go to http://www.hbsp.harvard.edu. No part of this publication may be reproduced, stored in a retrieval system, used in a spreadsheet, or transmitted in any form or by any means—electronic, mechanical, photocopying, recording, or otherwise—without the permission of Harvard Business School.

R O B E R T D . A U S T I N

CMM versus Agile: Methodology Wars in Software Development

Jennifer Fenton, CIO of Hardcore Financial Bank (HFB), settled back into a big, comfortable chair in the corner of her office, sipped her coffee and got ready to read a report that a trusted member of the IT staff had given her. The report, written by information technology (IT) thought-leader Ken Orr, had an intriguing title: “CMM versus Agile: Religious Wars and Software Development.” The post-it stuck to the report’s cover said it was as impartial a comparison of these two ways of developing software as she would find anywhere.

Some advocates of each approach fiercely contested the legitimacy of the other. Fenton had inadvertently touched off a firestorm when she announced her intention to explore whether HFB should adopt the “Capability Maturity Model” (CMM). She had gotten the idea at an industry conference where a competitor had spoken about his company’s experience with it. The matter had not seemed controversial at the conference, and some people in her IT department seemed to like the idea. Then she discovered that the angriest opposition to the CMM came from some of her very best developers. Fenton heard harsh language from each side, which made it even more difficult for her to form an opinion. After she had expressed frustration that no one was able to give her the straight story, one of her team had suggested this report.

With HFB on a rapid growth trajectory and moving into new businesses all the time, Fenton had to get this decision right. Most of the company’s various businesses depended heavily on IT, and corporate strategy called for developing best-in-class IT services so that clients could manage their own banking affairs. The IT group worked with many outside partners but developed plenty of software in-house, especially for customer interfaces. Her most talented developers knew a lot about software, naturally, but they also knew a lot about banking. Senior management considered the company’s software systems a competitive advantage.

Nevertheless, members of the senior team felt that HFB’s development processes needed to mature; they were still more ad hoc than suited a company with annual revenues now reaching into the hundreds of millions of dollars. Projects too often failed or ran over budget. So Fenton began to consider the CMM, a “maturity model” that marketed itself as best practice and had notable advocates in all sorts of businesses.

This document is authorized for use only by Nadim Ali ([email protected]). Copying or posting is an infringement of copyright. Please contact [email protected] or 800-988-0886 for additional copies.

607-084 CMM versus Agile: Methodology Wars in Software Development

2

Two of her developers had said that they would quit if HFB adopted the CMM. According to them, the CMM was the old way of doing things and that the emerging best practice was “Agile.” Fenton had heard of both, knew something about each, but she was far from expert in either. HFB had been so busy growing, and the IT department had been so busy building software, that control of development policy and methodology had remained informal and on the back burner.

Fenton thought she remembered taking classes in college that taught “Warnier-Orr” diagramming, and she was pretty sure that this report was by the same Orr. Ken Orr, a Fellow of the Cutter Consortium, a highly regarded information and analysis service, had written the report for Cutter’s Agile Project Management & Software Development practice. The Cutter business model gave it better claim to impartiality than most similar services.1 Fenton had high hopes that the report could help her figure out whether the CMM was a good idea for her firm.

Here’s what she read.

The Cutter Report

NOTE: The contents of the following sections are adapted, with permission of the Cutter Consortium, from its report, “CMM versus Agile Development: Religious Wars and Software Development,” by Ken Orr, Executive Report, Cutter Consortium, Vol. 3, No. 7, 2002. Orr’s voice has been retained (with the use of “I”) in what follows. Cutter holds all copyrights to the original report.

In 2001 proponents of radical software development methodologies met near Salt Lake City, Utah. After intense discussion, they issued “The Agile Manifesto,”2 setting in motion a software schism between an old guard, supporters of the Software Engineering Institute’s3 “Capability Maturity Model” (CMM), and a newly organized “Agile” development movement. This report explains the relationships between Agile and the CMM, and how each relates to “rigorous,” “light,” and “heavy” approaches to systems development.

Software Methodology Wars

“Q: What’s the difference between a terrorist and a methodologist? A: You can negotiate with a terrorist.” —Variously attributed, source unknown

Every decade or so development methodologies come into conflict. During the 70s, it was structured development vs. traditional development; in the 80s, data modeling driven vs. traditional development; and during the 90s, object-oriented design versus traditional development. In the first decade of the 21st century, supporters of “Agile methods” do battle with supporters of the most recent of the traditional “waterfall” software development approaches, the CMM.

1 Cutter maintained impartiality by avoiding relationships with IT vendors. Many other analyst firms derived significant portions of their revenues from vendors, creating the possibility of conflict of interest when the analyst firm’s advice had implications for vendor products or services. For more information on Cutter and its business model, see www.cutter.com.

2 http://agilemanifesto.org/.

3 The Software Engineering Institute is a research and development center funded by the U.S. government, “conducting software engineering research in acquisition, architecture and product lines, process improvement and performance measurement, security, and system interoperability and dependability.” It is part of Carnegie Mellon University, which is located in Pittsburgh, PA.

This document is authorized for use only by Nadim Ali ([email protected]). Copying or posting is an infringement of copyright. Please contact [email protected] or 800-988-0886 for additional copies.

CMM versus Agile: Methodology Wars in Software Development 607-084

3

In software wars, nobody gets killed or maimed. But for participants, the metaphor is real enough. Careers are made or destroyed, organizations thrive or perish in the struggle. The most interested bystanders are CIOs and development managers of large organizations. Just when they decide that “CMM Level 3” represents the current “best practice,” someone (usually a young programmer) asserts that the CMM is out and something called “Agile Development” is in. What’s a conscientious manager to think?

In addition to comparing Agile and CMM methods to see how they differ, and under what circumstances one approach might be preferable to the other, I’ll cast what light I can on the hidden agendas animating the debate. One of the most important of these centers on control: Who has it? The programmer or the manager? The Agile “revolution” could also be labeled “the programmer’s revenge.” During the 80s and 90s a Computer Aided Software Engineering movement appeared intent upon eliminating, or at least deemphasizing, programmers and programming. Within that movement, programmers occupied a role analogous to assembly line workers in manufacturing: following rote routines laid out by others. Programmers found this condescending, to say the least. When management implemented these ideas, they forced programmers to do all kinds of bothersome, tedious chores. Object-Oriented (OO) techniques put development initiative back into the hands of programmers. Agile goes OO one further by turning even more control of development over to programmers and users, reducing the influence of many traditional management levers.

A related hidden agenda involves process: Should professional development follow a scripted sequence of steps, or should it remain flexible and allow the people doing it to exercise discretion? Many managers prefer the predictability of a scripted process; many programmers prefer a climate of flexibility that allows them to take initiative. The CMM vs. Agile debate is to some degree an argument about how people work best on complex problems.

Yet another hidden agenda has to do with documentation and design: Some programmers consider documentation and abstract design work that doesn’t involve “writing code” a waste of their time. On other hand, others, many of them managers, like to see tangible deliverables that they can use to measure the progress emerging from development.

All of the items on this agenda list influence the debate. Partisans on both sides formulate “us” vs. “them” propositions—”We’re on the side of the Angels, they’re on the other side of . . . the other side.” CMM proponents are in favor of “process improvement”; Agile developers are in favor of “increased user involvement” and “rapid development.” Who could oppose any of these? But the issues aren’t clear cut, and as the debate between the CMM and Agile matures, both sides adjust their positions and improve their methods.

Capability Maturity Model Background

The CMM originated as a means to address the difficulties of large-scale military software development. In 1984, as part of a long-term program to promote improved large-scale software development and software management, the United States Department of Defense (DoD), in conjunction with Carnegie Mellon University, chartered the Software Engineering Institute (SEI) to promote software development best practices and reuse. Over time, SEI became a major force in software research and education; the CMM has become one of the major programs it developed. The SEI has reached outside the defense community to promote software engineering in general and the CMM in particular.

In the 80s, Watts Humphrey, a researcher and manager from IBM, combined software lifecycles with maturity levels from the manufacturing quality movement into an approach to software

This document is authorized for use only by Nadim Ali ([email protected]). Copying or posting is an infringement of copyright. Please contact [email protected] or 800-988-0886 for additional copies.

607-084 CMM versus Agile: Methodology Wars in Software Development

4

development. His book became the basis for the development of the CMM.4 In an article written in 1998, Humphrey explained the CMM’s origins:

. . . the U.S. Air Force asked the Software Engineering Institute (SEI) to devise an improved method to select software vendors. . . . A careful examination of failed projects shows that they often fail for nontechnical reasons. The most common problems concern poor scheduling and planning or uncontrolled requirements. Poorly run projects also often lose control of changes or fail to use even rudimentary quality processes.5

Throughout its history, the CMM has been associated with defense and military systems. The DoD is the largest long-term purchaser of software development services in the world; it wields immense influence. The DoD has been developing large-scale systems longer than anyone and, some would say, more successfully than almost any other organization. The DoD has also funded research in software development and software methods longer than any other organization, with the possible exception of the telecommunications industry.6 DoD systems tend to be both huge and state-of-the- art, requiring vast investments in custom hardware and software. Moreover, the DoD uses outside developers to develop most of their systems. With so much at stake, the DoD has worked mightily to take as much risk as possible out of critical systems projects.

For decades, the DoD has promoted “rigorous systems methodologies” (RSMs). In the 50s and 60s, for example, the DoD promoted the first “Waterfall methodologies” adapted from work on hardware development (see Exhibit 1). The Waterfall emphasized the idea of serially phased development: planning, requirements, design, development/testing, and deployment. Each phase produced voluminous documentation to guide the next phase.

The Waterfall allowed careful consideration of problems and made sure that major elements were not missed. The serial approach also made it possible to break up the work so that, for example, one organization might do the planning and requirements while another could do the design, development/test and deployment. This modularity fit well with standard procurement practices on government projects, which called for using different vendors on different activities.

Because the DoD was such a big customer, many large military/aerospace firms adopted Waterfall methods very similar to the DoD’s.7 Those organizations with the most “rigorous” methods were often large, military software vendors. This pattern is being repeated today in the private sector. As more large organizations buy huge chunks of software from outside vendors, they are looking for better ways to manage this important relationship. The DoD has had so much experience in controlling outsourced software projects that commercial firms have taken a clue: they’ve begun to force the adoption of CMM practices among their own vendors.

One industry segment has embraced the CMM: software development outsourcing vendors, especially in India. For more than a decade now, large Indian software companies have been among the most aggressive in the world in pursuing higher and higher levels of CMM certification.8 Indian firms feel they need CMM certification to allay fears customers might have about leaving software work to offshore firms. According to my colleague and friend Ed Yourdon, who sits on the Board of 4 Humphrey, W., Managing the Software Process, Reading MA, Addison-Wesley, 1989. 5 Humphrey, W., “Three Dimensions of Process Improvement (Part I: Process Maturity),” Crosstalk, February 1998. 6 Most technologists will recognize the importance that DoD’s Advanced Research Project Agency (ARPA) has had in the development of information technology. ARPA supported research in computers, software, database and, of course, the Internet. Other major technology research funding came from various military and intelligence services. 7 The DoD has reinforced this by making systems development and systems management methods part of the standards that vendors must comply with to get DoD contracts. 8 Roughly 40% of all CMM Level 4 and Level 5 certifications have been earned by Indian firms.

This document is authorized for use only by Nadim Ali ([email protected]). Copying or posting is an infringement of copyright. Please contact [email protected] or 800-988-0886 for additional copies.

CMM versus Agile: Methodology Wars in Software Development 607-084

5

Directors of one of India’s largest software vendors, these companies have become expert at following CMM best practices and have found ways of applying the CMM to small projects.

Many of the ideas behind the CMM are taken from statistical product quality control work pioneered by people like W. Edwards Deming and Joseph Juran. One of the principal ideas behind the CMM is that organizations can improve quality by gaining (statistical) control of their processes.9 This idea is widely accepted within the quality movement worldwide; it is one of the guiding ideas behind other popular initiatives such as ISO 9000.10 The idea of capability levels comes from the quality movement, as do definitions for the five maturity levels (initial, repeatable, defined, managed, and optimized).

In the complex world of software development outsourcing, the CMM has become a way of certifying expertise. In the same way that Oracle DBA and Cisco Internetworking Engineer certifications have become valuable on a resume, “CMM Level 3” certification has become valuable in marketing software development outsourcing services. Becoming Level 4 or 5 places one in rarified company as an elite software engineering firm.

CMM Levels

The CMM (see Exhibit 2) describes 5 levels:

• “Initial”

• “Repeatable”

• “Defined”

• “Managed”

• “Optimized”

CMM Level 1—“Initial”

Level 1 processes are ad hoc. There is no specific methodology; each project is a new activity. The “Initial” stage is the default in software management, the state attributed to a company that has achieved no higher level of maturity. “Unfortunately, the initial level processes are the most practiced processes in the software business.”11 Many Level 1 organizations don’t admit they are Level 1 organizations. Like an alcoholic who can’t be helped until he/she admits the problem, Level 1 organizations can’t improve until management recognizes that they are in fact at Level 1. Recognition is sometimes forced when an organization wants to sell services to another organization that insists that its vendors have a CMM process in place.

9 It is important to note that by processes, the CMM means mostly software management processes, like estimating, scheduling, quality control etc. The CMM has been faulted for its lack of interest in product development process, at which, as we shall see, Agile Development excels. 10 One of the most controversial ideas behind the CMM is the notion that a software development process can be managed as closely as a manufacturing one. Indeed, a number of major thinkers consider the idea of quality capability maturity models to be fundamentally flawed. 11 Raynus, J. Software Process Improvement with CMM (Norwood, MA: Artech House, 1999), p. 14.

This document is authorized for use only by Nadim Ali ([email protected]). Copying or posting is an infringement of copyright. Please contact [email protected] or 800-988-0886 for additional copies.

607-084 CMM versus Agile: Methodology Wars in Software Development

6

CMM Level 2—“Repeatable”

Level 2 organizations have a basic project management structure in place to track costs, schedules, and some systems functions. Repeatable software processes in place are reinforced by training and by management controls. Because Level 2 organizations follow the same processes time after time, they can begin to work on measuring and improving those processes.

CMM Level 3—“Defined”

At Level 3, a software development organization has a well-defined software engineering approach operating in a project management framework. Well-documented processes are communicated across the organization through standards and training. “If the repeatable level defines what to do and who should do it, the defined level specifies when to do it and how to do it.”12 While Level 2 organizations are mostly concerned with project management processes, Level 3 organizations, theoretically at least, also define and measure their software development processes.

CMM Level 4—“Managed”

At Level 4, software development managers increasingly use statistical methods. They collect and manage process and product quality measures. At Level 4, software products are not only managed to meet time and cost schedules, but to meet specific customer satisfaction and defect levels as well.

CMM Level 5—“Optimizing”

The Level 5 organization has reached quality Nirvana. They produce software at Level 4, and never stop improving processes and standards. CMM Level 5 organizations are presumed to be world-class innovators in software development.

The CMM certification process examines organizational practices, determines their current maturity level, and provides management with a roadmap for improving that level. By committing to the CMM process, organizations can start wherever they happen to be and, through a conscious program, begin to improve along a trajectory much like that described by Total Quality Management gurus. It takes nothing more or less than commitment, training, measurement, and correction.

CMM Pluses and Minuses

The CMM appeals to organizations and managers interested in control and certification. Expert consultants certify an organization’s CMM level. This is important in organizations in which CIOs and others look for outside creditability.

Surely there’s nothing wrong with being “well managed.” Software is not such a unique business that sound management practices don’t apply. As the best-known, best-documented software management method in use in the real world, the CMM looks much like applied common sense. Tens of thousands of managers and programmers have been trained in its use and find the CMM a lingua franca for communicating with others. For managers seeking tangible improvement, those five CMM levels provide a way to direct attention to needs and to set objectives for meeting them.

On the other hand, people have noted that some organizations that train companies in CMM methods also provide certification, an apparent conflict of interest. Others have complained that gaining certification at Levels 2 and 3 seems to require good paperwork, not good management. Still

12 Ibid., p. 17.

This document is authorized for use only by Nadim Ali ([email protected]). Copying or posting is an infringement of copyright. Please contact [email protected] or 800-988-0886 for additional copies.

CMM versus Agile: Methodology Wars in Software Development 607-084

7

others ask how a CMM certification process can hope to succeed in assessing very complex software development practices. They point to the difficulty audit firms have in preventing poor financial reporting. In addition, critics aver that CMM certification has more to do with an organization’s management processes (estimating, scheduling, control) than with the quality of the software produced.13 There are even those who say that in order to become a Level 2 or 3 organization, you don’t need a good (or state-of-the-art) software process in place, you need only blindly follow some process, any process.

One thing stands out: CMM Level 3 or 4 leads to a very strong (even heavy-handed) management style. By and large, these organizations pay more attention to project management than to product output. This can make software developers cranky; they’d rather program than fill out project management documentation. The CMM in the wrong hands may stifle innovation. Poorly implemented, the CMM becomes all the bad things that its opponents say about it

Agile Development Background

With some notable exceptions,14 the people most responsible for the Agile movement came of age at the beginning of the “object revolution” in the late 80s and early 90s. That revolution was very successful; the most popular development languages and operating environments today all have an OO flavor. But not everything has gone as planned. Most disturbing, OO projects have been late and over budget as often as any other projects. As a consequence, some of the most devoted OO advocates came to recognize by the mid 90s that OO techniques alone would not revolutionize the software world. In order to really create new classes of software in very short periods of time, the software process needed a radical overhaul. People experimented with different approaches to OO development. Agile grew out of the convergence of a number of the most successful outcomes of OO development experiments.

The important themes of the early Agile movement included the following:

• Systems are best developed in small increments;

• Users and developers have to work hand-in-hand;

• Each system increment should be designed to handle the minimum requirements;

• When changes in requirements occur, they should be designed in; and,

• There should be little or no documentation beyond the actual code.

The visual image most associated with the CMM is a waterfall; the image of Agile is a rapid prototyping cycle (see Exhibit 3).

Most OO programming gurus who took up Agile techniques shared a dislike for paperwork, especially paperwork imposed by “rigorous” software approaches such as the CMM. In the circle of Agile gurus, there is a strong minimalist bias. Software itself is the product; everything else is overhead. “Why worry about documentation or project management forms, etc. if all that people want is the product?” Then: “What if we throw a few good programmers in a small room with the 13 In response to the criticism about the CMM’s lack of objectivity, the SEI has created a measurement program to support CMM certification. This program is called Software Engineering Measurement and Analysis (SEMA). 14 A very notable exception: Jim Highsmith, the author of several influential books on Agile development, especially Adaptive Software Development, is a pioneer in systems methodologies going back to the 70s. Bob Charette, Steve Mellor, and Ken Schwaber are other greybeards that have joined forces with younger Agilists.

This document is authorized for use only by Nadim Ali ([email protected]). Copying or posting is an infringement of copyright. Please contact [email protected] or 800-988-0886 for additional copies.

607-084 CMM versus Agile: Methodology Wars in Software Development

8

user and let them develop the software a little at a time. That could eliminate waste and miscommunication.” Far from being imposed by some large organization like the DoD, Agile developed spontaneously in the work of a number of independent consultants.

One of the most influential gurus in the Agile movement is Kent Beck. He’s written many books and articles on eXtreme Programming (XP), and has lectured around the world. After receiving his MS in computer programming from the University of Oregon, Beck worked for a number of organizations including Apple and HP. At Chrysler in the mid-90s he began to formulate his ideas for a radical new way to develop systems. Throughout the late 90s these ideas began to catch on. Now, into the 21st century, an increasing number of people have taken up XP or one of the other, similar “fast-track” methodologies.

Software developers and managers had a tough time sorting out the differences and similarities among fast-track methodologies. Finally, in early 2001, proponents of the new ideas met in Utah to see if they could come up with a set of common principles. Out of that meeting came the now famous Agile Manifesto. The Manifesto proposed a simple and straightforward set of principles (see Exhibit 4). These threw down a gauntlet, an unmistakable challenge. The answer? Open warfare between the newly united rebel band and the establishment—at least the part supporting the CMM.

The Agile Approach

In contrast to the CMM, which is a set of loosely connected software management best practices, Agile is a set of highly integrated development and management practices.15 In his book, Extreme Programming Explained,16 Kent Beck proposed 12 ideas that together constituted an Agile approach17:

1. The Planning Game

&

Collepals.com Plagiarism Free Papers

Are you looking for custom essay writing service or even dissertation writing services? Just request for our write my paper service, and we'll match you with the best essay writer in your subject! With an exceptional team of professional academic experts in a wide range of subjects, we can guarantee you an unrivaled quality of custom-written papers.

Get ZERO PLAGIARISM, HUMAN WRITTEN ESSAYS

Why Hire Collepals.com writers to do your paper?

Quality- We are experienced and have access to ample research materials.

We write plagiarism Free Content

Confidential- We never share or sell your personal information to third parties.

Support-Chat with us today! We are always waiting to answer all your questions.