Archive | Ladder of Inference RSS for this section

Conversations for double-loop mindset changes with Kanban

You can watch the video of my talkfrom the Lean Software Systems Consortium (LSSC12) conference in Boston earlier this month.

Me presenting on using the Ladder of Inference to produce Double Loop Learning conversations

Using the Ladder of Inference to produce Double Loop Learning conversations

Visualising work is a key part of the Kanban Method. In many situations it can lead to people realising there are problems or opportunities for improvement, which can be successfully accomplished by simply changing behaviour (single loop learning). However, in some situations, particularly where there could embarrassment or threat, these change may need challenging existing mindsets (called double loop learning). Using practical examples drawn from directly helping teams, this talk will present a model for understanding how we can proactively engage in conversations that increase the chances of capitalising on the value that visualising the work provides.

Here’s a review from Jack Vinson

Benjamin Mitchell used the topic of “what comes after visualization” to start a conversation of what to do once you’ve got some visualization.  He particularly talked about Chris Argyris‘  Ladder of Inference (and expanded by Peter Senge), which he used as a way of thinking about how we see things and how we interact with our colleagues and coaching / consulting clients.  He particularly warned about staying away from making assumptions and working at the levels of Select and Describe (rather than Explain, Evaluate, Propose Actions).  Since Argyris is one of the promoters of double-loop learning, it is not surprising that Benjamin discussed the Mindset -> Actions -> Results learning loop.  I liked the discussion of taking different actions to get results vs changing one’s mindset because the Actions aren’t getting anywhere like where they need to go.

Here were some reactions from Twitter:

Let me know your reaction in the comments.

The Art of Handling Elephants in the Room

When we spot and elephant in the room, or an undiscussable topic that isn’t being addressed, it is tempting to tackle it head on.  However, just naming the elephant or telling people that they’re not discussing an undiscussable topic  is rarely a productive approach.

Afterwards Tom and Eric weren't exactly sure at which point during their discussion the elephant had entered the room

Having spotted an elephant in the
room it is tempting to shout about it

Here’s a scenario from a team’s retrospective meeting:

The team had talked about a problem and had decided to hold a workshop to focus on that issue. Kelly, the external consultant, saw a problem that no one was mentioning.

“I think there’s an elephant in the room here!” declared Kelly


“Yes, there’s a proposal to have a workshop, but no one has mentioned that last time we ran a workshop no one turned up! This seems like an undiscussable topic!” said Kelly

There was general agreement that people hadn’t shown up for the last workshop. After some discussion the team decided “let’s not have a workshop then” and the meeting ended.

I think Kelly’s intention was honourable – how can I get the group to start discussing things to better understand the cause of problems and ways to avoid them in future.

However, in this scenario, Kelly didn’t get what she wanted – rather than get to the cause of their problems in the past, they just decided to bypass these issues and cancel the workshop.

Unfortunately I think Kelly’s behaviour may have contributed to the results she got including the unintended consequences, such as possibly reducing the chance that the team would feel comfortable talking about ‘undiscussable’ topics in future.

Problems with the approach

There are several possible problems I see with Kelly’s approach.

Unclear intent. Kelly raises the issue of the groups not mentioning that no-one attended the previous workshop, but she doesn’t state what her intention for mentioning it was. If you are not explicit about your intention for saying something then people will automatically invent their own reason, which may not have been what you wanted.

Negative assumptions about others’ motives without providing evidence. When Kelly makes the claim that there’s an “elephant in the room” it could be interpreted as her saying that the group were all aware that no one turned up to the previous workshop and that they were all deliberately not mentioning it.

Kelly doesn’t provide any evidence that others are all aware of the issue, or that they have made a deliberate decision to avoid discussing the issue.  Kelly’s claim is high on the ladder of inference.

Making an assumption about someone else’s motive, such as thinking “this group is deliberately not talking about a problem they know to exist” is an example of an attribution. Making negative attributions like this without providing evidence can mean that people feel confused or unjustly accused. Once people feel accused then it increases the chance they will respond defensively or withdraw from the conversation.

No curiosity about how others see the situation. Kelly states her view to the group but doesn’t ask whether they see things the same way or see it differently. I’d assume that Kelly was acting as if her view was obvious to others. Since Kelly asked no questions about how others see the situation and expressed her view in a definite way, it reduces the chance that others will offer their view or that Kelly would find out if others saw the situation differently.

Changing the focus from conversation’s content to it’s style is challenging. Moving from talking about the topic of a conversation (“we should have a workshop”) to talking about the style of the conversation (“we’re not discussing the undiscussable”) is a high-impact change of direction.  “Going meta” like this is often worthwhile but takes skill, time and energy. To justify the investment it is better to wait until you have solid evidence of a pattern of this type of behaviour. If it’s just a single instance it more effective to keep talking about the content (“how can we make sure people turn up to this next workshop?”) rather than the communication pattern (“we’re not discussing the undiscussable”)

A more effective approach

A more effective approach may have been as follows, with annotations in brackets on what I’m trying to model:

I’d like to check a concern I have about how we are discussing the plan to hold a workshop [share your intent] and see what other’s views are. My recollection was that the last time we planned a workshop no one showed up. I was speaking to Bob and Jane about this yesterday [share your evidence].  Do you remember the last workshop the same way or differently? [be curious about others’ views]

If there was agreement around the fact no-one showed up to the last workshop I’d continue:

This is making me wonder if we are avoiding talking about what happened around the last workshop [state your reasoning]. I would like to talk briefly about what happened so we can avoid the same problems happening with this workshop [state your intent]. In terms of the last workshop, would anyone be willing to share what caused them not to attend? [inquire into others views]

Let me know your view in the comments.

Benjamin Mitchell's Twitter ProfileHi, I’m Benjamin. I hope that you enjoyed the post. I’m a consultant and coach who helps IT teams and their managers consistently deliver the right software solutions. You can find out more about me and my services. Contact me for a conversation about your situation.

Image Credit: David Blackwell on Flickr

Good question: how to unblock stuck conversations

When discussions become stuck in a ‘death-spiral’ of point-counterpoint views it’s useful to have some techniques to unblock the discussion. One great technique is to shift the focus from telling people about your views and start asking questions to understand theirs.

Arm Wrestling

I was in a bid planning meeting at a large consultancy when the discussion started to enter a conversational death spiral. Manager A believed that there should be a project manager involved in the project whilst Manager B disagreed. The conversation shifted from a discussion to a disagreement – the difference in views hooked the participants into a verbal arm wrestle over who was right.

I realised that neither manager was asking any questions of the other. It was all “let me tell you again why I’m right”.

It was as if each person thought the other person was just failing to see what was obvious to them, so each was using an ineffective strategy of repeating their view again this time stronger and louder.

I fought back my impulse to ‘take sides’ and focus on what one side was missing. Instead I decided to ask a question to move the conversation forward:

Me: “[To Manager A] If we agreed to go with the idea of a project manager, could you say what that would look like to you? How much budget do you think would be needed?”

Manager A: “I think we’d need to use 5% of the budget”

Me: “[To Manager B] How does that sound to you? What issues would you see if 5% of the budget was used?”

Manager B: “I’d assumed it was more than that. If that’s all it would take then that works for me”

One well-placed question changed the nature of the discussion. The reduction in tension in the room was obvious.

My question was designed to take the other person “down their ladder [of inference]” and produce more specific observable data. By doing so it uncovered some assumptions about what exactly was involved.

Have you found switching from backing one side to asking questions about the other side’s ideas has helped unblock conversations? Share your views in the comments.

Benjamin Mitchell's Twitter ProfileHi, I’m Benjamin. I hope that you enjoyed the post. I’m a consultant and coach who helps IT teams and their managers consistently deliver the right software solutions. You can find out more about me and my services. Contact me for a conversation about your situation.

Image Credit: newneonunion on flickr

Ineffective pushback to a pushy manager?

How do you deal with a manager who believes that a software development team needs to go faster and should be pushed? I want to review some of the responses to my earlier blog and test the idea that they would create a productive conversation that would lead to effective outcomes.

Just an ordinary reflection
How does our advice look if others reflect it back to us?

What were the responses?

I got responses from the the earlier post’s comments, twitter and the DZone Agile centre that were mostly from the team’s perspective.

I believe that the responses were intended to be helpful to someone in the manager’s position and raise some important issues. I’ve seen the results of teams accepting a request to “push harder” and in the majority of cases these have been ineffective, demoralising and created more problems down the track. My intent with the earlier post was to encourage a manager with these views to find a way to discuss differences in views in public in order to jointly design productive ways forward.

When handling issues that generate strong points of view it’s important to focus on not just ‘what is right’ but ‘how can I communicate this effectively?’

I’ve summarised some of the responses under headings from the three assumption level ‘rungs’ of the ladder of inference


  • Thinking that pushing a team to go faster is a dysfunctional view and implies little intention to help
  • The causes of poor performance are a management issue
  • It’s probably not a speed of development issue, usually it’s about prioritisation and communications


  • There are too many assumptions in the question “how can I push the team to go faster?”
  • Just going faster is the wrong goal
  • Going faster or pushing wont help you reach your goal

Predictions / Proposals for Action

  • Pushing has never worked and will never work
  • Talk about it differently – say “pulling or enabling” to remind you that it’s about you helping remove impediments
  • Focus on removing obstacles not “pushing people”
  • The first step is for you to ask the team what you as a manager can change or what you can do to help.
  • Ask yourself “is it a pattern that I keep having to push teams to go faster?” If lots of projects require a push then it’s not the team that’s the problem, it’s your planning!

Unjust high-level negative assumptions?

Looking at the comments from a manager’s point of view, they come across as high-level assumptions that are often negative towards the manager.

My assumption is that the responses were in reaction to the perceived unjust negative evaluation implied by a manager even considering “how could I push a team to go faster?” (the headline of the earlier post).

This highlights the importance of a manager with these views clarifying what’s behind them, and sharing them with specific concrete examples, to avoid creating defensiveness in the responses and becoming stuck in a point-counter-point argument.

It intrigues me that some of the responses may have created the same impact for a manager that they felt manager’s views had on them.

What would a manager think if told these views?

I realise that many of the responses were not intended to be directly said to the manager, but if they were I believe it would create defensiveness in the manager.

I doubt that the manager would feel listened to or understood.

The views were mainly stated in strong, rather than tentative terms. There was no mention of asking for more detailed observable data from the manager or any inquiries into what was behind the manager’s view.

How would people would avoid these negative views “leaking out” into the conversation through body language or tone of voice? As a manager (share your views in the comments) I could imagine thinking:

“These responses show people reacting defensively before they’ve listened or understood my view. They are telling me I’m wrong to think this way and I should start by asking how I could be different. It just shows that you can’t talk to a team about these issues”

Skilled unawareness and skilled incompetence?

Some comments advised the manager to take the team’s perspective and ask the team what they might be unintentionally doing to hinder the team and how they as a manager could help. This is useful as other people have a great ability to spot gaps or inconsistencies in our behaviour. Learning how to honestly ask for help from others is a worthwhile practice.

Yet, there was limited evidence in the responses of following that advice and thinking things through from the manager’s perspective and asking how they might be unintentionally contributing or how they could help.

This is an example where people, acting with good intentions, may be skilfully unaware of the fact they’re not following their own advice to others. This relates to the skilled incompetence demonstrated at a recent Agile workshop

I’d welcome your views in the comments. How productive do you think the responses would be if communicated to a manager? If you wanted to respond more productively to a manager who thought it was necessary to push the team what would you say or do?

Benjamin Mitchell's Twitter ProfileHi, I’m Benjamin. I hope that you enjoyed the post. I’m a consultant and coach who helps IT teams and their managers consistently deliver the right software solutions. You can find out more about me and my services. Contact me for a conversation about your situation.

Image Credit: Steve-h on flickr

Naming names: helping Agile teams effectively deal with discussing individuals’ behaviour

I’ve seen a common issue where people in Agile teams are afraid to mention the behaviour of specific individuals. There’s often a fear that speaking about individuals’ behaviour will result in conflict, but indirect strategies are often self-protective and avoid dealing with the issue in a way that allows everyone to learn. By reframing the issue and learning ways of speaking about the behaviour and views of those on the team it is possible to reduce the tension, help the team learn and create more effective team interactions.

guess who

Sally was the manager of a software development team that were under pressure after a release produced high-profile customer bugs. Tensions between individuals, which in happier times were not visible, had started to simmer and erupt.

Some of the team approached Sally in private to complain about others in the team, and one member in particular, John. They spoke of how John was “lazy” for arriving late for work and "evasive and uncommitted” because he wasn’t providing good updates or asking for help with issues at the daily stand up.

Sally listened to each team member and tried to gently raise the issue in one-on-one meetings with John. John seemed oblivious to the views that others had of him, and spent most of the discussions talking about his views on how others should act.

With the situation degrading, and pressure from senior management to “sort out the team issues” Sally called a team meeting. Sally was worried that naming individual’s such as John in the meeting would just be unproductive; he’d feel attacked, retaliate and the conflict wouldn’t do any good. Instead she decided to ask the team to figure out it’s policy on working hours and “what it looked like to participate effectively in a stand-up”. During the discussion no one mentioned John or anyone else’s attitudes or behaviour by name. There was a lot of generalised abstract discussion about “what the team should do” but the results weren’t good.

Nothing had changed in the weeks after the meeting; the team still complained to Sally about John in private conversations, John’s behaviour was no different. In the end Sally and the team decided that John’s contract had to be terminated.

It’s a common scenario for managers and individuals in teams to be afraid of naming people’s behaviour directly, often for fear of how it might make someone like John feel. In the interest of kindness, they talk around the issue (often easing-in), using indirect approaches such as gentle one-on-one conversations or generalised discussion about “team policy” even when the target is one individual in particular. When these approaches fail to work then the manager “does what they have to do” and involves HR in discussions about moving or replacing the “problem” individual. Although moving or sacking John is more likely to have a negative impact on him than speaking to him directly, the manager and team resolve that “there’s nothing else we can do”. 

Sally and the team’s desire to avoid making anyone feel bad eventually resulted in a situation where a stunned and confused John lost his role on the team. Neither Sally or the team learnt about how their behaviour may have contributed to the situation or how they might change the way they view the situation or act differently in future.

Make the behaviour of individuals discussable
It is important to be able to name people when talking about specific examples because failing to do so makes the issues hard to understand and resolve. It’s quite possible in this scenario John did not know that the discussion was focussed on him (from his point of view it was others who were the issue). Even if he did, he may feel puzzled about why the rest of the team failed to speak to him directly.

Create conditions of psychological safety
Creating an environment where the team feel safe talking about individual behaviour is important.

It can be useful to make “how do we feel about talking about individual behaviour?” a topic of team discussion.

If the team are uncomfortable it can be worth doing an exercise such as asking “what would need to happen for the team to feel comfortable using specific examples that referred to individuals?”.

One exercise is to ask people to think about situations where they have felt comfortable having others speak about their own behaviour or views explicitly. People commonly mention things like feeling like others had their interest at heart, that other’s views of them were based on specific examples and there was a sense of of working together to understand any unintended consequences of each person’s behaviour.

Reframe the situation with compassion and awareness of skilled incompetence
In the scenario above, rather than seeing John as the “problem”, Sally and the team could have been more effective if they could have re-framed the way they were looking at the situation. The view that John is “the problem” hides several assumptions, such as:

  • John is aware of the impact his behaviour is having on others
  • John has chosen his behaviour deliberately
  • The problem is mostly John
  • What the team believes about John is the truth
  • The team and the situation are not involved

As I’ve shown in my workshop on effective feedback, we are often skilfully unaware of our own ‘incompetence’ so these assumption about John’s awareness and intentions are not necessarily valid.

In the scenario, it’s not just John with an issue. Sally and the team are also part of the problem and contributing to it by not being direct with John and not owning up to the easing-in and by-pass strategies they are using. It may be worth reflecting as a team about what leads them to talk to Sally about problems they experience with others in the team, rather than talking to John directly at the time when the issues happen. 

Sally’s approach of discussing team policies, when the major issue is an individual’s behaviour is an example of solving a special cause problem (one individual’s behaviour) with a common cause strategy (change the policy/system for everyone) and is unlikely to be effective.

Learn more effective ways to talk about individual’s behaviour
Having more effective discussions that can use individual behaviour as examples requires a change in the way we talk. Telling John that he is “lazy, evasive and uncommitted” is likely to result in him feeling unfairly judged or insulted. This is because these views are high level negative evaluations of John’s behaviour that make assumptions about John’s awareness and intentions. Further, they are delivered without referring to observable behaviours that John could agree with. See my previous blog on using the ladder of inference to give feedback to someone who talks to much for more information.

Whilst it’s not necessarily easy to reframe and practice more effective ways of acting in these situations, I’ve seen many benefits with clients that have chosen to do so. A major benefit is that it is more just for all of the whole team. Further benefits include reduced confusion, reduced tensions and greater opportunities for learning for all involved.

Photo Credit: Erin Watson Photography

Handling a team member who “talks too much”

How do you handle a situation as a team manager or coach where one member of the team seems to dominate the conversation? The scenario below is based on several experiences where team members think “that person’s talking rubbish!” but don’t know how to address it. This blog shows how the Ladder of Inference can be used to deal with these  difficult or complex issues productively.

listen to me

Mike, the Development Team Manager, sat in on one of his team’s retrospectives. During the meeting he noticed that one member of the team, James, was taking more turns speaking than other members of the team and often speaking for a long time about how he wanted to solve problems he saw. Mike noticed that the rest of the team had stopped talking.  While James was talking the others were like ‘frozen statues’ looking at the ceiling or their shoes.

After the meeting, Mike went up to one of the team members who had leaned back in their chair so much that they were almost lying horizontal and asked “Can you tell me how useful you thought that meeting was?” The team member said “It wasn’t very good; James spent most of the time talking utter rubbish!”

Mike approached James later in the day “James, I had some observations about how you acted during that meeting that I wanted to check with you. Would you be interested in talking about this?” James said he was interested in hearing more about it.

Mike continued “I noticed that you took more turns speaking than others in the group and often spoke for longer than other people. Did you notice that or did you see it differently?” James said that he’d thought that might have been the case.

“I observed that when you were speaking others in the team weren’t looking at you. In fact one person was leaning back to the point of being horizontal and the others were often looking at the ceiling. How does that match your experience?”

James said that he was aware he might have been talking for too long, but that this was because he was trying to avoid being too “black and white” when describing his views.

Mike agreed that he had seen James be less extreme in his description of the issues in the meeting, then said “From my point of view, if people weren’t looking at you then this suggested they were probably not listening to you, so it would have been unlikely that you were communicating effectively with them.  Can you understand how I’ve arrived at that view?”

“I agree, I’m just struggling to know what to do – on the one hand I can bee too extreme with my views and that stops people talking, but when I try and be less extreme I talk for too long and they also stop listening” said James.

Mike was pleased to have found out more about what James was struggling with. They talked a bit more about what lead James to experience this bind before going on to design options so that James could act more effectively in future.

“If you were in this situation again, is there some help that you could ask for from me or the team to help you recognise that you were starting to speak for too long?” asked Mike

After that they had a discussion that James would start the next retrospective describing the bind that he was in to the group and asking someone on the team to give him a visual signal, such as raising their hand, if they thought James was starting to lose people’s interest.

There are several points I wanted to highlight in this scenario:

  • The feedback from the other team member “he just talked a lot of rubbish” was a high level evaluation that couldn’t be shared publicly with James because he’d likely feel quite defensive and accused.
  • Mike started out by offering James an invitation about whether to have the conversation.
  • Mike walked up the “ladder of inference” from the bottom ‘rung’ of directly observable data, to the meaning Mike made of what he saw, and finally to the evaluation that Mike took (“It’s unlikely that you were communicating effectively when you continued to talk even when others were visibly not paying attention”).
  • Mike did this is in a way that remained curious about how James saw the world, and open to the fact that Mike may have missed other cues or come to the wrong conclusions. Mike showed this by checking for James’ view at each “rung of the ladder”
  • Mike balanced sharing his view at each rung of the ladder with asking James for his view.  This style meant that Mike was able to uncover the bind that James felt in, which also provided a possible explanation of James’ behaviour.
  • Finally, Mike was able to work with James to jointly design a way to improve this situation in future.

I believe this scenario shows how adopting a curious mindset, combined with using the ladder of inference, results in more productive sharing of information which helps design more effective future actions.

I’ve seen clients who have taken these approaches to benefit from reduced time to solve problems, more productive team conversation and a better experience of working as a team.

Image Credit: Leonard John Matthews