I think of the three accountabilities in the Scrum framework as creating a balance of power. The Product Owner owns the content and ordering of the Product Backlog, which describes what the team will work on. The Developers own how to deliver their work. And the Scrum Master helps to maintain the balance between them. But what happens when an individual fulfilling one (or more!) of the accountabilities in Scrum gets a bit — um — power hungry? Below are just a few examples of how people fulfilling each of the three accountabilities can overstep their bounds.
The Product Owner
The Product Owner accountability is critically important for the Scrum Team. This person is accountable for maximizing the product's value through the content and ordering of the Product Backlog.
However, the Product Owner should not be telling Developers how to accomplish their work, nor should they demand that Developers perform more work in a Sprint than the Developers think is reasonable. The Product Owner owns the Product Backlog, but Developers own the Sprint Backlog.
At the Sprint Planning event, the Developers select the Product Backlog items (PBIs) they think they will be able to deliver in the upcoming Sprint. They also create a plan for how they will deliver those PBIs, and craft a Sprint Goal summarizing why they are delivering the Increment. While the Product Owner can - and should! - encourage Developers to take on more work, only the Developers can decide how much work they can reasonably accomplish during the Sprint.
For the most part, the Developers will select items from the Product Backlog for the Sprint according to their order. However, when the Sprint is almost full, the Developers may choose some lower-ordered PBIs small enough to fit. This decision is a negotiation at the Sprint Planning event, with Developers collaborating with the Scrum Master and the Product Owner to determine what is the most valuable thing to do next.
Can the Product Owner push for more? Absolutely, but ultimately the Developers own the Sprint Backlog, and it’s their call.
Can the Product Owner forecast delivery for future Sprints? Yes, the Product Owner can create a forecast or roadmap estimating how much work Developers can accomplish or what they might deliver in future Sprints. Forecasting is appropriate as long as it is understood that it is just a forecast. Like tomorrow’s weather, it can always change as the situation evolves and more becomes known. For more on the Product Owner role, signup for Rebel Scrum’s upcoming Professional Scrum Product Owner course. The Professional Scrum Product Owner (PSPO) course explores the critical role of the Product Owner on the Scrum Team.
The Scrum Master
The Scrum Master is accountable for improving the adoption of Scrum by leading, training, and coaching the organization in its Scrum adoption. This includes maintaining the balance of power between the three accountabilities in Scrum by ensuring that individuals on the Scrum team understand how to interact with each other, helping the organization understand how to interact with the Scrum team and removing barriers between stakeholders and Scrum Teams. It’s a daunting mandate, and a Scrum Master cannot achieve success overnight.
Successful Scrum adoption requires a change in mindset. It is a change in values and principles for the organization. As any change manager knows, these types of changes are slow and require constant reinforcement to stick. It can be easy for a Scrum Master to become frustrated with the slow pace of change.
There are some common problems that many Scrum Masters face in organizations that are newer to Scrum. For example, stakeholders may not yet know the best way to interact with the Scrum team. Sometimes a stakeholder will request work directly from a Developer rather than working with the Product Owner to discuss whether the new work that the stakeholder is interested in should be added to the Product Backlog. Sometimes a supervisor will unknowingly reduce the Developers autonomy by assigning individual tasks from the Sprint Backlog to a particular developer.
Frustrated Scrum Masters may sometimes try to force change rather than winning hearts and minds. When a stakeholder requests work directly from Developer, the Scrum Master should coach Developers to redirect the stakeholder to the Product Owner or the Scrum Master themselves should provide coaching to stakeholders on how best to interact with the Scrum team. However, sometimes frustrated Scrum Masters will simply demand that all communications to the Scrum team must go through the Scrum Master.
I get it. It can be difficult for a Scrum Master to constantly have to uphold the Scrum framework and maintain the balance of power between the various groups. However, taking the stance that no one can talk to the Scrum team except through the medium of the Scrum Master is the same as breaking the Scrum framework while trying to save it.
The Scrum Master must remember in these situations that the individual fulfilling the Scrum Master accountability should be an expert in Scrum; not the commander of all communications channels coming into and out of the Scrum Team. The Professional Scrum Master course can help Scrum Masters articulate the “why” behind the Scrum framework, which is invaluable when trying to manage change in an organization new to the Scrum Framework. The Professional Scrum Master II course is an advanced course that will help Scrum Masters understand and embrace the eight stances of an effective Scrum Master — from servant leader to change agent.
Developers
Developers on a Scrum team are accountable for delivering a done increment which meets the Sprint Goal at least once per Sprint. As a team, Developers on the Scrum team have all of the skills needed to deliver a done increment each Sprint, which means that they are cross-functional, they hold each other accountable and they instill quality in the Product by adhering to the definition of Done.
Wise Product Owners actively collaborate with Developers and may order the Product Backlog taking dependencies into account. However, there is a balance between taking into account dependencies in the content and ordering of the Product Backlog and the Developers demanding specific criteria for ordering the Product Backlog.
For example, Technical debt is a common software development term describing coding decisions that might slow the future delivery of value. Delaying necessary upgrades or poorly written code or code which does not contain enough documentation (such as a lack of code comments) are all common examples of technical debt.
Developers should make the Product Owner aware of technical debt so that the Product Owner can determine whether fixes for technical debt should be added to the Product Backlog. However, developers cannot demand that certain Sprints be dedicated exclusively to the fixing or “Paying back” of technical debt. Instead, Developers should collaborate with the Product Owner on ways to maximize the value of the Product, which may mean sometimes strategically taking on technical debt or timing the fixing of technical debt strategically.
The Scrum Team
The fundamental unit of Scrum is a small team of people which includes the Scrum Master, Product Owner and Developer(s). A Scrum hallmark is the idea that the Scrum team itself is self-managing. Self-management is important because it allows those who are closest to the work to determine the best way to accomplish that work. The role of leaders is to support individuals on a Scrum team by removing impediments and promoting self-management so that the Scrum team can be as effective at value delivery as possible. The successful resource manager supporting Scrum Team members focuses on:
- Reinforcing clear accountabilities within the Scrum Team
- Reinforcing the concept of self-managing teams while setting guardrails within which teams can self-manage
- Creating a culture of trust by supporting the Scrum values
- Fostering collaborative problem-solving
- Helping Scrum Team members work effectively together
- Eliminating impediments
- Ensuring that team members have the right resources
However, sometimes a Scrum team may believe that self-management means that anything goes. On so many occasions, I have heard the words “there’s no manager in Scrum”. It’s a very misleading statement, because there is no CEO in Scrum either. Your CEO doesn’t need to start their job search as soon as Scrum is implemented in an organization, and neither does the manager.
The manager’s role in organizations using Scrum is to help create an environment which promotes bounded areas for action. These boundaries are important in helping the Scrum team maintain focus on delivering value in support of the Product Goal. In Scrum, a manager’s role is to promote self-management while setting limits within which teams can self-manage. It’s a contradiction, but it’s important to understand why there are limits to self-management.
Part of a leaders’ role is to ensure that team members have the resources that they need to deliver value to the organization. This can include ensuring that Developers understand the change control process at that particular organization or that Developers and are able to access the training that they need. Leaders have the difficult job of determining which resources the Scrum team needs and what limits should be placed upon the Scrum team in order to maximize value delivery to the organization while reducing risk.
In addition, sometimes managers within an organization may decide to create a definition of Done which all teams within a department or organization must adopt at a minimum. For example, an IT department may require that all Scrum teams conduct performance testing on each Product Backlog item before it is considered done. Other departments or organizations may have certain security requirements or regulatory compliance requirements which must be completed before each Product Backlog item is considered done.
Why would leaders create a shared Definition of Done for the organization? Because a shared definition of Done which crosses product teams can help promote transparency in cases where an organization or department has more than one Product team. In addition, a shared definition of Done can be used to promote the accountability of Developers on all Scrum teams to deliver increments of potentially releasable product frequently.
It’s not an easy job, but the best Scrum teams that I have ever worked with were supported by leaders who were focused on removing impediments, providing resources and promoting a mindset of Agility and a culture which supports the values of Scrum. For more on how leaders can best support Agile teams, signup for Rebel Scrum’s upcoming Professional Agile Leadership course.
Conclusion
The three Scrum accountabilities are part of the larger framework and set out the relationships and interactions on the Scrum Team. Each accountability commands respect so that the team remains in balance and working collaboratively to deliver value in a complex environment. Maintaining the balance of power between those fulfilling the 3 accountabilities within a Scrum team as well as between the Scrum team and the rest of the organization is important to ensure that the Scrum team is able to maintain their focus on providing value to the organization through the delivery of valuable Product Backlog items in alignment with the Product Goal. In complex environments, the way we work together is more important than ever.