Sometimes when I think about Agile software development and the alternative Waterfall method I am reminded of the Reese's Peanut Butter Cups commercials when the product was first introduced. Each character was adamant that his or her snack was the tastiest until they accidently were combined into something that was even better. Having worked extensively with both methodologies in the Agile vs. Waterfall debate, rarely is one clearly superior to the other. In most projects, aspects of Agile software development provided something the Waterfall method was lacking or vice versa.
Development teams who believe either the Agile or Waterfall approach is superior without having tried the other process are missing out. The ways these two software development methodologies can benefit each other could easily fill a book, so for now let's look at one aspect of Agile that will clearly benefit the Waterfall process: Prioritization of requirements.
The Agile vs. Waterfall Requirements Story
In the Waterfall methodology, requirements are required. They must be done, and nothing can or will get in the way of their realization in the end product. As such, requirements are broken into deliverables and then deliverables are broken into tasks (to really over-simplify the process for the sake of space). The tasks are sequenced by dependency. All of this makes perfect sense ... in a perfect world. In the real world, it still makes sense but not perfect sense.
In Agile, business users tell stories that are captured singularly and then sorted by priority (again paraphrasing the process). This also works great in a universe where everyone takes into account dependencies as well as the value of the long-term goal versus short-term success. A very mature Agile organization achieves this accounting and touts their success, though they will often forget the trauma endured in reaching this level of maturity.
Agile Requirements Prioritization to the Rescue
In this article, I am picking on Waterfall by focusing on the well known fact that the vast majority of projects hit a point where funding, time, or both run out before all of the requirements can be delivered. At that point, the best solution usually is to extend the time and finish what was started, and the most frequent choice is to reduce the scope to "deliver a solution on time."
The best Waterfall project managers know how to plan for parallel tracks that will result in the most cost-effective successful project. When the time comes to cut scope to meet a business timeline, even lower-priority items have almost always been already started. This forces the managers to cut more deliverables from scope in order to complete as many as possible within the allotted time. Here Agile requirements prioritization can come to the rescue (in the future, as this must be done up front to be of benefit at the late stages of the project).
The value of Agile requirements prioritization is that not all tasks must be done in a sequence. Having priorities for the requirements can make it easier to adjust scope when needed, because the deliverables and tasks can be performed in order of importance rather than the order that is the most cost-effective if (and only if) everything goes according to plan.
Admittedly, adding requirements prioritization to the early stages of the project planning process will add time, expense or both to the project. This is when having the trust of your business partners becomes important. You should be able to point out that most projects hit a point where they may not deliver all of the requirements. Every project team wants to deliver all of the requirements, but it is much more realistic to expect that some requirements will need to be sacrificed when unknown issues crop up. By determining which requirements are most important up front, fewer will need to be removed from scope if time runs short. And if time doesn't run out, no one loses anything. You would be surprised at how often your business partners will accept this level of honesty and realistic planning.