The Future is Digital
Becoming digital is the surest way for you to understand your customers' needs and meet their expectations. Learn how Perficient can help anticipate what's ahead for you and your customer with a digital strategy centered around empathy, alignment, and agility.
So you’re part of the dev team and looking forward to getting some work done. You have your first planning meeting, and while you and the rest of the team are discussing the User Story and the tasks that need to be accomplished in order to deliver, a voice speaks out of the darkness and tells you what you need to do in order to deliver what the business is wanting. You look over to see who is speaking and contributing to the discussion, and who do you see? The Product Owner.
Can this happen? Is the PO allowed to dictate technologies and methods used to deliver on a user story?
If we look at the Scrum Guide, we can see that the answer is no. The Product Owner is not allowed to dictate technology to the development team. The product owner is there to do one thing, manage the product backlog. They put stories into the product backlog, take stories out of the product backlog and change the order of the stories in the product backlog. They do not decide how, what, when or even what order the work in the sprint backlog happens in. The dev team determines all of that, the product owner officially has no say in the specific technologies or implementations.
Of course that is in a perfect Scrum World. And, as far as I have been able to determine, that world is extremely rare. In the real world usually one of two things happen.
1. The Product Owner has the knowledge
In this case, the product owner has a lot of knowledge around the technologies and implementations and has valuable opinions or strategies. For example, I worked for a while on a team doing major architecture / refactoring work of a big enterprise system. The product owner happened to be a very experienced senior architect, and he had a big bold vision for the refactoring of the current system to a new platform. So while he couldn’t get down into the weeds and discuss very minor code-level details of the work, he could and did set the overall technology direction and implementation.
2. The client sets the rules
This scenario is much more common, especially as a consultant. Your team will probably be working for a company with architects, tech managers, and/or various governance groups that will dictate what technologies will be used and the methods that need to be used in order to implement them. These various people will probably say, “OK we’re building REST APIs with JSON, Angular and Node” or “We’re building a Java Spring application.” It makes sense for the company to have a clear and consistent set of technologies, architecture patterns, etc. These people aren’t “product owners” and they’re not listed as part of the scrum team. However that doesn’t mean they don’t exist. While the Scrum guide describes the roles, rules and responsibilities of a small group of people with specific tasks, including the Product Owner. However, in a decent size company there will be many people outside that small scrum bubble and they will probably have responsibilities and input that will directly impact the team.
I know I have worked with several different types of Product Owners and they can all present different challenges, from a Product Owner that is not empowered to make decisions, to a Product Owner that over steps the boundaries of their roles and act more as a Project Manager. I have found that the best way to handle either of these extremes is training. As a Scrum Master, my duty is to protect that team and often that can mean explaining, teaching and coaching the Product Owner in their role.
Has there been a time when you have had a Product Owner that felt the need to tell the dev team how and what to do in order to deliver the stories? How did you handle this challenge?
