The product owner in Scrum is a very busy guy/girl. S/he’s got to:
- Define features of the product (or desired outcome)
- Decide release date and content
- Ensure profitability
- Prioritise features/outcomes
- Adjust priorities
- Accept or reject work
Does this person really exist? Is it possible that somebody can be found to do this job; that has the subject matter expertise and the authority to make big decisions all wrapped up in one person? That’s a busy person. And isn’t it likely that somebody like that is too busy to participate in the Scrum team on a daily (insert time period you prefer here depending on how ‘Scrummy’ you are) basis?
So we come on to the subject of the proxy product owner. Where is this defined in Scrum? Roman Pichler at the Aglie Alliance writes:
Using a proxy product owner is an attempt to superficially treat a systemic issue. Rather than employing a quick fix, organizations should address the underlying issues. This might require freeing up the product owner from other obligations; colocating the product owner, ScrumMaster, and team; or even finding a new product owner.
http://www.scrumalliance.org/articles/168-common-product-owner-traps
So is this Product Owner a logical role or a physical role? I think it’s supposed to be a physical role i.e. one person does it. I was talking to the owner of an Agile consultancy recently, and he said he’d never met one. I’ve never met one either. Sometimes I get the feeling that Scrum dictates what the world should be like and the world struggles to fit the definition and that’s frustrating. Which is flawed, the world or the Scrum definition?
What was wrong with Project sponsor, Responsible owner, Subject matter expert and Story Teller? After all, these are the competencies the Product Owner is being asked to exhibit. No wonder it’s hard to find this guy/gal. Maybe s/he’s a unicorn.
If you enjoyed this post, make sure you subscribe to my RSS feed!Tags: Product owner, Scrummy, Unicorn
Before Agile, I learned or was taught, “Roles aren’t People.”
One of my Agile adoption clients has a single person as Product Owner. Another has a team. Both pull in people who know details, as needed.
Agile is more about principles than rules. What’s the simplest thing that could work? One person. Then you use observations from the daily stand-up, and iteration-end retrospectives (very important) to keep things real.
Product Owner doesn’t have time or knowledge to feed the team details for test cases? Usually not. Add subject-matter experts, as needed.
Other stakeholders don’t agree with Product Owner’s prioritization? Make their common supervisor the Product Owner, or pick a Governance pattern (I use the set from Weill and Ross’ wonderful “IT Governance” book) and form a Product Owner team.
Effective iteration-end retrospectives are your best friend. “Effective” means “changes something for the next iteration.” At least some of the time, you should choose to simplify something and see if it still works.
Maybe the Product Owner team can disband, leaving one person, because there were no arguments in their last two meetings, and they’re starting to complete one another’s sentences, correctly.
I often set up an Agile project with a facilitated stakeholder workshop to build the backlog, and then a smaller group (or one person) can manage it.
Both the world and the Scrum definition are flawed, but in my 5+ years of experience with Agile adoptions it’s a lot easier to ignore the Scrum definition and remain useful.
My first visit here, and this was the first article presented. I read the title and as a Product Owner laughed out load as its so true.
I have be very vocally, internally in organisations and on blogs about the importance of the BPO role – as a member of an Agile team. A product owner normally sweeps around in 4 areas; Team Lead (sets the vision, and often the will of the team), Floor Walker (sets the expectations and stirs the feedback), Product manager (bread-and-butter prod man work) and Business Analyst.
Thats the hardskills – above all though they must employ the most important function, team member. Nothing takes priority over being there for you team. As the daily decision maker, as the point of domain expertise, as person to shoot ideas with. The rest all flows from here and the common point of failure is not because they are to busy to execute those tasks you list, but that they themselves have not been empowered to execute those tasks by the organisation.
What I mean by that is they have not been given full accountability for the product, so therefore cannot be responsible for the prioritisation. They are not trusted as domain experts, they role itself is not understood and committed to by the organisation.
For example – are you empowered as a BPO to make a decision and then explain it, or do you have to rally around for support on a decision and then ‘make’ it. That’s just one area where time (so … much … time… ) can be lost. As a BPO, let me make a decision and sack me for it later – if I have got it wrong.
Without that your BPOs are not empowered, as they cannot retrospectively examine their performance and improve. With it, comes BPO productivity and a body always ‘there for the team’ doing the bits of the Agile function that brings so much value when it is done the right way.
That said. I am busy