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.

Agile Requirements Prioritization In Action

The first time you try to add weight to requirements you may experience a lot of spin as everyone insists that either nothing or everything is important and is a must-have. Here is a simple, practical example to get people on the same planet, if not the same page: Button styling. Button styling may be very desirable for UIs in general, but is a very low priority for internal-facing applications.

Other requirements prioritization examples include:

• Web developers who prioritize their project requirements by doing page layouts first and then lower-priority details later can adjust faster.
• JavaBean developers can create the retrieval methods before the sorting methods as sorting can be passed on to the presentation layer if the back end work gets backed up.
• Creating a functional navigation first and refining it to an intelligently flexible navigation later can save time if the delivery date arrives and only the current functionality is ready. Starting with flexible navigation first could leave many requirements unfulfilled as the delivery date approaches.

Adapt Agile or Waterfall Process to Your Environment

While I explained how Waterfall projects can benefit from one (and more) Agile approaches in this article, I am not implying that one process is always superior to another. Waterfall works under one illusion: everything in a software project can be planned and executed according to that plan. However, Agile has its own illusion: business stakeholders will be involved throughout the software development lifecycle. I have participated in many Agile projects where business stakeholders didn’t appear at 99% the daily stand ups; everyone was surprised the 1% of the time when they did show up.

The goal should be to know how to adapt these processes to provide the maximum value possible within a given environment rather than how closely the environment can be modified to match the process.