Tuesday, April 3, 2007

Agile Software Development v. Traditional "Waterfall"

I've been involved in two projects recently in which I got a first hand opportunity to compare the results of software development under Agile and under the traditional "waterfall" method. The two projects were not really similar in any way, but they still bear some scrutiny for the results of the two different approaches.

The project done using a tradition (or waterfall) methodology (which I'll call "Project W") began with a requirements gathering phase in July/2004. This was followed by an architecture and design phase, programming, testing and acceptance testing. We will (hopefully) deploy this system to customers in June, 2007, nearly three years after the project started.

The project done using Agile (which I'll call "Project A") was started in August, 2006 and was delivered and live in production in December 1006, around 5 months after the start.

Now, there are some very big differences in these two projects, including the complexity of the underlying data models and in the overall software architecture. However, it is interesting to note that a big part of the 3-year time to deliver on Project W came from two factors: redesign of system components that were found to be faulty during programming, and under-developed requirements. Especially in the past six months, we have spent a significant amount of developer resources adding/changing/deleting user features long after the requirement were solidified. In contrast, on Project A, at the point where the software was ready for testing, there were few feature changes.

Why? A significant aspect of Agile is that the client/user/stakeholder "sees" working versions of the software early on. So if there are any mis-understood requirements, these are found and fixed very early in the development life-cycle. Also, in Agile there is a much more limited design
process, relying instead on developing working code. As a result, any design errors were uncovered earlier in the cycle.

An interesting thing happened on Project A -- we exceeded the budgeted costs. Although this was conveyed to the customer as it happened, it still caused a great deal of consternation. However, and in spite of that issue, I view the project as a huge success. Had we followed a "waterfall" paradigm, it would likely have cost the same or more and would have taken longer to complete. So although we missed our target budget, we delivered a market-ready product in five months, enabling the customer to begin generating revenues quickly.

I'm totally convinced that Agile is superior for the kinds of projects on which I tend to work.