Multiple Scrum Accountabilities: Good or Bad?

In 2020, the Scrum Guide changed “Scrum Roles” to “Scrum Accountabilities”. This implies that a member of a Scrum Team is not tied to a role. A Scrum Team member takes accountability to work towards the same Product Goal. It also implies that a single member may take multiple Scrum Accountabilities. But is it recommended?

Despite the influential people at Scrum.org not recommending us to take multiple Scrum Accountabilities, I had no choice but to take all three accountabilities since my team’s establishment. The team works quite smoothly most of the time, but there are unnoticed risks.

The Product Owner always wants to maximise the product’s value resulting from the Scrum Team’s work. On the other hand, the Scrum Master helps the Scrum team focus on creating high-value Increments that meet the Definition of Done. The three Scrum Accountabilities are designed to work as checks and balances mechanisms. There is a serious conflict of interest among them. They work with the same group of parties but often use different approaches to face the same group of parties.

Often, when I talked to the Developers, I wondered whether I was a Scrum Master, Product Owner, or fellow Developer. Even if I sometimes cannot distinguish my roles, do the other developers know which hat I am wearing while talking to them? A single person working for multiple accountabilities creates an imbalance of power and eventually leads to an unwanted hierarchy, damaging the self-management of the Scrum Team.

The Product Owner works beyond the Scrum. He formulates Product Goals and Vision, orders the Product Backlog, and establishes the Roadmap. He is also required to stay engaged with the stakeholders regarding the direction of the Product. On the other hand, the Scrum Master does not work only for a team. He works as a change agent within the whole organisation. He leads, trains, and coaches the organisation in its Scrum adoption by helping the employees and stakeholders understand and enact an empirical approach to complex work. The Developers work everything within a Sprint. There is already a heavy workload for each accountability. Each of them deserves a full-time job.

The management thinks that someone could take all the accountabilities often because they misunderstand the responsibility of each accountability. In their mind, the Product Owner and Scrum Master only work within a Scrum Team. But a person who works as a part-time Product Owner, a part-time Scrum Master, and even a part-time Developer can never accommodate the three-times workload. Eventually, this poor person gives up part of the jobs of each accountability. This diminishes the effectiveness of each accountability and degrades the Scrum Team’s self-management.

By the third year, I could no longer bear the heavy workload and recognised the risks associated with the diminished effectiveness of the Scrum Master and Product Owner roles. Consequently, I decided to give up the accountability as a Developer. I told the Scrum Team that I would not actively take on the Developer’s accountability unless the team encountered a catastrophic situation that required my fire-fighting. The team also reflected that no one except me would bother to take care of the work beyond Scrum. Thus, they agreed to “sacrifice” a Developer and reduce one-third of my workload, allowing me to focus more on the accountabilities of Scrum Master and Product Owner.

Now, I am working as the Scrum Master and Product Owner. I still participate in the Code Review to learn the implementation from the Developers. During the sessions, we sometimes discuss matters at the Product level. Does this impact productivity? There was a slight impact during the transition. However, we do not praise productivity or velocity as the metric of success. With part of my availability restored as a Product Owner, I can now focus more on the Product Vision and the Roadmap. Every member of the team now has a clear vision to guide our decision-making. As a result, we deliver a product that closely matches the users’ needs, reducing waste. Although I am still working in dual accountabilities, I hope that one day our team will develop a member who is interested in working as a Scrum Master or Product Owner, allowing me to transfer either one accountability to someone else and make it a full-time job.

Indeed, taking on multiple accountabilities presents significant challenges. There is a conflict of interest among the accountabilities, and some responsibilities may be compromised as a single person cannot effectively manage everything. However, this does not mean that achieving better results is impossible.

As a Scrum Trainer mentioned in the  Agile for Humans episode, you can either change the organisation or change the organisation (by leaving the job). You can delegate the responsibilities to others, help the team members to develop an interest in working as Scrum Master or Product Owner, and eventually let them take accountability, moving towards the goal – one person takes one accountability.