Using the Daily Stand-up Meeting as an example
There are many ways to play the Product Owner role in a team. As with any role in a team, it depends a lot on the context and on the other members on the team: the team will build its very own dynamics, each member complementing the work of the other team members.
Today I want to focus on one specific element that plays a major part in how the Product Owner role is lived by: whether the team is working on a project or on a product.
The “Project” Product Owner
I know this title sounds dumb. But that’s a fact: many team are using Scrum to run projects, and are doing it with a lot of success.
On projects, it is a natural pitfall for Product Owners to behave as project managers:
- Status reports and “making sure we’re on track” is seen as very important
- Product mindset is often neglected in favor of sticking up with contracts
Don’t allow such a behavior!
Such a behavior should be fought against. In a Scrum team, project management is handled by the development team: it is a key driver of the self-organizing development team.
In that respect, the Scrum Guide makes a clear separation between the Product Owner and the Development Team, with good reasons.
One could even argue that it looks like a customer-supplier relationship and that would be right in the context of a project.
The perfect Product Owner is appointed by the customer
Still not convinced? Please consider that Scrum recommends having the Product Owner appointed by the customer. Obviously this applies to projects, and more specifically to software shops filling up custom software orders.
In such a situation, it would be non-sense to have the customer-appointed Product Owner behave as the project manager.
In such a situation, it’s obviously a good idea to reinforce the customer-supplier relationship between the Product Owner and the Development Team.
Please ponder this idea for a while… Having the Product Owner appointed by the customer casts the whole Scrum Guide under a different light.
One could even argue that’s the only way the Product Owner role makes sense if you are working on a project: because as the customer, the Product Owner can actually own the product.
Daily Stand-up Meeting dynamics
As an example, let’s consider how the Daily Stand-up Meeting (DSM) should happen on a project:
- The purpose of the DSM is for the Development Team only
- The Product Owner is not allowed to take part to the DSM; she can attend it if she wishes so, but is not allowed to talk during the meeting
The “Product” Product Owner
On the other hand, when the team works on a product, defining the Product Owner role feels natural: the Product Owner can literally own the product and make crucial decisions on it.
Almost part of the Development Team?
In such a case, the separation between Product Owner and Development Team is less clear.
The Product Owner is expected to set the vision for the product. But all the other stuff she does could actually be handled by the Development Team, or at least would benefit to be handled by the Development Team and the Product Owner side by side.
While on a project the Development Team is mainly concerned with Delivery, on a product the Development Team also takes actively part in the Discovery work. Every iteration, the team not only manages technical risks but also learns critical information on the product, the customers and the market.
Finally, is there any real reason not to consider the Product Owner as part of the Development Team when working on a product?
Daily Stand-up Meeting dynamics
Let’s have another look at how the Daily Stand-up Meeting (DSM) should happen, this time on a product:
- The Product Owner is welcome to take part to the DSM; any information she brings to the team is good to have
- The purpose of the DSM extends outside of the Development Team as long as it serves a greater goal
Don’t mix the two!
Project requires a strong structure to get Scrum right
Please don’t allow the Product Owner to behave as part of the Development Team if you’re on a project. Please don’t create an environment that will foster or even allow the Product Owner to behave as a project manager. That would kill the Development Team’s ability to self-organize.
Product unlocks many interesting opportunities beyond Scrum
Yet don’t limit yourself to blindly follow the Scrum Guide if you’re on a product. Only focus on creating value, any kind of value.