Rocket-Powered Waterfall

There has been a lot of talk on twitter and the blogosphere recently about how agile as a word and a movement has been hijacked by product vendors and consultants ready to sell their products or time. 

To be honest this doesn't surprise me, my colleagues and I have talked about the agile or scrum backlash for a number of years. Personally I think the "agile" of today is pretty much identical to the waterfall of 10 years ago. 

When I started my professional career back in 2000 this was pretty much the state of how projects were run:

  • Projects kicked off with a budget, deadline and some vaguely agreed scope.
  • BAs would generally run just a little ahead of developers.
  • Developers would implement specs, iterating around them with the BAs as complexity was uncovered.
  • Completed functionality passed to test who were running a little behind the developers. 
  • No unit or automated testing.
  • No continuous integration.
  • Manual releases to environments.

Before project kick-off there would generally have been an initiation phase where the scope/requirements were written down but as the project proceeds they would rapidly be abandoned. Maybe changes would be managed with a Change Control process but sometimes not, especially if the project was time & materials.

This process would be called Waterfall but doesn't actually bear much resemblence to what people think Waterfall is. When asked to describe it most would say that project activities are done in distinct phases and the output of each is passed over the fence to the next stage. In practice this never really happened and we always iterated as we went. 

As an aside I believe the original paper on Waterfall not only said that it should involve iteration but the whole process was a terrible idea and people shouldn't do it. 

If we fast forward to where we are today then this is how I see a lot of projects run:

  • Projects kicked off with a budget, deadline and some vaguely agreed scope.
  • BAs would generally run just a little ahead of developers.
  • Developers would implement specs, iterating around them with the BAs as complexity was uncovered.
  • Completed functionality passed to test who were running a little behind the developers. 
  • Unit or automated testing.
  • Continuous integration.
  • Automated releases to environments.
  • We have standups and retrospectives.

The software engineering aspects have improved due to developer testing and automation, however the process remains completely unchanged except for the addition of some new ceremonies. The main difference now is everyone can trumpet that things are better because we are agile. 

All that we have really done is strap a rocket to our old "Waterfall" process and can now deliver software faster. 

We still have the same problems as before. The business believes that they will get the software they want now because they have gone agile. There is no change in mindset. 

The business pay vast amounts of money to run a project yet won't engage to make sure it delivers what they need. 

How many agile teams have you seen where they deliver something every sprint, demo it and then it doesn't go live for months because the business want the whole feature set to go live at once? 

How many agile teams have you seen where it is impossible to get any time with a product owner or real user because they are too busy?

How many agile teams have you seen where the software is eventually kicked out of the door and they never get any feedback about what the users think?

To truly be agile you need to be getting feedback, iterating frequently and constantly adjusting what you do. Implementing the same half-arsed process as before with a few standups is not agile, it's rocket-powered waterfall.