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.
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.
Benefits
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.
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
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?
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.
How three forks on a hand-drawn chart helped a team improve
After visualising the workflow of a recent client’s software development process, and showing where the work was, the team realised there was a queue of tasks that had been developed and were waiting to be validated (‘tested’). The team decided to move from a “I just do my task” approach to a “whole team” approach where they focussed on making a single task flow across all of the development process with minimum delay. They decided that rather than continuing to do more development and hoping that the validation work would eventually complete, the people who did development would go and help those who were validating the work.
The problem was that the Development Manager (who believed his role was to maximise the number of development tasks completed) was concerned that if the development work stopped to reduce the queue in validation, then eventually the validation step might run out of work to do.
In order to address the Development Manager’s concern we went to the hand-drawn cumulative flow diagram (sometimes called a finger chart). The cumulative flow diagram was drawn each day, by the team member who ran the daily stand up, by simply counting the number of tasks in each stage of the workflow. The x-axis shows time in days, and the y-axis shows the number of tasks in each step of the workflow.
As we had a couple of weeks data it was possible to extrapolate the rate at which the validation work was being completed. We were also able to extrapolate the rate at which development work was finishing. In order to do this extrapolation we grabbed the nearest straight-edge items we could find, which turned out to be forks!
As the photo shows, the forks indicated that it would take about two weeks for the validation step to run out of work to do if most of the people doing development spent their time helping do the validation. This data allowed the Development Manager to feel more comfortable about allowing the strategy a shot for a week, after which it could be reviewed.
This example demonstrated the benefits of using quick, low-fidelity data collection methods. The discipline of hand-drawing the chart each day meant that it was better understood by the team members than if it had been automatically produced in an electronic tool. The team were also able to see how the data could be valuable, as it allowed them to discuss the Development Manager’s concerns with data rather than just opinion.
In the end, the strategy to work as a whole team and focus on the validation step turned out very well. The team were able to reduce the time it took to validate tasks, providing quicker feedback to development (which reduced defects), increase the amount of work they got done at the same time as improving the team’s morale.
Do you have stories of using quick, low-fidelity data collection techniques to improve team performance?
Can Agile overcome Organisational Defences to achieve Double Loop Learning?
Agile approaches are sometimes focussed on helping organisations experience transformational change. Many Agile adoptions have failed to achieve long-term change, especially outside core teams, where the problems are non-routine and potentially embarrassing or threatening. Chris Argyris has developed a theory that provides a possible explanation of why Agile adoption has failed to bring about these hoped-for organisational changes.
Argyris & Schön’s Theory of Action
Chris Argyris, a retired Harvard Professor, has spent his career developing ideas around Theory of Action (co-developed with Donald Schön) [1, 2]. The Theory of Action approach is based on the idea that we store programs in our heads which we use to determine action strategies (behaviours) that will achieve the consequences we desire in a way that is consistent with our governing values (preferred states we try to ‘satisfice’ when acting). Effective action is any action which produces an intended outcome that persists over time and achieves this without harming the current level of organisational performance.
Argyris and Schön believe there are two types of theories, those that we say we use (espoused theories), and those that we actually use (our ‘theories-in-use’). Espoused theories represent our ideals about effective action, whereas theories-in-use are used to produce real, concrete actions. We are often able to identify the gaps between what someone says and how they act, as the saying “watch what people do, not what they say” illustrates. However, we are often blind to the fact our own actions aren’t consistent with our espoused view of the world. If we are made aware of this gap, our usual reaction is to blame someone else or “the system”
Model I and Skilled Incompetence
Argyris and Schön have found that while there are differences between people’s espoused theories, there is very little difference in theories-in-use across cultures, age groups and gender (even after over 10,000 case studies). Argyris and Schön label this common theory-in-use “Model I” (other authors have describe it as “closed to learning” or the “unilateral control model”). The governing variables of Model I are:
- Maintain control the situation (unilaterally). Get what you want, achieve your objectives/goals
- “win, do not lose”
- suppress negative feelings, such as embarrassment, in yourself and others
- act “rationally” (suppress or deny emotions).
Based on these governing variables we choose action strategies such as advocating our own position, making evaluations of others’ performance and their intentions in ways that ensure we remain in control, maximise our chance of winning whilst ensuring that we act diplomatically and ensure that no-one expresses negative feelings. We do this in ways that encourage neither inquiry into our views nor the robust testing of claims that we make, often relying on self-sealing logic such as “Trust me; I know what I am doing” [3].
When we are producing these actions, especially in non-routine situations which might be embarrassing or threatening, we are often blind to our own Model I behaviour. Worse, we actively try and by-pass the embarrassment or threat and then cover-up the bypass, leading to situations where we are unable to “discuss the undiscussable”. Using Model I means that we are likely to produce consequences we don’t intend. Model I behaviour is learnt over a lifetime and is produced skilfully, which makes it even harder to spot when we are producing it, leading to what Argyris labels “Skilled Incompetence”.
One way of detecting the gap between your own espoused theory and your theory-in-use is to use the “Left Hand Right Hand Case Study” tool. Describe an actual or an imagined conversation with another person on a difficult topic. On the right hand side, write the script of what was said. Ideally this would be a transcript of an audio recording, but a description of the conversation will also work. On the left hand side, write what you thought but did not say. Having done this, reflect on whether there was a gap between what you said and what you thought, but did not say. Argyris describes this gap as an ethical gap since it involves deliberately hiding information that may be useful to test, or share with others, without admitting that this is what is actually happening (it is covered-up and the cover-up is also covered-up). Argyris advocates striving to reduce the gap between what is on the left hand side and right hand side in a way that minimises the likelihood of all of those involved becoming defensive.
Individuals operating in a Model I fashion are likely to produce organisations full of defensive routines. Defensive routines are ways of acting that prevent us and others from threat or embarrassment, but also from learning. Common examples of defensive routines are mixed messages, such as “I didn’t mean to interrupt you …” (clearly you did, and just have) or “I don’t want to upset you, but …” or to say “that’s an interesting idea” when there is no intent to act on it. Defensive routines make it harder for organisations to surface the information needed in order to learn.
Double-Loop Learning
Argyris defines learning as “the detection and correction of error” where an error is a mismatch between what was intended and what was produced. Single-loop learning is where the changes only involve changing the action strategies (at its simplest ‘try harder!’). Double-loop learning goes one step further and requires changing the values that govern theory-in use, often by questioning the status quo. The most common analogy is a thermostat [4, p.10]:
A thermostat is a single-loop learner. It is programmed to increase or decrease the heat in order to keep the temperature constant. A thermostat could be a double-loop learner if it inquired into why it should measure heat and why it is set so that the temperature is constant
Single-loop learning can be compared with becoming more efficient at what you’re already doing, whereas double-loop learning is about questioning the effectiveness of the goals. Or in other words that single-loop learning is doing things right, while double-loop learning is doing the right things.
Double-loop learning can happen around technical problems, while at the same time not occurring around human problems. My view is that XP practices, such as Test Driven Development (TDD), have led to double-loop learning at the technical level because there has been a change in mind-set. Prior to TDD I remember people trying single loop solutions that only involved changes in action strategies, such as “just write better quality software, and leave testing to the testers” whereas now people talk more about TDD as a design tool. I do not believe that Agile approaches have led to double-loop learning in terms of human problems.
Model II: Overcoming organisational defensive routines
Changing the defensive routines requires double-loop learning because it involves people giving up their Model I theories-in-use. Argyris describes Model II as one possible theory-in-use that can produce double-loop learning. The three governing variables of Model II are:
- Produce valid information
- Informed Choice
- Internal (rather than external commitment)
These are used together with vigilant monitoring of the effectiveness of the implemented actions.
It’s important to note that Model II is more than just the opposite of Model I; in the same way that listening is more than just the suppression of the urge to talk. The governing variables of the opposite of Model I would be [4]:
- Everyone is in control
- Everyone wins
- [all] feelings are expressed
- rationality is downplayed
Model II is not a replacement for Model I; Model I behaviour is appropriate when problems are routine or in emergency situations. The action strategies of Model II include clearly articulating a position, the difference from Model I is that there is an emphasis on enquiry and testing, similar to Bob Sutton’s concept of “strong opinions, weakly held”. Often when people realise the gaps between their espoused- and theory-in-use they want to quickly overcome this gap. A common experience is that after a few days of trying to learn quickly, most people relax and slow down, realising that learning to produce actions consistent with Model II will take some time. Argyris argues that “most people require as much practice to overcome skilled incompetence [by learning Model II] as to play a not-so-decent game of tennis” [5].
Examples from Agile / XP
In general, Agile methodologies and frameworks have taken unsophisticated approaches to organisational change, most of which fit within a Model I view of the world.
Scrum talks about “shock therapy” where “teams are trained on exactly how to implement Scrum with no deviations for several sprints” [6]. It uses an openly coercive approach described as “forceful and mandatory way of implementing Scrum” [7] in the hope that managers will receive a “wake-up call” and change their view of the world and their behaviours once they see the “hyperproductive” results. The approach does not focus on organisational defensive routines, or even double loop learning at the management level. It does not ask questions like “What was stopping us from acting this way before? Can we be sure that the thinking behind the previous approaches has really changed?” Predictably, from an Argyris point of view, the authors report that management failed to change their view of the world: “…management tends to disrupt hyper-productive teams … in all but one case, management ‘killed the golden goose.’”.
XP and Agile often speak of the importance of underlying values, such as “courage”. The problem with values is that they are not usually described in an actionable way. Further, the interpretation of a value depends on whether a person has a Model I or Model II mindset, or view of the world. When courage is illustrated, it is often of examples that represent a coercive approach consistent with Model I, as mentioned in an interview on “What’s Missing from the Agile Manifesto?” [8]:
[Courage is] … the courage to do what is best for the team, the project, even the business, despite the pressure to do otherwise. … An example [credited to Ken Schwaber] is of a scrum master who disassembled the team’s cubicles, so that they could have the team space that they wanted. When confronted by the ‘furniture police’ she made it clear that she would quit if the cubicles were restored.
This advice seems to contain several potential errors. How is a “courageous person” meant to validate or test that what they believe is “best for the team” is actually the best for the team? Is it OK for them to decide simply by “asking themselves?” Do they need to make this known to others? How would this advice deal with the potential that the courageous person did not understand the wider context of their change? In the example given, the scrum master acted in a unilaterally controlling way, and when confronted blackmailed the organisation in order to get their way, entirely consistent with Model I.
Moving Forward: Detection and then correction of errors
If Agile approaches are to have an effective impact on organisations at more than just a local team level, across longer than just the short-term, then it would be useful to spend time focussing on personal and organisational defensive mechanisms. This starts with developing an awareness of the gaps between what we espouse and how we act, so that we can at least detect errors. A useful step is to acknowledge threatening or embarrassing issues that are likely to lead to defensive Model I behaviour at the individual and group level. The next step is to work on being able to demonstrate that we have learnt by being able to produce effective behaviour, even around threatening or embarrassing issues. The challenge for the Agile community is whether we want to deal with the feelings that come from acknowledging our own blindness to our current skilled incompetence and start practicing more effective ways of acting.
References
1 – Argyris, C., & Schön, D. (1978) Organisational learning: A theory of action perspective. Reading, Mass: Addison Wesley.
2 – Argyris, C., & Schön, D. (1996) Organisational learning II: Theory, Method, and Practice. Reading, Mass: Addison Wesley.
3 – Argyris, C. (2000) Flawed Advice and the Management Trap: How Managers Can Know When They’re Getting Good Advice and When They’re Not. Oxford, England: Oxford University Press.
4 – Argyris, C. (2004), Reasons and Rationalizations. The Limits to Organizational Knowledge, Oxford, England: Oxford University Press.
5 – Argyris, C (1986) Skilled incompetence. Harvard Business Review, 64(5), 74-79.
6 – Sutherland, J., Downey, S. & Granvick, B. (2009) Shock Therapy: A Bootstrap for Hyper-Productive Scrum. http://jeffsutherland.com/SutherlandShockTherapyAgile2009.pdf
7 – Sutherland, J. (2008) Shock Therapy: Bootstrapping Hyperproductive Scrum. http://scrum.jeffsutherland.com/2008/09/shock-therapy-bootstrapping.html
8 – Brian Marick: What’s Missing From the Agile Manifesto http://www.infoq.com/news/2008/11/Marick-on-Agile-Manifesto
Benjamin Mitchell's Blog 