Scrum is broken, and other tedious refrains

Note, I dashed this ages ago but never thought it was worth publishing – however, I publish it now as it may provide some value to someone somewhere!

It’s very popular these days to hate Scrum. Most of the time it comes with a special kind of hatred for agile in general, which for the most part is well placed.

Agile, as I have said before, is something of an Albatross. However, just hating something is all rather tedious. There’s nothing to be learned from this. Scrum is terrible ha ha ha – then you move on to your next silver bullet and wonder why that didn’t work either.

So really we should be looking at why Scrum might not work.

Now, this is not a post about context, appropriate methods and situational awareness. There’s plenty of literature on that already – Cynefin, Wardley maps etc.

No, instead this post is about scale.

By this I mean the level of abstractions you are working at and if they are consistent across your Scrum boundaries.

Mostly Scrum breaks because what is delivered is not the sprint. The sprint is the unit of work, not the user story.

The user story or stories are useful (ignoring the issues with user stories) but not as useful as the sprint goal. What are we going to deliver/learn with is sprint?

What is inside that unit is of no business to anyone other than the people executing the sprint. Yet where do we see all the focus? On what is happening in the sprint.

At its heart, the issue is an issue with scale. You have different groups working at different scales but without knowing it.

This is how you get pathologies like working on the most valuable items. Useful but not helpful at all scales. At the sprint level that’s not useful – as the sprint is the unit of work. But for the delivery team, it may be useful to help them think about the work, but the risk is also a factor or dependencies.

But what about loooong sprints, in the order of months. Which I’ve seen before. Often this again is a scaling issue but this time across different boundaries. Here the sprint is just a release of a product increment, not an iteration in a product. This is commonly caused by the macro scale bleeding down to the micro-scale.

The point is there need to be boundaries and those boundaries can help or hinder, but the first thing to think about is, are we working at the same scale? Do we inhabit the same world, are we talking about the same things or different things using the same language?