As Agile development methods sidle towards the mainstream it seems that the word on everyone’s lips is ‘Scrum‘. Sadly, not so many people talk about eXtreme Programming these days – perhaps its too extreme for the mainstream? – and I’ve yet to speak to anyone who is adamant that DSDM or Crystal is the way to go.
Now I quite like Scrum: it brings clarity to the practices required to manage the immediate and future requirements, and the concept of a Scrum Master is elucidated far better than ‘XP coach’ ever was. But, as far as I can tell, Scrum isn’t Agile.
Let me explain … I’ve seen a couple of Scrum projects where the development practices used do not support the ability to accurately estimate a Sprintsworth of development work or the ability to totally re-prioritize the Product Backlog when things change. Developers worked in isolation (other than coming together for the Scrum) and owned ‘their’ bit of the system, there was little or no developer testing, integration was relatively frequent but definitely not continuous, and there was little attention paid to refactoring. As time went on, estimates became less accurate (because the risk of a change breaking other bits of the code was greater) and there was no foundation to support large-scale changes to the codebase: tests and well-factored code understood by the whole team.
So whilst these projects were Iterative and Incremental – they delivered some software at regular intervals – they certainly were not Agile. And the project managers and business got a nasty shock when the development velocity dropped and the ability of the team to deliver changes to the system waned.
Is this Scrum’s fault? In my opinion: absolutely. Its all in this wishy-washy “If engineering practices are the candy bars, Scrum is the candy bar wrapper” (the bit you throw away in order to get to the good stuff???) nonsense. If the Scrum book said “you need to put XP [or something very similar] in the middle of Scrum to be Agile, otherwise you’ll not get the benefits Agile promises” it would be very clear what Scrum brings to the party. But to pretend that you can choose the engineering practices you like, wrap them in Scrum, and be Agile is disingenuous at best and potentially dangerous. The danger is that Scrum becomes the acceptable face of Agile – “keep doing what you did before but with some lists, charts and a certified ScrumMaster (TM) (available from every good consultancy near you)” – and the real message and benefits of Agile get lost along the way.