Skip to main content

The Product Owner is a Metaphor Too

I've been having many conversations recently about how to set up the agile teams I'm coaching with the right Product Owner.  As we all know, the PO must be empowered to make decisions, yet must also be knowledgeable enough about what the software should do that she can make constant small decisions for the team so they don't have to wait.  The PO understands the big picture, understands the small picture, and can set priorities.

I blogged a few months back about how the "Team Room" must be considered a metaphor, not a literal prerequisite to trying agile for the first time.  I know I am stepping into equally sacred cow pies here, but I am going throw my weight behind greater thinkers than I who have already posited that the "Product Owner" should be considered as a team, not an individual.  A small village, not a literal person.  Consider these "Product Owner Team" proposals from Mike Cottmeyer, Ben Linders, and Marc Löffler, specifically when considering how to do the Product Owner role at scale.

Product Owner Team enthusiasts posit that if the village can reach consensus and speak with one voice in a timely way on a consistent basis, the whole agile development team will be in fine shape.  The trick is building the right village.

"The Body Politic" from governingtemptation.wordpress.com

I'm currently helping a large vertical in a corporate environment structure the product ownership function for its teams, and it's going to look something like this:
  • 1 Executive Point person where the buck stops (contacted as infrequently as possible)
  • Some large number of SMEs who have details about value and usage of the feature (contacted only as needed by appointment, with a fall-back appointment arranged in case the first one falls through)
  • 1 Business-side "feature point person" per desired feature (readily available but not in the metaphorical team room.)
  • A team of business analysts, user acceptance testers, and business systems analysts who are responsible for knowing which SMEs are needed for each feature, and are able to get those people to the table in a reliable way (part of the core team, always working in the metaphorical team room)
For the software features these teams are building, the "value" of a particular function is generally a corporate legal compliance issue.  The real "Product Owner" who is paying to get the work done has skin in this game only insofar as they need to get a signed approval from an auditor who has made a "finding" against them.   If they don't get this approval, they will face true Profit and Loss consequences.  They are motivated.  Sadly, this person whose neck is on the line for the new feature most likely doesn't ever see the software in use by the people who use it.

On the other hand, the people who do see the software have no funding authority for the team.  In a waterfall world, their only power is to scream loudly for the first time when they first see the software (at UAT or even in production).  They get their way, but in the least convenient way for the business and for the technologists who need to absorb a huge influx of last minute requirements from an unexpected direction, all in the unlovely package of a "production down" situation.

If you will pardon the use of a second major metaphor, this situation is like that of the company that makes chairs for airport seating areas.  The airport will willingly buy chairs that are uncomfortable if they are made of knife-resistant kevlar, if what they're optimizing is wear-and-tear.  The people who actually sit in the chairs don't get the last say.

At any rate, in this enterprise environment, the actual requirements for the software are spread among many corporate divisions and controlled by many different national laws, and the people who do the actual work are spread across many parts of the business.  The person with "final say" is actually an executive at a high enough level to placate others who may be annoyed at what is happening in their operational area in order for this business owner to be in compliance.  Powerful executives are not available to sit in a team room all day long.  They must be consulted sparingly.

The people who know all the details of the various "sunny day" and "cloudy day" scenarios of software use are scattered all over the enterprise, and all over the real world, and they only speak for a piece of the whole software puzzle.  They have day-to-day responsibilities with live clients, and they are certainly not available to sit in the team room, nor do they have the objectivity to make decisions.

The actual decision-making Product Owner, therefore, must be a group of people who together have the right business-side contacts to put together a proposed solution that meets the needs of all stakeholders with the right level of priority for each stakeholder.  That's where we get to the trifecta of business analyst, business systems analyst, and user acceptance tester.  Decisions need to be made by the whole village, so some simultaneous-in-time meetings will need to be set up to get full Product Ownership up and running.  But it is quite likely the whole Product Owner team may never meet simultaneously.  The Product Owner body politic will need to self-govern in a way that will be as efficient as possible for the team, but at least it doesn't need to ask the software developers to guess what to do.

I imagine that this scenario will make some agile purists totally freak out, but I think if we're serious about taking agile to "enterprise scale," we have to be prepared to scale things like the team room and the product owner as well, and we need to be comfortable with that.

Comments

  1. I'm not freaking out at this definition of product ownership for a large convoluted enterprise.
    I'm rather sad.

    I'm sad about the fact that the work which could have been potentially done by bringing in key stakeholders "together" for a limited period of time will now take weeks (if not months) to visualize, comprehend and deliver (however many iterations and showcases you care for). The question that springs to the mind "is that being effective or being efficient?"

    The arrangement of organizations into functional silos seems anachronistic. This is the age of cross functional teams and polyglot skill set. This is the age of collective wisdom over individual brilliance. May be an organizational transformation of the corporate environment is overdue.

    ReplyDelete
  2. Thanks, arcane. I agree. I think there are companies that purposely organize themselves into self-governing units of 200 people or less (the company that makes Gore-Tex, for example). It would be cool to see a very large company do that.

    ReplyDelete

Post a Comment

Popular posts from this blog

How Do You Vote Someone Off of Your Agile Team?

One of the conundrums of agile conversion is that although you are ordered by management to "self-organize," you don't get to pick your own team.  You may not have pictured it this way, but your agile team members are going to be the same people you worked with before, when you were all doing waterfall!   I know I wasn't picturing it that way for my first agile team, so I thought I should warn you.  (I thought I was going to get between six and eight original Agile Manifesto signers.  That didn't happen.). Why "warn" you (as opposed to "reassure" you, say)?  Because the agile process is going to reveal every wart, mole, quirk, goiter, and flatulence issue on the team within a few hours.  In the old days, you could all be eccentric or even unpleasant in your own cube, communicating only by document, wiki, email, and, in extreme situations, by phone.  Now you are suddenly forced to interact in real time, perhaps in person, with written messag

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else. From http://www.yogawithjohn.com/tag/yoga-class/ Here's what you should think about: 1.        Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that: a.        You need your user experience people (if a

Your Agile Transformation Needs to Start with a Quiet Phase

From a really great blog post on agile adoption:  http://smoovejazz.wordpress.com/2011/02/16/an-agile-approach-for-adopting-agile-practices/ I've observed some different agile transformation patterns, and maybe you have too: Just Do Standups   (Shoot, then Aim):   some people feel that since you're "agile," you should just start doing stuff, like daily standups, and then build more of the the plan as you go.  Find a team and start doing some agile with them!  Start a revolution one practice at a time, one team at a time. Pros:   you're very busy from the start. Cons:   what exactly are you doing and why? KPI-Driven Change (Aim, then Shoot) : some people who have worked in large corporations for a while will tell you that to get the respect of the people, you need to start with a plan, support the plan with awesome printed and online collateral.  Then you "kick off," tell teams what to do, and measure them using "Key Productivity Indica