BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News How to Scale the Product Owner Role

How to Scale the Product Owner Role

This item in japanese

Bookmarks

The product owner role from Scrum is used to interface between the business and development. In larger organization with complex products and many decisions that need to be made, having this role filled in by one person is often not feasible. When that is the case, solutions are needed to scale the product owner role.

At the XP Days Benelux 2013 conference, Timo Punkka will do a workshop where he discusses possible solutions to scale the product owner role. InfoQ did an interview with him about the role of the product owner, lean portfolio management, and customer collaboration.

InfoQ; Your session at XP Days Benelux 2013 will be about scaling the product owner role. Can you give some examples of this scaling, when would you need to do this?

Timo: There are number of reasons. Obviously the scaling becomes an issue when the size of the organization grows, which affects all dimensions; technical, business, strategic, etc. But the main reason in my opinion is the cheer amount of decisions that needs to be made - continuously. Organizations need to balance between the different products and product lines, short term revenue and long-term survival, selling products and selling services, and so forth. Decisions need to be made with the best possible information and everyone needs to be aligned to put these decisions into action. Making these tradeoff decisions is usually called roadmap and portfolio management. Most of the times too much work for a single Product Owner.

This been said, often times Agile is started within development, and single Product Owner for a team –model helps by giving the development team a clear understanding of priorities. However, there is large number of decisions that need to be done before the work arrives to team’s backlog. This is where the scaling helps.

InfoQ: Sometimes I get the idea that teams expect too much from product owners, and that it is difficult for product owners to live up to these expectations. Do you recognize this?

Timo: Yes I do. And not just development teams but organizations as a whole. Organizations think that Scrum, if that is the chosen model, concerns only the development function - and still hope that this would solve everything. That is not the case. Agile development will affect eventually the whole organization. The immediate effect can be noticed between development and Product Management for example. And, yes, I do mean that Product Management exists in Agile organization.

Maybe it is not so much setting the expectations, but not realizing what the other functions actually need to do, and how they need to change. The current state of affairs can be that the stakeholders are occupied with crisis meetings, fighting priorities between multiple initiatives, and making excuses. Because of this they do not realize that they could actually themselves proactively work to be better informed to make decisions regarding roadmap and portfolio.

Everyone needs to be responsible for this work. It is too much for a single Product Owner.

InfoQ: What can you do to scale the product owner role?

Timo: I often talk about hierarchy – maybe surprisingly in Agile context. I do not mean hierarchy as chain-of-command, but hierarchy of roles that focus on different time horizons. Roles focus on decisions impacting different time spans. For example, Product Owner typically focuses on current Release, but Product Management is more worried about the roadmap spanning several releases. Contra dictionary to organizational hierarchy the co-operation between the roles, or planning levels, is collaborative and dynamic. People focusing on certain time span don’t work in isolation or just provide a single hand-over every so often. People from different planning levels will collaborate, and this provides an opportunity for alignment, a shared understanding of the direction.

InfoQ: In your session you will also talk about lean portfolio management. Can you explain what it is, and how it can help to bridge the gap between the business and agile IT teams?

Timo: Lean portfolio management builds on top of the same magic that is so central to Agile development, transparency. On numerous occasions I have worked with organizations that have more “projects” on going, than people going at them. We have been so accustomed to the sayings like “we have to at least start this”, that we get blinded by all these things that we have in progress. Lean portfolio management, or at least what I mean when I use the term, guides us to limit the number of ongoing things. I actually promote giving up the concept of doing projects, and focus on continuous development flow using frequent releases. Release can in some environment be only a planning item, but preferably it of course results in actual release to the customer.

This brings several benefits. Having limited number of ongoing things, the status quo is of course clearer for everyone. Having a steady cadence for decision making also leads to fewer crisis meetings. When we stop frequently to re-synchronize the plans, we also have an opportunity to develop only the valuable part of each initiative, and move earlier to the next initiative when it makes sense.

InfoQ: Can you tell the InfoQ readers something about the real life story on customer collaboration that you will cover in your XP Days session? 

Timo: During the workshop we will do an exercise to visualize a feedback path matrix in an imaginary organization with complicated distributed customer chain. Feedback is needed in as many formats as possible, and also at all the different planning levels. In addition to typical planning and review meetings of Agile development, examples are customer representative panels, workshops with different stakeholder groups and workshops with participants from different stakeholder groups, different formats of user experience research and field trips. When the customer chain is geographically distributed we usually also need to use traditional practices like surveys and questionnaires, but to use them to support other - more collaborative practices.

The XP Days Benelux conference, held on November 28-29 in Mechelen (Belgium), is covered by InfoQ. Earlier InfoQ did an interview with two of the conference hosts about new developments in agile, successful agile transformations and the needs of European organizations in agile adoption.

Rate this Article

Adoption
Style

BT