Scrum Accountability

(Germany)

September 3, 2019

TL; DR: Scrum Accountability

‘Autonomy without accountability equals anarchy’ summarizes an essential design element of any agile organization. Without these checks and balances in place any aspiration to transform an organization is likely to fail. (Or at best level out at a mechanistic level.) Learn more about how Scrum deals with accountability.

Scrum Accountability — Boss tells Scrum Team that he will hold them accountable for meeting his Sprint Goals

Accountability Enabling Cultures

From my perspective, Scrum places a significant emphasis on accountability to establish a system of checks & balances within the framework, thus enabling self-organization, empiricism, and a focus on quality. (Here, accountability acts as an enabler for Scrum first principles.)

In my experience, accountability also requires alignment at a team and an organizational level to flourish. Accountability is exercised collectively—as in the Development Team—or at an individual level. For example, it is the Product Owner’s prerogative to determine the content and the ordering of the Product Backlog.

Accountability needs to be pulled as it cannot be pushed upon teams or individuals. This requires a culture that does not punish failure but supports Scrum Values, thus providing the psychological safety for those who volunteer to be held accountable. (There is no blame game, finger-pointing, or butt-covering in a real Scrum environment.)

Finally, this approach rules out that Scrum can be imposed upon a team by an external authority, for example, the line management. It also provides an explanation of why the level of voluntarily assumed accountability seems to correlate directly with the engagement level of the involved individuals. (Do not expect the cogs in the machinery who are told what to when and how to be enthusiastic about their work.)

The Scrum Guide on Accountability

The Scrum Guide uses responsibility and accountability synonymously. Nevertheless, the uniform application of the idea of accountability across all three Scrum roles provides the basis for Scrum’s beforementioned system of checks and balances:

“The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team.”
“The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.”
“The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.”
“Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.”
“The Development Team is responsible for all estimates.”
“[Development Teams] are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality.”
“The Scrum Master participates as a peer team member in the meeting from the accountability over the Scrum process.”
“The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide.”

Source: Scrum Guide 2017.

Characteristics of Accountability

Let’s delve into some thoughts on and practical aspects of accountability:

Checks and Balances

Accountability and autonomy/self-organization are the two sides of the same medal—you cannot have one without the other:

Generally, in a self-organization enabling organization, distributed decision-making is rather the norm than the exception. (Top-down imposed decisions are unsuited for accountability assumed bottom-up.)
Team accountability for the Sprint Goal turns into individual accountability for tasks within a Scrum Team’s rules of engagement.
“Freedom and responsibility” may unlock infinite potential.
Prerequisites for accountability are trust and safety.

Collective Accountability

Scrum accountability heavily depends on the Team:

In Scrum, the Development Team is accountable to meet the Sprint Goal: “They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality.” (Source.)
The Scrum Team is also accountable to improve its way of working; there is supposed to be at least one improvement item to become part of every Sprint Backlog.

Physical Aspects of Accountability

There are haptic or physical moments that manifest accountability:

Grabbing or initialing an index card or adding “your” avatar to a task on a Sprint board to signal you’re working on this.
Taking a copy of a card to your workplace while working on the task.
Moving index cards on a Sprint board during the Daily Scrum.
Taking a stand during an event. (Does not work well with Jira or in distributed teams that rely on electronic communication.)

(Please note that Scrum does not say anything about Sprint boards, index cards, or avatars.)

Separation of Concerns

Scrum supports a separation of concerns at the Scrum role level, thus strengthening its internal checks and balance. For example, while the Product Owner is accountable to maximize the value of the Development Team’s work by defining the content and the ordering of the Product Backlog, the Product Owner does neither dictate the Sprint Goal, nor which Product Backlog items to pick. Ultimately, the Product Owner is accountable for the “why,” while the Development Team is accountable for the “how.”

Amateurs vs. Professionals

The maturity or proficiency aspect of accountability is borrowed from the Farnam Street blog:

“Amateurs make decisions in committees, so there is no one person responsible if things go wrong. Professionals make decisions as individuals and accept responsibility.”
“Amateurs blame others. Professionals accept responsibility.”