Blamestorming - Who's Accountable In Scrum?

One of the things about Scrum that many organisations find uncomfortable is the concept of accountability. Who do we hold accountable for this piece of work if things don't go well? Because Scrum doesn't have the role of project manager, there is no single point of failure upon whose shoulders responsibility will ultimately rest, which is inconvenient. There is an underpinning philosophy to Scrum which is that "people are good, they want to do a good job and nobody screws up deliberately". Not everybody agrees with this view of human nature and some are quite explicit in their distrust of other human beings. For these people, Scrum will never work as it is so heavily built on trust. Management who operate at a distance find it harder to trust and would really like the clarity of one person they can go to, exert some pressure on and perhaps have a hold over to encourage greater performance.

Most people realise this is a fallacy when operating in an environment where the engagement of the delivery team is crucial. Instead Scrum was engineered to develop a close bond between all of those committed to making a project work, such that everyone feels a sense of responsibility and, more importantly, an innate desire to be successful due to having an explicit stake in the creation and outcome of whatever it is we are building. The fact that the development team is given a solution-agnostic goal to work on, has control over what they commit to, how they intend to go about building it and then get to demonstrate their progress every couple of weeks identifying ways to improve gives them the three elements of motivation that Dan Pink points out in his talk on The Surprising Science of Motivation: Autonomy, Mastery & Purpose.

If we overlaid an authoritative role on this setup, it would naturally undermine the impact that the concept of a self-organising team would have. That is not to say that the Product Owner doesn't have authority - they do, but over the product not the team. The product owner will make decisions (perhaps even autocratically in some situations) about goals, release dates, requirements and priorities. That's their job. But the development team itself doesn't have the easy way out of a leader to make a decision, or even a simple, democratic voting process - the minority shouldn't be steamrollered. The development team make their decisions based on consensus - that is something that we are all happy to go along with and support. So there isn't even a process for singling out a scapegoat within the development team. They succeed or fail as a team. As do the Scrum team as a whole.

‍If (and I really want to stress the word IF here) you wanted the most black and white version of accountability in Scrum it would go like this:

• If the product turns out to not be valuable or viable, the product owner should pull the plug.
• If the product owner doesn't pull the plug on a failing product, they should be stopped by the organisation
• If the team is unable to deliver enough value to make what would otherwise be a valuable product viable then the product owner should either (a) support the team's development so they can improve or (b) find find themselves a new team.
• If the team aren't able to deliver enough value because there are too many impediments, they should find themselves a new ScrumMaster.
• If there are too many impediments, the ScrumMaster should change their organisation or change their organisation!
  

I will say it again though - this is black and white (too much so) and in reality it will be a lot more collaborative than this but it shows how low down the chain the ScrumMaster comes in terms of accountability - this is often a huge surprise for many organisations as they confuse the ScrumMaster with a project manager role.

Projects should be evaluated on a sprint by sprint basis, constantly asking whether this is still a worthy investment and how we can improve our situation. This isn't about voting off the weakest link but rather continually finding ways to help people who inherently want to do a good job, do what they need to do.