One of a Kind Beats Three of a Kind

This article has an audio version:    Download Audio Version

I worked with a team last week that had three business people who each established the team's priorities. This caused a number of problems for the team because they had no clear guidance on who to listen to. The three business people each reported to the same vice president who had given them the vague guidance to not overload the team with their own priorities and to work out any conflicts among themselves.

This worked well enough--except when it didn't.

When there were conflicts the team was left in the unenviable position of having to resolve prioritization conflicts among the three business people. This was impossible. Resolving business conflicts like this required a deep business knowledge the developers didn't possess. Apparently the three business people didn't possess an adequate shared knowledge or they could have gotten beyond their differences of opinion and presented a shared set of priorities to the team.

In situations like this, I find a common approach is to push the problem down to the team. Sometimes that's right--Scrum teams are meant to be empowered and self-organizing, after all. But in cases of conflict I find it more appropriate to push the problems up the organization. In this case, rather than pushing the problems down to the team, the problem should have been pushed up the organization to the vice president to whom the three business people reported.

Because this was a Scrum project on which I was consulting, the business people were each called "product owner." And this made things very hard for the team. Team members knew they were to work on things prioritized by the product owner. But they didn't know what to do when they had three product owners who occasionally differed on priorities.

Conceptually, there is a very simple solution: Each Scrum team should have one person they recognize as their product owner. Practically, though, this can be hard to put in practice because companies often want a team to listen to multiple "product owners." To solve the problem, the organization needs to make the hard decision of classifying one of the individuals as the product owner. This makes the others (the former product owners) stakeholders.

The newly singled out product owner does not get enforce his or her will across the product. There are, of course, other stakeholders who must be satisfied. However, satisfying those stakeholders by prioritizing the proper mix of features will no longer be the responsibility of the team. The problem is pushed up the organization to the one rightful product owner.


Get Your Customized Elements of Agile℠ Assessment

Get Your Customized Elements of Agile℠ Assessment

Find out how your team is progressing in their mastery of the 20 key Elements of Agile.

9

Posted:

Mike Cohn

About the Author

Mike Cohn specializes in helping companies adopt and improve their use of agile processes and techniques to build extremely high-performance teams. He is the author of User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile as well as the Better User Stories video course. Mike is a founding member of the Agile Alliance and Scrum Alliance and can be reached at hello@mountaingoatsoftware.com. If you want to succeed with agile, you can also have Mike email you a short tip each week.

The discussion here is closed but join us in the Agile Mentors Community to further discuss this topic.

Go to AgileMentors.com