Do projects today still go over budget and over schedule? Are requirements still changing even though we do not want them to? Are we still building systems at great cost and effort that woefully fail to satisfy the customer's needs? Yes, but how can this be? In a world where the Capability Maturity Model® (CMM®) has taken such a grip on the collective engineering consciousness, and government contractors have widely embraced the climb up the CMM ladder, how can bad things continue to happen to good programs?

Perhaps we are not planning enough. Perhaps we are not measuring enough, or providing enough management or technical oversight. Perhaps we lack true commitment to process discipline and need to create more comprehensive, accurate models before we attempt to implement these systems. Or perhaps something else is going on, and we should stop trying to hit everything with the same hammer.

First, consider that customer needs change, technology evolves, and evolution is accelerating. Markets shift with increasing speed and even the missions of government organizations are changing more rapidly. Therefore, requirements are likely to change over the course of a project.

Second, consider that systems are increasingly sophisticated, built to address increasingly complex problems. The customer may hardly grasp the problem, much less the best system to address it. Therefore, requirements are likely to be vague or speculative where they should be specific.

Third, consider that systems are ultimately built by people, not by tools, methodologies, nor key practices. When people attempt to use evolving technologies (with which they are not fully familiar) and build complex systems (which they do not fully understand), they are unable to construct reliable plans. Even risk planning demands sufficient understanding of problems and solutions to recognize risks and predict adequate mitigation strategies. So we try to gain enough knowledge for adequate planning by building models of the system and prototypes. Can we gain adequate knowledge of the system from models based on our initially inadequate knowledge? Can we bootstrap our knowledge using extensive models? Can we keep such extensive models up to date?

The INCOSE Handbook [1] depicts the phases of a conventional system life cycle, beginning with Needs Analysis, and leading to Concept Exploration and Prototyping before proceeding with Development and Production. One of the most important points of these earlier phases is to gain sufficient knowledge about the customer's needs and alternative solution approaches to enable credible planning of optimum solution development with tolerable risk. The intent is that, for the most part, uncertainty and risk have been beaten out of the system requirements, designing, and planning before serious implementation commences.

However, consider finally, that time is the costliest resource. Until a usable system is delivered, the customer has nothing to show for its investment. Worse, when needs are changing, the value of the original system as specified, however optimum it was at the time of its conception, depreciates daily. In this scenario, extensive up-front analysis and throwaway prototypes are devalued as risk mitigation alternatives.

So what is left for us but to anticipate potential future requirements and risks, build alternatives and flexibility into our system designs and plans, and thus create even more complex, expensive, slower projects?

Agile development proposes a different strategy.

Agile thinking begins with a stark economic perspective: There can be no return on investment until the system starts operating. Consequently, you should at least strive to get some operable sort of system of some value to the customer as soon as possible. Further, you should continue to deliver system updates of maximum value in minimum time. Short delivery cycles also enable you to stay on target with the customer's changing value criteria.

Moreover, evolving the product via short delivery cycles reflects another fundamental assertion of agile development: Your only real knowledge comes from a working system. Intermediate artifacts of development, however formal and well inspected, are still imperfect representations of the system. No metric of intermediate artifacts measures project progress and the potential value of the developing system nearly as well as users exercising some version of the actual system. Intermediate artifacts are no guarantee of the performance or utility of the system as implemented.

This minimalist view of agile development comes courtesy of Tom Gilb's "Evolutionary Delivery Versus the Waterfall Model" [2]. Agile development is an urgent push to get feedback on the developing system via customers using the system. All the other techniques ascribed to agile development may be perceived as supporting shorter, evolutionary delivery cycles, and providing maximum customer benefit and feedback in the shortest interval. It is the ultimate risk reduction strategy.

A profound shift in mindset distinguishes agile development from conventional approaches heavy on planning and up-front analysis. As expressed by the Agile Alliance [3], agile development emphasizes:

"Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.
That is, while there is value in the items on the right, we value the items on the left more."

In short, agile development regards system development primarily as a learning process. This perception alters the conventional risk/benefit tradeoff. For example, detailed planning for the long-term is seen as having little value; the details (at least) will undoubtedly change as the project team learns more during the early delivery cycles. Similarly, agile development prefers to substitute frequent, informal person-to-person (and optimally, face-to-face) interaction for formal textual or graphical documents, which always fail to be comprehensive and are impossible to maintain at an appropriate rate of change the closer they come to being comprehensive.

Some aspect of your project can benefit from increased agility. You can become more agile by adopting one or more of the following practices:

• Shorter delivery cycles, shorter focus.
• Agile sub-team(s).
• Selected agile techniques.

The best starting point is to deliver working software to your customer more often than you currently do. Gilb [2] recommends each delivery should take less than 5 percent of the project's budget and schedule, preferably closer to 2 percent. Other agile proponents recommend delivery every one to 13 weeks. Choose what works best for your project. Treat the master plan as only a speculative projection of the goals for each release. You and your customer choose whatever goals make sense for the next release when you are faced with that release, regardless of the original master plan. Rather than depending on an elaborate master plan, project control consists of continually correcting the project course, and planning each release as it occurs.

If your project cannot adopt agile behavior overall, find sub-teams willing and able to be agile. Boehm [4] points out that agile versus up-front planning/analysis orientation can be treated as two ends of a continuum rather than absolutely in conflict. Consider Figure 1, derived from a similar figure by Cockburn [5]. Agile development fits most easily with small (less than 50 developers), non-life-critical projects. On the other hand, on larger or life-critical projects, the advantages of heavy up-front planning and analysis outweigh its disadvantages as project logistics become very complicated and/or the customer's willingness to tolerate defects in the delivered system decreases.

Figure 1: Area of Dominance for Agile versus Conventional Development
(Click on image above to show full-size version in pop-up window.)

However, a large project need not be wholly planned or agile. Where you have considerable experience with and understanding of a large or complicated system element, or safety or correct operation is otherwise at a premium, extended planning and analysis may be your best strategy. More volatile or less understood system elements deserve a more agile treatment. Alternately, select development sub-teams for agile practice based on their size and cultural outlook. Grenning [6] describes the successful insertion of a small agile team effort into a larger, more formally planned project. Overall, the benefits of agile techniques will be much constrained using a piecemeal approach, but will be an improvement over ignoring agility entirely.

You can adopt other techniques associated with agile development regardless of how agile you are. They can improve any project. For example, pair programming has been shown in studies by Williams [7] to improve quality and schedule at reasonable cost (an increase of 15 percent). Writing automated unit tests first is a clever way of inducing developers to not only unit test their code efficiently, but also to write their code efficiently without superfluous logic. Refactoring [8] is a set of disciplined, prescriptive techniques for safe design simplification and improvement that every software developer should practice.

Most importantly, look carefully at your practices with the principles of agile development in mind. Ultimately, agile development is about people because projects only improve when people become more effective. Recognize human nature and try to leverage it to your best advantage. When developers are told what tasks to do in a narrow, piecemeal fashion, they tend to do just that and no more; when challenged to do whatever it takes to accomplish project goals, they will discover what needs to be done and task themselves to do it.

Critics have raised the following serious issues about agile development:

• It is just an excuse to "hack."
• Agile cannot scale up to large projects.
• Agile cannot work with distributed teams.
• Agile cannot handle serious architectural issues.
• My customers/developers will not work that way.

The first concern is that agile development is just another new euphemism for hacking; that is, process anarchy. In fact, agile development can be practiced with any degree of process discipline, as can more conventional development styles. eXtreme Programming (XP), for example, is extremely disciplined; XP guidance prescribes an explicit set of well-specified practices and tolerates very little deviation from them.

Obviously, as the size of a project grows, agile development becomes more challenging. However, we have yet to see compelling evidence that any approach to large projects is consistently successful! A 1995 Standish Group [9] survey showed that only 16 percent of software development projects finished on time and under budget, 31 percent were canceled, and the remaining 53 percent overran by an average of 189 percent on cost and 222 percent on schedule.

On the other hand, we have found no reports of agile development being used on very large projects (more than 250 developers). Perhaps we should regard this lack of experience as a point in favor of agile development: It has yet to fail on large projects! More seriously, we believe even a large project can be more agile. You will have to document more decisions on a large project than a small one, but delivering early versions of a working system is still key. You may not be able to deliver with 5 percent of your schedule/budget, but even a modest number of additional delivery cycles can yield significant improvements. Spuck [10] reports the advantages of an agile approach to several military systems using six- to 12-month delivery cycles. IBM Federal Systems Division had a 200 person-year project delivered in 45 increments with each delivery on time and under budget [2].

Similarly, distributed teams have always been a source of problems for any project. Formal documentation alone cannot solve these problems. In fact, written documents are the leanest form of communication [11]. Consider each type of information and the medium that best supports its characteristics. More frequent and interactive communications via phone, video link, Web pages, e-mail list servers, and distributed configuration management and group-editing tools can enhance agility despite distance. Consider how you might create mechanisms that enable developers to dynamically subscribe to the project information sources they need, rather than control the flow from a central authority.

Perhaps the most serious concern with agile development is that the lack of sufficient up-front planning and design will lead a project to "code itself into a blind alley," especially with respect to non-functional requirements such as performance. People worry that an unforeseen problem will surface in a later development cycle, revealing the current system design as invalid and demanding extensive rework. Of course, attempting to resolve all the major design issues up front is no guarantee of avoiding unforeseen problems either! The point of agile development is to carefully reconsider the cost/benefit of up-front design, and to choose the point that makes sense between the extremes of no design and the illusion of a complete design.

Some design issues may be critical and yet so obscure that you need to invest in a throwaway prototype(s) to clarify the tradeoffs. Otherwise, you can prioritize the goals for your early deliveries so as to address the most pervasive architectural issues. Having some notion of what aspects of a project are more likely to be stable or volatile can help (as long as you do not bet too heavily on your prediction). In general, agile development will favor simple, flexible architectures. By the way, agile development is not limited to object-oriented software, but the facility with which an object-oriented approach enables flexible architecture makes it a good match to agile development.

Finally, there is the assertion that agile development is culturally incompatible with some projects (e.g., "My customer will never go for that!"). Agile proponents would be the last to suggest that you can successfully foist some practice on people who do not want it. Our advice is, "Try it, they might like it." Given permission to try and fail and try again, we predict many teams will discover they are more effective using some mix of agile techniques, and moreover, that they enjoy it.

Success is no small part of that enjoyment: The positive feedback provided by rapidly delivering and improving upon a small release is a powerful psychological morale builder for both customers and developers. Ironically, developers used to complain that managers would push them to code prematurely, shortchanging design. The difference here is that the system is not expected to be perfect on the first release (not that it ever was, anyway). The project team has multiple cycles to correct mistakes in requirements, design, code, methodology, and estimation of cost/schedule. Given the chance, people enjoy learning, especially when they have the opportunity to improve based on what they have learned.

Can you afford to be more agile? Can you afford not to be? System complexity is not decreasing. Human needs and technology are not evolving slower or more predictably. Every project should want the benefits of agility: faster feedback, more satisfied customers, and more motivated employees.

Every project can become more agile if it is so desired. Just start doing it! Stop finding reasons your project cannot fit the mold of agile development, and start finding ways to incorporate these ideas into your day-to-day practices. Identify just one place in your project willing to adopt an agile technique, and try out one that will provide the most value. Plan multiple, evolutionary deliveries to increase customer involvement and improve risk mitigation. Try test-first development and/or pair programming to improve design and code quality. If a technique does not work out, try a different one. When a technique proves successful, try to add another, and/or expand your use of it. Keep at it until you find the optimal mix of agility that works for your project and organization.

The question is not, "Should you be more agile?" but, "How agile can you be?"

1. International Council on Systems Engineering (INCOSE). Systems Engineering Handbook - A "How To" Guide for All Engineers, Release 1.0. Seattle: INCOSE, 1998.
2. Gilb, Tom. "Evolutionary Delivery versus the Waterfall Model." ACM Sigsoft Software Engineering Notes 10.3: July 1985.
3. Agile Alliance Web site. Available at www.agilealliance.org.
4. Boehm, Barry. "Get Ready for Agile Methods, with Care." IEEE Computer Jan. 2002: 64-69.
5. Cockburn, Alistair. Agile Software Development. Boston: Addison-Wesley, 2002.
6. Grenning, James. "Launching Extreme Programming at a Process-Intensive Company." IEEE Software Nov./Dec. 2001.
7. Williams, Laurie, Robert Kessler, Ward Cunningham, and Ron Jeffries. "Strengthening the Case for Pair Programming." IEEE Software July/Aug. 2000.
8. Fowler, Martin, Refactoring. Reading: Addison-Wesley, 1999.
9. The Standish Group. "The Chaos Report." 1995. Available at www.scs.carleton.ca/~beau/PM/Standish-Report.html.
10. Spuck, W. H. "Management of Rapid Development Projects." Jet Propulsion Laboratory, D-8415, April 8, 1991.
11. Daft, R. L. Organization Theory and Design. Saint Paul: West Publishing Company, 1992.

Rich McCabe is a principal member of the Technical Staff at the Software Productivity Consortium. McCabe co-authored the consortium's Object-Oriented Approach to Software-Intensive Systems (OOASIS) methodology. He also has headed the consortium's pioneering work in the product-line approach for systematic reuse since its inception in the early 1990s. Outside the consortium, he has nearly 15 years of software and system development experience with Bell Laboratories and other firms.

Software Productivity Consortium
2214 Rock Hill Road
Herndon, VA 20170-4227
Phone: (703) 742-7289
Fax: (703) 742-7200
E-mail: mccabe@software.org

Michael Polen is a senior member of the Technical Staff at the Software Productivity Consortium. He co-authored the consortium's Object-Oriented Approach to Software-Intensive Systems (OOASIS) methodology and consults with consortium members on its practice. Lately, Polen is merging OOASIS with agile techniques. He has more than 11 years of software and system development experience with Motorola, Booz-Allen & Hamilton, and other firms.

Software Productivity Consortium
2214 Rock Hill Road
Herndon, VA 20170-4227
Phone: (703) 742-7281
Fax: (703) 742-7200
E-mail: polenm@software.org

® Capability Maturity Model and CMM are registered in the U.S. Patent and Trademark Office.