Product Owner or Product Ownership
Last post we explored the idea that teams are the elemental building blocks of agile organizations. We talked about how teams need steady inputs if we are going to expect steady outputs. Towards the end we concluded that the Product Owner in Scrum is that single person responsible for making sure the team has what it needs to deliver working software.
In most organizations, the Product Owner is pretty simply acting as a buffer between the team and the business. This is a nice clean solution for the team… but what about the Product Owner? Did we actually solve the problem or just transfer ownership?
If our cloud of stakeholders can’t make up their mind about what they want… if there is no vision and they can’t give clear direction to the Product Owner… the team will come to a standstill. The Product Owner will be unable to keep the backlog full of groomed features. The team will be unable to deliver working software.
What I am suggesting here is that we don’t really so much need Product Owners… what we need is Product Ownership. We need a business that can make up its mind about what it wants to build and then translate strategic direction into products, projects, and ultimately backlog items our teams can build.
Right now teams are struggling. The are struggling not so much because they can’t figure out how to write code… do continuous integration… test… or conduct a retrospective. They are failing at agile because we have pushed the alignment problem outside the team to a business that is not prepared to adequately provide a solution.
Solving this problem is going to be integral to any discussion of scaling agile.
Decisions, Decisions, Decisions
Deciding between feature teams or component teams is the first design decision you’ll make as you build out your organization. Deciding on the right teams to build those features or components is the second.
Without a firm commitment to establish teams, decide what they are going to work on, and to coordinate their backlog… making sure they are always working on the highest value stuff … your agile transformation is going to struggle. These decisions are foundational to everything else we are going to talk about.
From here out our discussion is going to revolve around figuring out how to give our teams the right stuff to work on…. coordinate their activities… do it in a way that best delivers on our organizations goals…. while minimizing the cost of context and coordination.
Comments (5)
Jeremy Kriegel
Great distinction between product owner and product ownership. I’d take it a step further and say that it is up to the Product Owner (person) to facilitate that decision making, if they are not empowered to make the decisions themselves, and communicate the implications of not having a clear vision.
Kevin E. Schlabach
Just a thought from a peer… when you have blog posts that begin by referring to “last time we talked about…”… can you link to it?
You have some really good multi-post threads, but months later it is hard to find/follow them. Linking them together (after the fact even) would help us leverage this content as a tool. You PMI:Agile thread is one I try to refind all the time.
Steve Campbell
This is a great series of posts! Looking forward to the next one…
Darrell Johnsrud
If agile shifts the problem from the Product Owner – Developer interface to the Product Owner – Business interface, how does one get the business more involved? What would it look like if they were more involved? How do you get the business to make up their minds?
Have you seen any real life examples of companies that had a holitic, agile product delivery ecosystem?
This reminds me of the principle about Service-Oriented Architecture that it is first a change to the architecture of the business, and only later a change to the technical platform.
Love the style of your drawings, Mike.
Stewart Rogers
Mike this is a problem I see at a lot of sites.
Unfortunately, the PM/PO is blasted with a firehouse of ideas and requests and it takes a lot of time to parse it, understand it and prioritize it.
PM/POs suffering from this have to seek efficiencies to optimize the innovation value chain.
Stewart