Which is faster: Waterfall or Agile?

To be clear, my personal position from the arrival of Agile a decade ago has been of scepticism rather than love-at-first sight. Agile's star couldn't be higher 5 years ago. If you weren't Agile then you were a dinosaur.

Fashion has quite clearly moved from Agile only to Water-Scrum-Fall. (Gone are the days (TG!) that starry-eyed developers would come back from Agile training courses wanting Marketing or Sales to go Agile too!)

Credit: iQuest Group 

Let's rewind at the outset: both Waterfall and Agile share exactly the same objectives: to deliver high quality products as quickly as possible to a willing market. Both have strengths and weaknesses, but the inappropriate application of the letter of the law in either case leads to its relative weakness.

On Agile

Agile does produce more recognizable product more quickly, but must be inefficient because:

• Making lots of software releases generates an overhead: for development, testing, deployment, customer communications, for customers themselves. 
• Gathering and analyzing customer feedback (which is so important to Agile) can be difficult and time consuming. (It is certainly expensive to set up and configure in order that this process isn't too arduous). Note that Engineering only does some of these tasks.

Agile's strength is that it doesn't do too much before all the parts in the workshop floor are re-assembled together and the product is shippable. (There is the theory that less development needs less testing, but in complex software, a small error can have massive consequences.)

Agile's weakness is that tends to encourage a horizon of a two or three sprints only. Estimating epics which span multiple sprints, can be even harder / more error prone than Waterfall.

Also there is fallacy at the bottom of Agile: that all resources are interchangeable. This is wrong: people develop specialisations or area of responsibility. This expertise can easily generate a bottleneck and tasks requiring a critical skill always end up on the critical path - not just for one project, but the problem appears to snowball, impacting multiple projects.

On Waterfall

Waterfall does mandate careful attention at the outset to scope of the product. This discipline (call it product planning or roadmapping) is considerably downgraded in Agile - which is a huge mistake. Many execs believe that once they have a product owner (who writes user stories and manage the sprint process), then they don't need product managers (who assess product concept, write epics & launch products).

Waterfall's strength (in terms of speed to delivery) is that it smashes the problem into little bits all over the workshop with the final deliverable in mind and only intends to reassemble all the bits at the end. Continual reassembly must be more time consuming to get to the same objective. Agilists will rightly point out that the objective invariably changes and that remembering how to reassemble all the
bits is error prone, requiring lots of testing.

Waterfall's inherent weakness is that because the endeavour is so carefully planned at the outset, then everyone follows the project plan, heads down in the sand. What a good product manager should be doing is constantly scanning for changes in the market place, in the requirements, in the deliverables. He or she should be constantly 'checking in' with all parties to ensure that any new information is gathered / digested / understood and its impact assessed.

Conclusion

As in life, it is a compromise. However, time spent in reconnaissance before a line of code is written is rarely wasted. And that's why I like Water-Scrum-Fall.

Some references

• Agile is for development only (previous blog post)
• Agile vs Waterfall (from Udemy)
• First mention of Water-Scrum-Fall in 2011: Water-Scrum-fall is the reality of agile