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 treading on equally sacred ground (stepping into equally sacred cow pies), but I am going to posit along the same lines that in a complex corporate environment, the "Product Owner" should be considered as a small village, not a literal person. (I hear the sounds of distant drums, or maybe bagpipes, preparing for war). I believe 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.