Monday, August 20, 2018

Product Owners deserve Healthy Ownership.

Spending quality time with Alex Sloley
I have been working as a scrum master for the last five years.  What I have discovered over that period of my practice as a coach and scrum master is that product ownership is the weak leg of the triad of Scrum roles.  We spend plenty of time making scrum masters and developers better, but we still struggle with the purpose of the product owner.  I suspect this is because as a former technical professionals scrum masters and developers speak a similar language.  Product ownership is different in experience and expectations.  It is why it is the weak leg because it is so radically different to slinging code.  It is why I want to talk about “healthy ownership” on my blog this week. 

The notion of “Healthy Ownership,” was constructed when I attended the Agile Coaches Retreat in London this summer.  I had just finished a contentious sprint planning session before getting on a plane to England where a product owner questioned the estimates of the development team.  It was a gross breach of the social compact of agile.  The product owner protested, “They did something similar last sprint, I thought they would be faster this sprint.” Typically, I do not want to drink bourbon at the office, but at that moment I was sorely tested. 

I brought this and other examples of bad behavior to the other coaches.  I pleaded with them for help. Others had similar challenges and solutions.  The truth was they did, but no one had come up with coaching techniques that would help them rectify the situation.  Like any other self-organizing group of individuals, we came up with a team to address this situation.  We had numerous people with different perspectives from former developers to project management professionals who were attempting to instill professional practices in their organizations. 

We had three goals: 1) open dialog between team members, 2) increased empathy between team members, and 3) collective ownership of outcomes.  It was not going to be easy.  We did discover that we could combine coaching techniques to gather information and come up with scenarios for common pain points.  From there we could collect data and try to inform and persuade others on how to approach situations.  It is not a script or prescriptive but more like a way to practice common coaching techniques with common problems on agile teams.  It is not perfect, and we are still forming approaches, but for the rookie coach or scrum master, it acts as a safety net.

Flash forward to the Agile 2018 conference, and I heard other people discuss their challenges in getting buy-in from product owners and developers.  It is why I am grateful for Alex Sloley and his discussion about transplanting the brains of product owners and scrum masters.  By shifting the roles of a scrum master and product owner, we get to “walk a mile in someone else’s moccasins.”  The product owner understands the challenges of the scrum master and developers while at the same time the developers and scrum master understand the challenges of the product owner.  It was a nice juxtaposition, and I will use the term “backlog coaching” in my practice for the rest of my career. 

So to me, “healthy ownership,” means putting yourself in another person’s situation and understanding the unique challenges they face.  It means that it may be necessary to do a “brain transplant” or less drastic measures for people to understand what is going on in the development process.  Product ownership is the weak leg of a scrum team, but it is because coaches and scrum masters do not pay enough attention to the role and how to make it better.  It is why I am going to be spending more time with my product owners and walking a few miles in their moccasins.  With a little luck, I will reduce the stress on my development teams and improve the performance of my product owners.

Until next time.

1 comment:

  1. I've only gotten a true product owner once or twice in my career. They're as common as unicorns.

    However, Any time I've had situations where estimates were challenged by someone who doesn't have enough expertise in the area, I try to make a comparison. For example, I would never go to a plumber and say, "It is just a tube from the sink outside. How hard can it be? You did it last time." Sure they did it last time, but maybe the house wasn't completed last time? Does it being on the second story matter? Well maybe they have to tie in some place different? I don't know! That's not my area of expertise.

    I'm not saying don't explain why one estimate is different than another, but being able to relate is what is important.

    ReplyDelete