Loading ...
Sorry, an error occurred while loading the content.

56220Re: [scrumdevelopment] Well done waterfall+agile

Expand Messages
  • Dan Greening
    Nov 8, 2012
    • 0 Attachment
      Hi Eric,

      Everyone is saying "Don't do it." I agree, but I'll try to explain why.

      There are MANY well-meaning people who think they can be the First People Ever to combine waterfall and Scrum, name their new process with some catchy name, start teaching this Frankenstein system, then cause internal organizational chaos or sloth.

      It comes from a serious misunderstanding of what agile/Scrum methods are.  They are a form of production science, where you measure end-user value production in short, fixed iterations, then use your measurements to diagnose problems, adjust your production methods and forecast.  Waterfall's long production cycles make it impossible to do this feasibly 

      You may think that Frankenprocess (waterfall + Scrum) can first measure design, then measure development, then measure testing, then measure deployment. The problem is that these measurements don't help highlight the high-risk items fast enough to avoid disaster.  You certainly can't forecast delivery time with them because, with Frankenprocess (as with waterfall), you haven't tried/measured any of the later stages when you formulate your early forecasts. You've just guessed. That's what waterfall is: a bunch of unproven guesses with no early verification/correction where you bet the project outcome on your guesses.

      You may think you can do mini-waterfall, like a series of 4 two-week Scrum sprints where the last sprint is, say, testing and deployment. If you do that, you basically have created an 8-week Sprint. The velocities of the first 3 sprints are meaningless. You have no certainty that the 4th Sprint will actually be shippable, so you can't rely on any of the velocities in the first three Sprints to forecast or diagnose. Finally, you dictate different processes in different Sprints and therefore lose the flow and rhythm of highly-effective teamwork where the whole team tries to get something shippable together.

      I tried to write this explanation as succinctly as possible. I hope this helps. 

      Dan Greening
      Managing Director, Evolve Beyond LLC
      Email: dgreening@..., Phone: +1 (415) 754-8311, Skypeid: drgreening, Site: http://evolvebeyond.com


      On Fri, Nov 9, 2012 at 6:21 AM, Ashish Mahajan <agileashish@...> wrote:
       

      Agreed.
      If you are good at swimming in water(fall),fine.
      If you are good at cycling(scrum cycles), fine.
      But trying cycling in water may be fatal.

      Regards
      Ashish

      Sent from my BlackBerry® smartphone

      From: Eric Tiongson <tiongks@...>
      Date: Fri, 9 Nov 2012 13:12:37 +0800
      Subject: Re: [scrumdevelopment] Well done waterfall+agile

       

      Agree with what Michael said, you'll just find yourself in a heap of trouble if you do that.

      However you can still use agile practices (not processes) within a waterfall processes.

      Sent from my iPhone

      On Nov 9, 2012, at 12:52 PM, Michael Vizdos <mvizdos@...> wrote:

       

      No.

      Don't do this.

      If you want to do waterfall. Just do that.

      Good luck.

      Don't fake it.

      Mike Vizdos

      On Nov 8, 2012 6:08 PM, "marcodorantes" <marcodorantes@...> wrote:
       

      Hi all,

      I am looking for articles or papers that talk about the details of how to successfully execute a development project with a waterfall façade to the upper-management layer and an agile approach for the development team. All is new in the project: the team, the users, the application, the technology. Note that with «waterfall» I mean strict sequential stages of requirements, analysis, design, coding, testing, deployment to production, and three months of maintenance; along with a fixed-price/fixed-scope contract, and a single Gantt chart as part of the signed contract. This Gantt chart will work as the criteria for payments at the end of each stage against stated deliverables in the contract.

      I have heard, from time to time, that some teams have done precisely that and very well done. Yet, I have not checked the evidence to believe it.

      Could you point to those articles or papers, or experiences?

      Thank you very much in advance.


    • Show all 27 messages in this topic