THE DANGERS OF EXTREME PROGRAMMING
A TERM PAPER PREPARED FOR
SWE625 SOFTWARE PROJECT MANAGEMENT
AND
SWE699 SOFTWARE ENGINEERING MANAGEMENT
BY
PATRICK EMERY
pemery@cox.net
May 20, 2002
Table of Contents
The CMMI
under extreme circumstances............................................................................. 26
Introduction
“Extreme Programming (XP) is a lightweight design method
developed by Kent Beck, Ward Cunningham, and others. After notable success, XP has been generating huge interest, and
no small amount of controversy. Much of
the interest stems from XP’s pragmatic approach to development. Key practices include pair programming,
writing tests upfront, frequent refactoring and rebuild, continuous integration
and testing. Key principles incremental
and iterative development, working with the simplest solution, cutting out
extraneous documentation and collective code ownership.”[1] This is XP as introduced by Kent Beck at the
Technology of Object-Oriented Languages and Systems conference in June 1999,
Nancy, France. The
methodology was invented in 1996, when automaker Chrysler called upon Kent
Beck, a software developer, to save a project known as Chrysler Comprehensive
Compensation, or C3.
The original C3 project began in
January 1995 as a fixed price contract to revamp the companies payroll
system. Kent Beck was brought in by
Chrysler in early 1996 to help with performance tuning. He recommended throwing out all the original
code and a new chapter in the project was started. Kent was head coach, Martin Fowler assisted Chrysler in
developing user stories and Ron Jeffries was brought in by Kent to assist with
the coaching. Keeping half of the staff
of the original project Kent and the new C3 team proceeded to invent and
practice the tenants of extreme Programming.
Using the new methodology the smaller newly formed team of 10
programmers (15 total staff) produced within 8 months a system that the
customer believed contained the required functionality. In the end, the C3 project was scarped in
February of 2000 because it was only paying 1/3 of the employees. The new process of eXtreme Programming had
already been released into the software development community through the rapid
injection process of web fame.
Extreme Programming has grown beyond the first project, beyond the first paper and beyond the first book. The first books in the XP series after, “eXtreme Programming explained: Embrace Change”[2] by Kent Beck were “eXtreme Programming Installed”[3] by Ron Jeffries, Ann Anderson, and Chet Hendrickson and “Planning EXtreme Programming”[4] by Kent Beck and Martin Fowler. More books have followed, as have more projects but the initial popularity of XP should not be a reason to jump on the bandwagon.
Mark C Paulk states, “Extreme programming is a lightweight (or agile) software methodology (or process) that is usually attributed to Kent Beck, Ron Jeffries, and Ward Cunnigham. XP is targeted toward small to medium sized teams building software in the face of vague and/or rapidly changing requirements.”[5] Robert Martin describes it as, “a software development method that view people, rather than paper, as a project’s most potent element.”[6] In the original XP book Beck explains that the basic problem XP attempts to tackle is RISK in software development:
In these pages you will read about Extreme Programming (XP), a software development discipline that addresses risk at all levels of the development process. XP is also very productive, produces high-quality software, and is a lot of fun to execute. …
If we accept project risk as the problem to be solved, where are we going to look for the solution? What we need to do is invent a style of software development that addresses these risks. We need to communicate this discipline as clearly as possible to programmers, managers, and customers. We need to set our guidelines for adapting it to local conditions (that is, communicate what is fixed and what is variable).
That’s what we cover in sections one and two of this book. We will go step by step through the aspects of the problem of creating a new style or discipline of development, and then we will solve the problem. From a set of basic assumptions, we will derive solutions that dictate how the various activities in software development – planning, testing, development, design, and deployment – should occur.2
XP is framed as trying to solve the problem of software development risk with a solution of people in the environment of a small project. XP’s approach is fragile and can fail if the project environment changes or the people change.
Related to the XP process is the concept of Agile Design. There is an Agile Design wave beginning. Agile Software Development by Alistair Cockburn came out October 12th. Agile Modeling by Scott W. Ambler is due out February 1st, 2002. Agile modeling seems to have the promise of fixing some of the shortcomings of the extreme programming process.
The first book to cover Agile Modeling, a new modeling
technique created specifically for XP projects eXtreme Programming (XP) has
created a buzz in the software development community-much like Design Patterns
did several years ago. Although XP presents a methodology for faster software
development, many developers find that XP does not allow for modeling time,
which is critical to ensure that a project meets its proposed requirements.
They have also found that standard modeling techniques that use the Unified
Modeling Language (UML) often do not work with this methodology. In this
innovative book, Software Development columnist Scott Ambler presents Agile
Modeling (AM)-a technique that he created for modeling XP projects using pieces
of the UML and Rational's Unified Process (RUP). Ambler clearly explains AM,
and shows readers how to incorporate AM, UML, and RUP into their development
projects with the help of numerous case studies integrated throughout the book.
*AM was created by the author for modeling XP projects-an element lacking in
the original XP design
*The XP community and its creator have embraced AM, which should give this book
strong market acceptance
Companion Web site at agilemodeling.com features updates, links to XP and AM
resources, and ongoing case studies about agile modeling.[7]
Impact of the economic downturn
The eXtreme Programming methodology grew strong in the economic environment of the Internet boom. As the economy slows and sours and layoffs abound this will certainly have an impact on XP’s use. Some propose XP’s use will increase: “More and more companies may begin turning to Extreme Programming, especially during the current economic slowdown, as they look for new ways to improve efficiency and stamp out defects in software long before they appear in the final product.”[8] Others propose that XP’s call for pair programming is a waist of dwindling resources. Others claim that cultural barriers prevent XP’s mass adoption in the US but that XP is taking hold in European and Asian countries. One thing is for certain the failure of a large amount of dot com companies has certainly decreased the number of projects that XP is an appropriate methodology for.
4 points to highlight
Dangers abound with XP but the following points are highlighted to give the reader a preview of the problems: Project Restrictions, Process versus Process Improvements, Local Optimization, and Magic.
Project Restrictions
There is a small set of project environments that the XP methodology can successfully be applied to- software only, small teams, and a clearly definable cooperative customer. It is a non-scalable process as a whole and claims it needs to be whole to reap the most benefit.
Process versus Process Improvements
The Capability Maturity Model Integration (CMMI) models emphasize complete coverage of the “what” of the model but the “how” is left to the organization or project and needs to make business sense. XP emphasizes complete coverage of the process specifying the “how” and it does not fit non-detrimentally within as many business environments.
Local Optimization
Ian Alexander states in The Limits of eXtreme Programming, "Maxims like, do the simplest thing that could possibly work, do not necessarily lead to optimal solutions."[9]
Magic
As Stephen J Mellor refers to the problem, “Why shouldn’t we write it down? Is something else going on? I think the answer to that is Yes. That something else is, bear with me here, the mysticism of creation. If you write it down, the (witch doctor’s) magic will go away and it won’t work any more. If you really examine it, and (again write it down, it won’t be “special” and it won’t work.”[10]
Two Strategies
Jawed Siddiqi states in, An Exposition of XP But No Position on XP, "For me, the best way to understand Beck’s explanation of XP is in terms of a project management strategy and a development strategy, each of which comprises a set of practices. XP assumes that the four project variables of cost, time, scope, and quality can be controlled."[11]
Management
Siddiqi goes on to explain that XP assumes currently available tools and practices can be used to control the four project variables. This assumption is contrary to one of the universal software engineering assumptions; the cost of changing a software system over time grows exponentially. Barry Boehm in Software Engineering Economics states, a dollar to fix a problem in a system at requirements might cost thousands after production.
The four management strategies are present in some fashion in most methodologies: Customer onsite, Short release, Metaphors and, the Planning game.
Development
Eight of the 12 XP practices describe XP’s development strategy. Four of these depart from other methodologies’ practices: 40-hour workweek, Pair Programming, Collective ownership, and Open workspace. Largely in accord with established good practices are the remaining 4: simple design, coding standards, testing and refactoring.
Is eXtreme Programming dangerous
This paper will present an overview of the XP Process, some of its benefits and criticisms, alternatives to the process, an analysis of the Capability Maturity Model (CMM) under extreme circumstances, and a summary of the dangers of XP. There really is no question that eXtreme Programming is dangerous. Its main objective is to control risk and risk by its nature implies danger. If the risk control mechanism only partially controls the risk or fails outright the danger will manifest itself as a problem. Various sources have been referenced that point out the shortcomings of the XP process. XP contains useful industry best practices and can be combined with other methodologies to greatly reduce a programs overall risk exposure but used by itself it is dangerous. The use of a CMMI compliant process is a good choice to use to fill in the gaps of the XP process. The CMMI models are an integrated set of models and a framework based upon the content of previous Capability Maturity Models (CMMs) and Capability Models and are tailorable to an organization’s mission/business objectives. The CMMI is aligned with ongoing international standardization efforts and should provide a solid path for process improvement. As a step to addressing the dangers one must start by examining the characteristics, benefits and criticisms of eXtreme Programming.
What is it - The 12 steps
Kent Beck, in Embracing Change with eXtreme Programming, explains how XP grew out of the historical project methodologies:
In the beginning was the waterfall (Figure 1a). We would get the users to tell us once and for all exactly what they wanted. We would design the system that would deliver those features. We would code it. We would test to make sure the features were delivered. All would be well.
All was not well. The users didn't tell us once and for all exactly what they wanted. They didn't know. They contradicted themselves. They changed their minds. And the users weren't the only problem. We programmers could think we were making great progress only to discover three-fourths of the way through that we were one-third of the way through.
If long development cycles were bad because they couldn't adapt to changes, perhaps what we needed was to make shorter development cycles. As Figure 1b shows, the waterfall begat iterations.
Figure 1. The evolution of the Waterfall Model (a) and its long development cycles (analysis, design, implementation, test) to the shorter, iterative development cycles within, for example, the Spiral Model (b) to Extreme Programming's (c) blending of all these activities, a little at a time, throughout the entire software development process.
The waterfall model didn't just appear. It was a rational reaction to the shocking measurement that the cost of changing a piece of software rose dramatically over time. If that's true, then you want to make the biggest, most far-reaching decisions as early in the life cycle as possible to avoid paying big bucks for them.
The academic software engineering community took the high cost of changing software as a challenge, creating technologies like relational databases, modular programming, and information hiding. What if all that hard work paid off? What if we got good at reducing the costs of ongoing changes? What if we didn't have to settle for taking a cleaver to the waterfall? What if we could throw it in a blender?
We might get a picture like the one shown in Figure 1c. It's called eXtreme Programming.[12]
Scott Ambler provides a good high-level view of the XP project lifecycle minus the death phase.
Kent also provides a list of the 12 or 13 XP Practices in the sidebar to the original article reprinted in the IEEE Dynabook:
Here is a quick summary of each of the major practices in XP.
Planning game. Customers decide the scope and timing of releases based on estimates provided by programmers. Programmers implement only the functionality demanded by the stories in this iteration.
Small releases. The system is put into production in a few months, before solving the whole problem. New releases are made often anywhere from daily to monthly.
Metaphor. The shape of the system is defined by a metaphor or set of metaphors shared between the customer and programmers.
Simple design. At every moment, the design runs all the tests, communicates everything the programmers want to communicate, contains no duplicate code, and has the fewest possible classes and methods. This rule can be summarized as, "Say everything once and only once."
Tests. Programmers write unit tests minute by minute. These tests are collected and they must all run correctly. Customers write functional tests for the stories in an iteration. These tests should also all run, although practically speaking, sometimes a business decision must be made comparing the cost of shipping a known defect and the cost of delay.
Refactoring. The design of the system is evolved through transformations of the existing design that keep all the tests running.
Pair programming. All production code is written by two people at one screen/keyboard/mouse.
Continuous integration. New code is integrated with the current system after no more than a few hours. When integrating, the system is built from scratch and all tests must pass or the changes are discarded.
Collective ownership. Every programmer improves any code anywhere in the system at any time if they see the opportunity.
On-site customer. A customer sits with the team full-time.
40-hour weeks. No one can work a second consecutive week of overtime. Even isolated overtime used too frequently is a sign of deeper problems that must be addressed.
Open workspace. The team works in a large room with small cubicles around the periphery. Pair programmers work on computers set up in the center.
Just rules. By being part of an Extreme team, you sign up to follow the rules. But they're just the rules. The team can change the rules at any time as long as they agree on how they will assess the effects of the change [14]
The practices truly are “Just rules” as this list differs from what’s on page 54 of the first book in the XP Series, “eXtreme Programming explained: Embrace Change”. The “Open Workspace” and “Just Rules” practices are not listed but instead a “Coding standards” practice is listed. The “Coding Standards” practice summary from the book is “Coding standards-Programmers write all code in accordance with rules emphasizing communication through the code.”2 Many statements are made in the XP literature that XP is not just the list of 12 but the spirit and the entire methodology must be followed to achieve the maximum benefit from the process. “Cult-like” vagaries such as these should be approached with the same skepticism that inspired Mellor’s magic analogy. The original paper ends by stating:
XP is by no means a finished, polished idea. The limits of its application are not clear. To try it today would require courage, flexibility, and a willingness to abandon the project should your use of XP be failing. …
My strategy is first to try XP where it is clearly applicable: outsourced or in-house development of small- to medium-sized systems where requirements are vague and likely to change. When we begin to refine XP, we can begin to try to reduce the cost of change in more challenging environments.
If you want to try XP, for goodness sake don't try to swallow it all at once. Pick the worst problem in your current process and try solving it the XP way. When it isn't your worst problem any more, rinse and repeat. As you go along, if you find that any of your old practices aren't helping, stop doing them.
This adoption process gives you a chance to build your own development style which you will have to do in any case to mitigate the risks should XP not work for you and to continue delivering as you change.12
Kent Beck may or may not still considers the process unfinished but potential users should beware of the shortcomings of XP.
The benefits
EXtreme Programming for all its flaws has benefit, that can be attested to by its many devote practitioners. One of the benefits is the elevation of the “coding” in the methodology. The customer desires functionality and other non-functional requirements but they are choosing this functionality be delivered as software. It seems natural that a process that delivers this product should be centered around coding. This is a benefit in a small software only environment where other aspects of software development can be minimized. This choice however hinders the ability of XP to be applied outside of this environment. It ties the methodology like a tether to small teams and software only teams. This is certainly a comfortable idea but it is not necessarily an industrial age idea let alone an information age idea. This ideology is touted by many as a Craftsmanship- approach to software development. Peter McBreen summarizes the benefits of using eXtreme Programming in Software Craftsmanship: The New Imperative:
Recently, solutions that pay attention to people and how they interact have been put forward, giving us ideas like eXtreme Programming.
eXtreme Programming works by paying attention to the craft of software development, to what developers and customers do on a minute-by-minute basis. Although initially this approach was seen as controversial, the key factor in the acceptance of eXtreme Programming by developers is that it fits the way humans like to work. More than anything else, it supports software development as a social process. It takes what has been seen as a purely intellectual challenge and transforms it into a conversation. Rather than reading documents, developers talk to the users and one another, and they pair up for producing all production code. eXtreme Programming is interesting because it has practices in place for insuring that the people on the project work together as a team. By forcing developers to communicate about the system they are building, eXtreme Programming is recreating a craft studio where everyone learns from each other.[15]
Watts S. Humphrey, a widely respected authority on software process improvement, and a long-time senior manager of software development at IBM, is a Fellow at the Software Engineering Institute at Carnegie Mellon University. He enumerates a list of the advantages for using XP.
1. Emphasis on customer involvement: A major help to projects where it can be applied.
2. Emphasis on teamwork and communication: As with the TSP, this is very important in improving the performance of just about every software team.
3. Programmer estimates before committing to a schedule: This helps to establish rational plans and schedules and to get the programmers personally committed to their schedules-a major advantage of XP and TSP.
4. Emphasis on responsibility for quality: Unless programmers strive to produce quality products, they probably won't.
5. Continuous measurement: Since software development is a people-intensive process, the principal measures concern people. It is therefore important to involve the programmers in measuring their own work.
6. Incremental development: Consistent with most modern development methods.
7. Simple design: Though obvious, worth stressing at every opportunity.
8. Frequent redesign, or refactoring: A good idea but could be troublesome with any but the smallest projects.
9. Having engineers manage functional content: Should help control function creep.
10. Frequent, extensive testing: Cannot be overemphasized.
11. Continuous reviews: A very important practice that can greatly improve any programming team's performance (few programmers do reviews at all, let alone continuous reviews). [16]
Mark Paulk is a senior member of the technical staff of the SEI. His key responsibilities are support for Software CMM, and as a contributor to and reviewer of ISO and IEEE software engineering standards. Mark states that the XP process is a well-defined process. He further refines, “XP is a specific set of practices – a “methodology” – that is effective within its context of small, co-located teams.”5
Diomidis D. Spinellis, Assistant Professor at Athens University reviews Kent’s original book and notes that XP emphasizes developing, “the most important features first, rapidly providing the customer with the functionality required and minimizing the risk of total project failure.”[17]
Terry Bollinger is a principle information systems engineer at The MITRE Corporation. He says positively, “I think XP is one of the healthier and more reality-based process improvement methodologies to come along in a long time, and that I’m quite optimistic about a number of its features.”19
Ian Alexander an independent consultant specializing in requirements engineering takes note, “An attractive aspect of XP is its promise to meet user needs accurately and quickly.”9 He concludes his comments in The Limits of eXtreme Programming, “XP clearly goes some way toward meeting the urgent need for a more responsive approach to software development for real people with real requirements.”9
Kent Beck sums the core benefit up well in his original book, “It’s been tricky, designing a process where following short-term self-interest also serves long-term team interest. You can expound all you want on how some practice or other is in everybody’s best interest long-term, but when the pressure mounts, if the practice doesn’t solve an immediate problem it will be discarded. If XP can’t work with people’s short-term interest, it is doomed to the outer methodological darkness.”2
The criticism
Extreme programming by its very choice of a name invited criticism. This paper will not attempt to make a study solely of XP’s flaws but will expose the reader to some of the criticisms put forth by the Engineering community to date.
Watts Humphrey enumerates an equal long list of advantages and disadvantages of XP in his Comments on Extreme Programming:
1. Code-centered rather than design-centered development: Although the lack of XP design practices might not be serious for small programs, it can be disastrous when programs are larger than a few thousand lines of code or when the work involves more than a few people.
2. Lack of design documentation: Limits XP to small programs and makes it difficult to take advantage of reuse opportunities.
3. Producing readable code (XP's way to document a design) has been a largely unmet objective for the last 40-plus years. Furthermore, using source code to document large systems is impractical because the listings often contain thousands of pages.
4. Lack of a structured review process: When engineers review their programs on the screen, they find about 10-25% of the defects. Even with pair programming, unstructured online reviews would still yield only 20-40%. With PSP's and TSP's structured review process, most engineers achieve personal review yields of 60-80%, resulting in high-quality programs and sharply reducing test time.
5. Quality through testing: A development process that relies heavily on testing is unlikely to produce quality products. The lack of an orderly design process and the use of unstructured reviews mean that extensive and time-consuming testing would still be needed, at least for any but the smallest programs.
6. Lack of a quality plan: We have found with the TSP that quality planning helps properly trained teams produce high-quality products, and it reduces test time by as much as 90%. XP does not explicitly plan, measure, or manage program quality.
7. Data gathering and use: We have found with the TSP that, unless the data are precisely defined, consistently gathered, and regularly checked, they will not be accurate or useful. The XP method provides essentially no data-gathering guidance.
8. Limited to a narrow segment of software work: Since many projects start as small efforts and then grow far beyond their original scope, XP's applicability to small teams and only certain kinds of management and customer environments could be a serious problem.
9. Methods are only briefly described: While some programmers are willing to work out process details for themselves, most engineers will not. Thus, when engineering methods are only generally described, practitioners will usually adopt the parts they like and ignore the rest. Kent Beck notes that, when the XP method fails in practice, this is usually the cause.
10. Obtaining management support: The biggest single problem in introducing any new software method is obtaining management support. The XP calls for a family of new management methods but does not provide the management training and guidance needed for these methods to be accepted and effectively practiced.
11. Lack of transition support: Transitioning any new process or method into general use is a large and challenging task. Successful transition of any technology requires considerable resources, a long-term support program, and a measurement and analysis effort to gather and report results. I am not aware of such support for the XP. 16
Mark Paulk states in Extreme Programming from a CMM Perspective, “some practices may be controversial and counter-productive outside a narrow domain. … Multi-discipline teams are also problematic since XP is aimed at software-only projects.”5
Paulk also indicates the lack of structure of pair programming may lessen its effectiveness compared to peer reviews. Mark's comments further point out that XP is a Process not a Process Model: “The main objection to using XP for process improvement is that it barely touches the management and organizational issues that the Software CMM emphasizes.”5
Stephen Mellor is cofounder, with Sally Shlaer, of Project Technology, Inc., a leading vendor of complete object-oriented development solutions. He and Sally also developed the Shlaer-Mellor Method of object-oriented analysis and recursive design. Mellor dispels the magic XP tries to conjure through its lack of documentation:
The power of XP for (that is, acting on) its proponents is the glorification of the magician — the programmer as craftsman, creator of abstractions, the weaver of powerful dreams, the magician. XP speaks to these people. And it gives them permission to disdain the engineering aspects of our discipline. I believe there’s a not-too-well-hidden war between the craftsmen/artists/magicians and the engineers/scientists/disciplinarians. The refusal to write stuff down (except in the form of the magic potion itself, code) is, under this theory of mine, a barrier to both imposters and potential competitors. Putting my wilder flights of fancy aside, though, surely there’s a case for describing the system for posterity. After all, this whole scheme assumes that the verbal tradition can be kept alive somehow. What happens when the last maintainer starts to drool? I have a lot of sympathy with the idea that we should only work on products we need, and not create anything “extra.” After all, if it’s extra, it is, by definition, superfluous. But surely we should ask why the code is the highest level of abstraction we can manage. (My interest is in executable models, and in building executable “metaphors,” separate from the application problem. The model then becomes the highest level of abstraction we use, not code.) There is now, by the way, talk of applying XP for building models. While this would remove some of my discomfort, it doesn’t answer the question of _why_ the model is the way it is. Write it down, dammit!10
XP's focus on doing only what is immediately necessary can cause architectural design problems, especially in complex or larger systems. Failure to take into account long-term goals early on in the lifecycle of a system can lead to project failure. Ian Alexander points out one of the places where XP stretches thin for large systems, “Traditionally, requirement engineers think through the scenarios – positive and negative – and organize them into a complete structure before design and coding can begin. XP claims that refactoring makes such analysis-in-advance unnecessary. … The approach is interesting but controversial, especially for larger systems.”9 Ian Alexander in Limits of XP: Handling Constraints also discusses constraints as a type of requirement that does not fit into the quick “push-button” type test of XP. Constraints are requirements that limit the way functionality can be provided. Typical types of constraints include performance, availability, safety, maintainability, marketability, and cost.[18]
Diomidis Spinellis observes “Beck takes for granted the use of object-oriented technology (including object-oriented databases) when discussing design refactoring and thus fails to give this important implementation constraint and its implications the attention it deserves.”17 Spinellis also notes, “Beck advises against using XP in an environment whose culture would not tolerate it: in large teams (a 10-person team is probably the upper limit), applications where changes incur large overheads, systems with long compile or test cycles, applications that do not allow easy testing, and physical environments that separate people.”17
Terry Bollinger had two concerns about XP. In his first concern he notes XP’s lack of scalability, “Scalability does not just happen by accident. It must be designed in, whether in a physical machine, executable software, or a work process for coordinating the activities of many people.”[19] His second concern is with XP’s applicability to typical business environments where there are, “complex mixtures of people, skills, and legacy software in which large numbers of craft-oriented generalists are not normally available…. One of the drivers for traditional software engineering structures then, is that they represent a more realistic model for the broad spectrum of skills and abilities typically available in the industry.”19
Clifford Shelley discusses problems with a concerted effort to apply the 12 practices of XP in an exploratory style to a new product effort:
Despite a conscious effort to exploit XP, we didn’t even get close. We failed to use it for the development of our new software product—although we have undoubtedly been influenced. This was due to a number of factors we had limited control over: new product, no customers, geography. However, we rejected some practices as too risky or expensive. How many other projects that share XP values cannot use XP? Software projects that are part of large systems projects with many subcontractors (CMM and Defense Department territory) will struggle with customer/user contact and frequent releases. They depend on stable, contractually controlled requirements and interface specifications. Safety-critical software projects cannot adopt the more dynamic aspects of XP. Projects producing software embedded in mass-market products must carefully review the cost–benefits of frequent releases, as do COTS software producers. Software projects with contractual requirements and staged payments for signed-off, intermediate deliverables, and those requiring adherence to development process standards, will also find XP needs a lot of tailoring. XP seems to fit stable, collocated, elite teams working on long projects (more than three months) developing and supporting custom software for organizational infrastructure. To be used widely, XP must offer good, specific guidance on the benefits of individual practices and their dependencies. I suspect that if they are too tightly coupled, they will not be widely used. I would like clear, experience-based guidance on tailoring it for the many diverse environments where software is produced. This might tend to dilute the X of XP, but this could be a good thing. Less X will move XP in from the tail end of the bell curve to become a valued set.[20]
Jawed Siddiqi states, “The troubles the C3 project later encountered, due to communication problems between the development team and the two sets of management stakeholders (the IS department which was the customer, and the Payroll Department which was the user) present significant concern because communication between the customers and the team lies at the heart of XP’s approach.”11
Doug Rosenberg and Kendall Scott highlight what went wrong with the C3 Project in their top 10 list of requirements review errors:
Not reviewing requirements at all. Instead, invite "feature-itis" by letting the coders build what they want. One of the fundamental tenets of Extreme Programming (XP) is that since requirements change every day, it doesn't make much sense to try to deal with them explicitly. Proponents of this approach lose not only requirements traceability, but the trust between customers and developers that can come solely from intensive, face-to-face negotiation.
The XP folks even have hip slogans to describe this phenomenon. Kent Beck used one to diagnose the failure of the C3 project on their Wiki Web site: " … the fundamental problem was [that] the Gold Owner and Goal Donor weren't the same. The customer feeding stories to the team didn't care about the same things as the managers evaluating the team's performance … The new customers wanted tweaks to the existing system more than they wanted to turn off the next mainframe payroll system. IT management wanted to turn off the next mainframe payroll system." Translation: In XP lingo, the Goal Donor is the customer representative who sits in the room with the coders, who explain that it's OK to change requirements midstream, while the Gold Owner is the project sponsor. In the case of C3 (a Y2K mainframe payroll replacement project), the Gold Owner "inexplicably" pulled the plug in February 2000, when, after four years of labor, it became apparent that the program (no doubt chock-full of cool features) was paying only one-third of the employees.
Would requirements review have saved C3? We can't say for certain, but we do know that "feature-itis," which comes at the expense of scheduling, is a predictable result of letting the programming team decide (and continuously change) the requirements priorities without informing the project sponsors.[21]
The alternatives
As will be shown later in the paper there is a quagmire of methodologies to choose from. This paper will not attempt to discuss all alternatives but will take a closer look at the following Agile Modeling, Rational Unified Process (RUP), CMM, CMMI and tailoring potential.
Agile Modeling
Scott ambler introduces the idea of agile modeling as an extension to XP or other complete practices:
Agile Modeling (AM) is a practices-based software process whose scope is to describe how to model and document in an effective and agile manner. On the AM home page I state that one of the goals of AM is to address the issue of how to apply modeling techniques on software projects taking an agile approach such as eXtreme Programming (XP) (Beck, 2000), Dynamic Systems Development Method (DSDM) (Stapleton, 1997), and SCRUM (Beedle & Schwaber, 2001) to name a few. Because the scope of XP is much greater than that of AM, XP covers the full development lifecycle, it is a candidate "base process" into which the techniques of AM may be tailored. Furthermore, although XP clearly includes modeling as part of its process it is not as explicit about how to do so as many developers would prefer. Hence an opportunity for AM. Luckily XP, like AM, is also an agile practices-based methodology which makes the conceptual fit between the two methods much easier than between AM and a prescriptive process such as the Unified Process (Kruchten, 2000; Ambler, 2001b), the topic of the essay Agile Modeling and the Unified Process. [22]
Scott gives an overview of the values, principles, and practices of Agile Modeling (AM):
Agile Modeling (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. Simply put, Agile Modeling (AM) is a collection of values, principles, and practices for modeling software that can be applied on a software development project in an effective and light-weight manner. Agile models are more effective than traditional models because they are just barely good, they don't have to be perfect. You may take an agile modeling approach to requirements, analysis, architecture, and design. ...
AM is not a prescriptive process, in other words it does not define detailed procedures for how to create a given type of model, instead it provides advice for how to be effective as a modeler. AM is not about less modeling, in fact many developers will find that they are doing more modeling following AM than they did in the past. AM is “touchy-feely”, it’s not hard and fast – think of AM as an art, not a science. ...
The values of AM, adopting and
extending those of eXtreme Programming, are communication, simplicity,
feedback, courage, and humility.
The keys to modeling success are to have effective communication between all
project stakeholders, to strive to develop the simplest solution possible that
meets all of your needs, to obtain feedback regarding your efforts often and
early, to have the courage to make and stick to your decisions, and to have the
humility to admit that you may not know everything, that others have value to
add to your project efforts.
AM is based on a collection of principles, such as the importance of assuming simplicity when you are
modeling and embracing change as you
are working because requirements do in fact change over time. You should
recognize that incremental change of
your system over time enables agility and that you should strive to obtain rapid feedback on your work to ensure
that it accurately reflects the needs of your project stakeholders. You
should model with a purpose, if you
don't know why you are working on something then you shouldn't be doing so, and
that you need multiple models in your
development toolkit to be effective. A critical concept is that models
are not necessarily documents, a realization that enables you travel light by discarding most of your
models once they have fulfilled their purpose. Agile modelers believe
that content is more important than
representation, that there are many ways you can model the same concept yet
still get it right. To be an effective modeler you need to know your tools and know your
models, and to be an effective teammate you should realize that everyone can learn from everyone else,
you should work with people's instincts,
and that open and honest communication
is often the best policy to follow to ensure effective teamwork. Finally,
a focus on quality work is important
because nobody likes to produce sloppy work and that local adaptation of AM to meet the exact needs of your environment
is important.
To model in an agile manner you will apply
AM's practices as appropriate. Fundamental
practices include creating several models
in parallel, applying the right
artifact(s) for the situation, and iterating
to another artifact to continue moving forward at a steady pace. Modeling in small increments, and not
attempting to create the magical "all encompassing model" from your
ivory tower, is also fundamental to your success as an agile modeler.
Because models are only abstract representations of software, abstractions that
may not be accurate, you should strive to prove
it with code to show that your ideas actually work in practice and not just
in theory. Active stakeholder
participation is critical to the success of your modeling efforts because
your project stakeholders know what they want and can provide you with the
feedback that you require. There are two fundamental reasons why you
create models, either you model to
understand an issue (such as how to design part of your system) or you model to communicate what your team is
doing (or has done). The principle of assume
simplicity is a supported by the practices of creating simple content by focusing only on the aspects that you
need to model and not attempting to creating a highly detailed modeling, depicting models simply via use of
simple notations, and using the simplest
tools to create your models. You travel light by discarding temporary models and updating
models only when it hurts. Communication is enabled by displaying models publicly, either on a
wall or internal web site, through collective
ownership of your project artifacts, through applying modeling standards, and by modeling with others. Your development efforts are greatly
enhanced when you consider testability,
apply patterns gently, and reuse existing artifacts. Because
you often need to integrate with other systems, including legacy databases as
well as web-based services, you will find that you need to formalize contract models with the owners of those systems. Read this essay for a better understanding
of how AM's practices fit together.
I would argue that AM is an agile approach to modeling, that at its core AM is
simply a collection of practices that reflect the principles and values shared
by many experienced software developers. My experience is that these practices
can be applied to most software development projects, you don't have to be
working on an project following an agile software process (such as XP) to take
advantage of the approaches described by AM, although one of AM's goals is to
explain how to model when following the XP approach. A project team doesn't
need to apply all of the practices, principles, and values of AM to benefit
from it -- I have always been a firm believer that you should tailor your
software process to reflect the unique needs of your environment -- although it
is my opinion that like XP you are much more likely to succeed if you do adopt
all of AM.[23]
As can be seen agile modeling may be beneficial to look at but will not entirely fill the gaps left by the XP process. Since agile modeling is designed with more thought towards the ability to tailor, use of some of its practices should be investigated to soften the extreme stance of XP toward things such as design documentation.
Rational Unified Process
“The Rational Unified Process® is a Web-enabled software engineering process that enhances team productivity and delivers software best practices to all team members. This e-coach is an easy-to-use online mentor that makes process practical by providing extensive guidelines, templates, and examples for all critical software development activities. RUP also includes e-business specific extensions that provide explicit guidance in areas such as business modeling, Web architectures and testing for the Web. RUP is a customizable framework, that is easily adapted to the way you work. It is tightly integrated with Rational tools, allowing development teams to gain the full benefits of Rational product features, the Unified Modeling Language (UML), and other industry best practices.“[24]
The Rational Unified Process can be tailored to include some of the practices of XP.[25] Some of the XP practices can be included directly and others would need to be modified.[26] The Rational Unified Process is a process framework that can be used to address the complete software development lifecycle including all activities necessary to deliver quality to the customer. This paper will not focus on the use of RUP to aid the completeness of XP but will focus on the CMMI as a standard guide to identify the missing and weak aspects of XP.
The Software CMM
Mark Paulk states, “The Capability Maturity Model for Software is a model for building organizational capability that has been widely adopted in the software community and beyond.” The Software Engineering Institute's (SEI) summary of the software CMM follows:
The Capability Maturity Model for Software describes the principles and practices underlying software process maturity and is intended to help software organizations improve the maturity of their software processes in terms of an evolutionary path from ad hoc, chaotic processes to mature, disciplined software processes. The CMM is organized into five maturity levels:
1) Initial. The software process is characterized as ad hoc, and occasionally even chaotic. Few processes are defined, and success depends on individual effort and heroics.
2) Repeatable. Basic project management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar applications.
3) Defined. The software process for both management and engineering activities is documented, standardized, and integrated into a standard software process for the organization. All projects use an approved, tailored version of the organization's standard software process for developing and maintaining software.
4) Managed. Detailed measures of the software process and product quality are collected. Both the software process and products are quantitatively understood and controlled.
5) Optimizing. Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies.
Predictability, effectiveness, and control of an organization's software processes are believed to improve as the organization moves up these five levels. While not rigorous, the empirical evidence to date supports this belief.
Except for Level 1, each maturity level is decomposed into several key process areas that indicate the areas an organization should focus on to improve its software process.
The key process areas at Level 2 focus on the software project's concerns related to establishing basic project management controls. They are Requirements Management, Software Project Planning, Software Project Tracking and Oversight, Software Subcontract Management, Software Quality Assurance, and Software Configuration Management.
The key process areas at Level 3 address both project and organizational issues, as the organization establishes an infrastructure that institutionalizes effective software engineering and management processes across all projects. They are Organization Process Focus, Organization Process Definition, Training Program, Integrated Software Management, Software Product Engineering, Intergroup Coordination, and Peer Reviews.
The key process areas at Level 4 focus on establishing a quantitative understanding of both the software process and the software work products being built. They are Quantitative Process Management and Software Quality Management.
The key process areas at Level 5 cover the issues that both the organization and the projects must address to implement continual, measurable software process improvement. They are Defect Prevention, Technology Change Management, and Process Change Management.
Each key process area is described in terms of the key practices that contribute to satisfying its goals. The key practices describe the infrastructure and activities that contribute most to the effective implementation and institutionalization of the key process area.[27]
Richard Bechtold states in the Essentials of Software Project Management, “The general premise behind this framework is that the more key practices you follow, the less risk you have on your project.”[28] Continuing with this notion later in the paper, the use of a CMMI compliant XP process will be considered as a synergistic risk lowering mechanism. The CMMI will be examined rather than the Software CMM as it incorporates the Software CMM and is intended eventually as a replacement. This replacement is currently scheduled for December 2003. The Software, Systems Engineering and Product Development CMMs are the scope of the initial CMMI Product Suite:
The SW-CMM, SE-CMM, and IPD-CMM are among several existing, widely-known models. The content and characteristics of these three models provide the basis for the initial CMM Integration Product Suite. The direction is to integrate the development characteristics and delivery methods of these and future capability models (CMs), which will enable users to reduce the cost of performing assessments and implementing improvements.
The initial CMM Integration Product Suite includes a framework for generating CMMISM products to meet business objectives/mission needs, and a set of CMMI products produced by the framework. The framework includes common elements and best features of the current models as well as rules and methods for generating CMMI products. Discipline-specific elements (e.g., software, systems engineering) of the CMMI Product Suite will provide the user with the ability to select elements applicable to specific situations.[29]
The CMMI
The SEI describes below the historical background of the CMMI and how it relates to the software CMM:
CMMI covers the same material as the SW-CMM, although some topics are given more extensive treatment that reflects the engineering community's learning over the past 10 years. Coverage for elements like Risk Management and Measurement and Analysis, for example, is crisper and more definitive than in the SW-CMM. One model is not more "official" than the other; CMMI builds on the experience gained in the SW-CMM and other models. Organizations that are using the SW-CMM can easily adjust to the expanded coverage that CMMI provides for the enterprise.
…
In the fall of 1997, a review of Software Engineering Institute (SEI) activities was conducted by the Office of the Under Secretary of Defense for Acquisition and Technology (hereafter referred to as OSD). And OSD-lead team comprised of government, industry, and the SEI decided to focus on developing an integrated framework for maturity model and associated products. As a result of interest expressed by the model user community, the SEI had already initiated an effort to develop a framework to integrate existing models.
The CMMISM effort is intended to support process and product improvement and to reduce redundancy and eliminate inconsistency when using separate stand-alone models. The goal is to improve efficiency, return on investment, and effectiveness by using models that integrate disciplines such as systems engineering and software engineering that are inseparable in a systems development endeavor.
The resulting CMMI models are referred to as Capability Maturity Model- Integrated-Discipline, where Discipline is the name of the discipline covered by the model. For example, the CMMI for Systems Engineering is designated CMMI-SE; for Systems Engineering and Software Engineering, the designation is CMMI-SE/SW. These models have the same structure and similar content as previous Capability Maturity Models (CMMs) and Capability Models, and are tailorable to an organization's mission/business objectives.
The CMMI requirements are published in a specification entitled "A" Specification for the CMMI Product Suite. This document (referred to hereafter as the A-Spec) is available on the Web at http://www.sei.cmu.edu/cmmi/org-docs/aspec1.4.html
The CMMI Project is a collaborative effort among industry, government, and the SEI. It is sponsored by OSD and the National Defense Industrial Association (NDIA) Systems Engineering Committee.[30]