Teaching Product Owners How To Fish
Product owners are responsible for defining WHAT the Agile team needs to create. The team is responsible for deciding HOW to build WHAT the product owner needs.
I don't think any Agilist would fundamentally disagree with that statement. Where there is inevitably a great deal of discussion and disagreement is describing the boundary between "WHAT" and "HOW." Is it thin or thick? How much overlap is there? Does this depend on the nature of the work or is there a fixed standard? Does it have to be determined for every story? These are often not easy questions to answer.
While reading some neuroscience material yesterday regarding how our brains construct "concepts," the topic lead into the notion of "goal-based concepts." Since I'm not a neuroscientist but an Agilist looking for ways neuroscience can be applied to the implementation of Agile principles and practices, the material had me thinking about how product owners might learn from the idea of "goal-based concepts." How can I teach them about the "WHAT" such that they better understand the type and amount of detail the team needs in order to figure out the "HOW?"
I came up with a series of short dialogs:
Product Owner (to team): I need a fish.
Team: OK.
(Team goes off to work on "fish" and returns the next day with a catfish.)
PO: That's not what I wanted! I need a fish!
(Team goes off to work on "fish" and returns the next day with a nurse shark.)
PO: That's not what I wanted either!
What if the PO had been more clear about not just WHAT she wanted, but the goal for that WHAT. That is, a description of the problem that the WHAT was intended to solve.
PO: I'm opening a fish store. I need a fish.
(Team goes off to work on "fish for fish store" and returns the next day with a goldfish.)
PO: That's good. But it's not enough. I need more fish. Different kinds of fish.
(The team goes off to work on "variety of fish for fish store" and returns the next day with guppies, mollies, swordtails, and angelfish.)
PO: Cool!
Or version two:
PO: I'm opening a restaurant. I need a fish.
(Team goes off to work on "fish for restaurant" and returns the next day with Poached Salmon in Dill Sauce.)
PO: That's good. But it's not enough. I need more fish. Different kinds of fish.
(The team goes off to work on "variety of fish for restaurant" and returns the next day with Miso-Glazed Chilean Sea Bass, Mediterranean Stuffed Swordfish, and Pan Seared Lemon Tilapia.)
PO: Yum!
Providing a little of the "WHY" for the "WHAT" has helped the team do a better job of delivering WHAT the product owner wanted.
Of course, these are simplified examples. There are many additional details the product owner could have supplied that would have helped the team dial in on exactly WHAT she needed. In the first dialog, the team had to make guesses about what the product owner meant by the rather broad concept of "fish." This unending loop is an expensive game of whack-a-mole. Except with fish. In the subsequent dialogs, the team at least had the benefit of the context that was of interest to the product owner. In these cases, the team had a better understanding of the goal the product owner had in mind.
In Agile-speak, this context or goal information would be provided in the "As a..." and "...so that..." part of the story. "As a restaurant owner I want fish so that patrons can enjoy a variety of menu options."
The less clear the product owner is on these elements, the longer it's going to take for the team to guess what she really wants.
Photo by Ben Wilkins on Unsplash