According to the Scrum guide, the Product Owner is responsible for maximizing the value of the product and the work of the Development Team. This involves several tasks that are not to be done only by her, although she remains accountable. In addition, the guide stress that the Product Owner is one person, not a committee. This makes it easier when taking decisions that can affect different people's interests. Until now, nothing new. Then, why this title for this post? Let's provide some context.
Some weeks ago I attended a retrospective of a team that had an amount of problems. This time, instead of watching them from the back of the room I decided to spend 10 minutes at the beginning in order to revisit some core principles that were completely missing. I started with a question: why are we here? What is our goal in our day to day routine? And one of the team members answered: we are here to code.
This, let's say, innocent answer provided a lot of insight about what was going on in the team and made me think about the relationship that team members should have with their product. Teams that simply code what their product owners ask for in the user stories do not feel real ownership of their products. They just receive requests and process them, forgetting somehow that we value customer collaboration over contract negotiation. In situations like this, there exists a barrier between the product owner and the development team. The do not work as a single team, but as the customer and the provider. And, obviously, this affects seriously to the product and to the team.
This disfunctionality must be addressed by getting the team members more involved in the product they are building, more connected to it, more interested in its impact on the market. What would happen if this product were their product? I know many developers that have their personal projects, just for fun or as the starting point for a future startup. And they all speak passionately about them. They care about every single detail. So, what if we make them also owners of the products they are building in our companies?
At first sight this seems to be against the one person, not a committee statement. But this is not the point. The role of the product owner remains. There must be someone to drive the vehicle, to take the appropriate decisions and to be accountable for them. But she should not do this alone. The team members must have voice in the design of the product. And not only from a technical prospective. It's their product too. They need to know the problems they are solving to the users. They must have empathy with their users, feel their pains and enjoy their satisfactions. Because once they share these concerns with the users, they will be motivated to address them. And they will consider them when creating new features. The product is not the product owner's toy anymore. It becomes the team's product.
 |
| Forerunners of the All Blacks. Christchurch, New Zealand: Canterbury University Press. |
And, how can we provide this ownership to team members? Just by involving them in the conversations where the users' needs are discussed and solutions are proposed. Jeff Patton's user story mapping workshops [1] are a perfect example. The user story maps should not be created just by the product owner. They should be the result of a workshop where to have open discussions about the goals we have, the users we want to reach and the features we plan to create for them. Also, upcoming sessions, such as backlog refinements or the reviews at the end of every sprint need to consider all the team members. This way, we will have better products and more cohesive teams. And team members will not be just coders anymore. Coding will be part of their skillset, but not their only contribution.
References:
[1] Jeff Patton and Peter Economy. 2014. User Story Mapping: Discover the Whole Story, Build the Right Product. O'Reilly Media, Inc.
