Empower the Product Owner

"Let's empower the product owner role fully!  If the product owner is the one ultimately responsible for the results of the product in the marketplace, then they are the "source and decision-maker" for things like budget, scope, approach, market/product timing.  These were things PMs respresented before but PMs were always just "middle men."  With agile, we put that work where it naturally occurs  –  with the PO.  So, when we're thinking of the "PM stuff" that Scrum does not prescribe, think of the role of PO  (plus, the role of the trash bin, because that's also where some "PM stuff" goes)."  Lyssa Adkins, Post in Lyra Mentor Group 2011

Planning an agile team structure is fun - redistributing the power as a result of introducing Scrum within an organisation is a delicate topic. Getting real with implementing the roles is where the hard work starts including the discussion about empowerment. How far can a product owner and thus a Scrum team go, where is the limit of their empowerment? How much do the managers trust their freshly born product owners and what responsibilities will they delegate to them and to which level? The product owner role links the agile organization with the rest of the company (world) which may be less or not agile at all. Thus the answers to these questions highly depend on the context's level of agility and may not be black and white but grey  –  and may evolve over time. 

Jurgen Appelo provides a simple yet powerful game called Delegation Poker to shed light on this grey area and foster an open discussion about the delicate issue of empowerment. The result of using this tool is an authority board which defines the level of freedom for Scrum teams and visualizes the walls within self organization may happen. Here is what I have learned using the tool with managers and product owners within an agile transformation. I plan two or even three iterations – timeboxed to 60 –120 minutes – with different focus depending on the size of the group and level of agreement about the management style within the group. One first dry run helps to get a clear picture of how the group wants to work together, an understanding of the work to be delegated and of the meaning of the delegation levels. It's also fun to use the winning element in this round so everyone tries to understand what delegation level may be best suited for the whole group. Another question that should be raised during the first round is how he delegation level will be implemented thus questions like 'uups agreement sounds so nice – we all want to be very polite right? – but isn't that a hell of work if we have to discuss about every user story in detail?'. 

The second round focuses on getting real with the responsibilities and their delegation level thus requires that everyone in the group understands the work of the product owner. A simple diagram mapping the flow from an idea to product increment helps to identify the most interesting spots for discussing the delegation level. 

It's essential to make clear how to deal with multiple hierarchy levels, e.g. CTO, product owner and direct line manager of the product owners. A simple diagram will do the job to clarify which hierarchy level is represented at the poker table. The full chain of power delegation being present in the game is necessary for coming up with binding results. Surprising differences between middle and higher management may surface during the game and result in insightful discussions about leadership style. Nevertheless the resulting authority board is most useful when the product owners (or any other group it is designed for) can take it and look up their level of freedom thus the discussion should be focused on the delegatees and not so much on the different viewpoints of the managers who delegate. 


The expected timeframe the authority board is supposed to be valid or will be revisited again should be made clear in advance: is the group discussing about the status quo or crafting a vision for the future or just the next step which includes a small challenge. I prefer not to use the winning mode oft he game when creating the final authority board and to have rather a discussion about deviations like in planning poker instead of truncating the highest delegation levels with the minority rule.

Delegation poker is fun to play, yields a common understanding of the responsibilities and makes the new level of freedom transparent for the Scrum teams when turning the organisation upside down during an agile transition. 

With the authority board in place the group has a starting point for implementing and re-adjusting empowerment when needed. And last but not least betting in a group together on the delicate issue of empowerment helps building the interlocking roles of product owner and agile manager.

References

• Jurgen Appelo 2011, Leading Agile Developers: The Seven Levels of Authority (Part 1 http://www.informit.com/articles/article.aspx?p=1675545, Part 2 http://www.informit.com/articles/article.aspx?p=1675546)
• Jennifer Allora, Guillermo Calzadilla, Gloria. US Pavilion, Venice Biennale 2011 (http://vernissage.tv/blog/2011/06/22/jennifer-allora-guillermo-calzadilla-gloria-us-pavilion-venice-biennale-2011, http://www.nytimes.com/2011/05/15/arts/design/allora-calzadilla-gloria-venice-biennale.html?pagewanted=all)