The Reluctant Product Owner

At this point in the discussion, it probably makes some sense to sync up a bit.

We started off looking for where all the traditional software development roles fit in Scrum. In the process we concluded that many of the roles are either the direct responsibility of the Product Owner or abstracted from the team behind the Product Owner. This conclusion is both powerful and problematic.

The Product Owner is a powerful construct because it solves two significant problems for the team. By virtue of having total ownership of the product direction, the Product Owner sets context. They give the team a single place to learn what needs to be done and why it is important to the business. The Product Owner also provides for coordination. They get to set priority and decide when the team has met its objectives.

Think about what happens when we don’t have a Product Owner working with the team. We might have excellent technologist, but no sense of the bigger market picture. If we sub out the Product Owner for a Business Analyst or Project Manager… we get the some of the coordination… some of the context… but little of of the vision. If we just have a Product Manager, we get much more of the context… but we are going to loose quite a bit of the coordination.

We lose the Single Wringable Neck. We must have both context and coordination for a successful agile team.

The Product Owner is problematic on several fronts. Most organizations have not hired single individuals with the breadth of skills necessary to fill the position. These skills rest with specialists… Business Analysts, Project Managers, and Product Managers. Do we convert these people to Product Owners? Can we train them with the new skills required to be a successful Product Owner? Will the organization trust these folks to be that Single Wringable Neck?

What if we hire from the outside? What do we do with our talented, dedicated, and most importantly…. knowledgeable traditionalists? Do we just let them all go? Is our organization structured such that a single person can do everything necessary to provide context and coordination for the team? Will we will able to find enough super human product owners to drive our mission critical products? What do we do while we are in transition?

This issue is BIG for small teams and mid-size organizations. It is even BIGGER for companies that want to do an enterprise agile roll-out. These are places where context will never be set by a single individual and coordination must happen on a much grander scale.

Let’s Start Small

We’ll start by looking at context and coordination issues on a small team and see what happens as that team tries to scale.

This picture describes our simple agile scenario. We have a single Product Owner working with a small team of 6-8 people… for this example, a team of generalists.

From the team’s point of view, the Product Owner has 100% responsibility for defining the context for the team. They create the product backlog, determine acceptance criteria, get the backlog ready for the team to build, and work with the team on a day to day basis to develop the emerging product. They own the product vision in its entirety.

In this example, the Product Owner also owns coordination. They set the priority of the backlog and thus the build order. If any trade-offs need to be made during the sprint, the Product Owner gets to make the call. At the end of the sprint, the Product Owner decides if the feature meets the acceptance criteria defined at the beginning of the sprint. They get to say when we are done.

Think about the kind of organization we are describing… probably a small start-up with a single visionary leader and a team of developers. There is no time or money for any unnecessary overhead, it is all about getting the product ready for market. There is no accountability to anyone other than the single stakeholder.

You might also see this model used on a small departmental IT project… someplace where there are no dependencies on any other part of the organization. This could be something like a small departmental website or maybe a homegrown accounting solution. These scenarios are optimally agile and optimally unconstrained… but do they reflect the reality of most organizations adopting agile? Probably not.

Next post, we’ll add some stakeholders and start to scale the size of our project. Any thoughts on what happens to our single point context and coordination model?