Now that we’ve determined *what* a Product Owner is and should do, the next question is:
Where are they?
At ScrumGathering in Seattle last month, that question was prevalent. Attitudes toward the lack of engagement from Product Owners – not just at the conference, but at work – ranged from perplexed to angry.
Why Are POs So Important?
In Scrum, the Product Owner represents all things ‘business’ – the business value to be derived from the application, the priority of backlog items, the backlog items themselves. In short, the key to the Scrum team’s success. So the lack of a Product Owner or lack of PO engagement is a show stopper in terms of Agile or Scrum adoption. So much so, that developers are declaring themselves Product Owners! While this isn’t quite “the blind leading the blind”, it’s close enough to make me nervous (unless they happen to be creating developer tools).
Why Can’t the PO’s Do Their Job?
Well, um… because they’re busy doing their jobs. Unless you’ve opened up a bunch of job reqs specifically for Product Owners, every PO assigned to your team already had a full-time job in your organization. And frankly, the Scrum team needs them to have the expertise that their ‘day job’ provides.
Has anyone discussed with management – the PO’s manager or your own development manager – how much time “good Product Ownership” (however you define it) requires? While some of that time is trade-off for not having to do long requirements documents, participating collaboratively and working toward team success is more time intensive than finishing a piece of work, throwing it over the wall, and hoping you get an application you can use. Or worse yet, hoping that someone in IT can read minds and magically produce a valuable application.
How Do We Convince Business to Invest in Product Owners?
Well, then. Here’s where you come in. Frankly, this has been the sticking point in getting the biggest value from your IT investment for the last, oh, 25-30 years. Successful IT efforts have a strong bridge into the business – from Business Analysts or some other form of business stakeholder participation. In commercial software companies, these folks are called Product Managers – so the bridge is understood and defined, and they *still* have a problem with carving off enough time to be good Product Owners. In corporate IT groups, this bridge is sometimes no more than a few stepping stones across a raging river.
Let’s hear your comments – how do we explain/cajole/beg business to invest in developing Product Owners and authorize them to spend the time away from their ‘normal’ jobs to participate with the Scrum team? What’s been successful for you? What issues have you encountered? If you are a Product Owner – what are the challenges and how have you worked with your management to overcome them?