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

How can I push the software development team to go faster?

A common challenge I’ve heard from Development Managers or Product Owners is “how do I push my software development team to go faster?” Here are ideas on how to approach this topic and have more productive conversations.


Understand your own mind

Start by clarifying your own mind, particularly your intention and motive for trying to get the team to go faster. If there increasing external pressures on the project, or it’s becoming clear that it wont be possible to get everything you hoped for by the due date then these are worth clarifying and sharing with the team.

Take the time to understand where you’re coming from and why.

This step may seem obvious, but it’s worth slowing this down and even talking it through with a mentor or trusted peer and asking them to play devils advocate and try to see things from the team’s perspective.  It’s much better to get clear on your own intentions and motives than to mop up from an argument later.

Focussing on “fast” may have unintended impacts on quality

As the old saying goes, “be careful what you wish for” because you may get it, but at the expense of other goals.  Sometimes to go faster you may need to use indirect or oblique strategies, such as removing the causes of bad quality or delays.

Seek to understand the situation by looking for evidence

If you think that the team is going slower than it could be, then get clear on the evidence you’ve seen or heard that leads you to this view. If you tell a team “I think you can push a bit harder and work faster” but can’t use specific examples that they recognise and understand then it’s likely they’ll feel unjustly accused. See my post on handling a team member who talks ‘too much‘ for an example of using directly observable data.

If you can’t be specific about why you think the team could be going faster, then be open and say so – “this is just a hunch” – You could ask the team to help look for evidence, by asking “If you were performing under or over-capacity, what would we look for as evidence?”

Talk to the team, sharing interests and concerns

Talk to the team about why you want to help them get more done. Share your intent for bringing it up.  Start by sharing what you’ve seen or heard. Ask them what their view is of the evidence you’ve got? Do they see it the same or different?  If they see it differently then get curious and ask them what they see that leads them to their view.

Sometimes the conversation can get bogged down under an escalating game of “no, your approach is bad for this reason, we should do my approach”. One way to avoid this conversational log-jam is to focus on the interests behind the positions, or more simply, ask them what they like about the solution they’ve proposed.

I’ve found the best way of encouraging more productive conversations is to learn and model these more effective approaches yourself.

Jointly design ways to tests disagreements and move forward

If there’s a strong disagreement between you and team about the level of productivity, then focus on jointly designing ways that you could move forward. Think about what data would persuade you from your point of view and ask the same of the team.  Use work that is about to begin and come up with a way of collecting data that would make future conversations clearer.

This is a topic I may come back to in future and look at it from the team’s perspective.

Image Credit: gentlemanhog, on Flickr

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 create more effective business results. You can find out more about me and my services. Contact me for a conversation about your situation and how I could help.

Removing the bubbles: solving bottlenecks in software product development

A challenge with software product development is visualising the work so that you can spot where there are delays in the process of converting ideas from “concept to cash”. This post shows how a cumulative flow diagram helped identify a pattern of queues over time. Removing these queues had many benefits such as fewer errors, increased team communication and improved team capacity.

Make the work visible
The first task is making the work visible. In knowledge work, such as software development, it is difficult to see the work being done, which is why a visualisation approach such as kanban can be so useful. Here’s a view of a kanban board from an earlier client team:

Kanban Board

The kanban board is useful for a “moment in time” view, but it’s not possible to easily see patterns that might develop over time. Looking at the kanban board on a particular day doesn’t make it easy to answer questions like these:

To find these answers and look more clearly for patterns over time we built a cumulative flow diagram (CFD, also called a ‘finger chart’) by counting the number of post-it notes in each stage (column) in the team’s process after each daily stand-up. Unlike my earlier post on using three forks and a hand-drawn chart to help a team improve in this case we used an Excel spread sheet.

Visualise the work over time to better understand queues (‘bubbles’)
The cumulative flow diagram for this team helped make visible that there were consistent queues of work in the functional testing and acceptance testing processes over time. These queues are visible as “bubbles” that develop in the cumulative flow diagram.  See the highlighted in orange and red stages below (click the image for a larger version).

Cumulative Flow Diagram

Do the detective work necessary to understand what causes the queues (‘bubbles’)
Around two-thirds of the way through the above chart (which covered about 36 weeks) we decided to focus on studying what was causing the queues to develop in functional and acceptance testing.

The functional testing involved someone other than the person who developed the functionality (user story) validating that it worked functionally (there were no obvious errors). Once functional testing was complete then the acceptance testing stage was performed by a business analyst or the product manager.

The team were releasing to production every second Wednesday. On the middle Wednesday the person who did the functional testing switched to doing the integration testing (ensuring the features which were created as a package to go to production worked individually and combined, as well as running a set of manual regression test scripts to make sure that the new functionality hadn’t had any impact on the rest of the website). During the week spent on Integration testing, no functional testing was done, which we believed was the cause of the queues or orange bubbles on the chart.

Creating a new policy to reduce the queues (‘bubbles’)
We sat down with the person who performed the Functional and Integration Testing and mapped out the schedule of their work across the fortnight between releases (see the hand-drawn diagram we came up with below).

The fortnightly plan of testing the project

We also mapped out a new “policy” that described what the person doing testing did for for the week spent integration testing:

While performing the Integration Testing in the week before the release, if there are any work items in the Functional Testing column, spend up to an hour each day doing them.

We experimented with the new policy for the last third of the cumulative flow chart. The cumulative flow diagram showed that the queue (bubble) in the Functional Testing (orange) step virtually disappeared, as did the queue in the Acceptance Testing (red) stage. The CFD not only highlighted the initial problem, but it also validated the experimental change we made in policy resulted in an improvement (it allowed us to answer the critical question – “did the change we made to our process result in an improvement?”)

It’s the system!
This example demonstrates how changing the way the work is structured can produce improvements without having to change the work that team members were doing. This example shows that the queues caused by the way the work was structured (e.g. the system we had designed) and not the work of the team members. It speaks to Deming’s ‘provocation’ that “95% of the variation [in how long the work takes] is due to the system and not the individuals”.

There were many benefits to the changes that we made above:

  • Removing the queue in functional testing meant that if a problem was found then the developer got faster feedback. Getting feedback faster reduced the time it took a developer to “get their head back into the issue” and fix the problems. It also improved the communication between members of the team – the developers were more likely to speak to the person who did test at stand-up about the work that was coming because they knew it would be tested quickly, rather than potentially sitting in a queue waiting for a week.
  • By reducing the bottleneck in Functional Testing also reduced the same bottleneck in Acceptance Testing.
  • The reduced “thrashing” from having issues discovered close to the release date meant the team’s capacity to do work increased.
  • As there were fewer queues it reduced the pressure on team members, helping them feel less rushed which improved the quality of life for the team, reduced “rushing” leading to better quality and team morale.

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 create more effective business results. You can find out more about me and my services. Contact me for a conversation about your situation and how I could help.

The importance of understanding variation or how to avoid treating all contractors as thieves

Here’s a story of how managers detected a problem, but by not understanding the cause of the problem of the type of variation the problem represented, applied the wrong type of solution which meant things were worse for everyone:

Once upon a time in a large financial institution that had many thousands of people in their headquarters, a handful of hourly-paid contractors got their manager to sign their time sheets for times they did not work.

This was clearly a type of fraud and the police were called and the contractors went to jail.

The senior managers looked for a way of making sure it would Never Happen Again.

They came up with a cunning plan! Connect the time clocks in the security gates with the electronic time tracking system for all contractors (yes, even those on day rates).

A little while later, some of the contractors began to change their behaviour. They started to watch the clocks themselves and only work the weekly 40 hour minimum number of hours. When they went out for a big lunch, they stayed out longer if they’d “done their time already this week”.

One clever team of contractors even worked out the rounding rules of the gate system so that if they arrived by 9:14 in the morning it would round their time back until 9:00 effectively saving them from having to work 70 minutes each week. Some of them even set timers to go off around the end of the day so they didn’t stay a minute longer than they were being paid for!

This story highlights the importance of understanding the cause of a problem and the type of variation the problem represents before trying to solve the problem.

Common cause vs special cause
In this case, the small handful of hourly paid contractors were not representative of the thousand of other full time employees and contractors in the building.  So the fraud they committed was not a signal that something was wrong with all the people in the building, but instead just a tiny minority. Rather than seeing this problem as a signal that represented a special event with an identifiable cause (referred to as special cause variation) the management acted as if this was a problem with all contractors in the building (something that could have happened in any team at any time – referred to as common cause variation)

In a special cause situation it’s worth asking “is there a specific root cause that explains what happened here?” because it’s likely there are a small number of identifiable causes. In the absence of good data (such as a longitudinal plot of data), a useful rule of thumb is to ask “If we replaced this bunch of people with another bunch of people would the problem occur?”. In this story, there were hundreds of other hourly-paid contractors in other teams who did not fabricated their timesheets, so the answer is probably ‘no’ indicating that this was likely a special cause situation. In a common cause situation there’s no point asking “what was the cause of this?” because there are multiple sources of variation (causes) all contributing to the problem.

The fix for a special cause situation is to go to the root cause and see if it can be prevented.  Indeed in this story it would have been useful to question the manager involved and understand what lead him to sign timesheets for times that his team did not work.  The fix for common cause variation (and most variation is common cause) is to go and study the situation, experiment and try and look for patterns or trends in the data before making a change to the system.

Implementing the wrong type of fix is tampering and mostly makes things worse
As this story illustrates, applying a common cause solution to a special cause problem – “tampering” as Deming called it – can lead to bad results. Making all contractors (even those on day rates) use the electronic time keeping system sent that all contractors were thieves! And as Deming says, if you muck people around they will use their ingenuity finding ways around the system instead of working towards the purpose of the system.  Applying a common cause solution to a special cause problem will reduce humans intrinsic motivation because it can seem unreasonable and unjust.

The story above is actually a reverse of the more common scenario where managers often treat what is a systemic problem as a special cause and blame the individual. There are many examples of this such as setting targets for sales in call centres (tip: most of the sales are the result of customers who want to buy phoning in, rather than the technique of the person who receives the call).

Have you seen examples of tampering where the wrong type of fix was applied to a problem? (such as yesterday’s blog where a manager tried to change the team’s process to cater for the behaviour of specific individuals) Do you have stories of fixes that were applied to the whole system when there was a clear special cause that could have been prevented at its source (e.g. sign-offs in a deployment process)? Please share your story in the comments.

Image credit: flickr

Hi, I’m Benjamin. I hope that you enjoyed the post. I’m a consultant and coach who helps IT teams and their managers create more effective business results. You can find out more about me and my services. Contact me for a conversation about your situation and how I could help.

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

Improvements on using a simple kanban for effective meetings

Since I posted last week about using a simple kanban to structure workshops, I’ve used the technique with several other clients and have made some subtle but useful improvements.

Here are the key improvements:

  • Making time constraints explicit. Ask everyone at the start of the meeting “are there any time constraints you have?”. Write a post-it for anyone that is coming late or will be leaving at a different time than the others. Use a “time constraints” column between the “to do” column and the “doing” column, where the post-it notes are queued in time order.  Placing the column here allows people to see what time constraints need to be considered when choosing the next most important topic.   If there are known breaks such as morning tea or lunch time then put these in the queue as well. As the time constraint is reached, then pull it into the “done” column (this means the done column can be read from top to bottom as a hi story of the meeting).
  • Defining key questions on the “to do” column. I’ve been writing the key questions to ask when focussing on the “to do” column. The benefit of making them explicit is that it has been easy to ask someone else to “run the board” and facilitate the meeting. This has been useful in giving clients the ability to practice running for themselves, which is more powerful than me demonstrating it to them. The key questions are:
    • Is there anything else to add?
    • Is there value in re-ordering the backlog (to do queue)?
    • What’s the next most important item to start
  • Adding an “any actions?” exit criteria to the “to do” column. Once the agreed time limit is reached, or earlier if anyone feels the current topic has finished being discussed, ask “are we done? would anyone like longer on this current topic?” if there’s no agreement about adding more time, then ask a second question “Are there any actions we need to record?”. If any actions are needed then these are added to the “actions” column.
  • Add an “actions” column to the right of “done”.  I’ve added an “actions” column to the right of “done” where any actions agreed in the discussion can be put.

photo (5)

Having run four or five workshops like this in the last week, it is critical is to be strict on not allowing discussion to continue once the timer has gone off (I use the marimba noise from my iPhone’s timer and deliberately let it ring several times if people are talking past the time). I stress that it’s OK to propose to take more time and to see if there’s consensus (by asking ‘Does anyone have a concern if we continue for X more minutes?’), but allowing people to keep talking makes it too easy to continue talking too long.

Some other observations and things I’m experimenting with:

  • Estimating times. In a few situations I’ve tried asking people to estimate how long they think a topic will take. This can be revised before the task is started. Once it is started the time can be updated by adding “+5” for example, when five extra minutes are added. I’m just experimenting with this at the moment. It has been useful at highlighting that a group has been underestimating each topic, which made people add more realistic times to future topics.
  • Inviting people to write the post-it notes, re-arrange or track actions themselves. Several times I’ve found myself doing the work for the clients, by writing the post-it notes, re-arranging them or tracking actions. I believe that the effectiveness of this approach can be enhanced if the participants have the experience of doing the work for themselves. Also, it reduces the possibility of error by writing the wrong thing.
  • Add a section for “policy changes” under the “actions” column. I’ve also been experimenting with “policy” changes for agreements around how the team might be working. I use the format “It’s OK to …” An example from a client this morning was “It’s OK for tasks to move tasks back into ‘to do’” or another one “It’s OK to split a larger task into smaller ones at any time”
  • Keeping a cumulative flow chart. This morning I was working with a client who wanted to try using a cumulative flow chart to record what occurred on their team kanban board. In order to illustrate, I got them to hand-draw the chart (see last week’s post on using three forks on a hand-drawn cumulative flow chart as an example) by counting the number of post-it notes in the columns (we ignored actions as these were by-products of discussing topics, rather than topics themselves). The client reaction was great, with the manager saying “I completely get what the chart is about now” and the result was we only need to spend two minutes actually talking about it (to help others in the team check their understanding).  Here’s the chart they produced:

photo (6)

Client Response
The response from clients has been really positive to this approach. The client this morning said they were amazed how much they achieved in a short workshop. They also said they felt more energized from that meeting than they had when we’d done a longer meeting without using this kanban format!  I’ve also used it with little or no introduction in meetings and it’s been very successful.

I’d welcome hearing further about your experiences, or your views on what I’ve mentioned, in the comments.

Skilled incompetence in action at Agile workshops

As part of my workshops on effective communication, especially around introducing innovative new process approaches such as Lean and Agile, I’ve found examples that demonstrate how people can act with “skilled incompetence” and “skilled unawareness”.

One exercise I run is to help people look at how effectively they communicate feedback on difficult topics. The scenario (based on Argyris’ XY case study) is that a manager, Y, has given some feedback to a poorly performing team member X.  I show the participants a list of comments that Y (the manager) has said to X (team member) and ask them to pretend that Y has come to them as a coach and asked:

Can you review the feedback I gave to X? I’m interested in learning how to improve – how effective was I?

Feedback is appreciated

At the recent London Software Practice Advancement (SPA2011) conference, I ran this workshop and one of the workshop participants said they’d give Y the following feedback:

Y, your feedback to X was ineffective because you failed to focus on things that X was doing well, and you also didn’t illustrate your feedback with an example of what X specifically did

I think the participant’s statement illustrated that we tend to store theories of effective behaviour in our heads. In this case, the participant’s feedback contains a micro-theory that:

Feedback is effective when it:

1) focuses on behaviours that are done well and

2) illustrates the feedback by using a specific example of the behaviours.

The participant confirmed that this was their view.

I was curious then to apply the participant’s ideas about effective feedback to the feedback they gave Y. I asked:

Let’s use your own theory of effectiveness to analyse the feedback you gave Y. I don’t think your feedback was about something that Y was doing well and I don’t think you gave an example of what Y specifically did. Do you see it that way or see it differently?

The participant agreed that the feedback they provided was not consistent with their own beliefs about effective feedback, and they also confirmed that they were able to see the inconsistency once it had been pointed out, but they were unaware that what they said was inconsistent when they originally produced the feedback.

In effect the workshop participant was telling Y, “do as I say, but not as I do” without admitting this directly. It’s likely that the recipient of the feedback, in this case Y, will experience it as inconsistent and puzzling.

This small example illustrates several points of Argyris’ concepts of skilled incompetence and skilled unawareness. Firstly, the fact that participant’s comment was incompetent in the sense that it did not meet the participant’s own beliefs about effective feedback. Secondly, the feedback was skilful in the sense it was automatically produced without the participant being aware of the inconsistency. Argyris refers to the lack of awareness of our own skilled incompetence as skilled unawareness.

Although it’s common for most of us to admit we can sometimes act in a hypocritical way, most of us are not aware that we are doing so when we are producing the action.

There are many benefits from accepting and finding ways to overcome our tendency to act with skilled incompetence and skilled unawareness. Adopting the mindset and behaviours of the mutual learning model (based on Argyris & Schön’s Model II) involves accepting we can act like this and choosing to act in ways that invite others to help us realise it in order to be more productive. I’ll write more about this in future.

Photo credit: Adwale Oshineye

Using a simple kanban to run effective meetings and workshops

I’ve found using a kanban a productive approach to structuring and running meetings, workshop and presentations.  Many meetings or workshops are often run from a fixed schedule that isn’t easy to update or change and also isn’t visible to the participants. I wanted to find a better way of structuring the day which balanced some competing goals:

  • Allow participants to take as much responsibility as they were comfortable with adding, removing or re-ordering the topics covered.
  • Acknowledge that as a content expert on many of the topics it’s appropriate for me to offer suggestions about which topics are likely to be most relevant, and the order and approach to presenting them.
  • Find an approach that addressed the previous two goals without spending longer than necessary talking about the process during the meeting.

The solution I came up with was to use a simple kanban system of post-it notes.  UPDATE: I’ve blogged a few improvements on using a simple kanban to structure meetings

Here’s how it worked:

  • At the start of the day I presented a list of topics/activities we could cover in a suggested order with suggested timings (e.g. 30 mins) in a “to do” column. At this stage there was an opportunity for the group to add or remove topics or re-arrange the order.
  • I introduced a “doing” column with a (work in process – WIP) limit of one topic at a time. When we decided to start a new topic there would be a quick discussion about how long we wanted to spend on the topic, which we wrote on the post-it note.
  • There was an exit criteria on the “doing” column, so that when we reached the time agreed we stopped and asked “is everyone happy to move on?” before it could move to “done”. This encouraged a focus on the coming to a close on topics before starting new topics (“stop starting, start finishing”)
  • If anyone wanted to continue then they had the option of creating a new post-it note that could be added to the ‘”to do” column that could be chosen to continue.
  • We then went to the “to do” column and checked if anyone wanted to add a new topic, re-arrange the list of topics and most importantly, decide which task to start next.


There were many benefits from using this approach:

  • It allowed the participants to take as much of responsibility for what we talked about as they wanted and left open the possibility for them to take more responsibility at each “which topic next” decision point during the day.
  • The list of ordered “to do” topics was visible throughout the day, so people could make more informed decisions about which topic to start next.  Nearing the end of the day it helped the participants focus on spending their ‘time budget’ on topics they thought most valuable.
  • The overhead of this approach was minimal.
  • Discussing how long the group wanted to spend on a topic helped me gauge how valuable the topic was. In one situation participants asked for a 10 minute overview of a topic which really focussed how I presented it. We also adopted the practice of asking someone to say what was most important about the topic, or what the key outcome they wanted from a topic was as the topic started (similar to defining the success criteria on a software development task)
  • It gave people an experience of working with kanban that increased their understanding of the approach.
  • Whenever discussions went off-track we stopped and asked “do we need to add this as a new ‘to do’ topic?”
  • Rather than having to structure the list of topics at the start of the day, when we have least information about what will be useful or interesting to the group, we were able to defer this decision by making lots of smaller “what’s the next most important task to begin?” decisions as we went.

I’ve used this technique several times in workshops and meetings and continue to find it helps increase the productivity of the meeting by ensuring the group are engaged in discussing exactly what they want to talk about for the time they want to talk about it. Have you used a similar approach? What’s your experience been?

Thanks to @HakanForrs and @YuvalYeret for discussions about Jim Benson’s Lean Coffee format which inspired my approach.