December 5, 2007

Waterfall trap for Agile projects.

I was reading about Jeff Patton's keynote Embrace Uncertainty in XPDay London. Jeff pointed out a blur line between Waterfall projects and Agile projects and how agile projects can face the same problem which comes into Waterfall Model. With an interesting example he explained how an agile project can fall into same old waterfall trap.

Difference between Incremental and Iterative
Jeff took an example of failed agile project. It started off almost by book. Customer involvement, user stories, stories spilt into iteration and agile criteria have been followed. On the deliverable, customer changed their minds (as they often do) and new stories introduced into plan. In this way scope started growing. Customer was expanding the scope and developers are there to oblige them.At the end project was not closer to be completed because of iteration after iteration.According to Jeff the concept of iteration has been lost and iteration has been replaced by increments. That made project fall into same as waterfall projects do.Jeff gave the following rule of thumb to check quickly if your plan is iterative or incremental: "it’s not iterating if you do it only once".

Jeff also mentioned three strategies to deal with uncertatinty in agile projects.
  • Focus on business goals,neither on the features nor on the stories.

  • Don't choose your goals too early.

  • Build up feature quality iteration by iteration.

Read the full story.

1 comment:

  1. "At the end project was not closer to be completed because of iteration after iteration...that made project fall into same as waterfall projects do."

    Defining "done" at each step of an agile project is very important. One of the reasons for sprint planning meetings is so that dev team can gain understanding of what the client feels "done" means for a particular user story. This also applies for the project in general. If a client continuously changes his mind, then yes, a project may never be "done," however, that does not necessarily equal failure.

    Without knowing all the details of the project it is hard to gauge what went wrong, and whether or not agile practices were employed from start to finish, and if agile was described well to the client.

    In all of our projects, when clients begin to add/remove/change functionality (thus changing the stories as in the example), we inform them of their deviance from their original goal. They are told that they are, in effect, changing what the deliverable is. However, that is entirely up to them, and should be. As long as they are reminded and can live with their decision, life is good.

    As defined by Wikipedia, Waterfall model is "a sequential software development which development is seen as flowing steadily downwards...through the phases of requirements analysis, design, implementation, testing (validation), integration, and maintenance." I am missing how either incremental (addition) or iterative (repeating) development equals Waterfall. Having a never ending cycle of iterations does not, as is stated by Jeff, equal Waterfall. That also doesn't seem to be why the project failed.