Monthly Archive: August 2018

Why Product Owner needs courage

I had a conversation with Steve Porter from 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).
Did he really trust his Development Team?
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.
Do they work on most valuable backlog item?
Are they still within their estimates of efforts?
Do they solve a problem in a way it should be solved?
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.

Using Cognitive Conceptualization Diagram in Organizational Transformations

What I want to emphasize before digging deeper is the fact that in order to use tools and techniques form psychology, one must first understand oneself and sort oneself out. As Jordan B. Peterson says, set you house in perfect order before criticizing the word. This will probably require a lot of work and will take time, but it is a necessary precondition to successful usage of those tools. Otherwise there is high probability that instead of looking into person’s psychi you will fight your own dragons. So tools I am going to discuss in that post are not some quick fixes. But I hope those tools can help us move forward in complex situations. After all, as Agile coaches we are aiming to change organizational culture and peoples mindsets, so psychology seems to be a good thing to start with.

We know that one of the possible sources of resistance to change is some unconscious reactions. But how we can deal with them? And, to be more precise, how we can make sense on what is the source of that resistance, so that we could address it more specifically?

In this post I want do discuss some of the tools of Cognitive Behavioral Therapy (CBT). Let’s start with some basics of CBT.

The core concept of CBT is a cognitive model. According to that model a person’s reaction (emotional, behavioral and physical) to a given situation is not a product of that situation as is. Rather the reaction is based on some automatic thoughts that a person have in a given situation. 

Let’s consider an example, when Agile coach proposes to use Kanban to visualize and manage workflow, there might be different reactions:

  • Developer A thinks that it would be cool to draw a Kanban and use it to collaborate with others, so he says “Cool! Let’s do this”.
  • Developer B might think that they have already tried to do Kanban, nobody was actually updating Kanban board, and they ended up having a board showing a months-old picture so that they eventually abandoned it, so he says that it will be a waste of time.
  • Developer C might think that everyone will see how little work he is doing, so he becomes defensive and says that he will not do it, cause it’s too much unnecessary work – writing tasks down and moving those cards and etc.

In the latter case, it is not necessary that Developer B is an underperformer – he could possibly be a top performer of the team, but his perception is that he does less than he should do. That is quite a common case that is called “the impostor syndrome”. So we have the same situation, but different reactions.

The extended cognitive model has three additional layers: core beliefs, intermediate beliefs (latter can take form of assumptions, rules or attitudes) and coping strategies. In our example, developer С might have a core belief “I am incompetent”, and have attitude “It’s terrible to look incompetent”. He has assumption “if no one knows what I am doing, no one will know that I am incompetent”. And he might have a rule like “If I will hide my real amount of work, everyone will think that I am smart, If i will disclose real amount of work, everyone will think that I am incompetent”.

It could be the case that one automatic thought or emotional or physical reaction triggers another automatic thought, creating a cascade of cognitive processes and reactions. For our purposes we will use this simplified model.

By understanding a cognitive model, one can analyze person’s cognitions and work towards changing those parts of cognitive model that are dysfunctional. People often unaware of their core and intermediate beliefs, while they might know some of their automatic thought – it depends on situation and a person’s self-awareness. Key point here is that these thoughts are usually taken by a person without any doubts.

In CBT a therapist can help both in conceptualizing that model and help in finding ways to improve that model by changing dysfunctional cognitions to more functional or at least neutral.

An Agile coach might also use that cognitive model to help a person accept changes. In the example above a coach might help developer to discover that he is actually a top performer, and by visualizing his work he could help himself (so as other team members) see his actual impact on team’s performance. But how a coach might learn how a particular person’s cognitive model works? Here comes a Cognitive Conceptualization Diagram (CCD).

As you can see CCD has two parts. Bottom one is about specific situations, automatic thoughts and reactions – we might consider this an outer layer, and top is about deeper layers – previous experiences, core beliefs and intermediate beliefs. We could use this diagram to hypothesize about one’s cognitive model, so that we could plan experiments to test our hypothesis.

First, you observe the situation-reaction patterns and fill in the bottom part. It is a good idea to look for different situations, e.g. interactions with team members in formal meetings, interactions with other colleagues during informal conversations, etc. It is important to make sure that those behavioral patterns are common for that person. By doing this you fill in boxes 1, 2 and 3. You hypothesize on automatic thoughts that can cause such a reaction to a given situation, filling box 4. After gathering at least three situations, you can create hypothesis about meaning of automatic thoughts (box 5). Based on that you may hypothesize what core beliefs (6) could lead to assumptions (7) and coping/compensatory strategies (8) that create such automatic thoughts. During a therapy process, a therapist would probably also look at childhood experiences that could create such assumptions, but as organizational change agents we probably will not dig so deep.

It is important to mention that in order to fill this diagram a coach have to spend some time with that person observing his behavior and looking for some patterns.

Having a (partially) filled CCD, therapist might try to validate the hypotheses it is based upon. He can do it by asking questions, and by observing some behavioral and thought patterns. Here comes a tricky part: In therapy, if he will try to discuss his ideas on core beliefs and intermediate beliefs too fast, when a client is not ready, client might resist and this could potentially destroy therapeutic relationships. As people do not expect any therapy from Agile coach, trying to discuss core beliefs will highly probably destroy coaching relationships. However, Agile coach don’t need to go that deep. He can focus on automatic thoughts and in many cases changing (or even making a person aware of) automatic thoughts is enough to start some changes. We could work deeper (if we have both expertize and client’s willingness to do so) – such interventions are outside of this discussion post.

In case of Developer С this diagram might look like this.


Black text represents overt things and blue – hypotheses.

Now a coach can make predictions and run some behavioral experiments based on this model to assess if these hypotheses are true or false (and update this model based on experiments results).

I will dig deeper onto behavioral experiments in one of my next posts. Here I would like to discuss what should we start with. Firstly, we need to master an unconditional positive regard an unconditional acceptance. Whatever a person thinks – it’s OK. We can disagree with that, but we accept it as it people without judgement. Why it is important? As I already stated in my previous post, if a person will see a signs of disapproval, that mere fact might (and almost surely will) switch him to a defensive mode. This will worsen our relationship, probably cause an aggression and make a person blind to whatever we want to offer.

Secondly, after we accepted person as is we can bring awareness to whatever there are. Such non-judgmental mirroring will raise person’s awareness of his thoughts, and it’s a necessary step towards changing them.

As soon as a person becomes aware of his or her thoughts, we can move to the next step – help him to rationally analyze those thoughts, their probable outcomes (both positive and negative), and helping a person design some behavioral experiments that could test the assumptions about outcomes. This could be done using socrative questioning, or other techniques. I will dig deeper into that in one of my next posts.

In the end of this post, I would like to focus once again on the importance of self-awareness and self-acceptance of a coach. Strait yourself out before trying to change others. And before any king of intervention remember the Hippocrates imperative: primum non nocere.

Firstly, do no harm.