In Scrum teams, discussions, and disagreements regarding titles and accountabilities are common. For instance, there are often debates about whether Product Owners are too tactical and not strategic enough like Product Managers, if senior engineers should be distinguished from junior engineers instead of both being referred to as "Developers," or if Scrum Masters should be considered on a lower tier compared to Agile Coaches.

While it is essential to understand the reasons behind such debates, they can also hinder the creation of value for customers and end users.

A constructive approach to address this issue is to ensure comprehensive coverage of the three key accountabilities: Product Owner, Developers, and Scrum Master. This means that all responsibilities expected of each role are covered, irrespective of the specific accountability described in the Scrum Guide.

A practical activity to achieve this is the Herculean Doughnut. After explaining how the activity functions, it is crucial to consider important factors, including potential downsides and consequences. Finally, we will talk about a strategy to implement beyond the activity.

Herculean Doughnut

Setting up

Begin by drawing a doughnut shape on a whiteboard or a digital whiteboard tool. The doughnut ring should be divided into three sections: Developer, Product Owner, and Scrum Master. The centre of the doughnut represents the Scrum Team.

To the side of the doughnut, prepare sticky notes listing the key accountabilities of the Developers, the Product Owner, and the Scrum Master.

The order of these notes is optional. It is advisable not to include every detail described in the Scrum Guide, as a deep dive into theory and philosophy might not initially engage all participants, especially those not training to be Scrum Masters.

Teaching about Scrum

This activity serves multiple purposes, the foremost being to educate about Scrum.

Using the Herculean Doughnut, explain the three accountabilities forming a Scrum Team. Next, describe which accountability each sticky note corresponds to. The level of audience engagement in this step can vary; it's essential to cover the basics briefly, allowing for questions without actively soliciting input on the placement of sticky notes. The main objective at this stage is to teach.

Layering the Team and Organisational Context

For this step, prepare a new doughnut diagram and a set of the same sticky notes. Before labelling the three accountabilities, ask the team if they want to modify any part of the doughnut. This could involve renaming the Product Owner to Product Manager or Business Analyst, dividing the doughnut into more than three sections, or replacing "Scrum Team" with the team’s name.

Next, go through each sticky note and ask the team where it should be placed on the doughnut based on their current situation. This often sparks lively discussions and debates, which are beneficial as they lead to a shared understanding and commitment when the team reaches a consensus.

The flexibility of sticky notes allows for immediate reflection of the discussions. Sticky notes can be placed on the edge between two accountabilities to indicate shared responsibility, positioning closer to one side to show who is ultimately accountable.

Balancing Expectation and Reality

A common topic in this activity is the difference between current and ideal responsibilities. For instance, if a new Product Owner still needs to acquire the necessary domain knowledge, a Developer (often a technical lead) might currently manage the Product Backlog. In such cases, place the sticky note where the responsibility lies presently and mark it with a star or colored dot to indicate an expected future change.

This discussion often extends to activities not directly associated with Scrum, like writing user stories and estimating with story points. Use differently colored sticky notes for these activities to distinguish them from Scrum-specific responsibilities. This differentiation helps in two significant ways:

• It identifies whether a less valuable practice or complementary practice is part of the Scrum framework;
• Highlighting responsibilities beyond the Scrum framework, aiding the Scrum Team in understanding organizational constraints and planning for greater cross-functionality.

Closing the Activity

Use the same doughnut and accountabilities, possibly with different titles and outside responsibilities.

By comparing the initial doughnut, based purely on the Scrum Guide, to the second doughnut reflecting the team’s specific context, the team gains a better understanding of Scrum and a sense of shared ownership in their collaborative work process.

To conclude the activity, invite participants to consider why it is called the Herculean Doughnut. Encourage them to imagine a giant doughnut with a customer waiting at the bottom of a hill. Discuss scenarios such as some members dividing their time pushing multiple doughnuts up the mountain or a member having access to a bulldozer but choosing not to use it.

This creative exercise helps reinforce the concepts and allows the team to personalize the activity.

Addressing Potential Downsides

No single solution fits all situations, and while this activity is beneficial, some potential negative consequences should be considered:

• Conflict of Interest: Modifying Scrum accountabilities can create conflicts of interest, such as a Developer managing the Product Backlog and prioritizing technical improvements over business value. Highlight this issue and encourage intentional decision-making;
• Confused Accountabilities: Shared responsibilities can lead to confusion and blame-shifting. Ensure clear accountability and revisit the Herculean Doughnut during Sprint Retrospectives to clarify duties if needed.

The Bottom Line

The Herculean Doughnut activity is valuable for setting expectations and overcoming initial reluctance. However, it is only a starting point; teams should continuously inspect and adapt to find more effective working methods. According to the 2020 Scrum Guide, each element of Scrum is crucial for realizing its full benefits. Therefore, understanding the purpose of each component is essential before modifying Scrum to fit specific contexts.

Did you try this or similar exercise? How did it go? Share your thoughts in the comments.