The Great Product Owner Challenge

Scaling Frameworks abound aplenty yet something seems to be eluding us. I was speaking the other day to a Scrum Master I used to coach a few years ago at a well know Fortune 100 company, who proceeded to tell me that they’ve now stopped doing Scrum and reverted to some other approach as per the latest management edicts. Disappointed I started thinking in that deep meaningful way, and while I drove to the office on Friday it hit me like a eureka moment! Why it had eluded me for so long I don’t know, after all it’s been staring me in the face since the first day I started to scale Scrum. The Product Owner is the problem! BAM!

For years I’ve been coaching and teaching, and often screaming that if you don’t get the PO Role right any agile approach will flounder. Obvious I can hear you saying. Well duh! I wanted to understand this a little better so I explored some ideas with my colleagues and team members and this post is the result. 

In the old world of PMI and PRINCE II et al we had a known stable interface between the development team/s and the business. This interface is known affectionally as the Requirements Document, BRD or similar. This was diligently created by that buffer between the technical world and the business world known as the Business Analyst. When we all went Agile we abandoned this known stable interface. It was gone!

We've replace the requirements document with a new concept we call The Product Backlog and assigned it a custodian known as the Product Owner (PO). We now require this PO to create and manage an ever evolving requirements document. We even changed the name of requirements to Product Backlog Items, and then went and learned how to write 3 line novels for each requirement we call user stories. N.B. User Stories are an eXtreme Programming tool, and not part of Scrum per se. FYI I like user stories.

As we race headlong into some sort of transformation have we given this new interface to the business scant regard? We remove this known stable interface, albeit a flawed interface, and hurriedly replaced it with a dysfunctional half baked PO process that's under skilled and ill equipped to deliver as effectively as its predecessor, yet we expect them to be better than their predecessor. No the role is not half baked or dysfunctional, but our implementation and execution often is!

The Product Backlog?

A Product Backlog is a living artifact that exists and evolves. It is never DONE, it is only present and ever changing and developing. That’s one of the ways we become agile. We are able to ‘Respond to Change over Following a Plan’ as 17 chaps once mused. By allowing our requirements to evolve continuously we are able to respond to the latest needs or desires of our customers in near real-time, and to adapt to changing markets and conditions. Therefore The Product Backlog is a good idea.

The Product Owner?

The poor soul who draws the short straw? Let’s look at what the Scrum Guide says.

The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:

• Clearly expressing Product Backlog items;
• Ordering the items in the Product Backlog to best achieve goals and missions;
• Optimizing the value of the work the Development Team performs;
• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
• Ensuring the Development Team understands items in the Product Backlog to the level needed.

The next line I have always contended is flawed often to much derision from my peers. “The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.”

It’s also a contradiction with the second paragraph above. “The Product Owner is the sole person responsible for managing the Product Backlog.” We just said the PO remains accountable, but can have the development team do all the work. Hmmm...

In scaling approaches like NEXUS and LeSS, both of which I have studied and used in various experiments, they both call for a SINGLE Product Owner, even for up to 9 teams (8 with LeSS). 

Wow, so now we have a single person who has to do all that backlog creation and management for maybe as many as 81 people (based on 3-9 development team members). Let me use that oft used phrase I hear when I’m teaching “yes Nigel, but in the ‘REAL WORLD’”. 

Well for once I agree, in the real world one single person simply does not have the time or ability to manage backlog sufficient to keep that many people fully engaged and fruitful in their labors.  

So then that line in the Scrum Guide comes back to plague us. Aha, the PO can drop all that work onto the Development Team to do. Awesome, I’m a VP or big boss and off I trot to meetings and other important VP type stuff while the teams figure the product backlog items out. It’ll be great! Oh the Sprint Review? Sorry I'm busy. Send me a status report every Friday!

Enter The Proxy PO

Another phrase we Scrum folks hate is ‘Proxy Product Owner’. Both the creators and their many disciples deride that silly notion, as do I, but what did we just do? We just created a Proxy PO in the Development Team! They became the POs proxy. The PO turned up and said “this is my vision for this sprint”, and maybe scattered some PBIs, and then left the team to do the rest!

Even if the PO is awesome and creating great PBIs or User Stories, he or she can only peddle so fast before someone else has to take over that work and add PO capacity. 

Teams Don't Make Great POs

In the years I have been doing this I have not yet found many teams that can fulfill the role of PO effectively. Some have that ability, usually in a single member, or worse still the Scrum Master becomes the effective PO.

In a company with 100s of developers that skill is not prevalent and aplenty. Developers for their part are highly skilled at delivering value, and NOT as it turns out good at writing and refining backlog items, nor do they get excited about doing so. That function needs to be fulfilled by someone with product domain knowledge, and an intimate relationship with the customer, or whoever the value is being delivered to. In short we need a great PO, and in the main this means each team needs their own great PO. 

Now in LeSS they sort of break up the PO as in Scrum at Scale. In Scrum at Scale we use the Chief Product Owner notion, and in LeSS they have APOs or Area Product Owners. We still have only ONE Product Backlog, and I am sure Craig would argue only ONE Product Owner, but we have now created proxies. 

Let’s look at what proxy actually means ‘the authority to represent someone else’. 

So the CPO (or ‘real’ PO) sets the vision, strategy, direction, and probably owns a roadmap of some sort, as well as the ‘real’ single backlog. The level of abstraction in that single backlog is probably at a meta level (higher level) and we might call these PBIs Epics or something else meaning big PBI. Then his/her proxies (empowered APOs or POs) pull from that single backlog into their own backlogs and further refine the PBIs for the teams they are working with.

In short it’s all semantics. We need more than one PO per product if we have more than one team. The breakpoint will vary in different contexts, and if some approach is working perfectly for you, awesome, but let’s return again to the real world in global corporations and not 100 person self contained organizations.

Now this article is not arguing for one scaling approach or another, but many of you know I played a role in Scrum at Scale in it’s earlier days, and I do believe it's creator got the role of PO at scale correct. One per team! Yes some of you can probably function with 1:2 or 1:3 or even more, but where I see several high performing teams working together on one product no single PO can keep pace with their velocity and value delivery. They’re just too fast! 

Think about this for a second. If the teams are being POs and creating backlog they’re not actually delivering backlog to DONE, they’re writing about it. In my experience the fastest teams are delivering value while the PO is creating and refining backlog. We teach focus and priority in our classes, so let the team focus and prioritize delivering the work, and the PO focus and prioritize the scheduling and ordering of the work. Yes a backlog is a schedule. Shock horror gasp.

The Ideal PO

My own DoR (Definition of Ready) for starting any form of Agile approach is that The Product Owner must be an employee of the organization, and not a contractor. Why? The PO holds the purse strings as it is they in the words of the Scrum Guide “responsible for maximizing the value of the product resulting from work of the Development Team.” That translates to management of the budget for the product. 

There has to be fiduciary ownership of the finances and as the Scrum Guide states ‘the entire organization must respect his or her decisions’ this means that this person is wholly responsible for how the money is spent. If the PO is from the same company as an outsourced development team we have a conflict of interest. So this means we need great POs from within the organization who is using Scrum.

The Manager Dilemma

Apart from the anti pattern of managers being the PO or Scrum master for a team that they are also the HR manager for, the problem is many ‘new’ POs I have worked with actually don’t want to be POs, and find the work onerous for different reasons. Not all, but many. 

They just get told by their boss they’re going to be the PO, and then we train them and try and coach them, but invariably they struggle. One key reason they struggle is often because we didn’t make it their day job. No one change their role, we just gave them more work to do.

Managers often get shoehorned into the PO or CPO role and move from telling people to work harder and being the regular recipient of status reports, to now being expected to be the producer of just in time requirements that evolve and emerge iteratively and continuously, while they become an interface to a real customer. They maybe didn’t even meet a customer before! 

Or that ‘real’ PO or Chief PO also has to be a director and do directing type stuff. The role of PO seems to become secondary and the teams pick up the slack, or in a scaled world the team level POs try to do their best without frequent refinement of the ‘real’ backlog. In fact the PO part of the CPO role doesn’t happen. You know, creating PBIs/User Stories, and refining the roadmap, talking to customers, and attending refinement sessions with other POs or stakeholders. The C part of CPO becomes the focus, and not the PO part.

Being a Product Owner at any level means creating backlog! Yep another shock horror gasp moment! If you do not create and refine backlog, you are NOT a Product Owner.

The Executive as a Product Owner

As we scale up the organization above the team level we have a need to refine the backlog at even higher levels of abstraction. This is where the executives must act like a PO. Yes the abstraction is much greater, but ultimately it is they that are driving the overall strategy and direction, and it is they that must play their part.

As part of implementing Scrum at Scale at Toyota we created the concept of a LMS Leadership Meta Scrum, and an Executive Meta Scrum. I believe these are similar to the patterns in the latest Scrum at Scale guide. In most companies even a PO or CPO needs to take some direction from leadership or executives. Its that ‘real world’ thing again. This is where the relevant executives must meet the POs in refinement sessions we call Meta Scrums. Meta simply denotes a higher level of Scrum and is the PO scaling pattern in Scrum at Scale. 

Simply stated a CPO must meet frequently with their team level POs, as well as separately with their relevant leadership or executives. Refining the backlog with the team level POs looking at alignment (Roadmap), Progress (Value Delivered), and Priority (Value Planned). But they must also refine upwards with those that represent the customer, or alas shareholders. Welcome to corporate life.

Where we have a very large scale product we may have many CPOs meeting different executives or leadership in many Meta Scrums. Whether you call this portfolio management, investments councils, or other descriptors it is all backlog refinement and product ownership. Remember, we threw out the requirements document so someone has to decide what we're building, and pay for that. In most corporations it's the executives who are paying, or approving payment, and it is they that are answering to shareholders and the markets. It is also they that represent their customers.

Of course the notion in Scrum is we devolve that power to decide who, what, when, and why to the Product Owner, but where there is a need to justify there is a need for a higher level of Product Ownership. At all levels we need Product Ownership. If we do not have good Product Ownership and good Backlog Refinement then ultimately product delivery will stall or fail.

So as we scale up the organization we either need fully engaged executives at all levels, or delegation of complete empowerment and trust at the lower levels. There is no abdication of duty in Product Ownership.

An Alternative

Believe it or not this is actually a strategy to move waterfall organizations to agile approaches. I DO NOT advocate this as a replacement for the PO, but I can see us falling back to this pattern if we do not address the Great Product Owner Challenge. It’s called waterfall sprints or mini waterfall. Not the kind where the teams all have their defined roles and hand things off to one another, that’s a different problem, but one where we still work from a requirements document.

The idea is someone creates a BRD or similar. The PO (or similar) then cuts that document up into individual requirements, and working with the customer or stakeholders for that document prioritizes that list. The team them start building the first requirements in their entirety in a sprint. 1 or 2 weeks later (no one is doing 3 or 4 week sprints any more right?) we review that value with the customer. In the sprint we did all the necessary design, build, and testing of those prioritized requirements and they are done! Yes we might need some backend infrastructure, but hey we are in the age of the cloud for fast prototyping. Architecture evolves! 

The customer sees what we delivered and either signs off without feedback, or provides feedback and we potentially create a change of the requirements. We do the latter without drama or committees and the related expenses. 

If you wonder if this works, yes it does. How do I know. I’ve done it for some customers. It’s a countermeasure to an environment that is not agile friendly, or where we simply do not have the skills and/or commitment for the PO role.

I do NOT advocate this and do NOT like it, but I am a pragmatist occasionally. I find countermeasures to problems.

Once upon a time we called patterns like this Guerrilla Scrum. We pretended to be doing something NOT Scrum, when in fact we were doing Scrum. Once the concept was delivering value we then revealed to the players the truth, and became far more transparent. Yes I know I can hear Ken screaming already! Sorry :(

The Large Scale Scaling Problem

I face two major scaling challenges that are not solved by any scaling framework or approach. Organizational structures and Shared Services. 

Organizations are organized into deep complex hierarchies, often mired in process and procedures in numerous empires and fiefdoms we lovingly refer to as silos. These are protected and fought over with Roman like zeal. Melvin Conway coined Conway's Law to describe this eloquently.

"organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations."

You cannot hope to scale Scrum or any Agile approach while ever you maintain these complex organizational structures, hierarchies and empires. You MUST first de-scale. If you want to maintain these complex webs of interrelations and power structures then good luck. You will fail, and it’s only a matter of time. Or you’ll simply rebrand the current condition with Agile sounding naming conventions, but in essence you’ll be doing the same thing as you did before, or you’ll claim you tried Scrum and it didn’t work. 

Many organizations are also divided into vertical and horizontal structures. Verticals are typically value producing to a customer, and horizontals are often known as shared services, and deliver supporting functions to those verticals. In most organizations the verticals are bigger and have far greater capacity than the horizontals, often due to the fact the verticals are funded by the business or customer, and the horizontals are subsequently funded by the verticals.

Guess what. This does not create agility!

This is why Scrum works for small startups and similar ventures, as they do not have any deep hierarchies or shared services. They typically have funding and a team/s with all the skills to go build whatever they're creating. There are no silos, politics, and empires. They develop later!

Often I hear Scrum doesn't work at Scale. Nonsense. Maintaining your current organizational structure will prevent agility. Scrum works. You're just not prepared to make the necessary changes to be agile. Remember agile is not the goal, it is a result.

Organize into Value Streams

In manufacturing we organize the workers and the tools into value streams. All the pieces we need to delver value from concept to cash, or idea to production. We do not hand off work to another area and wait in a queue as this is one of the great Lean wastes. We streamline the system (systems thinking) and deliver a level workflow (heijunka) just enough and just in time (JIT). 

We must organize ourselves into value streams if we are to be more agile, and able to respond to change and deliver rapidly to the customer. We must eliminate all waste in the system. Silos are wasteful. Handing work off and waiting for some deep hierarchal process to execute is simply paying for a process that adds no value. Non Value Added work! Non value added work is not free! You are paying people to do it!

Value Added work is defined as work the customer cares about or is willing to pay for, work that physically changes the product or service by being processed, and work thats done right the first time requiring no rework.

Devops and automation capabilities and similar self service tools will all help, but limiting shared services to a specialized group will ultimately be your major constraint in the system.

Become Entrepreneurs  

Trying to implement Scrum across departments of a 1000 people will be a nightmare. Ask me how I know. Then if those same 1000 people are dependent on another 1000 people, themselves spread across several other silos (vertical or horizontal) the idea of rapidly responding to change and delivering value every sprint becomes a fantasy. What you end up doing is delivering parts of a product to another 'sprinting' team who them handoff down the chain and so on. That's not the idea!

We must de-scale the organizational structures. We have to remove the barriers between silos, and restructure our organization to enable rapid value delivery. To create true value streams where all the people, tools, and processes are contained in one organizational unit. 

We need to create mini businesses across a larger landscape. This is the idea of what Spotify created. No Tribe bigger than 150 people. A Tribe being a collection of Squads (what they call teams). 150 is Dunbar's Number (often misquoted as 125). The theory of Dunbar's Number posits that 150 is the number of individuals with whom any one person can maintain stable relationships.

In a value stream a group of teams have all the skills and tools necessary to deliver all the products they own to all the customers they service. Not some nightmare we call matrix management.

It's all about Prioritization

Yes but we have so much to do and so few people, and cost cutting, and budget restraint, and we have to deliver everything, you just don’t understand. 

“Hogwash”, to quote an old mentor of mine! You are blind to the reality. You cannot simply have less people doing more work and expect to deliver high quality on time and on budget. You will simply thrash your workforce until they burn out, and ignore the second lean principle, Respect for Humanity. You'll also create some known as the Product Death Spiral Lean Product and Process Development 2nd Edition by Allen C. Ward, Durward K. Sobek II.

You either have to fund the work you want to do, or you have to prioritize the work you can do. Let me say that again.

You either need to FUND the work you WANT to do, or you have to PRIORITIZE the work you CAN do.

Guess who’s role that is! Yep you guessed it. The Product Owner!

So there you have it. The Great Product Owner Challenge. 

If you want to be agile, and succeed at Scrum then you’re going to need to create great Product Owners who fully understand the role, and who are empowered and able to perform in that role as defined. You’re also going to need to scale that role across the organization, an organization you must transform and change to succeed, or you better start typing that next requirements document.

Nigel

Footnote: As people have started to discuss this article with me I have started to reach a conclusion. The Product Owner Role at Scale is flawed. It works great at small scale, but rapidly runs into significant challenges at a scale above a few teams. I am not sure we can make this work at large scale. This is caused in part by the complex organizational structures, silos, and power centers in large companies. The answer is of course to de-scale as I wrote above. I continue to run experiments and inspect and adapt though rapid PDCA cycles, but I do wonder if we can ever actually solve this, given what we know about how corporations are structured and their motivations for NOT changing.