Are you overstepping?
For a Scrum team, role clarity can make the difference between a low performing and a high performing team. In fact, whenever I see strife on a team, it almost always stems from a lack of role clarity. When people step on each other's toes - even with the best of intentions - it can create tension on a team.
In this article, we will provide common oversteps for the Product Owner, Developers and Scrum Masters and what you can do to fix them.
Product Owner Oversteps
The Product Owner is accountable for maximizing the value of the product by focusing on what to deliver, not how to deliver it.
Solutioning
If your Product Backlog describes not only what you want, but how to deliver it, you may be overstepping. If you're putting table names in your Product Backlog items, you may be getting too far into the weeds.
Instead, focus on what you want and why it matters. Let the Developers figure out how best to deliver it.
Preloading the Sprint
If the Product Owner is building out a detailed Sprint Backlog before Sprint Planning event starts, they may be taking away from the creativity and problem-solving aspects that belong to Developers.
Instead, come to Sprint Planning prepared to discuss what's most valuable and why. Give the Developers room to figure out what's possible.
Roadmap is not flexible
It's one thing to have a roadmap. It's another to demand that the Scrum Team deliver it, come hell or high water. A roadmap is a guess. I'm not saying we can't have deadlines, but I am saying that how we get there should change as we learn more. You may need to remove scope or add budget to meet your Product Goal.
Why are these oversteps?
The Product Owner should be minding the store, not stocking the shelves. They should be looking two, three, or more Sprints ahead, thinking about where the product needs to go, rather than getting caught up in tactical details that the Developers can handle.
Developer Oversteps
Developers are accountable for creating a usable Increment every Sprint and determining how to turn Product Backlog items into value.
Unilaterally deciding to work on technical debt
I've seen Developers decide to spend an entire Sprint cleaning up code because they believe it's important. And they may be right! But when Developers make significant decisions about how to spend the team's time without involving the Product Owner, they're taking away from the Product Owner's ability to maximize value.
Working on lower priority work because it's in the same module
I've seen Developers pull lower-priority work into the Sprint (mid-Sprint!) simply because they were already working in that module. I appreciate efficiency, but working on lower priority work is never going to be efficient.
Just one more fix
Don't pull work into the Sprint unless you believe that it can be developed and tested by the end of the Sprint. And if you are pulling work into the Sprint mid-Sprint, talk to your teammates before you make that decision.
Why are these oversteps?
Developers want to improve the quality of the product, work efficiently, and get as much done as possible. Those are all good things! But when Developers make these decisions on their own, they can undermine the Product Owner's accountability for maximizing value and the team's ability to meet the Sprint Goal.
Scrum Master Oversteps
The Scrum Master is accountable for establishing Scrum and improving the Scrum Team's effectiveness. I know from experience that it can be easy to get overzealous when you're trying to help.
Becoming the Team's Administrator
I once tried to help a Scrum team by submitting all their security requests for them. Pretty soon I got behind and I became a bottleneck. Don't try to do everyone's work for them. You aren't doing anyone any favors and in fact you are creating a sense of disempowerment.
Assigning work to Developers
When the Scrum Master starts assigning tasks or deciding how work should be distributed, they're stepping into the Developers' accountability. How can Developers learn to self-manage if someone else is always telling them what to do?
Running every Event
It's true that the Scrum Guide says that the Scrum Master should facilitate events when requested or needed. But it doesn't mean you own every event. Start with letting the Developers run the Daily Scrum. Take turns leading the Retrospective. You may be surprised at how much more powerful these events become when you realize that the Scrum team is full of creative leaders.
Your goal should be to help the Scrum Team become less dependent on you, not more.
Conclusion
Most oversteps happen with the best of intentions. We want to help! But sometimes the best way to help is to step back and give someone else the opportunity to do their job.
So, the next time you find yourself stepping into someone else's accountability, ask yourself: Am I really helping, or am I getting in the way?
