Why Product Owner needs courage

I had a conversation with Steve Porter from scrum.org on dysfunctional interactions between Product Owner and Development Team in Scrum. This discussion reminded me of an idea that I learned from Jordan B. Peterson that real trust is an act of courage. In this post I am trying to unfold this idea applied to Scrum team.

A newly trained Product Owner usually is inspired by ideas of self-organization believes that a Scrum is a best way to solve complex problems, and that self-organizing Development Team is a best way to do right things right (and fast). He acts as Agile evangelist, working to promote Agile as much as he can. Based on this beliefs and inspiration he trusts Development Team to do what is needed to deliver Sprint Backlog and reach Sprint Goal. You probably have seen such a person. Many will say that having such an inspired Product Owner is critical for Scrum success.

What inevitably happens next? Development team fails. Sooner or later it happens to each and every development team (even if they are extremely undercommiting and overperforming 🙂 So this failure raises some questions for Product Owner. Why did they fail? Did I trusted them enough? Or maybe I trusted too much? Why are they destroying my trust? There is a good chance that Product Owner had some commitments regarding product, and his stakeholders are truly unhappy. Product owner feels bitter (and maybe resentment).

If that trust was based on naive view that a team will be able to do anything if trusted, can we consider that a trust. Or it’s just a naivety? Trust is a necessary precondition for a team to reach peak performance and engagement, but it does not guarantee success. We are living in a complex world, and working to deliver value solving complex problems. There is always something we don’t know. There is always a change. There is always something missing. And this mean that sometimes we inevitably fail.

Next step for Product Owner is to think of what to do next. He might think “How can I prevent this from happening again”? He wants bad news early, so that he could get prepared (and prepare his stakeholders). He might decide to check Development Team regularly on how are they doing and if they are doing what he expects them to do.

This creates micromanagement habit, and eventually such checks become a daily (or hourly) status meeting.

What will happen to Development Team? First, such questions, even if they look innocent from Product Owner perspective, probably perceived by Development Team not as questions, but as requests. Product Owner’s role is associated with power and authority, and people have tendency to listen to everything said by empowered figure as if it is a demand, not a question. Next, Development Team will feel that they are not trusted, and this feeling will result in more and more disengaged team. Moreover, team loses it’s ability to self-organize: developers stop making their own decisions because Product Owner will decide anyway. In such a way, Product Owner becomes a bottleneck. And while he takes more and more decisions, team has less power, so he sees that he has to decide more. Less trust leads to fewer decisions that leads to worse decisions, which leads to less trust. And so it goes.

Some Product Owner will stay stuck on that level. “They can’t be trusted – they are too immature” view is wrong! They cannot mature because they don’t have opportunity to fail and learn. It is not the team. A Product Owner is the one who is immature.

What is an antidote for that? The answer is courage. It is one of five Scrum values, and I would say that it’s perhaps the most important one. If Product Owner has courage, he might think something like “OK. If I will trust them to do the work on their own, they will sometimes fail. This will be painful for me (and probably for Development Team also). But we need trust to move faster, to deliver more value, to deliver best possible solutions”. So he decides to be courageous enough to trust Development Team knowing that they will sometimes fail.

This is what a real trust is. It is a trust that is based on wisdom, not just some naive expectation that people succeed if trusted. Yes, if I will trust them, there is a risk. But I am taking this risk as necessary precondition for success. This is  a courage that a Product Owner should cultivate. And one of the key things that Scrum Master could do to server a Scrum Team – help everyone in a team to nurture enough courage for such kind of trust. Feeling vulnerable, but having enough courage to trust each other. This is a trust that makes Scrum so effective in dealing with complexity and allows Scrum Teams to thrive.