As both Rachel and Tom alluded to in their posts about our Scrum training with Mike Cohn, the Product Owner role is one we struggle most with at LevelTen. The stresses associated with Product Ownership can be overwhelming, especially when we load down our POs with multiple projects. Why is this role so challenging?
Well, according to the Standish Group's report "Chaos," the most common reasons a software project failed or was impeded are:
- Lack of User Input (12.8%)
- Incomplete Requirements and Specifications (12.3%)
- Changing Requirements and Specifications (11.8%)
- Lack of Executive Support (7.5%)
- Technology Incompetence (7.0%)
- Lack of Resources (6.4%)
- Unrealistic Expectations (5.9%)
- Unclear Objectives (5.3%)
- Unrealistic Time Frames (4.3%)
- New Technology (3.7%)
- Other (23.0%)
Out of those top ten reasons, all but "technology incompetence" and "lack of resources" are the responsibility of the Product Owner. That is, eight of the top ten reasons relate to poorly articulated vision or a weak understanding of what the team can reasonably accomplish.
The report makes it clear that strong leadership and vision are most critical for software project success. Thus, the Product Owner's job is actually much more demanding than "owning the backlog" would imply.1
How do we lighten the PO load?
In my earlier blog post, I discussed our decision to implement a proxy model with the account manager and client working together as the Product Owner. This works well, but as the account managers continue to do a great job and bring in more accounts, they become spread too thin across multiple projects. We could hire additional account managers but for now, we’re supporting the account managers from within.
Rachel or I will go with the account managers to conduct the initial user story workshop and backlog grooming meetings. That way if the account manager is out of the office on a sales call or a client meeting, one of us can be available to the team to answer questions and give feedback. The account manager is still responsible for writing the sprint goals, prioritizing the backlog and doing the client demos, but we actually write the stories and conditions of acceptance.
Got any better suggestions on how to handle this? I’d love to hear 'em.
1. Agile Journal, Agile Journal, Monday, May 11, 2009 - How Scrum Generates Increased Productivity, Part Two: The Product Owner by Laszlo Szalvay (image source: http://farm4.static.flickr.com/3603/3578548023_2b64d413cb.jpg)