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.
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:
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.
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)
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.
I'm not freaking out at this definition of product ownership for a large convoluted enterprise.
ReplyDeleteI'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.
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