Managing a Product Owner in a not-yet-agile organization

Question

When my company was acquired, my 20-person development team gained a Product Owner who is energetic, engaged, and extremely idealistic. While many of the programmers on our team are familiar with agile principles, our methodology has been eclectic rather than agile, and we have delivered high-quality products on time for almost 10 years. Our programmers work on more than one project simultaneously, and all projects are not in this PO's area of responsibility.

We've "gone agile" in that we work in 2-week sprints from a backlog of prioritized user stories (not broken into 2-week size). The PO wants to know how many hours programmer X has available during each sprint and exactly what he will do with them. He wants demonstrations of features completed at the end of each sprint, and if an implementation is more complicated than we expected and something isn't done, he considers that we have broken our commitment.

I've been reading about the Product Owner role in hopes of finding language to tell this person, "Your role is to set the goals and priorities, not to manage our time at the level of hours. You need to focus on making sure the user stories are clear, and then leave us alone for a sprint to do our jobs unless we have questions." However, the more I read, the more I think maybe he's not overdoing the role per se; rather, the whole problem is that he's performing it too enthusiastically in an organization that isn't following his methodology and isn't convinced it will improve our output.

My specific question: Is my statement above about the PO's role legitimate? In a truly agile environment, does the PO go to the level of saying things like, "OK, we have 40 person hours of work for Arthur and 32 person hours of work for Candace, and since they're each supposed to be half-time on this project, they should finish that work by the end of the next sprint." ?? I know we have a lot of issues to resolve, but if you all tell me that this guy isn't over-stepping his role as a reasonable PO in an agile environment, our group might find a way to be less resentful.

Answer 1

TL; DR

It really sounds like the Scrum Master and the Product Owner have both bought into the velocity and utilization trap. Break the cycle.

Dissecting the Product Owner Role

The PO wants to know how many hours programmer X has available during each sprint and exactly what he will do with them.

Not his business in a Scrum shop. He is part of the Scrum team, but he's not in charge of story assignment or team organization. A Scrum team is self-organizing (when it's working well), so this is a no-no.

He wants demonstrations of features completed at the end of each sprint[.]

This is legitimate. A Sprint Review is a standard Scrum meeting, and definitely part of the framework. It should be focused on completed, user-visible features, but that's somewhat of an implementation detail. The critical thing is that the Sprint Review is the opportunity to show the Product Owner and the stakeholders what's been completed during the most recent Sprint.

[I]f an implementation is more complicated than we expected and something isn't done, he considers that we have broken our commitment.

Maybe, and maybe not. There are several issues wrapped up here. Let's look at them.

1. The Team should have a "definition of done." If the Sprint Goal has not been met, and the work doesn't meet the definition of done, then it's simply not done. It's never partially-done; in Scrum, "done" for a user story is all-or-nothing.
2. The caveat to the previous axiom is if the Team and the Product Owner cooperatively redefine "done" during the course of a Sprint. If you are part-way through a Sprint and realize you will not meet the Sprint Goal or complete a story, then you should immediately involve the Product Owner to discuss your options.
3. If the Team is properly executing Sprint Planning, then the Team is committing to the Sprint Goal and a set of user stories. That's why it's important to estimate properly, and not to overcommit.

How to Handle Failing or Failed Sprints

The PO is wrong in making this a blame issue, though. The Scrum Master's job is to use the Scrum process to manage everyone's expectations during and after a failed Sprint.

If a Sprint is in danger of failing, the PO should be involved ASAP. The Product Owner has several options:

1. Work with the team to redefine the Sprint Goal or the accepted user stories in order to salvage value from the Sprint.
2. Terminate the Sprint early so that a Sprint Retrospective and a new Sprint Planning session can reboot the process now that everyone has more insight.

Neither option should be a "blame game." Having to renegotiate or restart a Sprint is a common occurrence in Scrum, especially with teams that are new to estimating. It is usually a result of some or all of the following:

• Process impediments that were not foreseen or included in story estimates.
• Mistaken estimates of one or more user stories.
• An overly-ambitious Sprint Goal.
• Over-committing during Sprint Planning due to incorrect story estimates, over-estimating team velocity, the "100% utilization" anti-pattern, having stories assigned to the team (rather than the team making its own commitments), or any other reason that places more stories on the Sprint Backlog than can reasonably be completed in a single Sprint.

Utilization Anti-Pattern

The 100% utilization anti-pattern is what concerns me most. You say that the Product Owner says things like:

OK, we have 40 person hours of work for Arthur and 32 person hours of work for Candace, and since they're each supposed to be half-time on this project, they should finish that work by the end of the next sprint.

This is a double fallacy. First, the Product Owner is not permitted to estimate work-effort for the team. His role is to prioritize stories, and to work with the rest of the Scrum Team to adjust scope or delivery dates to meet business requirements based on the Team's estimates of the amount of work involved.

Secondly, a successful Scrum Team is self-organizing. If the Product Owner is assigning work, attempting to implement 100% per-person utilization, or otherwise micro-managing the Team's intra-Sprint processes, then the Scrum Master must:

1. Educate the Product Owner on the benefits (and limitations) of the process.
2. Ensure the Team is not over-committing.
3. Coach the Team to organize as efficiently as possible around accepted Sprint Goals. This has nothing to do with utilization, and everything to do with shared ownership and voluntary commitments.

The goal of Scrum is not to maximize feature velocity or resource utilization; the goal of Scrum is to manage the Cone of Uncertainty involved in large or complex projects, and to create a sustainable pace of work based on increasingly-reliable story estimates. In other words, reliability and consistency trump speed; the speed evolves as processes, estimation practices, automation, and work-flow improve over time.

Answer 2

In a truly agile environment, does the PO go to the level of saying things like, "OK, we have 40 person hours of work for Arthur and 32 person hours of work for Candace, and since they're each supposed to be half-time on this project, they should finish that work by the end of the next sprint." ??

Well, in a Scrum environment, or in any other project environments for that matter, the product owner should not estimate the tasks for the developers. People doing the work should be providing estimates, especially when decomposing stories into tasks. This is even more important in Scrum where the team is self organized.

In addition, since you are just getting started, you probably don't have a handle on the team velocity (how many stories the team can implement in an iteration) and this makes the product owner's statement even more ludicrous.

In my group, the product owners are responsible for what we are going to be doing and the teams are responsible for how it is going to be done.

It is perfectly fine for the product owner to share an opinion, but one should not confuse estimates with target.

It may be the right time for your group to review the 10 Deadly mistakes of Software Development. :-)

Answer 3

Role descriptions...or a lack thereof. Poorly drafted role descriptions will wreak havoc on your capabilities.

Whether this PO is outside of his boundaries with focusing on hours really depends on how your organization defines the role. I'd bet you could get a few inconsistent opinions from surveying this site. But at the end of the day, it becomes how your organization defines the boundaries of each role.

Speaking of boundaries, this is often overlooked when drafting role descriptions. Most just write to responsibilities. They forget about accountabilities and boundaries.

Because you are complaining, it sounds like the PO is overstepping your perception of where the boundary is between his role and the agile team lead's role.

Your answer is not found about what is right in an agile environment; it is found by properly establishing firm role descriptions for the organization.

Answer 4

Agile Common Understanding

In short, agile methodologies like Scrum or XP usually split responsibilities into 3 parts:

1. the cross-functional team : all the people (developers, testers, integrators...) needed to achieve actual project work. They usually are self-organized, which basically means that there is nobody outside the team who assigns work to individual team members. They commit themselves on the work they can do in each iteration (for iteration-centric methodologies like Scrum. It might be a bit different with flow-focused teams like in Kanban)

2. the coach : called "Scrum Master" in Scrum, he is responsible for the HOW part. He knows the methodology and how to apply it. His work consists in helping both the product owner and the team work together. He is not a project manager in the classical understanding of the term and will not assign work nor impose his decisions.

3. the product owner : called "customer" in XP, he is responsible for the WHAT part. The product owner is the stakeholders' representative. For the team, his role consists in providing a prioritized set of items to work on (features, user stories, etc.). For the stakeholders, his role is to report project progress. The product owner usually works full-time on the project and is easily available for the team.

So if you - I mean your company, team, PO, etc. - explicitly decided to use such a methodology - but you did not - there should be no doubt about what is everyone's responsibility. In this case the Product Owner should not (have to) deal with the HOW part at all.

The role of a Scrum Master is important here as he will make sure that nobody crosses the line. For a Scrum-focused answer you should also read the question "Why can't the scrum master and the project manager be the same person?" which features very interesting answers.

Role definition

my 20-person development team gained a Product Owner

My understanding of your question is that the Product Owner was kind of dropped into your team deus ex machina. If I understand well then there might be a misunderstanding in role definition that you must try to clarify. David Espina's answer is pretty clear here on this point. "Product Owner" is just a name after all...

Classical Project Manager

The PO wants to know how many hours programmer X has available during each sprint and exactly what he will do with them.

If your PO used to be a command-and-control project manager, he might have trouble with becoming "only" a PO. He is used to having lots of metrics related to individual work that allow him to monitor the progress of the project. Try to understand why he wants to collect these data and how you could provide him relevant indicators that would achieve the same role but at a higher level (velocity, throughput, cycle-time, etc.)

He might also want to make sure that everybody is 100%-loaded. Please refer to CodeGnome's answer on that point. Also read Pawel Brodzinski's article A Myth of 100% Utilization.

Trust

"OK, we have 40 person hours of work for Arthur and 32 person hours of work for Candace, and since they're each supposed to be half-time on this project, they should finish that work by the end of the next sprint."

If your Product Owner often wants to go to this level, then there might be a trust problem between him and you. Maybe your lack of experience with Agile projects, his experience with non-Agile projects or a possible broken commitment earlier in the project makes him reluctant to trust you and your team. Under business pressure, he might want to "do it himself".

In this situation you want to sort things out quickly, since this lack of trust is likely to kill your project.

Summary

Is my statement above about the PO's role legitimate?

In absolute terms : yes. Your definition of a Product Owner is very "scrumy". But the thing is that there obviously is a misunderstanding somewhere, either on each other's role, or on each others skills, or on each other's goal, etc. Make sure that you both are on the same page on this question.