Having spent a significant portion of my early career as a business analyst, I have always been keenly interested in potential means of delivering functionality faster to my users. As a long-standing practitioner of the traditional "waterfall" software development/project management methodology, I have integrated early prototyping and iterative functionality over the years.
Recently, I've become aware of a growing trend toward the adoption of agile software development and project management methodologies. I began investigating agile methods to understand if this trend offered a real breakthrough in delivery speed -- the elusive holy grail to IT organizations (not to mention our business partners).
The agile methodology was designed to speed up the delivery of developed capabilities (systems, applications, and functions). Time to market is important to all aspects of business systems development, but it is especially critical to customer-facing e-commerce systems.
I have seen the agile methodology described as involving "early and regular delivery of working software, a focus on team communications, and close interaction with the users."
Seems familiar, no? Isn't that what we have always strived to achieve? Agile methodology, it seems, is founded on a philosophy that espouses people and their interaction over methodological processes, tools, and documentation. Remember people, process, and technology? To the casual observer, this methodology seems more of an evolutionary step.
In reality, it appears to have borrowed from and recombined the best-practices that have been used in software development over the past 40 years. Essentially, the agile process for a software development project includes the following steps:
- The overall scope of the project is assessed. The business determines the overall priorities, and the development team estimates the effort required.
- A fixed iteration or "sprint" length is determined. Two weeks appears to be a common length for iterations.
- Functions determined to be in scope are broken into sets of high-level user stories (capabilities). Before implementation within a sprint, the stories are fleshed out at a level of detail sufficient for each function to be implemented within a single sprint. (Use cases, anyone?)
- Sprint planning starts. Stories are gathered until a full sprint's worth of functions are identified. Naturally, high-risk/priority functions are scheduled for implementation sooner in the development sprint cycle.
- Each story (capability) is refined. Specific tasks are deteremined, as we noted in step No. 3.
- Functions are developed, tested, and rolled out into production. This would happen in any waterfall-based project. Presumably, the process cycles back to step No. 4, concurrently with this step.
The primary differences between the waterfall and agile methods include the frequency of functionality delivery and the formalized iterative approach in the agile method. This method has even developed its own jargon -- participants are classified as "chickens" and "pigs" (in a bacon-and-eggs breakfast, chickens are involved, but pigs are committed).
Conversely, waterfall development goes through a series of distinct phases: analyses, requirements, design, implementation/integration, testing, and rollout for the entire set of functions. This has also come to be nicknamed "the big bang."
Having used an iterative approach to software delivery (aka phases) for years, I find myself at a loss to determine the agile value proposition. I can see how it provides a codified methodology for iterative development, including how late business requirements can be incorporated (no mean feat). What isn't clear is how it addresses and improves upon the two most time-consuming activities of any software development effort: analysis and design.
If there is truth in the hackneyed expression "The devil is in the details," then how does employing an agile methodology avoid the time needed to analyze and design holistically? Wouldn't deeper requirements, specifications, and design performed just before sprint implementation reveal details that could result in more expensive development or force you to undo and then redo previous functions?
One could never say these things wouldn't happen using a waterfall approach, but it seems that the agile approach tacitly invites them to occur. I think it can be a helpful methodology, but the holy grail remains elusive.
— Brian Margolies is the CIO of Allied Beverage Group, New Jersey's largest distributor of wine and spirits.