When to solve or save.

I recently had the pleasure of discussing Product Ownership with Bob Galen on a recent episode of Deliver It Cast.  Part of that discussion was the next level for Product Ownership to get to; the bottom line is that there really isn’t one. A lot of PO’s are still struggling with the basics and still need help and to focus there.

After I read Lyssa Atkins great book “Coaching Agile Teams“, one of the areas I now think should be an additive skill for PO’s is to help the team to get better.  That doesn’t mean a PO should morph into a coach per se, once they nail the basics and look for improvements, I think helping the team is likely the best place. In thinking about how to help them learn, Lyssa really emphasises having the team learn themselves, experiment, and have the PO/SM/Managers support them.

My usual reaction to things is to give an answer, or idea and work with the team to make it so.  Now I’m thinking of different times that I should not jump in and let the team handle it. In doing so, having a plan for when to intervene or not would be needed.

So lets assume you are a good PO with a good team, you are nailing the basics and looking to improve.

With that I can think of these 3 different outcomes:

  1. Paper cut:
    1. These are small items that the team can learn and recover quickly from.  They will sting a bit and be remembered in the sprint but may fade after time.  Enough of these and the team will learn they don’t like them.
    2. Don’t jump in here. Even if you see if coming, let it happen, help them recover, and support them when they come up with ideas and actions to prevent it from happening again.
  2. Broken leg:
    1. These are impactful issues that really stop the team. This one will hurt and  hinder them for a while.  The impact is big and they might need some time to recover, refactor, replan, or change something major with the team or product to get back working.
    2. I would feel really bad if I saw the team headed for something like this. I would want them to learn still and maybe head off the severity, but not the impact. If I could find ways to subtly suggest or show what would happen, I would do that. Otherwise, buy some get well soon ballons and a bear.
  3. 100 ft cliff:
    1. This is something the team likely would not recover from, if they survived it at all.  These things are bigger than just the team and the affect is felt in the largest possible sense. Heads might roll ( including yours ) and the blamestorming might become a Cat5.
    2. I would jump in here.  I would take 2 or 3 attempts at making sure the team understood the issue, consquences, and impact. As a last ditch effort I would create stories and acceptence criteria that greatly reduce the chance for a bad outcome. It might still happen but I will have done what I could as a PO to avoid it.

So that last one might be harsh, I thought about getting hit by a bus instead becuase I love that phrase.  Point being there is a level at which I would give an answer or idea to the team but I’d like it to be pushed back further than where it is now.

The more the team can learn and do for themselves, the better they will become.  Stepping up to help them as they learn I think is a great next area for Product Owners to reach for.




I like to create things, work with interesting people, and do all things agile. I have a testing background and really want to make great products that solve problems.

Posted in Uncategorized

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: