Month: November 2010

 

Authority issues are at the root of most failed Scrum implementations. Most organizations doing Scrum are unaware of the way Scrum roles contain specific authorized tasks. In Scrum, there is a clear separation of non-overlapping powers across the 3 roles. When this clear division becomes fuzzy, the result is all sorts of serious problems with Scrum.

Diagramming the specific authorized tasks in Scrum, by role, provides a simple and powerful way to depict exactly what is going on with authority in your Scrum implementation. I formulated Authority Mapping in late 2010 in response to client requests for diagrams describing complex authority problems in Scrum.Freely downloadable Scrum Authority Map diagrams appear at the end of this post in PDF format.

Scrum Authorized Tasks– by Role

Listing the various tasks authorized under each Role is Scrum an interesting exercise in deconstructing Scrum. Let’s enumerate the specific authorized tasks associated with each Scrum role:

 

Product Owner: Authorized Tasks

• Gather requirements and describe in PB
• Define per-story acceptance criteria and “definition of done” as part of requirements
• Gather estimates and place into Product Backlog
• Prioritize and properly size Product Backlog items
• Present PB at Sprint Planning meeting
• Preside in authority at the Sprint Planning meeting
• Behave in conformance with Scrum rules at all Scrum ceremonies
• Optionally abort the Sprint
• Accept or reject the increment per definition of DONE
• Develop Release Backlog & Plans
• Preside in authority at the Sprint Demo
• Participate in the iteration retro

 

Team: Authorized Tasks

• Supply estimates to PO for PB items
• Pull work (the “what”) from PB to SB during SP meeting
• Carve SB into tasks (the “how”) during Sprint
• Execute Daily Scrum meeting per Scrum rules
• Follow the protocol of the three questions
• Deliver per-Sprint increments
• Demo increments at Sprint Review
• Participate in iteration Retro

Scrum Master: Authorized Tasks

• Facilitate Sprint Planning meeting for PO
• Facilitate Sprint Review (demo) meeting for PO
• Facilitate Sprint Review (retro) for Scrum Team
• Facilitate Daily Scrum (each day) for Team
• Protect Team from distractions and threats
• Referee the rules of Scrum (keep the process)
• Identify and remove impediments for Team
• Arrange for Daily Scrum (location and time)
• Help identify a Product Owner

 

Authorized Tasks

I do not believe a list of this sort has ever been assembled as a way to analyze and view Scrum along the lines of authorized tasks.

Scrum’s clear roles are actually containers that contain authorized tasks— tasks which that each specific role has the right to do per genuine and authentic Scrum per the Scrum Guide.

It is useful to note that there is little or no overlap in the powers (“authority”, or “right to do work”) assigned to each Role. Early versions of Scrum vested the Product Owner AND the Team with the dual authority to kill the Sprint. The modern and most current version of Scrum per the Scrum Guide (found at Scrum.org) now assigns that authority ONLY to the Product Owner.

 

Mapping Authorized Tasks

The clear containment of specific authorized tasks by Role in Scrum creates an opportunity to visually depict or map the Role. This can be done by utilizing a simple “radar” graph, where each ‘spoke’ in the diagram depicts a specific authorized task for the role under consideration.

For example, here is the Scrum Authority Map for the [Team] role:

Figure 1: The Scrum Team Authority Map: Team tasks mapped to a radar graph

With this map, we can now depict the various ways in which a Team can take up (or not fully take up) the Team role. The map provides a way for you to accurately depict what is going on.

In your organization, you are probably familiar with people who “over-step” their Role. They take up more authority than the Role requires. Over-stepping is a common occurrence. Just as common is “under-stepping”– that is, NOT taking up all the authority vested in a Role.

This is exactly what new Scrum teams do: they under-step, and do not take up the full authority Scrum provides to the Team.

Now here is an authority map, filled in to depict the typical new Scrum team:

Figure 2. The Authority Map of a new Scrum Team who is not “taking up” all of the task authority granted to them in Scrum.

Here the new Scrum team is at about 50% on all the tasks they are authorized to do. This means they are assuming only about 1/2 of the authority they have per the Scrum rules. This is typical and entirely normal for new Teams, who often are uncomfortable (at least initially) with the higher levels of authorization granted by Scrum.

The green color signifies the level of authority they have effectively taken up, the yellow region depicts the substantial additional authority they have yet to “take up”. Teams new to Scrum typically “under-step” for many complex reasons.

Authority is not something that lays there unclaimed for very long. I’m sure you have seen persons in your own organization that actively collect authority “scraps” and begin wielding these small chunks of power.

Authority is often ceded, abandoned or otherwise left behind. Since authorization is valuable, others “take it up”. This is exactly what happens to new Scrum teams who are not sure how much authorization they have. The authority to do things gets picked up by others, such as the Scrum Master or the Product Owner.

For example, if the team is timid about pulling work from the Product Backlog during Sprint Planning, the Product Owner or the Scrum Master might choose to “help” by actually assigning the work into the Sprint Backlog. Once that happens, the Team is blocked, demoralized– and de-authorized. They check out and become a de-authorized team of zombies– a zombie team– present in body only, not engaged and definitely not passionate about this de-authorized brand of “Scrum”.

Depicting an Impeded Team with an Authority Map

Here is how a blocked team might look– a Team who is slow to take up their full Role, and is in fact leaving authority on the table. In such cases, the Scrum Master or Product Owner (or someone else) actually picks it up:

 

Figure 3. A Team with authorization blockages depicted.

Here, red signifies that some other person, group or organization is effectively impeding the Team from fully taking up all the authority genuine Scrum provides. In this depiction, the Team is ‘surrounded’ by others who are taking up about 50% of their total authority per Scrum.

In real-life scenarios, the Authority Map has various odd shapes that vary according to the situation.

The Artful Scrum Master

Teams typically are slow to take up the full authority granted by Scrum. There are many reasons for this. They might not want the higher levels of authorization Scrum provides. The new Team role with higher authorization might not be comfortable. The team might want to told what they “should” do. Or the Team may have low confidence that the organization is capable of actually maintaining high levels of Team authorization.

Eventually, if the organization is genuinely committed to Scrum, the Team will begin to take up the full authority vested in them by Scrum itself. It is the job of an artful Scrum Master to MAKE SURE that others do not “take up” the Team’s task authority during this delay. This is part of what is meant by the phrase “Protect the Team”.

If you have an artful Scrum Master, then within 2 or so iterations, the Team will begin to put its toe in the water, testing to see if they really do have the power to load the Sprint Backlog, define the Tasks, conduct the Daily Scrum and so on. When they realize they do, their Authority Map starts to looks like this, the Authority Map profile of a extremely healthy Scrum Team that has excellent execution and no impediments:

Figure 4. A healthy Scrum Team who fully “takes up” all the authority granted by Scrum.

Authority Mapping is a simple yet powerful way to depict exactly what is going on with authority in Scrum– by Role. Similar maps can be created for the Product Owner and Scrum Master role. An endless variety of situations can be depicted accurately using the Authority Map technique.

Practical Use of Authority Maps

Authority Maps are useful for depicting authority-related impediments, and provide a visual context for examining the problem under consideration. These maps are particularly useful for depicting issues with Scrum to sponsors, executives and Product Owners, as well as Teams. Use of Authority Maps is especially useful for Scrum Masters during Retrospectives with the Scrum Team. These diagrams are also useful at the start of adopting Scrum, to help describe and depict the various ways sponsors and executives can help Scrum take root. For example, a depiction of the Team’s Authority Map before and after an executive attends a Daily Scrum as an Observer can be useful for habituating those executives to Scrum and Scrum dynamics

Case Study Example: Teams Dominated by Product Owner and Scrum Master

The following is an Authority Map of a Team that has problems. The Product Owner is doing certain of the Team’s tasks and is doing so outside the rules of Scrum. Likewise the Scrum Master has grabbed certain tasks reserved for the Team role in Scrum. The result is a Team that cannot function well. Intrusions into the Team role and the taking up of Team tasks by others are depicted in RED in Authority Maps.

The Product Owner (PO) is pulling the work “for the team” or to “help the team” in the Sprint Planning (SP) meeting and is also “helping the team” by carving the Sprint Backlog (SB) into tasks during the Sprint Planning meeting. The Scrum Master (SM) is updating the BurnDown chart which is a task that only the Team is authorized to do in Scrum. This team was train wreck for these reasons.

The coverage in green is very low due to the Team being dominated by the Product Owner and Scrum Master. The other authorized tasks of the Team are not well-executed because of these unauthorized intrusions by the PO and SM. The game of Scrum was poorly played by this group of people.

 

 

Summary

Explicit examination is a hallmark of genuine and authentic Scrum. Authority maps extend our ability to visualize social dynamics in an easy-to-read yet powerful depiction of the current reality of your Scrum implementation.

Authority Map Diagrams are Available Now

You can download blank authority maps for the Product Owner, Team and Scrum Master roles below, for use in your own coaching and Scrum Mastering work.

Links:

Reference: Boundary, Authority, Role and Task: BART Analysis of Complex Systems

Download: This article as a PDF:  ScrumAuthorityMapsArticleV2

Download: Team Authority Map: TeamA-MapV2

Download: Product Owner Authority Map: ProductOwner-A-MapV2

Download: Scrum Master Authority Map: ScrumMaster-A-MapV2

***

About the Author

Daniel Mezick: An expert on teams and a trusted adviser to CxO-level executives worldwide, Dan consults on enterprise-wide culture change, implementing Scrum, and the often difficult adoption of authentic Lean principles. Learn more about Daniel Mezick here.