Agile Sw Development

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 CXOswith 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 whileproviding 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 intoproduction 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 productionline 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 consideredon-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.

Page 2

incremental and iterative development where requirements, design, implementation, and testingcontinue throughout the project lifecycle.

Figure 1
Traditional Methods: sequential phased approach

Project Phase

1. Requirements Analysis

2. Architecture & Design

3. Code

4. Test

5. Deploy

Up-front Requirements Analysis
What are requirements? From the stakeholder’s perspective, the requirements are the features and specifications of the system. Requirements define whatdevelopers are to build. For example, the system must have a web site with e-commerce capability that can handle 10,000 purchases per hour, or the system must be accessible 99.999% of the time. 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. In Figure 1, the first block represents the requirementsanalysis phase of a software development project. Analysts slave for weeks or months compiling everything they can gleam about the proposed system into comprehensive “Software Requirements Specification” (SRS) documents. Once finished, the SRS is sent over the fence to the designers while the requirements analysts go to work on the next project. Imagine a scenario where you engage a software...