Welcome to another installment in my blog series on “Anti-patterns that Doom Product Owners to Fail”, in which I cover the multitude of ways that Product Owners can cause things to go wrong. In this episode, I tackle the topic of confusion and misunderstandings about the roles on a Scrum Team, and what you can do to alleviate these problems.
Role Confusion
Problem
There are only three official roles in Scrum, and yet there is widespread confusion about which role is responsible for what. It’s quite easy to start blurring the lines between the roles and when you do, you’ll start stepping on each other’s toes. Not only that, but you’ll also end up with duplicative work and possible conflicts.
Solution
It’s essential to understand the three roles in Scrum, which (for the record) are:
- Product Owner
- Provides the vision and direction for the product
- Owns the Product Backlog (but may delegate work to team members)
- Makes decisions on whether to accept built increments
- Creates a Product Roadmap to map out delivery of the vision
- Manages stakeholders and their engagement
- Acts as the voice of the customer
- Keeps up with the market, industry, and competition
- Decides when to release
- Constantly assesses value delivery (aka: value maximizer)
- Developer(s)
- Develops the product
- Decides what backlog items to work on in each iteration
- Ensures quality
- Self-organizes and self-manages
- Has all the skills necessary to get to a “done” increment, which may include:
- Programmers
- Engineers
- Designers
- Business Analysts
- Data Analysts
- Data Engineers
- Quality Assurance Testers
- Any other specialized skills needed…
- Scrum Master
- Coaches the team on Agile and Scrum values and principles
- Serves the team
- Helps to remove impediments (when the team can’t do it themselves)
- Ensures that Scrum events happen (but is not required to facilitate them)
- Uses the concepts of empiricism to guide the team in making improvements
- Protects the team from interference (sometimes from the Product Owner)
- Guides the team in self-management
- BONUS “MOM” THOUGHT: I view the Scrum Master role like that of a parent: my job is to work myself out of a job (for the most part)
As you can see, each of these roles has a distinct set of responsibilities, and yet they are also meant to be highly collaborative and supportive of one another.
(NOTE: This is too deep a topic to dig into in this blog, so check out this great blog by Dave West, the President of Scrum.org: https://www.atlassian.com/agile/scrum/roles)
Misunderstanding of Scrum accountabilities
Problem
Each role in Scrum comes along with accountability. What does accountability mean? According to my go-to resource for definitions (dictionary.com), the word “accountable” means:
“Subject to the obligation to report, explain, or justify something; responsible; answerable.”
– dictionary.com
So, if you don’t understand what you‘re accountable for (see the previous section), how will you know if you are successful (or not)?
Solution
Kick-off your Scrum Team the right way, with a little activity called “Roles & Responsibilities.” I learned this magical technique from a colleague many years ago, and I find it to be a critical component when building any new team. It’s simple to do:
- Get some post-in notes and markers (skip this if virtual)
- Set up a meeting place (or a virtual meeting space)
- Create an agenda and invite your team members
- Invite everyone to write each of the things they are responsible / accountable for – one sticky note per item (give the team plenty of time to do this)
- Have a volunteer be the first to put their post-it notes on a wall (real or digital) and ask them to explain their understanding of their responsibilities
- Repeat until everyone has gone
- After everyone has shared, look for any overlap and discuss for clarification. Add or remove tasks as necessary to set clear job boundaries
- Also, be sure to address things that are shared responsibilities, such as quality, and ensure the whole team knows that they are all responsible for those items
- Ask the team if anything is wrong or missing and fix or fill the gaps
- Document what was discovered in a shared location (physical or digital)
As (or when) new team members on-board or old team members depart, revisit this document to make sure that it is still relevant and that any new people clearly understand what they are accountable for.
Playing multiple Scrum roles
Problem
Are you a Scrum Master/Product Owner? A Product Owner/Developer? Or a Developer/Scrum Master? Or do you play all three roles? If so, you will have problems. That said, there’s nothing in the Scrum Guide that says this can’t be done, but based on my experience, I would not recommend having anyone on a Scrum Team doing double (or triple) duty like this. For one thing, it’s insanely inefficient. Every time you take one hat off and put another one on, you lose time (it’s called “Context Switching”). That’s wasteful. And one of the key tenants of Agile is to avoid waste. On the other hand, it’s generally too much work for one person to perform multiple roles. It’s unsustainable, and that’s another Agile ideal that needs to be kept in mind: maintaining a sustainable pace.
Solution
Stop the madness. Yes, I get that in reality sometimes it’s totally unavoidable to have one person play more than one role due to cost, resource constraints, skills, etc. But if it’s all possible, I would recommend having different people in these roles. They approach their work from vastly different, but complementary, perspectives, and by allowing them to laser focus on one role, you’ll be much more successful. I have personally been caught in this trap several times before, and I don’t recommend it to anyone.
Final Thoughts
To recap, be clear on the official roles in Scrum. Having a Roles and Responsibilities session will reduce the possibility of people misunderstanding what they’re supposed to do. And whenever possible, don’t have one person act in more than one of these roles on the same team.
And that’s a wrap! If you have seen any other problems related to Scrum roles, I would love to hear about them, so drop me a note in the comments below!