Mapping Accountabilities

In Scrum, the domains of servant-leadership, self-management of work, and product ownership, are split into distinct areas of accountability.

Scrum empowers Scrum Teams to self-manage. Autonomy comes with accountability. A team must now collectively manage the entire stream of value, from refinement to delivery and beyond. This means a team member is not only limited in its responsibility for just one area of competence. A programmer is no longer just responsible for programming. A designer is no longer just responsible for the design. A forward pass is not a goal. They must discover, refine, plan, communicate, collaborate, share knowledge, train, inspect, demo, review, deliver, learn, improve, resolve impediments, and make work visible. Wow.

Fortunately, they are a team. So they can self-manage how all this is done. That means expectations must be made clear.

"Not me, we! I was where I was supposed to be because someone else was where they were supposed to be." - Kevin Garnett.

A prerequisite to a safe and creative environment is transparency over roles and responsibilities. When roles and responsibilities are unclear, there is bound to be miscommunication, confusion, and ultimately frustration. When they are clear, a team will experience being in-the-flow. Players react naturally to each other's movements. They interact naturally as value flows through the system. And that feels great. They will:

• flexibility to calmly adapt autonomously to changing conditions and timely detect and resolve impediments;
• creativity to work out better ways to work through complex challenges or learn and experiment what could increase the value of the product;
• Increase productivity to timely, consistently, and predictively produce valuable and qualitative “done” increments.

When players are attuned to each other, they can focus on the play rather than argue over responsibilities.
A good team focuses on playing the game rather than arguing over it. When team members argue amongst themselves, the competition wins.

In this co-create activity, the team can run through a set of accountabilities and visualize where they belong. This activity is designed to make visible where accountabilities are not transparent and provide an opportunity to resolve that.

To make it safe: Understand that this activity is designed to make clear and resolve where accountabilities are not clear. Whether these will be resolved or not during this activity, at least it provides visibility over the situation in the field and where there may be 'gaps in the play'. It provides the Scrum Master with an understanding of where there may be impediments in self-management and team autonomy.

To make it safe: Respect that opinions will differ. Be thankful for members in being open and having the courage to clear the game of any noise.

To make it safe: Accountabilities need to be accepted, not enforced. The team may lack certain prerequisites and empowerment to accept certain accountabilities. A Scrum Master may list these prerequisites as impediments to self-management and work with the organization to resolve them.

Prepare the event:

layout a canvas for the following roles with overlap.

• Developers
• Product Owner
• Scrum Master
• Stakeholders
• Scrum Team
• Leadership outside the Scrum Team
• No one

Miro Template

List accountabilities:

• Deliver done increments
• Manage Sprint Backlog
• Determine what can be done this Sprint.
• Helping everyone understand Scrum
• Inspect the DoD
• Create and express the Product Goal
• Coaching the Developers in self-management and cross-functionality
• Refine the Product Backlog
• Total Cost of Ownership (TCO)
• Improve the DoD over time
• Improve the architecture over time
• Provide feedback during Sprint Review
• Leading the Scrum adoption
• Self-manage how the work is done
• Define the Sprint Goal
• Chair Sprint review and invite stakeholders
• Support the Scrum Team in Improving over time
• Backlog ordering
• Sizing work
• Define Product Vision
• Share market trends in Sprint Review
• Facilitate events when needed
• Accountable for the Scrum Team’s effectiveness
• Supporting each other along the way
• Resolving conflict within the Scrum Team
• Define architectural guidelines
• Testing
• Improve commercial health of the product
• Create a plan for implementing improvements to the way the Scrum Team does its work
• Resolving technical debt
• Any decision regarding the Product Backlog
• Expressing  the value of new requirements clearly
• Creating an improvement plan during the Sprint Retrospective
• Decide on releasing increments
• Keep the Sprint Backlog up to date
• Ensuring quality goals do not decrease during a sprint
• Sprint Backlog inspection
• Product Backlog inspection
• Adress & solve impediments
• Resolving inter-team dependencies involving the work in the Sprint
• Facilitate team in team decision making
• Participate in the Daily Scrum
• Creating a Sprint Plan during the Sprint Planning
• Planning Scrum implementations within the organization;
• Decompose PBI's into a plan to meet Sprint Goal
• Increment inspection
• Ensuring that the Product Backlog is visible, transparent, and clear to all
• Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done
• Providing transparency over decisions made in the Product Backlog
• Ensuring that goals, scope, and product domain are understood by everyone
• Instilling quality by adhering to a Definition of Done
• Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox.
• Adapting their plan each day toward the Sprint Goal
• Holding each other accountable as professionals
• Respecting each other to be capable individuals
• Being open about the work and the challenges
• Commit to the DoD
• Commit to the Sprint Goal
• Commit to the Product Goal
• Commit to supporting each other

The activity can be run in various ways:

• Mapping how the team believes it currently is
• Mapping how the team believes it should be
  

The team members may also add additional accountabilities which are applicable to their current context to this board.
For example:

• Opening a vacancy to hire
• Interviewing a candidate
• Hiring a new team member
• Onboarding a new team member
• Adjourning a team member
• Taking a day off
• Determining work hours
• Evaluating performance of individual team members
• Going on a training
• Managing a 'team' budget
  

Follow me...