Product Ownership at the Enterprise
Over at Agile Journal, Dean Leffingwell has posted the first of a three-part series on the role of the Product Owner within an enterprise-sized agile organization. This seems like a particularly valuable subject, given that it examines the intersection of a pair of hot topics in the agile community: Not only does it address the precarious endeavor of scaling agile throughout an enterprise, it also focuses on how the Product Owner can help make that process a smoother, more successful transition. Leffingwell is writing from a point of experience—having trained thousands of CSMs at large-scale installations—so when he claims that none of the professionals he has trained would ever consider going back to their previous methods of development, it’s a compelling argument for agile.
In this opening article, he stresses the need for organizations to develop a nuanced Product Owner role. That is, Leffingwell suggests that simply following the role’s prescriptive responsibilities might undercut its potential. While he cites Scrum founder Ken Schwaber’s definition of the Product Owner as a solid starting point, he quickly expands the role’s functions to include:
- Setting objectives for the Sprint (or iteration)
- Prioritizing and maintaining the backlog
- Participating in the Sprint planning meeting
- Elaborating stories on a just in time basis with the team
- Accepting stories into the baseline
- Accepting the Sprint
- Driving release planning
For anyone who has served as a Product Owner, whether in an enterprise or a smaller organization, this list of responsibilities will look very familiar. Still, those of you may be thinking it doesn’t quite capture the extent of a Product Owner’s participation. For Leffingwell, that’s because Product Ownership at enterprises tend to fall into two distinct categories. On the one hand, the Product Owner exists outside of the team, interfacing with clients and focusing on visionary activities such as forecasting and identifying opportunities within a thrashing market landscape. On the other, the Product Owner is very much part of the team, working with them to realize the customer’s vision and provide guidance when needed. Rather than ask customer-facing Product Owners to take on more technical responsibility within the team or, conversely, ask technical managers to take on more customer-facing activities, he suggests that enterprise-level installations require both kinds of Product Owners. After all, they represent distinctly different skill sets.
For the most part, I tend to believe that the Scrum framework is flexible enough to scale, without making drastic amendments to the framework itself, but Leffingwell’s point is well taken. What do you think? How do you deal with these kinds of issues at your organization?
You can read Leffingwell’s entire post here: http://www.agilejournal.com/articles/columns/articles/1225-the-product-owner-in-the-agile-enterprise


