Originally posted on www.debooij.training
Many teams and organizations struggle to get the most out of Scrum. In my previous post “Don’t blame “agile” for existing problems” I shared my analysis why agile or Scrum itself often gets the blame. In this first post out of three I will focus on what the most common mistakes are with Scrum that lead to dysfunctional Scrum. And what you can do about it. We are going to start by looking at the Product Owner role.
Scrum roles and responsibilities
Over the years I have learned and experienced that most symptoms can be traced back to not adhering to the responsibilities of the Scrum Roles. That’s why I have sliced this topic into three separate posts:
- Product Owner – Why your Scrum Doesn’t work (1/3)
- Development Team – Why your Scrum Doesn’t work (2/3)
- Scrum Master – Why your Scrum Doesn’t work (3/3)
Each post takes the perspective from the role being covered. I explore high impact discrepancies between how Scrum is intended (referred to as Professional Scrum) and how it is often practiced and misunderstood. The posts are based on my own experience when I practiced the roles of Development Team (member), Product Owner, and Scrum Master. And on recurring examples my students mention during my Scrum.org courses.
Product Owner
Professional Scrum Product Owner
As a Professional Scrum Product Owner you are maximizing value for your organization. You do this by deciding for your product what to work on and in what order. You have feedback loops in place so you can measure and validate the value of what has been released to your end users. And together with a solid Product Vision that aligns with the company strategy and vision, they form your compass for your daily decisions what to do next and what not to do. You help various types of stakeholders understand the decisions you make. And you use their feedback as additional input for future decisions.
You are the only one who decides what the Development Team will work on in future Sprints. Which you do by expressing it on your Product Backlog.
As a Product Owner, you closely collaborate with the Development Team to help them understand what needs you are trying to address and why they represent value. Together you will discover – preferably in close collaboration with end users of your product – just enough detail and boundaries to enable the Development Team to figure out how they eventually will implement this in the product Increment. During Sprint Planning you help craft a Sprint Goal that enables flexibility and facilitates self-organization throughout the Sprint. And you trust the Development Team to do everything they can to achieve the Sprint Goal, without interfering with the Sprint.
Read more about the importance of the Sprint Goal in my previous post
Why this might not work for you
Your organization might have slightly different expectations, like:
- just keep the Development Team busy
- make sure they deliver on time
- detailed and clear upfront requirements so there we won’t be any surprises about what comes out
- add this to the Product Backlog for the next Sprint
- and add this to the Product Backlog for the next Sprint
- tell me what you are going to deliver the upcoming year
- just focus on your product (or component), don’t worry about the rest of the organization.
Or maybe you – as a Product Owner – have a different understanding of the Product Owner role, like:
- I must spoon-feed the development team with the tasks they need to execute: they aren’t mature enough to self-organize
- during the Sprint, I make decisions for the Development Team to make sure they build it right. They can’t do it without me.
- I carefully monitor how the Development Team executes their work during the Sprint so I can be certain that quality and functional requirements are met
- I’m just a proxy between “business” and “development”
- I accept other people will tell me to add and remove Product Backlog items.
- it’s not my job to challenge the business and product strategy, I just execute what comes out of it
- it’s sufficient if I use feedback from internal stakeholders (that aren’t end users of your product) during Sprint Reviews in order to decide how to manage my Product Backlog and maximize value
What you can do about it
Frequently inspect what we should expect from a Professional Scrum Product Owner. For example by attending a Professional Scrum Product Owner course, studying the book The Professional Product Owner, and revisiting the Scrum Guide. Furthermore, reflect on how you practice the role at this moment. Only then you can identify discrepancies. And as a result you can figure out what you can do to change it for the better. Your Scrum Master can be of service here. If you want to know how, have a look at these posts:
What about the Development Team and Scrum Master perspective?
Read here the Development Team perspective and Scrum Master perspective.