Equality - accountabilities in Scrum
The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal. - Scrum Guide
All of these accountabilities (previously known as "roles") are needed in a Scrum Team. And all equally important to be successful.
It's all there is to it. And if we would practice Scrum within our companies the way described this way we can all be successful in delivering incremental value to our customers each Sprint.
The wording "roles" was removed from the Scrum Guide 2020 version, you can read more on why in this blog of Dave West. I still use the term roles in this blog, because in daily practice, we need a structure to group these accountabilities.
A word on "Developers"
It's important to understand that a Developer as is described in the Scrum Guide is not the same as a software developer. From the Scrum Guide:
Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.
Ergo: developers can be marketeers, analysts, android developers, designers, UX-ers, testers etc. etc.
Often these roles are not used effectively. And there are a couple of dysfunctions that take place in organizations that I would like to address in this article.
- Not all roles exist.
- Roles are combined.
- Hierarchy exist between people in one Scrum Team.
Taking away these dysfunctions will highly increase the effectiveness of Scrum in your organization. But first let's take a closer look at these dysfunctions.
Not all roles exist
All roles within Scrum are there for a reason and cannot be left out. This might be surprising, but I've seen cases with every role that has been left out, even the Developers! Which makes it pretty hard to produce a releasable increment. All the roles are needed in Scrum to be able to create products in this complex environment. Leaving out one of the roles will cripple your product and is not called Scrum.
Leaving out the Product Owner
I've seen cases where the important work of the Product Owner is left entirely to Developers. Leaving them with not only the accountability of producing a high quality releasable product, but also with stakeholder management, release management, maintaining vision and roadmap, etc. You can maybe imagine what this will do to the effectiveness of Developers and it's progress having no focus at all.
The focus of the Product Owner is to maximize the value of the product resulting from the work of the Scrum Team and therefore deserves it's own role.
Leaving out the Developers
Can you even imagine what you would do without Developers? You might think that there would be no way around this important group of people. However, I've seen cases where there are no Developers, just project managers shopping for development skills elsewhere, disabling them to deliver a "Done" increment of releasable product each Sprint.
The Developers are needed to be able to continuously work on achieving goals with attention for product excellence and the quality of the product delivered.
Leaving out the Scrum Master
This role is most often discarded. For a number of reasons. The most important one is that the role of the Scrum Master is often not well understood. Which is not surprising, as the role most differs from what we're used to in product development and projects. Sometimes, the existing role of a project manager is taking the place of the Scrum Master. Sometimes, the Product Owner also takes on the role of the Scrum Master, which is a problem I'll get into later.
There are a lot of good articles out there that cover this topic. The way I would like to summarize it is that the Scrum Master fosters empiricism and makes sure Scrum is understood by all.
Roles are combined
Leaving out roles is often done for reasons of efficiency. However, doing Scrum doesn't mean being efficient. It means being effective. Saving time does not increase the impact you make with your product on your customer. Focusing and caring for your product and your customers does. Focus, on of the five Scrum values, is an important aspect of Scrum. The reason that combining roles is not a good idea is because of focus. Every role has its own unique focus. And because every role is equally important and serves both other roles in one of more ways, combining is not a great idea.
Combining the Product Owner and the Scrum Master role should be avoided at all costs. There has not been a single case where I've seen this work. Not only the amount of work these two roles take on is tremendous and would make a 80 hour week; the two roles require a whole set of different competencies.
Hierarchy exist between people in one Scrum Team
You might wonder why the existence of hierarchy would pose a problem to the Scrum Team?
Often, the Product Owner is let to be in charge of Developers and sometimes in organizations this person is even the manager of other people on the Scrum Team.
The starting point for Scrum to be effective is that this team is self organizing. Meaning that each role is equally important, with its own focus and responsibility. And a Scrum Team cannot exist without all of these roles present.
Equality: Services to the other roles
What I mean by equality in the case of a Scrum Team is that each role is needed by the other roles and cannot function on it's own. Having one of the roles disabled in any way, means a less effective Scrum Team as a whole. So you could say the Scrum Team is as strong (or weak) as its weakest link. So making sure you let each of the roles fulfill their services to the other roles in an effective manner is very important.
Services to the Developers
Delivering valuable and releasable products for the customer is the purpose of the Developers. The Product Owner serves the Developers by making sure they are constantly aware of the vision of the product and goals that come with it. Also, the Product Owner constantly updates the Product Backlog with the latest insights and changes. And most importantly, the Product Owner trusts the Developers with decision making related to the quality, construction and maintenance of the product.
The Scrum Master serves the Developers by helping them self manage. Removing organizational impediments and increasing transparency where needed. The Scrum Master also facilitates the continuous improvement of the Scrum Team as a cross functional, self managing team.
Services to the Scrum Master
For the Scrum Master to be effective in his role, he needs the support of the Product Owner and Developers. The Product Owner serves the Scrum Master by being open and transparent about organizational impediments and things that require the Scrum Masters attention. Openness, one of the Scrum Values, comes into play here. The Product Owner needs to be open to be able to receive help from the Scrum Master to become more effective.
Developers needs to respect (another Scrum value) the authority of the Scrum Master on Scrum and guidance of the empirical process. They too need to be open about what's going on in the team and how they can improve. This trust is the bases for the Scrum Team to grow.
Services to the Product Owner
Developers serves the Product Owner by taking ownership of the quality and construction of the product. They are a formidable partner in the creation and maintenance of the product. They are honest and transparent about what is possible and what is not possible. They offer help in construction of the Sprint Goals and the estimation of work needed for the Product Owner to do stakeholder management and release planning.
The Scrum Master serves the Product Owner by being honest and transparent and offers help in the facilitation of events so that inspection and adaptation can take place and Scrum can be effective. Also the Scrum Master helps to remove organizational impediments and enables change in the organization so that the Product Owner role can be effective. For instance in helping the Product Owner to be mandated for product (business) decisions.
The roles all equally important within the Scrum framework, each with their own focus, responsibility and services to the other roles. Together, they form a cross functional and self managing team that can create great products and services within complex environments.
- Leaving out one of the roles means there is no Scrum Team, therefore no Scrum
- Combining the roles makes the team less effective and even disable it, despite of some possible efficiency gains
- Each role serves the two other roles in different ways making a combined effective Scrum Team