BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

Known vs Unknown

by Christopher R. Goldsbury on Oct 21, 2011 |

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.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Waterfall ????????????????? by Serge Bureau

It should never be used at all.

I totally agree with this comment:
“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.”

People & Best Practices by John Galvin

Agile wins every time because it puts a focus on the people/team and formalizes the use of best practices to deliver a quality product that meets the goals of the stakeholders. Everyone intends to do the same in waterfall but, because it's not formalized in the process, it's not a priority so gets forgotten about or missed.

Re: People & Best Practices by Ben Keeping

Agile "formalizes the use of best practices" ? Not sure about that one ... you should watch Dan North at Oredev 2007 : www.viddler.com/explore/kvarnhammar/videos/6/

Agile is the new waterfall by Dan Tines

I'm not buying into the Agile hype. That's not to say that I disagree with all of its practices, but Agile has issues of its own. I think most of its problems have to do with consultants/"thought leaders" trying to pimp it as some kind of cure-all, and managers buying into it as some kind of religious dogma.

I think if you take Agile at its definition and not try to adhere without question to some "Agile methodology" then most teams will be better off.

Agile doesn't work for everybody. NASA (www.fastcompany.com/magazine/06/writestuff.html) isn't going to use it.

More about the Unknowns by Luca Minudel

Here an article and a video to investigate more the topic of the unknowns
- On Understanding Software Agility—A Social Complexity Point Of View: www.cognitive-edge.com/ceresources/articles/110...
- The Cynefin Framework: youtu.be/N7oz366X0-8

Re: Agile is the new waterfall by Tim Arthur

With all due respect to NASA, I think Fishman's article comes from a different place than "what agile really is and isn't". Agile is used all of the time on health and life science projects, highly regulated support related to life-and-death decisions.

Or taking a different twist, my uncle worked on the Instrument Unit in the Saturn program at NASA and I have a photo of him standing in front of their wall-chart... and what he described as a daily process was in fact, agile. Today we use different terms but it is essentially the same. I have a government background and background at the world's largest held public *and* privately held software companies and have kept an eye open for where agile just should not be applied.

Haven't found a case yet.
It doesn't substitute for leadership.

Re: Agile is the new waterfall by Dan Tines

I have a government background and background at the world's largest held public *and* privately held software companies and have kept an eye open for where agile just should not be applied.

Haven't found a case yet.


The problem is that everybody thinks that their very limited experience and exposure relative to the overall software development ecosystem is applicable to everybody.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

7 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT