You are on page 1of 11

November 2004

An Introduction to Agile Software Development
by Victor Szalvay, co-founder
Danube Technologies, Inc.
Web site: http://www.danube.com
Web log: http://danube.com/blog/
12011 Bel-Red Rd. Suite 201
Bellevue, WA 98005
(425) 688-0888, ext. 812

Introduction
This paper is an introduction to the Agile school of software development, and is primarily
targeted at IT managers and CXOs with an interest in improving development productivity.
What is Agile? How can Agile help improve my organization? First, I introduce the two broad
schools of thought when it comes to software development: traditional sequential, a.k.a. “the
waterfall method”, and iterative methods of which Agile is a subset. My objective is to
demonstrate the short-comings of the waterfall approach while providing a solution in iterative,
and more specifically, Agile methods.

Part I – Shortcomings of Traditional Waterfall Approach
The essence of waterfall software development is that complex software systems can be built in a
sequential, phase-wise manner where all of the requirements are gathered at the beginning, all of
the design is completed next, and finally the master design is implemented into production
quality software. This approach holds that complex systems can be built in a single pass, without
going back and revisiting requirements or design ideas in light of changing business or
technology conditions. It was first introduced in an article written by Winston Royce in 1970,
primarily intended for use in government projects1.
Waterfall equates software development to a production line conveyor belt.
“Requirements analysts” compile the system specifications until they pass the finished
requirements specification document to “software designers” who plan the software system and
create diagrams documenting how the code should be written. The design diagrams are then
passed to the “developers” who implement the code from the design (See Figure 1).
Under the waterfall approach, traditional IT managers have made valiant efforts to craft
and adhere to large-scale development plans. These plans are typically laid out in advance of
development projects using Gantt or PERT charts to map detailed tasks and dependencies for
each member of the development group months or years down the line. However, studies of past
software projects show that only 9% to 16% are considered on-time and on-budget2. In this
article, I attempt to summarize current thinking among computer scientists on why waterfall fails
in so many cases. I also explore a leading alternative to waterfall: “Agile” methods that focus on

Copyright © 2004 Danube Technologies, Inc. All rights reserved.

design. In Figure 1. the system must have a web site with e-commerce capability that can handle 10. One of the biggest problems with waterfall is that it assumes that all project requirements can be accurately gathered at the beginning of the project. Figure 1 Traditional Methods: sequential phased approach Project 1. The cost of change in a waterfall project increases exponentially over time because the developer is forced to make any and all project decisions at the beginning of the project. All rights reserved. Requirements 2. the first block represents the requirements analysis phase of a software development project.3 This means that the requirements typically change outside of the requirements phase in the form of “change orders”. Requirements define what developers are to build. and testing continue throughout the project lifecycle. Page 2 incremental and iterative development where requirements. scalability and concurrent user support. user roles and restrictions. As a start. Once finished. browser or OS support. the SRS is sent over the fence to the designers while the requirements analysts go to work on the next project. consider the areas that must be addressed: business rules and exceptions. it is inevitable that attempts at up-front requirements specification will leave out some very important details simply because the stakeholders cannot tell developers everything about the system at the beginning of the project. Analysts slave for weeks or months compiling everything they can gleam about the proposed system into comprehensive “Software Requirements Specification” (SRS) documents. Imagine a scenario where you engage a software group to build a critical software system. Do you think you could provide every last detail the developers need to know right off the bat? I have yet to encounter such a customer and I am hard pressed to think I ever will. Code 4.000 purchases per hour. By virtue of a requirements change. and in many waterfall projects this can be very costly. In fact. Inc. user interface standards. . the intricately planned design can be affected dramatically. the requirements are the features and specifications of the system. which will in turn affect any implementation and test strategies.999% of the time. What if your business needs are still emerging and certain aspects of the system are rapidly changing or cannot be defined yet? Business climates and objectives often change Copyright © 2004 Danube Technologies. Architecture & 3. or the system must be accessible 99. implementation. For example. Deploy Analysis Design Phase Up-front Requirements Analysis What are requirements? From the stakeholder’s perspective. Test 5.

a national test preparation organization commissioned my company to build a simulator for an upcoming standardized test. waterfall projects allocate copious effort detailing every possible risk. People need to see and feel something before they really know what they want. But this is what waterfall asks customers to do: specify the entire system without having a chance to periodically see the progress and make adjustments to the requirements as needed. has no laws or clear certainties on which to build.g. . and artistry. software is almost always flawed or sub-optimized.).. If I tried to close my eyes and draw the same picture. especially in today’s age of instant information. Software development is innovation. Also consider that the building blocks of software projects is usually other software systems (e. discovery. Can you afford to lock your business into a rigid long-term project where the cost of change grows exponentially? For example. functional software. Software development. Because the foundations of software development are inherently unstable and unreliable. Page 3 rapidly. and emerging requirements presents a very large challenge to waterfall projects because by definition all requirements must be captured up-front at the risk of costly changes later. programming languages. Bridge building relies on physical and mathematical laws. All software systems are imperfect because they cannot be built with mathematical or physical certainty. Inc. database platforms. Markets are forcing the software development community to respond with flexible development plans that flatten the cost of change. The problem of undefined. Software Development is more like New Product Development than Manufacturing Software development is a highly complex field with countless variables impacting the system. etc. As a result. But is it possible Copyright © 2004 Danube Technologies. however. when I draw a picture I need to see the drawing as I progress. it would prove far less successful. All rights reserved. changing. the requirements are solicited from the user and some time later the finished product is presented to the user. It is therefore fair to say that software development is more akin to new product research and development than it is to assembly-line style manufacturing. The “I’ll Know it When I See It” (IKIWISI) law says that software development customers can better describe what they really want after seeing and trying working. Waterfall is an “over the fence” approach. In fact. organizations developing software must realize variables exist that are largely outside of management control. Although I’m a terrible artist. mitigation plan. and those systems that act as building blocks contain bugs and cannot be relied on with certainty. cookie- cutter solutions4. The waterfall methodology assumes that up-front planning is enough to take into account all variables that could impact the development process. This is entirely unnatural because customers find it difficult to specify software perfectly without seeing it evolve and progress. each foray into a development project presents new and difficult challenges that cannot be overcome with one-size-fits-all. Since the test itself had not been released yet. But the system had to be done shortly after the tests were released. the types of questions that would appear on the test were unknown when we started development. I often use a “drawing” analogy to help explain this effect. and contingency.

This concept of iterative development hails from the “lean development” era of the 1980s described above where Japanese auto makers made tremendous efficiency and innovation increases simply by removing the phased. The idea of revisiting phases over and over is called “incremental and iterative development” (IID). sequential approach and implementing an iterative approach. supplanted the sequential “Phased Program Planning” (PPP) approach to new product development with a flexible. waterfall-style approaches to new product development were effectively abandoned outside the software development industry.5 Waterfall therefore equates software development to an assembly line. The development lifecycle is cut up into increments or “iterations” and each iteration touches on each of the traditional “phases” of development. result in a successful project each time. with IID requirements is an ongoing process that is periodically revisited. defined processes can be established that. Honda. . since the late 1970s product development companies lead by Toyota. Inc. Part II . holistic approach where the traditional phases of development overlap throughout the product lifecycle. The inherent uncertainty and complexity in all software projects requires an adaptive development plan to cope with uncertainty and a high number of unknown variables. the second is Y. Following the lead of Japanese auto makers. 6 The results were a dramatic improvement in cost and development time to market and ultimately lead to the popular rise of “lean development” and “just-in-time manufacturing”.8 IID allows for multiple “passes”. over a project lifecycle to properly address complexities and risk factors. and the result is always Z. 3M.Iterative and Agile methods Incremental and Iterative Development The simple ability to revisit the “phases” of development dramatically improves project efficiency. or iterations. The first step is X.7 But longstanding insistence from IT managers to categorize software development as a straightforward assembly line progression has kept the software industry from evolving to better methods. the benefits of which other new product development industries have been reaping for decades. All rights reserved. when used sequentially. IID processes continually capture the requirements iteration after iteration Interestingly. HP. in the 1990s sequential. It’s ironic that a cutting edge technology field like software is so far behind more traditional engineering fields in terms of development methods. On the contrary. Winston Royce (of waterfall process fame) later noted that his ideas were incorrectly interpreted and that a “single pass” framework would never work (his article actually advocates at least a second pass). Can research really be relegated to a series of steps that when performed in sequence result in a new product? If this formulaic approach were adequate. Page 4 to predict any and all variables that could possibly affect a software project? The empirical answer is “no” considering the limited success of waterfall projects. Almost no software system is so simple that the development can be entirely scripted from beginning to end. medical researchers could simply plug variables into equations to discover new medicines. Each Copyright © 2004 Danube Technologies. As new requirements surface and as the scope changes. Canon. Fujitsu. where prototypes were developed for short-term milestones (see Figure 2). For example. and NEC.

Spiral. the success of lean development has influenced a broad class of “iterative” software methods including the Unified Process. Nevertheless. 1986. Page 5 phase was actually a layer that continued throughout the entire development lifecycle. Agile visionary Kent Beck challenged the traditional cost of change curve evidenced by Barry Boehm11 over twenty years ago. and they further increase the iterative nature of the software lifecycle by tightening design-code-test loop to at least once a day (if not much more frequently) as opposed to once per iteration. Agile methods: Embracing Change Agile methods stress productivity and values over heavy-weight process overhead and artifacts. 137-146. "The New New Product Development Game". Beck’s idealistic “flat” cost of change curve has since been revised and softened by Alister Cockburn 13 and Scott Ambler 14 to reflect modern corporate realities. Agile methods promote a number of engineering practices that enable cost effective change. Takeuchi and I. All rights reserved. Inc. Figure 2 Iterative approach: Overlapping phases of development Phase 1 2 3 4 5 6 Source: Adapted from H.. pp. was written and signed in 2001 although Agile methods have existed since the early 90s. Agile methods promote an iterative mechanism for producing software. “Test driven development” is a quality-first approach where developer tests (called unit tests) are written prior to the functional code itself. Harvard Business Rev. Beck’s model espouses that the cost of change can be inexpensive even late in the project lifecycle while maintaining or increasing system quality12. and implementation cycle was revisited for each short-term milestone. the requirements. Agile ideals can be applied to reduce the cost of change throughout the software lifecycle even if the cost of change is not perfectly flat. The Agile Manifesto10. like rapid production and minimum up-front design 15. Evo. design. a concise summary of Agile values. Rather than focusing a lot of effort on big up front design analysis. and Agile methods. To accomplish this “flatter” cost of change curve. . It is the role of the automated test suite built around the rapidly evolving code to act as a harness that Copyright © 2004 Danube Technologies. small increments of functional code are produced according to immediate business need. Jan. Author and speaker Martin Fowler describes testing and continuous integration as the “enabling” Agile practices that allow for the advantages gained. This “concurrent” development approach created an atmosphere of trial-and-error experimentation and learning that ultimately broke down the status quo and led to efficient innovation.9 Although direct analogies between industries are never seamless. Nonaka.

a popular Agile project management method. even late in the project lifecycle. project plans are continuously inspected and adapted based on the empirical reality of the project. Scrum holds that straightforward defined processes alone cannot be used to effectively manage complex and dynamic software projects. Agile Project Management: Empirical Process Scrum. . changing software projects.16 As a result. Although it has been attempted in the past. Agile project management approaches balance the four variables in software development while keeping in mind the limits associated with new product development. Inc. an empirical or adaptive management approach is employed to measure and adjust the chemical process periodically to achieve the desired outcome. the manufacturing industry has long known that certain chemical processes. there cannot be a single exhaustive library of defined processes to handle every situation that could possibly surface during a software project. Page 6 allows developers to make aggressive code changes without fear of undetected regression failure. Risk factors and emerging requirements complicate software development to a point where defined processes fall short. in the Scrum process. In fact. for example. In Copyright © 2004 Danube Technologies. Figure 3: Cost of Change Curves Cost of Change Boehm Cockburn/Ambler Beck Project Lifecycle Progress Object technology and modern integrated development environments (IDEs) boasting built-in testing and refactoring mechanisms negate the expensive Boehm cost of change curve and allow for the cheap change. All rights reserved. Instead. introduced the concept of empirical process control for the management of complex. are too difficult to script and define.

Teams can work independently for a while but the code base never diverges for long periods of time. Agile methods have their conceptual roots in the Japanese manufacturing productivity boom of the 1980s 19. Consider for example the “small batch” principle: things produced in smaller batches are of higher quality and efficiency because the feedback loop is short. In reality. organizations can reduce risks by leaving options open to decide at a better time when more accurate information is available. controls can be adjusted more frequently. These factors are interconnected. § Quality – Cut corners by reducing quality. Agile methods encourage delaying irreversible decisions until the last responsible moment. Many software development organizations that implement Agile software development are finding they get something they never expected: options. and the development process dictates the fourth.20 Agile Requirements: A Focus on Business ROI Agile projects avoid “up-front” requirements gathering for the reasons stated above: customers cannot effectively produce all requirements in high enough detail for implementation to occur at the beginning of a project. middle and upper management often assumes that all four of these factors could be dictated to the development team under the waterfall approach. Lean Thinking Another effective way to analyze how Agile methods increase efficiencies is to apply lean manufacturing principles to software development. It is therefore unreasonable to assume that management can control all four of these factors. Available money impacts the amount of effort put into the system. Inc. management can pick values for three of the four factors at most. Agile values a high visibility and customer involvement. Third. § Schedule – A software project is impacted as the timeline is changed. The frequent demonstration and release of software common in Agile approaches Copyright © 2004 Danube Technologies.18 The highly complex and uncertain nature of software development makes this expectation of full control unrealistic. thereby reducing the risks associated with large integrations at the tail end of projects. § Cost – or Effort. Rather than locking into decisions at the beginning of a project. § Requirements – The scope of the work that needs to be done can be increased or decreased to affect the project. when one changes at least one other factor must also change. . However software development cannot be described by a simple linear process because it cannot be predicted accurately in advance. All rights reserved. Although cross-industry analysis can be tenuous. Second. and resources are utilized efficiently to avoid “queuing” (see “queuing theory” and the theory of constraints). Page 7 software development there are four broad control factors.17 Because software development is often considered a sequential. Customers may not want to make decisions about the system until they have more information. the concept of frequent or continuous integration keep software development teams synchronized. linear process.

Convergence with Agile One of the most commonly asked questions by those examining Agile is. But we already know that we cannot plan for everything in advance. which is the amount of estimated effort a team can complete in a time-boxed iteration. One of the biggest advantages to IID is that work can begin before all of the requirements are known. Page 8 gives customers a chance to “try software” periodically and provide feedback. Each point of the chart in Figure 4 represents an iteration (or Sprint in Scrum). All rights reserved. Because we can change direction rapidly (every iteration) and the cost of change is low. For example. a Project Burndown Chart can be utilized to estimate the eventual conclusion of an estimated backlog of work. Many organizations are not fully staffed with business analysts cranking out reams of requirements specs. Agile processes like Scrum and XP use a concept called velocity. “how do you know when the software will be finished if there’s no up-front plan?” and the obligatory follow up question. and the Y-axis represents the total estimated effort remaining for the backlog. Agile helps companies produce the “right product”.21 This is largely because the unused features were specified in some up- front plan before the ratio of their cost to value was considered or even knowable. We therefore built the system in a database independent manner. Of course. How do Agile projects prioritize work? A study by the Standish Group shows that in typical software systems 45 percent of the features are never actually used by users and another 19% are only rare used. An iterative approach allows customers to delay decisions as well. IID is ideally suited then to take on bite-sized chunks of requirements that the customer can easily digest. in our experience often the bottleneck in the development process has been the lack of availability of customer domain experts for detailed requirements analysis. a trendline can be established through the points to create a velocity (work the team can complete per iteration). “how can we budget for such a project?” It sounds a bit scary: let’s start working in short iterative cycles that yield demonstrable software without actually planning everything in advance. and (luckily) a few weeks before the product launch a new version was released by one of the database vendors that solved our problem. The Agile answer is to examine project progress empirically. Once a team has established a velocity. we recently delayed selecting a database package for an application because some of the desired features were not available at that time in the options we had to choose from. there is a valuable opportunity for the customer to re-examine business factors at the beginning of each iteration to select features for inclusion in the current iteration according to business ROI. The trendline can then be Copyright © 2004 Danube Technologies. Decisions can be delayed to some future iteration when better information or technology is available to optimize the choice. but in the end it is the customer that decides what the development team builds. Quite the contrary. rather than trying to guess how things might shape up a priori. This is especially the case with small businesses where domain experts wear many hats and often cannot commit to two or three months of straight requirements analysis. Focusing on high business value features first is therefore a critical component of efficient Agile development. the development team must bring technical risks to the customer. As iterations progress. . Inc.

22 That is. quality). Through the first nine iterations. Figure 4: Product Burndown Chart with Velocity 1200 Velocity: 5 story pts per sprint 1000 800 Story Points 600 Velocity: 25 story pts per sprint 400 200 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Sprints Figure 3 is a Product Burndown Chart representation of a typical project. schedule. In this case. Copyright © 2004 Danube Technologies. the product scope had been adjusted down so that the project could be completed by the budgeted 20th iteration. All rights reserved. Page 9 extrapolated to determine the X-intercept. And quality is non-negotiable. but it is certain that the highest priority features will go into production and that they will be built well. Notice also that the velocity (slope) changed for the better. . Inc. There is no guarantee all features will be built. especially considering the Standish report cited above that nearly 65% of features are never or rarely used in reality. To answer the questions above. By iteration ten. if the timeline and cost variables are fixed. then the scope of the work must be variable or the definition of the scope must be at a high level so the robustness of each feature can be negotiated. work will proceed on the highest priority requirements first to ensure that the most important things get done before a deadline or the money runs out. which represents the empirical estimate of the completion date. Agile methods tell us that the customer cannot specify all four of the software development variables (cost. perhaps the reduction in scope was accompanied by the removal of critical impediments to efficient progress. the project’s “burndown” trendline indicated an X-intercept well into the future (off the charts!). scope. For complex problems like project convergence. adhering to strict code and testing standards. the features built should always be high quality. Going to production with high priority features is better than never going to production at all.

but how do you do agile? Scrum is a very good place to start on the management side. Prentice Hall. . Addison-Wesley. a highly effective agile project management method. and the most recent 2004 Standish Group CHAOS report on the success of software projects shows a dramatic improvement in the failure rate of software projects. Addison-Wesley. Mike Beedle. Ken Schwaber. In 1994. “Extreme Programming Explained: Embrace Change”. Unlike bridge building. This book is about “Scrum”. Although waterfall is often referred to as “traditional”. Copyright © 2004 Danube Technologies. So what do your developers do differently in agile? Extreme Programming (or XP) advocates engineering principles such as pair programming and test driven development and Beck’s book is the de facto authority. It also delivers outstanding tools for implementing agile. Inc. It has the most comprehensive empirical evidence for Agile/Iterative of any book currently on the market. It also nicely summarizes and contrasts some of the major Agile/Iterative approaches such as Scrum. software engineering has had a very short history relative to other engineering disciplines. and the Unified Process. Mary Poppendieck. 2000. 2003. “Agile Software Development with Scrum”. and is therefore in a rapidly evolving infancy as an engineering discipline. It contains the most compelling case for agile over sequential development I have yet to uncover. Tom Poppendieck. Agile is simply the latest theory that is widely replacing the waterfall approach that itself will change and evolve well into the future. tried and true history of waterfall software development is incorrect. sometimes I wish I could ask the author for a list of good books or articles to further my knowledge on the subject. Addison-Wesley. software development is not built on thousands of years of trial and error. 2003. XP. Kent Beck. Page 10 Conclusion But does Agile/IID work? Of course the proof is always in the pudding.25 References After reading an introductory article. Below are a few good starting points for anyone interested in learning more about agile software development. “Agile & Iterative Development: A Manager’s Guide”. Craig Larman. much of this article leans on the Poppendieck’s work. Standish reported a 31% failure rate that has improved to 15% in 2004. This book is outstanding and each page seems to offer a valuable nugget of information. 2001. “Lean Software Development An Agile Toolkit”. This book should be read by any manager interested in Agile. Theory and rhetoric are nice.24 The notion that Agile is a radical deviation from the long established. All rights reserved. 23 Standish Chairman Jim Johnson attributes the improvement to smaller projects using iterative processes as opposed to the waterfall method.

softwaremag. 89-94 5 Standish Group International. Tom Poppendieck. 2000. “The New New Product Development Game”. IEEE CS Press. “Agile Software Development with Scrum”. 137-146. IEEE CS Press.standishgroup. 13 Reexamining the Cost of Change Curve. 1994. 328-339. 137-146. pp. 23 Standish Group International.php 3 Kent Beck.php 6 I. “Iterative and Incremental Development: A Brief History”. pp.com/articleshttps://www.scribd.com/designDead. 2001. pp. see: Mary Poppendieck. pp. http://martinfowler. and for the same ethical implications software developers resent this charge. pp.com/L. Addison-Wesley. Addison-Wesley. Software developers should always aim for high quality software. H. Agile Modeling Essays excerpted from the book “The Object Primer. 2003. 22 Mary Poppendieck. “Software Engineering Economics”. by Scott Ambler. “Lean Software Development An Agile Toolkit”. Prentice Hall. Proc. software developers find it very objectionable when asked to skimp on quality. Takeuchi. pp. http://www1. Developers write only robust tests and supercomputers will write and compile code until all tests pass.com//sample_research/chaos_1994_1. Inc.html . “Chaos Chronicals”. p 32.. 19 The Scrum Agile method has its roots in the Nonaka-Takeuchi article referenced above. Addison-Wesley.org/ 11 Barry Boehm. 25 Software architect Michael James has a semi-serious theory that “test-only” development will soon be feasible with the advances in cheap.cfm?Doc=newsletter/2004-01-15/Standish. Addison-Wesley. “Managing the Development of Large Software Systems”.: Agile Model-Driven Development with UML2”.agilemanifesto. January 1986.. 100-101 17 In fact. XP Magazine. “Extreme Programming Explained: Embrace Change”. 9 I. Tom Poppendieck. p 28. 15-19. Basili. 21 Jim Johnson. Inc. January 1986. “The New New Product Development Game”. Tom Poppendieck. June 2004. Westcon. 10 The Agile Manifesto is online at http://www. All rights reserved. Harvard Business Review. 1970. Cambridge University Press. 2000. 18-19. Mike Beedle. http://www. it is debatable whether Quality is really an adjustable factor. Nonaka. “Agile Software Development with Scrum”. 1994. Victor R. Harvard Business Review. H. 1981. It’s Your Job!”. 2001. “Extreme Programming Explained: Embrace Change”. 14 Examining the Cost of Change Curve. 2 Standish Group International. http://www1. Published Keynote Third International Conference on Extreme Programming. pp. period. 3rd ed. Addison-Wesley. Prentice Hall PTR. September 2000. Inc. p. 2004. Prentice Hall. Copyright © 2004 Danube Technologies.standishgroup. “Extreme Programming Explained: Embrace Change”. 7 For more on how lean development influences agile software development. 8 Craig Larman. Mike Beedle. 48. clustered supercomputing. . As professionals. 2003. “Lean Software Development An Agile Toolkit”. Inc. 18 Kent Beck. Page 11 1 Winston Royce. “Is Design Dead”. Software Magazine and Weisner Publishing. 2002. 12 Kent Beck. year 2000. 2004. “Lean Software Development An Agile Toolkit”. 4 Ken Schwaber. Surgeons or lawyers would be sued for malpractice. “Chaos Chronicles”. Addison-Wesley. “ROI.. Nonaka. Computer.com//sample_research/chaos_1994_1. 2003. 16 Ken Schwaber. “Chaos Chronicals”. 15 Martin Fowler. 20 Mary Poppendieck. by Scott Ambler. 24 “Standish: Project Success Rates Improved Over 10 Years”. Takeuchi. by Alistair Cockburn. 2004. 2000.