1. Home
2. Blog
3. Why a Product Owner needs courage

I had a conversation with Steve Porter from scrum.org on dysfunctional interactions between the Product Owner and the 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 take this idea and apply it to a Scrum team.

 

A newly trained Product Owner is usually inspired by ideas of self-organization and believes that Scrum is the best way to solve complex problems, and that a self-organizing Development Team is the best way to do the right things right (and fast). He acts as an Agile evangelist, working to promote Agile as much as he can. Based on these beliefs and inspiration he trusts the Development Team to do what is needed to deliver the Sprint Backlog and reach the 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? The development team fails. Sooner or later it happens to each and every development team - even if they are extremely undercommiting and over performing :). So this failure raises some questions for the Product Owner. Why did they fail? Did I trust them enough? Or maybe I trusted them too much? Why are they destroying my trust? There is a good chance that the Product Owner had some commitments regarding product, and his stakeholders are truly unhappy. Now the Product owner feels bitter (and maybe resentful).

 

 

Did he really trust his Development Team?

 

If that trust was based on the naive view that a team will be able to do anything if it is trusted, can we consider that a trust. Or it’s just 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 means that sometimes we inevitably fail.

 

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

 

1. Are they working on the most valuable backlog item?
2. Are they still within their estimates of efforts?
3. Are they solving the problem in the way it should be solved?

 

This creates a micromanagement habit, and eventually such checks turn into daily (or hourly) status meetings.

 

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

 

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

 

What is an antidote for that? The answer is courage. It is one of the five Scrum values, and I would say that it’s perhaps the most important one. If the 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 the Development Team also). But we need trust to move faster, to deliver more value, to deliver the best possible solutions”. So he decides to be courageous enough to trust the 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 a 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 serve a Scrum Team — help everyone in the team to nurture enough courage for such kind of trust. Feeling vulnerable, but having enough courage to trust each other. This is the trust that makes Scrum so effective in dealing with complexity and allows Scrum Teams to thrive.