Engaging the reluctant Product Owner

Product Owners are what drives a team.  They are the motivation and the catalyst behind any successful agile team.  For many struggling agile teams the biggest bang for the buck in improvement is an engaged product owner.  But how do you take a reluctant, absent product expert and convert them into a successful product owner?  You train them.  And how do you motivate these Product Owners In Training to engage?  You make it worth their while.


Product Owners, like all people, only repeat behavior that works for them.  Therefore, our job as agile team members and scrum masters is to provide that value to keep the PO coming back for more.  We provide that value through early and repetitive visibiltiy into what we are building, and the ability to easily change course when what we are building does not match their ever growing insight into what should be built.

A core requirement of a good product owner is to have the industry domain experience and the ability to fashion a vision of solving buisness needs within that domain.  However, PO's cannot be expected to nail this vision right out of the box; they need input to help aid with constant course correction to make that initial vision into a usable solution.  Think of the old artillery capabilities where an initial shot was fired, response was fed back to the artillery captain regarding adjustments, another shot was fired, and the process repeated until they were on target.  Modern systems rely on specific coordinates and GPS aids to directly target the first time, but PO's don't have a built in SatNav receiver.  They need this fire and learn feedback to adjust their vision.  Providing this feedback, and teaching them how to use it, is part of the value return for a PO.

And this feedback comes from working software.  We couldn't with honest confidence tell the artillery captain before the shot is fired "Your shot will land right at these coordinates, so you need to adjust accordingly".  In the same mode we cannot provide the needed feedback on product direction without those early shots given in the form of product demo's.  Invest in making those demo sessions provide that needed insight, and with a little encouragement your product owner will become an eager fan and no longer find reasons to skip your demo's.  Continue this process throughout the sprint and you are well on the way to building your own super PO.

Inspect and Adapt

Think about one of our most useful inventions of all time; the wheel.  Do you think that first caveman sat down and thought through all of the facets of building a wheel, and got it right the first time?  No, he most likely had a need, and set about to fill that need through trial and error.  His first attempt was almost certainly very crude and didn’t work well, but he kept iterating through it until he had something that worked.  If he had sat down and scratched out his design in the sand and said “Ugg, that’s what I need” and built exactly that, we would still be using our feet to get around.  Instead, he started building with what he knew at the time, and used that knowledge to improve the next version, and the next, until he had something that worked.

In the same way, we need to be willing to start with what we know, and understand that we will learn along the way.  Hanging on to the need to understand exactly what will happen in the future just doesn’t work.  Customers change their mind, product owners learn more and adapt (at least, the good ones do), and designs need to change along with them.  Also, if we really could just write TDD”s and know that’s what we want, why have developers?  We could just plug our designs into code generators and push a button. 

As developers of software, we need to be able to do a little work, inspect that work, learn from it, and then do a little more.  That’s how our friend the caveman did it.

‘Estimating Session’ is a misnomer

I think the agile community might do itself a favor by renaming these to ‘Understanding Sessions’.

People new to Agile, especially coming from the waterfall/traditional PM role, struggle with the concept of agile estimation sessions.  How can slotting stories into piles of like size be of any benefit?  I need real numbers, not these Fibonacci things!  And then, inevitably, comes the dreaded question; “how many hours is a 5 point story?”.

Let’s think about the advantages of an estimation session.  Sure, we get story points associated to a story, which helps with release and sprint planning, but what’s the real benefit?  Think about how you get to a consensus on a story estimation, it requires discussion on the story sufficient to gain a group understanding, it requires compromise on what the story scope is (which helps further define the story), and it requires all aspects of the completion of the story to be involved (dev, BA’s, QA, deployment, etc).  A successful estimation session ends with the participants gaining further understanding of what is needed.

However, estimation sessions are not planning sessions, and this is where a lot of PM/Waterfall folks get frustrated.  Do we know exactly how we are going to implement this?  Do we have a detailed task list that needs completing?  Do we even have a clear picture yet on how we are going to test this?  No to all.  What we do have is an early agreement on our short term direction based on a ‘slotting’ of these stories into like piles.  It also presents an opportunity for a new team to start to gel around the work they are about to undertake.

I know there are many in the agile community that are starting to question the need for estimations as agile practices continue to mature.  I think they still have an invaluable place as Understanding Sessions, and will remain on my list of preferred practices for the foreseeable future.