Blame != Accountability

I am often asked how teams are held accountable in Scrum and Agile methodologies. Many teams and Scrum Masters often confuse accountability with blame. To start, let’s make sure we understand the definitions of blame and accountable:

— adj
1. responsible to someone or for some action; answerable
2. able to be explained
— n
1. responsibility for something that is wrong or deserving censure;culpability
2. an expression of condemnation; reproof
3. be to blame  to be at fault or culpable

Notice the difference?

Blame has a negative connotation and is often assigned to a single person. e.g. You messed up and it is your fault…

Accountability is not assigned, it is something the team, rather than the individual, owns. It is not positive or negative; it is connotation-less e.g. We did not fulfill our obligation/commitment – let’s find out why.

Blame is born of malice and ego. People who wish to assign blame are usually unhappy with anything less than a public flogging; which is why they are the first to shift the blame to someone else. It’s like watching a children’s game of Hot Potato.

Accountability is born of maturity and curiosity. People who are accountable are genuinely interested in finding cause (not fault) and improving the maturity of the team. Disciples of Edwards Deming will assert that the individual is never to blame; only the process is at fault. Blaming an individual removes focus from fixing the system.

To answer the original question: accountability occurs organically as part of the Scrum process. The team is committing to a Sprint, Release, etc. Who owns that commitment? The team does, not an individual. The team is not only making a commitment to the Sprint or Release, but also to each other. If the Sprint fails, the team will perform a retrospective to investigate why it failed. The only way accountability can happen is if the commitment is truly owned by the team. The team should care that they did not complete all of the work in the Sprint, and why the work wasn’t completed; but not to the point where blame needs to be assigned.

The team has the chance to hold itself accountable many times during the project lifecycle:

  • The team will be held accountable on a daily basis during the standup meeting. How are we doing on our Sprint goals? Do we need help? What is preventing us from getting work done?
  • The team will be held accountable during the Demo. Did we deliver what we promised? Was it of sufficient quality?
  • Finally the team will hold itself accountable during the retrospective. Did we honor our working agreements? What could we have done better? How will we improve next time? A team needs to be careful how it decides to run its retrospective, lest they start drifting back into the blame game.

In addition to the original question, newer Scrum teams often ask how tasks are assigned in Scrum (or who assigns them). This is an ancillary opportunity to discuss the concept of accountability. The answer is: tasks are not assigned, team members volunteer for tasks. Assigning tasks prevents accountability, by not allowing teams to decide how the work will get done.

To increase accountability within the team, I have found the following suggestions helpful:

  • In Backlog Grooming, only allow those that are actually doing the work, to estimate the story. Scrum Master and Product Owner do not participate (unless they are going to be working on the story).
  • In iteration planning, only allow those doing the work, to create the tasks. Furthermore, make sure you don’t assign tasks. Let the team members volunteer.
  • During standups, have the team face each other and let the team decide who and how they will report on tasks. Product Owner and Scrum Master should act as chickens unless there is an impediment to address.
  • During the Retrospective, let the team decide how they will run the retrospective. The Scrum Master can facilitate and act as scribe.

What opportunities and/or techniques have you found to increase accountability and reduce blame among your teams?

3 thoughts on “Blame != Accountability

  1. Pingback: Root Cause Search « MakeThingsGo

  2. Good post – thank you!
    Regarding backlog grooming and estimations, and regarding breaking to tasks: I find that some people translate this literally – e.g. the person that will develop the story will estimate it and break it to tasks. This is obviously not what you tried to say – but it may be worthwhile making it clear.

    Regarding blame and responsibility: Christopher Avery talks about this in The Leadership Gift:
    His workshop is most highly recommended!

    • Good point! Perhaps a better way to state this: A team of developers could estimate stories and create tasks, even if they are not directly involved with the story. However I would not recommend SM and PO to participate unless they are involved in or have direct knowledge of story and/or tasks. I am familiar with Chris’s works. He spoke at SMU while I was working on my graduate degree. I refer to his work quite often.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s