Suddenly everyone seems to be talking about SCRUM. In fact it's become (rather amazingly, given what it is) a requirement for employment in a lot of the jobs I am currently looking at. I therefore thought it best to investigate what SCRUM was to see whether I could sensibly put "has SCRUM experience" on my CV.

Following a short article by Robert Martin comparing methodologies I decided that I could, though after looking at it in some detail myself (see the references below) I'm not so sure it's such a good thing.

Because I have a bit of a problem with it - not so much about what the Methodology is saying (which isn't very much), but about what it omits.

If we cast our minds back to XP, those of us who were around at the time might recall how it was stated that XP's principles enabled one another and worked off one another when they were all being put to use at once.

I wonder now whether XP was just a bit too big a pill to swallow for most management teams so that SCRUM was presented as a sort of "acceptable face". But - it's all very well talking about a light-weight method, SCRUM simply doesn't work without that one thing that all of these methodologies need and that one thing which accounts for 99% of the difficulty and effort of working in this fashion:

Flattening the cost of change curve.

Ken Schwaber in his presentation below, bless him, does allude to the fact that your speed might just slow down as time goes on, but he makes sure he describes this as happening between releases (i.e. outside SCRUM) rather than between Sprints. I'd like to know what Scrum Masters do when they start plotting their Burndown Chart and find that they have a curve, rather than a line, and that that curve rather disturbingly decreases in gradient as time goes on.

You could rather blithely answer that it is the Scrum Master's job as QA guy or whatever to make sure that code maintains its beautiful integrity across Sprints. This, however, is where *all* the effort in software engineering happens, and it had better be your best engineer that is Scrum Master if that's going to be his particular job.

And even then I don't think anyone ever believes you will flatten the curve completely. Rules of interoperability (c.f. The Mythical Man-Month) still state that as time goes on the same step-wise increment in functionality will take longer and longer to implement. Keeping code's integrity clean will stop you getting into a mess, but it wont prevent your code getting more complex.

And even if you could still somehow do it you still have to factor in requirements-churn, which is not going to be constant throughout the lifetime of the project.

And (and I'm sorry about all the "and"s) you also need to measure how much extra deprecated work you are having to produce in order to sustain your short iterations and rapid release. I do most certainly believe that some of this has to happen, however I do not believe that time should be your only consideration in determining your iteration life-cycles. You have to consider the certainty of requirements and the risk of implementation as well. If you're sub-optimal, you could end up doing a lot of un-necessary refactoring.

Everyone wants predictability and everyone wants increased productivity. SCRUM and XP both recommend the mega-sensible approach of taking vertical slices through a product and developing iteratively. I'm not quite sure about SCRUM insisting on "release" - sometimes that's simply not possible - just "completion" is enough for me. Time-boxing meetings just seems like a bit of a sales-pitch to all those managers who think their engineers waste a lot of time arguing (those managers should read PeopleWare or start managing something else). I certainly wouldn't want anyone ringing the bell and saying time's up if I'm still not sure what I should be doing that day. Of course, you need structure, but SCRUM doesn't have to lay that down - decent team leaders do that already in whatever way suits them and their team best.

After that, you have to look at XP or other techniques for the best way to improve your engineering practices.

Ask yourself: if 65% of software doesn't make it out the door, why is that? Is it because programmers aren't typing fast enough? Is it because programmers are spending too much time chatting about TV or something? Is it because project management is up the spout?

Or is it because programmers are producing too many defects?

SCRUM, well, ok, maybe it's a good way to get XP through the door. Introducing iterative development is fantastic but you really need to go elsewhere to make the biggest improvements in productivity and predictability. I strongly suspect that where claims of SCRUMs great successes are being made that actually it's something else, not actually part of SCRUM itself but something that SCRUM has helped introduce, that is making all the difference.

Richard

References:

Robert Martin's article can be found here.

The original SCRUM white paper can be downloaded from here.

The author himself talks about it here:

And Jeff Sutherland adds his views to it here: