A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

Scrum problem – when there are multiple Product Owners for the project, and they do not coordinate well

The problem that I am describing in this post does not happen for a large number of projects, where you have teams of around 5 – 10 people, with one Scrum team, and one Product Owner. In teams of this size, everything is self-contained and the team does not have any dependencies that cannot be easily resolved. However, there are a number of projects and products that are much bigger than the prescribed team size (between 5 and 9 people). In such cases, what happens is that the product is broken down into a number of Scrum teams, with each team typically handling a feature or a group of features, and a Product Owner for each team. The same Product Owner could be owning the features handled by multiple teams, and in many cases, where the project or product is complicated, the team can have multiple such Product Owners. Typically, the Product Owners are all part of the same Product Management Organization and work for the same manager (would be a more senior Product Manager or a Group Product Manager).
However, when there are such multiple Product Owners, things can get complicated pretty soon. Typically, a product is built of many features built by the various teams working together; and there can be a large number of dependencies between these teams. The output set of variables in the code being built by one team works with the input set of variables for the other team, and if there is any change in this functionality due to new features or modification of features, then the changes need to be coordinated pretty well. Now, in my experiences, Scrum teams can be pretty insular, and not likely to watch out for the other teams are doing (unless there is a Scrum of scrums happening, and even those can be a challenge to be pretty effective). What caused some of the biggest problems was that the priority set of one Product Owner did not sufficiently match with the priority set of another Product Owner (since they were working on different areas of the product and had their own analysis of what is more important). As a result, a team would make a change in one area, and the other did not make the necessary changes at the same time, more likely in another Sprint. This caused features to functional oddly, or even break – and deciphering the reasons for these breaks was an interesting effort by itself.
The second time such a thing happened, we decided that the a Scrum of Scrums was an absolute essential process that we needed to do, and we also set a process whereby the Product Owners working on the product met on a periodic basis, shared their Product Backlogs, and ensured that interlocking features got the required coordination in terms of priority.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>