Cloud Foundry: Design and Architecture
Derek Collison discusses the goals, the design premises and patterns employed in creating the architecture of Cloud Foundry, VMware’s open source PaaS, unveiling internal architectural details.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Known vs Unknown
Posted 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.
- This article is part of a featured topic series on Agile
- See more Agile content at: http://www.infoq.com/agile
- Other recent content items in this topic
RelatedVendorContent
Agile Maturity Model Applied to Building and Releasing Software
Visual Studio vNext: ALM features for Agile Planning, Team Collaboration
Using ALM to Drive Business/IT Alignment
Related Sponsor
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
Waterfall ?????????????????
by
Serge Bureau
Posted
People & Best Practices
by
John Galvin
Posted
Re: People & Best Practices
by
Ben Keeping
Posted
Agile is the new waterfall
by
Dan Tines
Posted
Re: Agile is the new waterfall
by
Tim Arthur
Posted
Re: Agile is the new waterfall
by
Dan Tines
Posted
More about the Unknowns
by
Luca Minudel
Posted
-
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.” -
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.
-
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/
-
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. -
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 -
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. -
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.
7 comments
Watch Thread Reply