After writing our Scrum Guide 2011 article in August a couple of tweets from Heinrik Kniberg (@henrikkniberg) caught our eye:
“I wish the derogatory term ScrumBut would die. Sometimes ScrumBut is a problem, sometimes ScrumBut is a solution. If your process is working for you, then it is right. Never mind if it is 0%, 50%, or 100% Scrum. And no matter how good or how bad your current process is working for you, it can be improved. Agile is a direction, not a place.”
We’re in total agreement with Heinrick on this.
Whatever flavour of “lean or agile development” you’re currently using: you’ll notice they’re are born out of Deming’s Plan, Do, Check, Act.
They are inherently evolutionary:
- You try something.
- If it works, you carry on doing more of that.
- If it doesn’t, you stop.
It’s like the rules of Chess.
The root of ScrumBut originates right from the top.
If you take this post from Scwhaber about 12 months ago. It’s a giant contradiction. Scwhaber talks about Scrum being a ‘framework’. The rules of that framework are captured in the Scrum Guide.
Scwhaber writes that Scrum is like the game of chess: it’s got its rules, and you make moves within those rules. Change the rules, and you’re no longer playing chess. It’s Scrum, but…
This is a terrible, terrible analogy. Chess is extremely rigid. There are a finite set of states in chess. Scrum compared to chess is extremely fuzzy. (in Scwhabers words: “The word “framework” means that much is not specified and must be devised by those using the framework.”)
But: Scrum, being a child of Deming, has a built in rule-rewriting routine. The retrospective.
Evolution via Continual Improvement
The Scrum Guide calls the Sprint Retrospective out as one of it’s core Ceremonies.
Take this example:
A retrospective occurs. The team decide they have an alternative to the ‘burndown’ so try it out. It works for them, they keep it.
Does that mean they’re not ‘doing Scrum’? The Scrum Rules changed to not have a burndown, so were they not ‘doing Scrum’ but now they are?
The same team also tried release cadances rather than hard sprint boundaries. They do virtually everything else in Scrum, but they’re certainly not ‘doing Scrum’ if you take Schwaber’s latest clarification from last month.
Because Scrum is born out of Deming’s Plan, Do, Check, Act, evolutionary change will occur. You will find deviations from the ‘Scrum Guide’ that are better for your business & your team. You should absolutely do them. We find it strange that Scrum doesn’t publicly acknowledge this (or if it is acknowledged, it’s contradicted)
The human cost of ScrumBut
Don’t get us wrong. We’re CSMs and CSPs. We’ll certainly consider the CSC/CST route as well. We believe Scrum has opened up great swathes of success in product development.
But we’re with Heinrick on this. The proliferation of the ‘ScrumBut’ attitude at best discourages the vital learning found in the Deming cycle, and at worst misleads people to believe they should ridgidly stick to a ‘process’.
Getting caught up in the confusion caused by the ScrumBut Anti-Pattern is an awful waste of human energy. Avoid it.
We’d encourage people to focus on what’s important: Customer Development using lightweight processes that work for you and your business.
