When You Have No Product Owner At All

What happens when you have no product owner at all? How does a team know what features to develop in what order?

Several teams I know encountered this. They all had product managers. Most of them had BAs. All of them had a technical manager who was willing to be their product owner, but they had no real product owner. They called themselves Scrum-but.

I used to think this was ok. I now think Scrum-but is a bad label.

That’s because agile needs a responsible person who is not part of the cross-functional technical team to rank the backlog so the team knows the order of the work. Without that person, the team does not know what to do.

So why is it so bad for a team to call itself Scrum-but? Because it’s not Scrum-but. It’s not Scrum. It’s iterative and incremental, but it’s not even close to Scrum. It’s not agile.

Johanna’s General Agile Picture

When you have no product owner who is not outside the team, or outside the hierarchy of the team, you lose something very precious to agility, the notion of the customer or customer surrogate. You lose the person who could be helping the team understand what the customer really wants. You lose the back-and-forth about the product that the customer helps the team understand.

The manager can help the team understand the requirements, but the manager is not the customer. The manager is not the person who can set the real acceptance criteria. The manager can see the demo, but the manager cannot say for sure that the team is developing the correct requirements in the correct order.

So why am I so insistent that we stop calling this Scrum-but, and even stop calling this agile? Because it breaks down the separation when-and-what-to-build (responsible person responsibility from ongoing incremental delivery of product on a regular basis (the cross-functional team responsibility). The customer or responsible person explains when-to-build in my little picture. The team decides how to build it. When the team manager gets involved, that allows the “business” to be unaccountable for developing the system. How do you know what is shippable product without the responsible person?

The problem is this: System development, product development is a joint venture between the business people and the technical people. We need the legal, marketing, sales, and anyone else on the “business” side of the house to help us with the what-and-when to build decisions. That’s why we need a responsible person. In Scrum, that person is called a product owner. And, we need a technical project team to deliver the value. We use agile as an approach and use the demo because it shows business value every iteration.

When the business is unaccountable, the agile ecosystem breaks down. We no longer have ideas coming into that funnel, being evaluated by that responsible person. Sure that responsible person has a lot to do. And, that responsible person should develop product roadmaps and make the potential product direction transparent to the rest of the organization. That way, the next iteration or two is clear for the team, and everyone can fight discuss the product direction. But when all the discussion is in the technical organization, those discussions tend to not happen. Or the discussions go off in a different direction than the product needs to go. And, that’s a Very Bad Thing.

Because, when the discussions don’t occur, the technical group takes all the responsibility for the product: for what to build, when to build it, and for how to build it. And that means we have let the rest of the business abdicate all of their responsibility for their part of the product. That’s not the partnership agile promises us, nor is the transparency agile promises us.

So, when you hear Scrum-but because you have no product owner, substitute “On the road to agile.” You’re actually iterative and incremental, but not agile. You have not made one of the necessary cultural changes for transitioning to agile. Can you keep doing what you are doing? Sure, if it’s working for you. And, that’s the million dollar question: How is this working for you? (If you would like more hints as to what else to do, consider my project management book, Manage It! Your Guide to Modern, Pragmatic Project Management. You have other options, if you cannot manage the agile cultural change right now. Those other options will help you move closer to agile than trying Scrum-but and failing.)

This is one of the points—the agile ecosystem and making it succeed—I’m working on for my keynote at the Agile Vancouver conference in late October.

Previous/Next Posts

9 Comments

I agree with your point about the product owner being essential. But why, I have to ask, do so many supposedly knowledgeable people advocate this role being taken by a trained business analyst. Not the same thing at all!

Good post Johanna. This is definitely a difficult transition that I think often gets overlooked. The partnership is somewhat of a balancing act and I think the community could use some more ideas and maybe suggestions on how to foster and build that partnership effectively. I also think renewed focus on the goal of delivering “valuable software” not just “working software” would help a lot as well (putting the finishing touches on my own post on this subject).

I also agree that I don’t like the Scrum-but term. I talked about that at the end of my presentation at Agile2011, I would only call it Scrum-but if you know you aren’t following the rules of Scrum and have no plans to get there (don’t think the rules apply to you). If you don’t think Scrum is right for you, but you are doing other agile practices, it’s okay to just be agile and not Scrum, you don’t have to call it Scrum-but. If you are working on adopting Scrum, but just aren’t quite there yet…that’s fine too. As long as you recognize you aren’t there yet and have a plan to get there. I like the “On the road to agile”, sounds a little better than my suggestion in my presentation of “not-scrum-yet”!

I’ve seen another symptom of Product Owner malfunction….and wonder whether you’ve seen this and might comment on it. The Product owner is busy (way too busy) gathering and ordering requirements, prioritizing backlog items…but the technical and development team isn’t commenting on or providing the PO any meaningful feedback. Instead they are grumbling that the PO is clueless….

This doesn’t seem healthy to me either.

Whole team means that ideally the feedback goes both ways (between the dev team and the PO). I think that healthy discussion is important to a vibrant product. The builders and designers often have deep insights about the product, too…

Let’s focus on what we mean by ‘agile’. The goal is for the company, or at least a workgroup within the company, to be agile. It’s not about the software developers being agile. I think many people miss this part of the concept. Johanna gets it.

We need to find ways of working with business organizations in developing good software. This requires an understanding on our part that business people have work to do, goals to meet, issues to resolve, etc. Working on software development with us is not a core competency of theirs. We haven’t solved that part of the problem and until we do, true agility will elude us.

@Rebecca, I think I have seen what you are referring to as well. I just finished my post I mentioned earlier (http://www.developmentblock.com/2011/08/is-working-software-enough/) and I think it could be a symptom of the same problem…too much focus on velocity, not enough focus on value. Really it seems like we may have just moved the fence…it’s great we’ve pretty much gotten rid of the fence between development and testing, but now there still seems to be a fence between the product owner and the rest of the team in some cases.

Yeah we really need a product owner that have the time and capacity to handle that role. I am interested in your view of combining the product manager and the product owner into one person. I have done that for a while and strongly suspect that it is the product management part of me that is suffering.

@christian I am currently doing what you talk about (product manager being the product owner), and it works well, I am far enough from the team, and close enough to the customer to be the customer advocate.

As you hint, this definitely impairs my ability to be the fullest sense of the “Product Manager”. I suspect that the reason why we overload the Product Owner role as a part time responsibility to some other person in the organization is the perception that it is a role that has heavy responsibilities around the iteration end/new iteration planning, and is fallow in between.

I would argue that this is neither accurate, nor true. I am constantly fiddling with my backlog, adjusting priorities, applying learning from customer interactions, and accommodating difficulties in the development process (i.e. feature X hit a roadblock, and will require significant refactoring to achieve success. Let’s slide in some more stories to fill out an other area and reschedule the “hard” task as appropriate.).

In this sense, I believe that the goal is to have a product owner who is dedicated to the role, without outside responsibilities to defer their attention. Where I am at, they are experimenting with a dedicated role, called Technical Product Manager. Great idea, but, these appear to be staffed with people who have so little experience, and not enough authority to even visit the toilet without permission. I fear it doesn’t bode well to staff the role with puppets, either.

I disagree… we live in a post modern world and I think there are many constructions of teams that achieve agility.

I think you are talking about a common problem in many businesses where you need someone to make certain types of decisions about what the product needs to do and tradeoffs of when those things get done. This is most often needed when the “development” people are not ‘experts’ in the domain and business of the product they are creating. They have no idea how to make the tradeoffs necessary or identify the key functionality needed. But this isn’t true of all teams!

Some groups of people don’t necessarily need this person/role, it’s quite possible for a group of people to develop a product making all the decisions themselves about what, when and then also how and to do all that in an agile manner.

There is no formula for agile. Agile is primarily a set of values and principles, if you can’t imagine multiple ways for people to organize themselves around these values and principles, then I say, *you* aren’t agile. You’ve become concrete and rigid about one mode of being agile. And as I said, we live in a post modern world, there are many modalities.

There’s value in discussing labels, roles, and specific techniques within one of those modalities, but don’t fall into the trap that that is the ‘one true way’

Hi,
I agree to the post above, the problem technical team encounters when there is no product owner or a product owner who dedicates very little time to the cross functional scrum team is the delivery ends up in chaos. The value of agile is truly acheived when the product owner reviews the sprint and makes his comments and prunes the product or release backlog accordingly and that results in continuous reprioritization according to the business needs and business value.when this continous pruning of product backlog does not happen the team loses direction and the purpose of delivering high business value is lost and often high priority items which is of high business value are ignored and worked very late in the release which endangers the release and loses value with the customer.

Subscribe to the Pragmatic Manager

Johanna’s Books

See Manage Your Job Search on Amazon, too.
See Hiring Geeks That Fit on Amazon, too.
Buy Now
See Manage Your Project Portfolio on Amazon, too.
Buy Now
See Manage It! on Amazon, too.
Buy Now
See Behind Closed Doors on Amazon, too.