Jasper Alblas — March 11, 2019 — March 11, 2019
The Scrum Team consists of three roles. The only three roles needed in Scrum. But all needed! And all equally important to be successful.
This first sentence is all there is to it. And if we would practice Scrum within our companies the way described in this first sentence we can all be successful in delivering incremental value to our customers each Sprint.
However, often the Scrum 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 roles.
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 Development Team! 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 the Development team. Leaving them with not only the responsibility of producing a high quality releasable product, but also with stakeholder management, release management, maintaining vision and roadmap, talking to customers, etc. You can maybe imagine what this will do to the Development Team and it’s progress having no focus at all.
The focus of the Product Owner is to maximize the value delivered by the Development Team and therefore deserves it’s own role.
Leaving out the Development Team
Can you even imagine what you would do without the Development Team? This self organizing, cross-functional team that can organize and complete the work that is needed to achieve the Sprint Goals. You might think that there would be no way around this important group of people. However, I’ve seen cases where the Product Owner and Scrum Master are also acting as the Development Team, or the Development Team consist solely of people with the same skill: disabling them to deliver a “Done” increment of releasable product.
The Development Team is 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. Focussing 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 cost. 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 roles
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 the Development Team 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 Development Team
Delivering valuable and releasable product for the customer is the purpose of the Development Team. The Product Owner serves the Development Team 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 Development Team with decision making related to the quality, construction and maintenance of the product.
The Scrum Master serves the Development Team by helping them self organize. 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 organizing 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 Development Team. 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.
The Development Team 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
The Development Team 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 offer 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 organisation so that the Product Owner role can be effective. For instance in helping the Product Owner to be mandated for product (business) decisions.
Closing
The roles are 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 organising team that can create great products and services within complex environments.
- Leaving out one of the roles means there is no Scrum Team, therefor 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.
Business & Finance Articles on Business 2 Community
(87)
