After a few months of working on my first “agile” project, I’ve come to the realization that the core challenges lie in the multi-faceted product owner role. In casual conversations with other business analysts (including Jake Calabrese, Ron Thompson, and Brad Swanson) and I’ve begun conceptualizing some thoughts about the myth of the perfect product owner.
Some questions to consider: What project really has one person who balances the input of a diverse collection of stakeholders and can make good decisions on-the-fly? How do you write user acceptance tests during a sprint without this perfect insight? Why has agile made everything seem so simple when in reality some things are complex? And why, why, why does it frustrate me so?
I have been surprised that most of my agile readings did not really dig deep into the role of the product owner or the complexities of analyzing and solving real business problems. But I wasn’t really surprised that when I finally took some time to seek out different opinions, there were others who shared views closely related to my own. I invite you to consider the following articles and come back to share your thoughts on the agile product owner topic with this community .
- Dean Leffingwell, a true authority on agile and requirements helps digest the complexity of the role in his post Organizational Insights and Comments on the Agile Product Owner Role. From his point of view, the product owner must blend business acumen and technical understanding with the ability to balance multiple perspectives to conceptualize a product plan. No small potatoes.
- Borland asks What is a Product Owner in Scrum? and answers: “There are many supporting responsibilities that ideally are handled by the product owner, but may be handled by other supporting members of the organization as long the final decision, and responsibility for the results of that decision, rest with the product owner directly.” Interesting insight: the product owner has authority and decision-making responsibility with the support of a myriad of individuals.
- Mike Cottmeyer breaks down the product owner responsibilities and also offers us a team-based model for fulfilling the complex set of roles in his post The Product Owner Team. Members include the business analyst, user experience designer, product manager, and project manager.
So there you are. Some interesting thoughts on what it means to be an agile product owner and how to fill this role successfully. This role is definitely not for the faint of heart. I’m pleased to see the depth of the dialog out there truly pushing the boundaries.
I invite you to share your experience with these responsibilities and provide links to other resources that explore this topic. And keep in mind some time-honored advice: If it were easy, anyone could do it.”
Update 4/14/2009: Thank you to all you Stumblers who are finding this post. I am working on a collection of posts about agile, business analysis, and the product owner role. I invite you to subscribe to the RSS feed to continue collaborating on these topics!
|
By Laura (Brandau) Brandenburg. Laura Brandenburg is an independent business analyst consultant. She is passionate about the BA profession and is committed to contributing by supporting this blog as a forum for business analysts to build on each other's experiences. View more blog posts by Laura (Brandau) Brandenburg |
Related posts:
Loading ...
.jpg)
{ 4 comments… read them below or add one }
g’day.
very good thoughts there. let me share my experience.
last 2 years i did exactly this stuff – extremely entangled and complex (90k python?) but low-resources project, me being the leader (and also the only methodolohy-aware one in the company), things got pretty rough.
i didn’t follow exactly Scrum, instead i went by Cockburn’s Crystal Clear but all the same, Product Owner roles became a nightmare. Yes they has to be multiple! They are the frontline between pure software and the rest – application/market and organisation.
So what i ended was: Business Analyst/Expert, Expert User, Product Manager, Project Manager, Architect, GUI-designer, (And End-Testing). Shared between two people, me and a lady that i was teaching on the run, both with plenty of other duties… impossible!
One may say that this or that of the above roles actualy lives elsewhere… yes but 50%/50%. And if u split by the letter, the info has to move more frequently between many more heads, and that slows the project! Probably there has to be 3 people as there are 3 main stakeholdoing directions: development, organisation, endusers; all these has to keep in mind the now and the future.
IMO this stuff is usualy all understated, underrated, underestimated, underthought if u want.
Regardless of the methodology, these roles has to be there and u cant lump them all into single person for any big project (note: big not just in the sense of people involved, but reality to describe)… That head will explode.
have fun
svil
Hello, Svil, and thanks for you comment. I hadn’t quite thought through the implications of having multiple people fill the role from a timing perspective. As you note, that will surely slow the project down as there will need to be more meetings, discussions, and alignment as the multiple perspectives of the product owner team are brought to bear. It would be interesting to hear if the results end up being worth it. If you can optimize a small product owner team and make it fairly efficient in it’s decision making, is the value of what’s delivered to the organization through the development process improved?
I share your concern that the functions of Product Owner role are not well defined by current Agile methods such as SCRUM or extreme programming. I have 10 years experience in agile development, mostly in a product manager role.
Doing a good job requires skills from multiple disciplines such as: business analyst, product management, portfolio management, and human factors / user interface design. Oh yeah, plus quality assurance for functional acceptance tests.
I think that companies tend to under staff the Product Owner role. I think of the PO as feeding developers. Good developers have a big appetite and can produce a lot if you feed them well. I think a ratio of 1:4 is good. If you starve developers by constraining access to and availability of the product owner their productivity goes down. This is the number one constraint to optimize if you want to get the most out of agile development.
So, what to do if you have a product with a larger development team? One client of mine breaks it down into having “feature owners” to keep their PO to developers ratio up.
Hi Bruce,
Thank you so much for your comment. I’d be interested in hearing about how you gain insight into the impact the product owner constraint is having. In my experience, given inadequate detail or information developers tend to try to forge ahead anyway because they are under time constraints or want to be successful. While I can appreciate their perspective, it makes the PO constraint hard to quantify, especially once you forgo the traditional gating mechanisms.