Scrum doesn’t say…
A rant about what Scrum isn’t.
We don’t use Scrum ourselves at Quietstars. I’m not a massive fan of Scrum (especially the certification industry that’s built up around it — see the CSSTWP for more on that).
Yet I seem to spend a lot of my time defending it. Because most of the criticisms I hear are not about things that Scrum mandates. For example:
- Scrum doesn’t say stories have to read “As a role I want to goal because reason”.
- Scrum doesn’t say you can only release once every Sprint.
- Scrum doesn’t say you can only release at the end of a Sprint.
- Scrum isn’t an acronym and isn’t spelt SCRUM (okay… I rarely hear complaints about that, but it does annoy the heck out of me!)
- Scrum doesn’t say the sprint and product backlogs need to contain the same kind of things.
- Scrum doesn’t say you have to have burn down or burn up charts.
- Scrum doesn’t say you have to wait until the sprint review to show people things.
- Scrum doesn’t say you have to wait until the sprint retrospective to talk about problems.
- Scrum doesn’t say you are only allowed to demo or talk to stakeholders once a sprint.
- Scrum doesn’t say how you should estimate backlog items.
- Scrum doesn’t say you have to have points.
- Scrum doesn’t say you should use velocity as a target.
- Scrum doesn’t say you must track velocity at all.
- Scrum doesn’t say you have to have epics, stories, or tasks.
- Scrum doesn’t say that you can’t have any meetings that are not sprint planning, standups, sprint reviews or sprint retrospectives.
- Scrum doesn’t say the Product Owner can prevent the team from working on technical debt.
- Scrum doesn’t say the Product Owner gets to tell the team how to turn the backlog into releasable code.
- Scrum doesn’t say that the Scrum Master gets to tell the team how to turn the backlog into releasable code.
- Scrum doesn’t say operations people cannot be on the team.
- Scrum doesn’t say testers cannot be on the team.
- Scrum doesn’t say designers or user researchers cannot be on the team.
- Scrum doesn’t say business analysts, managers, project managers, etc. are not necessary.
- Scrum doesn’t say the Product Owner has to make all the decisions by themselves.
- Scrum doesn’t say that the Product Owner needs to prioritise the whole product backlog.
- Scrum does not say you must work an 80+ hour week to meet the forecast you made at the start of the sprint.
- … and probably many many more — do offer suggestions!
As Tim Ottinger said so concisely said in response to the twitter rant that kicked off this post:
I’ve found “Can you talk a bit about how Scrum and Agile relate?” to be a really powerful question to ask. At one end of the spectrum you get confused looks because folk think Scrum and Agile are synonyms. At the other extreme you’ll get a thoughtful discussion about Scrum, other Agile methods, how they relate, and what the trade-offs are.
Many, if not most, of the complaints about Scrum I hear are caused by people mindlessly copying practices from whatever dysfunctional organisation they first learned about agile in.
So, when you hear somebody complain about what Scrum forces them to do encourage them to read the Scrum Guide. They’ll be able to do it in over a lunch break and still have time for a leisurely dessert — it’s less than twenty pages long.
Scrum, at its core, is a really minimal process improvement framework.
Understanding how that framework is put together will help you deal with the ghastly stretch-goal, velocity tracking, eighty-hour-work-week monstrosity that’s often labelled Scrum.
Sometimes that knowledge will be the thing that lets you know that Scrum isn’t what you need.
Because Scrum doesn’t say that it’s the only way to do agile, or the only way to work.
Subscribe to our newsletter for the latest thinking on effective strategy, research, and delivery work. No spam. No fluff. No fads. Just the good stuff most people overlook. Summarised and delivered to your inbox every other week. Check out our 10+ year archive if you don’t believe us.
