«
»

Known Problem, Unknown Solution


I found myself quoting Eric Ries today.

It occurred when a VP asked me to compare Waterfall vs. Agile, and to explain when it was appropriate to apply each methodology.

In under 10 seconds, I was able to get my point across thanks to the following slide deck:

Eric Ries Lean Startup Schematic View Of Agile Development And Customer Development
View more presentations from Eric Ries.

Waterfall is quite effective when tackling a Known Problem with a Known Solution.

Agile works best when faced with a Known Problem and an Unknown Solution.

With that said, I strongly believe that Waterfall and the old guard of Product Development will become less and less prevalent as we accelerate time to market. In today’s technology sector, by the time you are finished with the 3rd review of your SRS document, another company will have already beaten you to market with a Minimum Viable Product using Agile and Rapid Customer Development.

Perhaps their early release will lack a certain polish from your perspective, but then again you have a slide deck, and they have actual customers.

Share and Enjoy:
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • StumbleUpon
  • Twitter
  • HackerNews
  • LinkedIn
  • MySpace
  • Posterous
  • Technorati
  • Yahoo! Bookmarks
  • Reddit

,

This entry was posted on October 14, 2009, 10:07 pm and is filed under agile, lean. You can follow any responses to this entry through RSS 2.0. You can leave a response, or trackback from your own site.

  • David, I agree completely. Waterfall works well when you are executing a proven process to implement a known solution, such as when a carpet contractor is planning for their 400th carpet installation in a house. He can use experience and parametric models to estimate the work required for each step, with reasonable confidence that the actuals will be in line with the estimates.

    When a project involves doing new things (usually the case with software), experience shows that we cannot estimate accurately, and so rather than fail at this kind of estimation for the 400th time, we're better off controlling what we can (schedule), and planning to adapt what we cannot control (scope). This is the Agile / Scrum area.
blog comments powered by Disqus