Is Dr. Seuss Your Product Owner?
Theodor Seuss Geisel was an amazing author. He has been credited with some of the most heartwarming, imaginative, and forward thinking children’s work in the last 100 years as well as being an inspiration to some of the most interesting Product Owners that I have had the opportunity to work with! Yes, that’s right – Seussian Product Owners. Let’s take a look at a few.
The “Red Fish, Blue Fish” Product Owner. This product owner can be credited with either providing conflicting or unclear acceptance criteria, OR so much information that the user story is inestimable. For example, and I quote the good Doctor:
One fish
Two fish
Red fish
Blue fish.
Black fish
Blue fish
Old fish
New fish.
This one has a little star.
This one has a little car.
Say! What a lot
Of fish there are.
And we also have the “Oh the Thinks You Can Think” Product Owner. Where the Red Fish, Blue Fish Product Owner’s Achilles heel is acceptance criteria, the O.T.T.Y.C.T. (Oh the Thinks You Can Think) Product suffers from the dreaded “I’ll never have the teams attention again, so we must ask for everything and the kitchen sink” syndrome. This Product Owner could have the backlog populated with everything from Gufs to Schlopps; expecting all of it to be released in a single release or sprint!
My favorite Product Owner has to be the “Green Eggs and Ham” Product Owner. Not just because this book was my first Dr. Seuss, but because they know what they are trying to gain in value; they just have a hard time explaining it even after seeing what they do not want. A typical conversation between the team and this Product Owner might go like this:
Team:
Would you like them in a house?
Would you like them with a mouse?
Product Owner:
I do not like them in a house.
I do not like them with a mouse.
I do not like them here or there.
I do not like them anywhere.
I do not like green eggs and ham.
I do not like them, Sam-I-Am.
Of course, this was a tongue and cheek look at many of the challenges of both implementing agility, but also at complexities of being an effective Product Owner. What can we do, then, to become better? I’m glad you asked!
Fully Engaged Backlog Refinement
While Backlog Refinement isn’t considered an event or ceremony in Agile, continuously refining and improving the list of backlog items, but more importantly the content of the backlog items is one of the most important actions we can take. As a full team, ask yourselves:
Is our backlog refinement always the Product Owner reading the story and the team yelling out an estimate or is it a two-way conversation in which more and more detail around what is expected and what can be done is identified to meet business need?
Are we sometimes prototyping or doing team research to find the best solution to a story?
Has backlog refinement become just another meeting or is it a cultural way of working that finds high-value solutions?
A refined backlog item should be clear and create the correct conversation, driving the solution toward the most valuable implementation.
Negotiation between the Team and Product Owner
One of the challenges of transitioning organizations (especially staunchly hierarchical ones) to Agile is teaching teams and leadership that negotiation is not just accepted, but required! Recently, I played a game with an emerging Agile team that I like to call “Team Speed Uno.” One of the lessons learned in this game is that to achieve the most efficient and ultimate goal of getting rid of both teams’ cards, both teams must negotiate with the facilitator, or acting Product Owner, their cards in and out of the deck. It was amazing to see their eyes light up when it clicked that they - along with the Product Owner - are in this together; trying to achieve the same goal, and that they have a say in delivered work!
This is where leadership and, in the case of many of the teams I have worked with, the Scrum Master encourages negotiation as a positive technique to improve the user stories, the backlog and even the viability of the product.
Minimum Viable Products
In some of our more traditional methodologies, a final ‘big-ole’ product was the end state of the project. Everyone worked for year(s) to provide a single releasable behemoth. Changes after the fact were not accepted, or were discouraged to the point where it created a behavioral paradigm in which “it had to be perfect the first time.” Agreeing to a minimum viable product (MVP) can be a conversation that helps accelerate the trust factor. The conversation should center on the value that the initial release of software can provide along with the fact that feedback from the customers/stakeholders can help drive the overall success of the product up. Using negotiation and full engagement refinement as tools can improve the MVP solution as well as the successive releases and features.
The concept of an MVP also allows for greater value – that of product adoption/acceptance – be identified which can bolster the continued development effort!
So, as we bring this to a close, if your Product Owner reminds you of a Dr. Seuss book, don’t fret! Just remember that we are all in this together trying to constantly improve. And stay tuned next time where I compare Agile Coaching to Edgar Allen Poe stories...Just kidding!