I’m currently working with a start-up that doesn’t do Scrum, and I must admit that it’s pretty refreshing.
In a Scrumless team, productive conversations aren’t sidetracked with silly questions like: “How should we do X according to Scrum?”
Not because what’s written there isn’t helpful (it is), but because I consider the principles and ideas behind what’s written down as way more important than following any Scrum rule by the letter. And if you talk about the purpose behind things, you don’t have to drop the Scrum Guide in conversation.
Doing things the best way possible is what I care about, not achieving perfect Scrum Guide adherence.
Plus, the “How should we do X according to Scrum” remark is like a vampire that sucks the soul of collaboration from a room. Somebody tries to invoke Scrum as a deus ex machina to descend from the heavens to solve all our problems (which it won’t).
Suddenly, an imaginary white picket fence is erected that we must respect… because… well, the bloody Scrum Guide says so! Those are precisely the kinds of fences that are safe to ignore. Imaginary white fences can be extremely dangerous, and I trust humans more than any of these rigid fences.
In Humans We Trust
Humans are better equipped to figure out what works for their situation than to rely on the dogmatic interpretation of a one-size-fits-all guide created by other human beings as fallible as you and me.
Scrum as a framework based on this same belief. Scrum leaves it up to you to create your own way of working. When you can’t trust people to devise better ways of working, it’s time to stop doing Scrum. Scrum won’t work, and you will never be able to make it work. It’s simply the wrong tool for the job.
I won’t claim everything is fine and dandy when a team doesn’t do Scrum. I’ve never encountered a team without any problems. You will still face struggles and tribulations regardless.
However, when you’re dealing with zero Scrum, it’s pretty freaking awesome not to have to deal with imaginary conflicts that are whipped up to seem important but that really aren’t.
Despite the good intentions behind the framework, why does Scrum often seem to make discussions more narrow-minded than they could be?
I recently finished the book ‘The Unaccountability Machine’ by Dan Davies where he coined the concept of an Accountability Sink, which perfectly explains why Scrum Teams often seem to come up with worse solutions to problems than teams that don’t use Scrum at all.
Let’s explore accountability sinks together.
What Is an Accountability Sink?
Davies argues that the starting point of accountability is that you can only be held accountable for decisions to the extent that you can change them. You can't be held accountable if you can’t change the decision.
Seems pretty reasonable right? So, where do accountability sinks come in?
Let’s say a system results in decisions that are likely to result in (unwanted) negative emotions that are likely to be appealed. Imagine a company wants the decision not to be appealed and tom prevent the feedback from traveling up the company chain: that’s where accountability sinks come in and shine.
The function of an accountability sink is to prevent feedback from persons impacted by a system from influencing the system's operation. In other words, they want to shield the decision from scrutiny by those affected by the decision.
This may sound abstract. Let’s make it concrete by providing an example of an accountability sink in action.
Accountability Sinks in Action
Have you ever tried returning an item to the store you bought it from without a receipt? You'll almost always end up in an endless loop, with the store employee repeating that they can’t help you without a receipt. This is the accountability sink in action, doing its intended job.
Almost all stores do not accept returns without a receipt. Even if the same employee saw you five minutes ago buying the item, if you don’t have a receipt, there is a big fat chance they won’t help you further.
Now imagine you’ve bought a phone at a store near where you live. Unfortunately, the battery explodes in the bag and burns your receipt in the process. You go back to the store, and the employee refuses to help you because you don’t have a receipt.
This is an example of an accountability sink that backfires. The accountability sink fails to take into account your extraordinary situation. The policy makes the decisions, and the person behind the counter simply adheres to the policy.
They continue adhering to the policy when it no longer makes sense to follow the policy. Any force majeure event that makes it impossible to return the phone with the receipt is a good reason for ignoring the policy. But if they don’t trust what you’re saying to be accurate, the policy kicks in.
The policy decides for the employee and both the employee and the company can hide behind the policy. The employee can say: sorry! My hands are tied. It’s company policy, and there is nothing I can do for you. I wish it were different, but it isn’t.
We’ve all experienced this before. Here are some common examples:
The manager who can’t give you a raise beyond the salary bandwidth for your job title.
The wardrobe with a sign that says the restaurant is not liable for any goods that are stolen.
The airline that does not offer you a refund because it falls outside the scope of their refund policy.
The TV with a few dead pixels you can’t return because it’s within the acceptable dead pixel limit of the company policy.
The call center employee that refuses to help you because you didn’t communicate your changed home address, and now their security policy kicks in because they don’t know if you really are who you say you are.
In most of these cases there’s an easy way to solve our problem. Still, they don’t want to solve our problem because the accountability sink gobbles up all humanity from our interactions. It prevents the employee from listening genuinely and taking into account our situation.
How Do Accountability Sinks Work
For an accountability sink to work, you need the following:
“So the crucial thing at work here seems to be the delegation to a rule book, removing the human from the process and thereby severing the connections that’s needed in order for the concept of accountability to make sense.”
- Dan Davies, The Unaccountability Machine
When you read this paragraph, it’s likely you’ve already connected all the dots to Scrum, but let me just repeat for the sake of clarity. All the ingredients for an accountability sink are unmistakenly present in Scrum:
Decisions are delegated to a rule book called the Scrum Guide.
When you’re not doing Scrum, and something doesn’t work, it’s your fault as you’re not doing Scrum.
The Scrum Guide acts as an accountability sink that removes responsibility for the outcome Scrum produces. If it works, you’re doing Scrum. If it doesn’t work, then: “But you’re not doing Scrum.”
Don’t Allow Scrum to Become an Accountability Sink
If you’re still in doubt if Scrum is an accountability sink, then let the following paragraph sink in:
“For an accountability sink to function, it has to break a link; it has to prevent the feedback of the person affected by the decision from accenting the operation of the system. The decision has to be fully determined by the policy, which means it cannot be altered by any information that wasn’t anticipated.”
- Dan Davies, The Unaccountability Machine
In short, the next time your team doesn’t want to do a Daily Scrum or doesn’t want to work with Sprint Goals, please ask yourself the following question: are we trying to comply to an accountability sink, or are we trying to help our team discover what works best for their situation?
Any question that contains “How do we do X according to Scrum?” likely means someone on your team is positioning Scrum as an accountability sink.
If people leverage Scrum as an accountability sink, then you can forget about empiricism, self-managing teams, and the discovery of a better way of working on top of the Scrum framework.
All you’re doing is diminishing Scrum to become an accountability sink, so nobody has to ultimately take ownership and accountability over the outcome of our way of working.
Scrum cannot work when people treat it as an accountability sink, and it definitely cannot work when used in conjunction with the one accountability sink to rule them all: the Scaled Agile Framework (SAFe).
Someone will likely respond to this article by saying I’m wrong and Scrum is never supposed to work that way. That’s our accountability sink in action.
Just because something isn’t intended to be an accountability sink on paper doesn’t mean it can’t become an accountability sink in reality.
Thought provoking! IMHO, Scrum has deliberately not been prescriptive for teams to adapt the framework to their needs. Apart from the Rituals & Timeboxed Iterations nothing is mandatory. If the team is heavily focused on software development and needs strong engineering discipline, XP would be a better choice.
Times I have seen in my career where people where mentioning the "rules of Scrum" as a reason to follow them:
- We must use Story Points for Scrum
- the team must committed to the entirety of the sprint backlog to be finished
- Stakeholders must wait the sprint review to give feedback to the team
- At the end of the sprint, and only then, the team must release a new version or the sprint is failed
- a team must have 2-3 months defines in advance and those sprints cannot be changed by anyone for a team to be successful with Scrum
See the pattern here? Yes, none of those are prescribed by Scrum. Even more, many of those contradicts the Scrum Guide. So, very often, when a team told me that Scrum failed them, I asked them why they think so, and most of the time, and I can't actually find a single example where it wasn't the case, it was about a prescription that the team give to themselves that as nothing to do with Scrum (like mentioned above).
In my practice, also, Scrum has many times proved itself an excellent "trust engine": following Scrum practices and values help building trust, not only with stakeholders, but also within the team itself and for yourself. Developers in my Scrum team have shown more confidence and better accountability than my non-Scrum team. So, very hard for me to believe that Scrum is responsible for the lack of accountability in your team. It's probably more how Scrum were introduced to your team, or a question of the culture of the team, but you are in better place to figure it out.
Now, should you use Scrum all the time? I think not. I have a principle to always start from where the team is and build from there. Radical sudden change rarely works unless properly support across the structure in place and with good example of success, especially if there is something else at stake, like the survival of your project, or even your team. So, building step by step, by keeping what your team is strong and adopting new principles were your team is weaker, very similar to what you proposed, is IMO, the way to go. And one day, you'll figure out, what the team is going is mostly Scrum, just by another name (e.g. it's not a sprint, it's an iteration cycle, it's not a backlog, it's a queue, it's not a retrospective, it's a postmortem, it's not a product owner, it's a request manager, it's not a scrum master, it's a coach...).