Known vs Unknown

Whether to use waterfall or agile methods should be determined by how well known the problem and solution are. That is the assessment from David J Blant, owner of Scrumology.

David’s article makes these points:

1. It's a matter of taste whether to use agile or waterfall when both the problem and the solution are mostly known.

2. Agile works well when the problem is mostly known and the solution is mostly unknown. waterfall does not.

3. Agile works well when the problem is mostly unknown and the solution is mostly unknown. Waterfall does not.

David summed up his opinion at the end of his article:

“The battle of agile vs waterfall is becoming old and tired. Neither one is going away anytime soon and the argument is white noise. It distracts us from the real issue of whether or not we mostly know the problem or solution.

So let’s stop blaming waterfall for all of our woes, and start asking ourselves if we are choosing the right tools for the job at hand.”

The article gained great interest on the LinkedIn agile group. Many posters agreed initially with David's comments, but as the group discussion progressed it became clear that many felt that it was a rare time when the solution and problem were both known in a software development effort. This is illustrated by a comment by Chris Shield:

“I would think that the solution is never 100% known in sw development - never. There is always change from day one, new assumption arose, assumption proved invalid, new requirement arrived late from the business, etc, etc.”

Greg Robinson offered this comment:

“Software development is essentially a research and development process where you wind your way through an infinite number of potential solutions to get to an acceptible optimum. To think that you can apply more of a manufacturing process where you can write down a blueprint, get everyone to agree it and build it right (OTOBOS) 1st time is at best optimistic and a fundamental flaw of all waterfall processes. Its hard enough planning a 2-week sprint never mind a 1 year detailed plan for delivery (are your so-called requirements still going to be current one year down the line, even if they were accurate at the time?). Waterfall only works when it gets lucky.”

The remaining comments discussed the feasibility of actually knowing the problem and/or the solution at the start of a software development effort. But there did seem to be consensus that waterfall and agile both had a place at the table for managing those efforts.

But other opinions could be found on the web including Pawel Bradzinski’s post. His view is that people, not process or methodology, determined the success of a software development effort.

Others dive deeper and give more thorough analysis of other contextual factors affecting software development. Tom Peplow did a nice piece on this in 2008.

Related Editorial

Related Vendor Content

Infographic: Just How Big is the Nerd Economy

Application Performance Management Buyer's Guide

Enterprise-class API Patterns for Cloud & Mobile

Agile Maturity Model Applied to Building and Releasing Software

Agile workshops and training

Related Sponsor

Agile Project Management That Adapts With You. Provide your global development team a shared space that adapts to the way they work.