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
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.
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:
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?
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?
Helping overcome impediments between Managers and Agile Teams
Agile teams often experience difficulties when they have to deal with problems that occur outside the team and may require management involvement to resolve. I’ve seen several Agile teams lose motivation when they question whether managers are really committed to helping the team. Often the team struggle to be open with the manager about the perceived problems or how they could jointly come up with ways to improve the situation.
Here’s a hypothetical scenario based on my experience:
Mike, the Development Manager at a small company, asked Alice, an Agile coach, to come in and help introduce Agile to his organisation, starting with the key development team.
Alice ran some introductory workshops with Mike and the whole team. At the end of these sessions Mike told everyone “I’m really excited about the potential of Agile to help our organisation, starting with this team. I want to do all that I can to support it”
When Alice came back to the organisation a few weeks later she found that the team were beginning to express doubts about how committed Mike was to adopting Agile. Mike had stopped coming to the daily stand-ups and worse, he wasn’t helping them remove the blockers they experienced with tasks that required a specialist user experience designer in another team.
The team told Alice: “Mike’s not doing anything to remove the delays caused by other teams. He says he supports Agile, but when we need him to help us out, he isn’t there for us. Yet again, the problem is with management! There’s no point us doing this Agile stuff if we’re not supported”
Alice agreed with the team Mike’s role is to help the team by overcoming organisational impediments. She decided to encourage Mike to attend the team’s daily stand-up where she hoped he’d recognise that the reasons for blocks which were causing delays on the tasks were things that he should help with. If Mike didn’t see this for himself, Alice would then model this behaviour for Mike by asking “What would it take to remove the blockers on those tasks? Would you benefit from help on those?” If this fails then Alice would be more direct to Mike by asking “What’s your view on talking to the team about the blockers and seeing how you could help?”
What’s your view of Alice’s approach to helping in this situation? Here’s my view – I welcome your thoughts if you see it differently.
- Alice seems to assume that what the team complain about is valid – that Mike is not helping resolve the causes of the external blockages – without clarifying what the team have said or done to raise the issues they see with Mike. Alice seems to assume that the team’s complaint is valid without checking if the team have raised their issue with Mike.
- Alice doesn’t ask the team for the reasoning behind the assumptions they seem to have made, firstly, that Mike is aware that he isn’t helping them, and secondly, he has deliberately chosen not to help them out. Alice doesn’t ask the team why they seem to think that Mike has deliberately chosen not to help them. It would be useful to focus on directly observable data – what the team has seen Mike do or say that lead them to their views?
- The next question is what have the team said or done to make Mike aware of the situation? Have they been explicit and described their point of view? If not, what, if anything prevented them from doing so?
- Alice seems to jump straight to taking action to help the team out, and in doing so, taking responsibility for them, rather than discussing her approach with the team and giving them an opportunity to handle the situation more effectively.
- Alice’s choice to ‘model’ the ‘correct’ behaviour for Mike, without explicitly saying that this is what she is doing, is an easing-in approach with the manager which may be based on assumptions that the Mike couldn’t handle being told directly. It’s likely that Mike will work out that Alice isn’t being direct with him, but rather than guessing what Alice’s view is, Mike is likely to feel puzzled or confused about what Alice is holding back.
Here are a couple of suggestions for how I think this situation could be dealt with more effectively.
Adopt a mindset of curiosity
First off, it’s worth trying to adopt a mindset of curiosity rather than certainty about the team’s view of the issue and the meaning and intent behind Mike’s behaviour. It’s common for the team in this situation to believe that they see the whole picture, that Mike is either lacking the right perspective or being deliberately difficult and the team’s task is to illustrate the obviousness of their perspective so that Mike will change. A more productive frame of mind is to believe that the team see many important things, but not the whole situation, Mike may see additional things they don’t and the task is to work together to design a productive way forward.
Focus on getting directly observable evidence rather than assumptions
It would be useful for Alice to ask the team to tell her what they’ve seen Mike say or avoid doing that leads them to believe he is aware of the blockers and has deliberately chosen not to do anything about them. Getting down to the level of directly observable data – what a video camera would capture – would allow Alice to understand more about the problem and potentially highlight how the team’s behaviour may (inadvertently) be contributing to the situation.
Strive to raise the issue with the people involved at the time it happens
An effective situation would be one where the team were able to raise their concerns directly with Mike and ask if he sees it similarly, or perhaps sees something that they are missing. For example, they might say:
“On our task board, there is a task that is blocked because we’re waiting on another team to do some work for us. Our understanding of the Agile process is that your role is to help us overcome these situations. Does that match your view? If so, can we share our view about what’s causing this blockage and how we could work together with you to remove it?”
In my experience working with teams using the suggestions above has created productive outcomes even in complex situations. I welcome your experiences or views in the comments.
Using a Case Study to learn the Mutual Learning Model
I’m currently focussed on improving my own skills around the Mutual Learning model (‘model II’ from Argyris & Schon’s Theory of Action). In order to do this, I’ve been using a Left Hand Right Hand Case Study approach, one of the key learning tools. In the interest of being open and sharing my experience with others, I wanted to highlight some of my recent reflections. I’m doing this to help me with my learning and to invite others to share their views on the approach and my goals.
Creating a Left Hand Column / Right Hand Column Case Study
The Left Hand Right Hand Case Study approach is a very simple tool. In order describe what it is I’ll go through how I created mine.
I started by describing the situation and what I was trying to achieve in the situation. In my case, I’d had a conversation with someone from another organisation about my experiences of trying to discover if there was a potential to work together in future. I was unclear about the status of the discussions and had some concerns about how the situation had developed and wanted to talk to someone I knew from that organisation about the situation.
The next step is to create two columns. I started with the right hand column, which is “what was said” written like a script. I did this using my memory of the conversation (the conversation had happened a couple of weeks earlier. Many people worry about ‘if it will work’ when using a remembered conversation. The answer is yes). I put it aside for a week or so, before filling in the left hand column, “what I thought, but did not say”. I was pretty surprised when started filling that column in as it highlighted the gap between how I think I act and how I actually act (espoused theory and theory in use in Argyris’ theory) then put it aside for another couple of days because I found it quite confronting and I wanted to let myself ‘calm down’ and come back to it with a fresh mind.
Here’s a fictitious example similar to what mine looked like:
| What I thought but did not say | What was said |
| I think that this group have mucked me around. Let’s see if I can prove my case. | Me: Hi Bob, have you got a minute for a quick chat? |
| Bob: [up beat] Sure! | |
| I think they treated me badly and don’t even realise it. I’m going to show them. | Me: I wanted to check out what was happening in terms of us working together. I caught up with your colleague the other day and they told me something that didn’t match my expectations [I briefly illustrated] and I felt mucked around! |
| Bob:[More serious] What they said was right. | |
| What?! It looks like he agrees with his colleague. I can’t believe that! I need to show him that his view is wrong. | Me: [Raising my voice and speaking quicker] Well there’s no way that what I was told was reasonable …
[further justification of my position, point/counter-point discussion and a muted resolution when the conversation was ended by an interruption] |
The next step was to reflect on what the case study had surfaced. I did this by answering the following kinds of questions:
- What was my intent with this conversation? How effective was the conversation at achieving my intent? How effectively did I communicate my intent?
- How effectively did I balance advocacy and inquiry?
- What was my ‘frame’ of the conversation, how did I view myself, the other person and the task I was trying to accomplish?
- What was I hiding from the other person, what was undiscussable and what prevented me from making it discussable?
I wasn’t expecting that I’d discover as many things about how I think and act as I did. Here’s what I came up with as I reflected:
- I wasn’t clear on my own intent. When I looked back over the conversation I realised that I’d entered the conversation without a clear understanding of what I wanted to achieve. From what I’d said I inferred that my goal was “to get the other person to make me feel better about the situation by agreeing with my view of the world”. Realising this gave me some insight into how it might have come across to the other person. If I wasn’t clear on it, what chance did they have of understanding me? Their difficulty may have been compounded by the fact that I didn’t express any tentativeness in my world view, in fact, the opposite is true!
- There was no balance of advocacy and inquiry. In terms of balancing advocacy (explaining how I saw and felt about the situation) and inquiry (asking about their view of the world) I was poor. I discovered that I had asked only three questions and two of them were rhetorical! At the same time, I’d made around 27 statements in a 10 minute conversation. I was unaware that the conversation was this unbalanced whilst I was having it.
- The goals I was trying to achieve were unilaterally controlling, fixed and hidden. I wanted the other person to see my view of the world and to agree with my position that they were wrong. I had no intention of changing my mind to accommodate their point of view. But I didn’t state any of these reasons as I was worried about how they might feel, and I didn’t tell them that I was hiding my intent because I was worried about their reaction. Although I say it was because I was worried about them, the fact that I didn’t test my beliefs meant that it was actually self-protective.
- Without intending to, I created conditions I didn’t want. The case study helped me see more of how I acted from the other person’s point of view. The evidence I saw was that I lured them into a conversation where I was asking them to admit that I was right and they were wrong. When I told them about my point of view, I often used high-level judgements like “you acted weirdly!” without demonstrating any observable things they said or did that led me to that belief. I thought I was being open with them, but I can see how they might have felt accused and threatened (there was evidence for this in the kinds of responses they made and the fact that the conversation felt like a ‘tussle’). So, my behaviour may have inadvertently created exactly the conditions I wanted to avoid.
- I wasn’t able to express myself as effectively as I thought I was. The conversation on paper highlighted there were many times when I used a kind of short-hand to describe my points, but in a way that, on reflection, was unclear or rife with potential points of confusion.
How did I feel after this?
On an intellectual level I found the case study interesting to do because it showed how unaware I was of how I actually acted. It was useful to realise that my framing of the situation (I’m right, they’re wrong / misguided, I have to convince them of my view) may have contributed to acting in the way I did (this gave me hope that maybe I could learn more about how I could be more effective in future).
On an emotional level, I felt pretty embarrassed (“How could I have acted like this without being aware of it? What if others knew I acted like this – in a way that I would not espouse?”), defensive (“I still believe that they were mostly responsible for the situation!”) and even a bit dejected (“How much more am I unaware of? It took me days to realise how blind I was to my involvement in the situation, and I produced all of these responses without even thinking about them, how am I ever going to learn to act differently? Is it even possible to learn a different way of thinking/acting?”).
Reflection is often improved by doing it with others
Reflecting is hard cognitive and emotional work. I had given myself some ‘rest days’ between filling in the case study to make it easier for me to reflect without getting emotionally engaged (I believe it’s a similar effect where it’s easy to spot things in other people’s behaviour, but it’s hard to spot it in ourselves when we are acting). It was interesting to me how each time I came back to look at the conversation I realised that I was able to reflect with more detachment, but I was still pretty attached to my view of the world being right! To help me further, I sent the case study to another person who reviewed it and provided some comments before a meeting where we discussed it.
The review comments were pretty confronting. I was secretly hoping that they might evaluate me positively and agree that the problem was the other person, but their comments highlighted how my behaviour may have had a lot more to do with the other person’s response than I was aware of / wanted to admit. The reviewer highlighted things such as:
- I was stuck on advocacy. There wasn’t a single example of genuine inquiry from me into the other person’s view (which he stated at least three times in the conversation, but I never acknowledged).
- I was hiding information. I was hiding a lot of useful information in my left hand column which would have been useful to find ways of sharing (and leaked out in the way I was treating the other person anyway)
- I wasn’t Illustrating evaluations and judgements. When I was advocating (sharing my view of the world) I was using high level evaluations (“I was mucked around”) without explaining the data I used to come to that conclusion. In Argyris’ model, I was advocating from a high rung on the Ladder of Inference without describing the ‘lower rungs’ that lead me to my conclusion. Doing this may have contributed to the other person being defensive or feeling attacked (I used some pretty extreme emotive words!).
- I was using ‘gimmicks’. I was using phrases and approaches associated with a Mutual Learning mindset but designed to achieve the goals of a Unilateral Control mindset (model I in Argyris’ approach). I was using my knowledge of the Mutual Learning model (model II) to ‘win’ (a goal of the Unilateral Control model, model I). It was curious that I was using my knowledge of the Mutual Learning model to accuse the other person of acting in a way that was consistent with the Unilateral Control model, and I was blind to the irony that doing this demonstrated that I was acting in a way consistent with the Unilateral Control model (e.g. trying to win)!
- I was punishing them for being wrong. Rather than testing if they shared my view, or being open to learning more about theirs, I was pushing them to admit they were wrong, and more than that, wrong for being wrong. I was in full righteous mode (at one point they even agreed with me that the way they acted had been unclear, but I didn’t listen to it because I was so focussed on ‘letting them have it’!)
Conversations with the reviewer
The conversation with the reviewer was very helpful. He wanted to check how I’d reacted to the case and his feedback and share the point that most people feel pretty embarrassed when confronted with what they find. There were several points I got out:
- It’s important to take responsibility for identifying what triggered my behaviour. Understanding the triggers allows me then to be aware of what might be about to happen, and to ‘create a buffer’ where I can pause my natural response (usually to react to the other person by attacking or to withdraw by becoming passive aggressive) and act differently. The reviewer shared that this is what Argyris’ Model II / Mutual Learning model is all about – providing another ‘degree of freedom’ in choosing how to act (rather than trying to ‘be Model II all the time’)
- The Ladder of Inference is a useful tool to help learning how to act differently. It was useful to realise that if I just state a high level evaluation without illustrating the data that I used (‘rung 1′) and the culturally meaning I applied (‘rung 2′) it could lead to the other person reacting defensively. Also, ‘staying low on the Ladder of Inference’ means that there is less likelihood that the other person will be confused, and ‘working slowly up the ladder’ helps more easily identify where the points of confusion/departure are.
- Advocating effectively is a skill which takes practice. The conversation with the reviewer helped me practice being clearer about what I was advocating. At some times I was able to do this, at other times I found this very difficult and stumbled or spoke for too long. It was confronting to realise that this would take more practice.
- Use the concept of binds, dilemmas or paradoxes to surface things that are undiscussable. I was worried about sharing that I had some concerns about whether I would be a compatible fit with the other group, but I didn’t want to raise this issue because I was worried that they would react negatively to it (“why would we want to work with you if you hold a negative belief about us?”). We spoke about how I could raise this in the form of a bind and ask for assistance from the other person (“I’m in a bind. On the one hand, I’d like to work with you. On the other hand, I’ve had a few experiences, which I could describe, which I’ve found confusing. I’d like your help to go through these experiences and check my understanding. Would you be interested in that?”) .
- My own competitiveness is not helping me learn. For better or worse, I’m often quite competitive with myself and other people (this is something I observe in how I think and act, rather than something I’d espouse to others!). My initial reaction when seeing the gap between how I think I act (espoused theory) and how I actually behave (theory-in-use) I wanted to close it as quickly as possible as I found it deeply uncomfortable. However, the pressure to overcome it quickly sets me up for failure, which makes me less likely to practice.
- My attitude to failure is not helping me learn. When confronted with feedback that I’m not as effective as I’d hope (e.g. demonstrating no examples of inquiry) I kind of collapse and go into a bit of a ‘doom zoom’. The problem with this approach is it means I find it harder to focus on learning to practice new behaviours that will help me be different in future.
- Improving skills is a matter of practice and that means failing (a lot). In order to improve my skills I need to do lots of practice (Argyris compares learning Model II to learning to play tennis. It would be unreasonable to think a few books and a lecture on tennis would be enough to learn how to play – you need to actually hit some balls). Similarly learning more effective ways to handle difficult conversations and learn will require ‘hitting a few balls’ and trying behaviours that ‘fail’ in order to reflect and learn.
- Changing how I frame the situation is useful. It was useful to reframe how I saw the discussion to think more about the fact I only have a partial view of the situation (self), that the other person may see parts I don’t (other) and the task of the conversation is to try and learn more about the situation together (task). It’s a challenge, in the heat of a difficult situation, to delay the natural tendency to attack / respond, and replace it with a ‘buffer’ around being curious about the other person’s perspective.
Where am I now?
I found the experience very useful. I’m now more humble about the scale of the task of learning a new set of skills and developing a different mindset. I’m grateful for having more insight into how I may have inadvertently been creating the conditions that I didn’t want. I’ve been able to try out some new skills in a few low-key conversations recently and I’ve been practicing watching for moments where I get ‘emotionally hooked’ and trying to work out what caused it. These experiences have been very rewarding.
I’ve also noticed that I’m less angry when I see others acting in a unilaterally controlling way (getting angry or punishing people for acting the same way I frequently/mostly do isn’t fair). My mindset is shifting from an evangelical one (Argyris’ model is great! Everyone needs it! I need to go out and evangelise!) to more of a reflective one (I really like it, and find it useful myself so I’m going to use it and model it. I’d like more opportunities to practice it. I’d welcome talking to others, if they are interested). And mostly, I’m still struggling. I’d like to be better sooner, with less effort and fewer embarrassing failures and I’m aware of the paradox that those expectations are probably making is slower and harder!.
I’d welcome comments, feedback or questions. If you’d like to go through a case study, please contact me.
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
