In Commitment, Olav and I wrote that the “rational” order of preference is:

1. Right
2. Uncertain
3. Wrong

We also wrote that the observed preference for most people is:

1. Right
2. Wrong
3. Uncertain

People would prefer to be wrong than uncertain. We know this because they make commitments earlier than they should, and destroy options unnecessarily. A preference for uncertainty would result in more learning. A preference for learning would be an advantage within a “Community of Need”. An aversion to uncertainty is an advantage in a “Community of Solutions” as you can be more compelling and forceful in your argument about a solution. You can be more certain.

We learn something new when we perceive it has value for us.

It is stressful to be aware of things that are valuable that we do not know. If we crave certainty, we ignore the value of these things. We can express value using this formula:

We can considering this value in Kolb’s “Circle of Learning” ( a.k.a. Feature Injection’s “Break the Model” ).

“Spot the value” means we spot an observation, Ix ,such that the value Vx, calculated using our value model

V = F ( Io … In, Ix )

is different to the value observed. In effect, we have an arbitrage situation. The difference between the observed value and the calculated value are different. We should act accordingly, learning and applying the new idea.

This seems fairly straight forward. It becomes tricky because our value function F ( Io … In ) acts as a filter on our perception of reality. The more certain we are, the less likely we are to differences between two things that reveal a problem with our value function. The more we are comfortable with uncertainty, the more like we are to identify differences.

This is very important to understand the impact of uncertainty on learning. If we are certain, we will not notice the problems. Its not a case of we ignore then, we simply will not perceive them as important. In fact, its when we notice these observations that do not fit our model that we are at danger of shifting from “Obvious” where we are certain, to “Chaos” where we see lots of observations that do not fit our model and the model effectively collapses as it is no longer of use.

Knowledge Options

Learning new things takes a lot of effort. Twenty hours of concentrated practiced has been suggested as a minimum to become barely sufficient in a subject. More effort is required to become proficient and significant effort is required to master a subject. “Community of Solutions” value masters of a subject. They will often be proficient to a level where they can make a tool work even though it is not a natural fit for the context. People in a “Community of Needs” need to understand the value of an idea, the context in which it is best applied. They also need knowledge options. A knowledge option involves knowing the value of an idea and having an option to acquire proficiency in the skill within a certain timescale. You can learn more about knowledge options in the “The Lazy Learner” talk. The most powerful option is to be a member in many “Community of Needs” with access to practitioners who can guide and help you learn quickly.

Organisations hiring Agile Coaches should always hire people from the “Community of Needs”. Trainers can come from either community. If you hire a coach from the “Community of Solutions”, they will attempt to solve your problem with their favourite solution, regardless of whether it is the best solution. They will attempt to demonstrate it will work in all contexts, even if there is a better tool for some of those contexts.

And here in lies the tragedy of the situation. Organisations attempting an Agile Transformation are seeking certainty. Their value model does not allow they to value a coach using option thinking, i.e. how many knowledge options they have to  acquire skills to solve a problem. Instead they value coaches based on their expertise and their popularity. Until Organisations learn to value coaches properly, they will continue to suffer failures in their transformations.

In my last post, I introduced two types of community. Communities of Need centered around solving problems, and a Communities of Solutions centered around selling solutions. The nature of these communities drive different types of behaviour. Neither is good, and neither is bad. They are just different. Whether the behaviour is appropriate is all about context.

The Agile Community started out as a learning community. Members of the community were highly linked, able to call upon other members when they became stuck or wanted some expert opinion. I was lucky enough to attend Agile Development Conferences in 2003 and 2004. For me, the most exciting sessions were those in the Open Space. You could discuss your tropes (apparently meme is a bad word) and get the most amazing feedback. I remember being disappointed that my first session on Real Options only attracted about eight people ( how was I meant to know who Rebecca Wirfs Brock, Steve Freeman, Eric Evans were? ), however I received amazing feedback (funny that). At ADC, the whole conference closed down for Open Space. This forced everyone to attend, or go for a walk. I still follow the ideas raised in the project management session that came up with the idea of a behavioural coach. Open Space broke down the barriers so that people who were not experts in Agile could talk about subjects that they were experts in.

Credit has to go to Alistair Cockburn and Todd Little for creating an amazing conference in ADC. The goal was to have “Three days to start a conversation”. Building community was at the heart of the conference. To this end, they created the ice breaker as a means to break down barriers and get people to introduce each other. Agile2009 was the last conference I attended by choice ( Kent forced me to go in Agile2013 ). At Agile2009, the ice breaker was little more than a way of enticing attendees into the sponsor’s lair with the lure of a few free drinks. The big conferences need to be about building community as well as selling selling selling ideas.

Many of the Agile practices map to Kolb’s Circle of Learning. In particular, the retrospective that is at the heart of improvement for many Agile teams.

Like others I skipped Agile2005 but unlike others I was drawn back in for Agile2006 in Minneapolis. Open Space was relegated to a corner of the conference next to the canteen. Hidden behind the growing ghetto of sponsor’s booths. Already the problems I discuss below were evident. Bil Kleb and I co-hosted an open space session on “Learning, Cognition, and the Scientific Method”. I explained how the Agile Community could be mapped to Kolb’s Circle of Learning, and the behaviours that were detracting from the learning. Here is how community learning maps to Kolb:

1. Spot the Example: “Yo dude that was awesome, let me try!”
2. Model: “Lean forward yo!”
3. Test: “Cool dude!”, “Major face plant loser! You did it wrong!”
4. Reflect: “This work most of the time! Lets do it”

In the next cycle.

1. Spot the Example: “Lots of people are face planting the same way”
2. Model: “Lean forward except in powder, then lean back.”
3. Test: “I hope he face plants! Face plant! No!!!! He pulled it off, even in powder.”
4. Reflect: “Much better. Only a few face plants now. But they really hurt so lets look out for them.”

You can travel around Kolb’s loop forwards (as above) or backwards (Feature Injection’s “Break the Model”)

Even in 2006, the following behaviours were becoming evident that detract from the learning.

1. People were not joining the Agile community. They were reading books and turning up to just listen. They were not engaging.
2. Conferences were seen as a corporate jolly rather than a community “Gathering of the Tribes*”. Attendees stuck together rather than meet new people.
3. Consultants were keen to prevent their clients from meeting other rival consultants.
4. We had no way of capturing the fails. Those attempts that resulted in failure.
5. Gladwellism was rife.
6. People are doing it wrong became a trope.
7. Some thought leaders started to get angry at the mention of community. These are solutions to sell.

Agile was rapidly shifting from a “Community of Needs” to a “Community of Solutions”. We started to hear talk about “Crossing the Chasm” as the goal. This goal assumed you wanted to sell Agile, rather than you had a need to solve problems.

The worst problem was number 4.

Capturing the Fails

Between finding a solution and reaching the chasm, the uncertainty surrounding a Trope has to be resolved. This means that those working with the idea have to be on the look out for failure masked as success, and for failures that are occurring silently. Community of Solutions need this to cross the chasm, and members of the “Community of Need” want the failure stories to improve the idea so that it fits more contexts.

Consider the following scenario. I give a presentation on Real Options. One hundred people decide to try out real options. They have the following success:

• One group have huge success and come back to the next presentation where they tell everyone how great real options is.
• One group have moderate success. Enough to keep using it, but not enough to go to another presentation or tell their friends.
• One group has so so results. They use it when its obviously going to work but do not talk about it.
• One group has moderate failure. They tell their friends and family to avoid.
• One group has huge failures. The failures are hushed up, or converted into success stories that create a new generation of evangelists. This leads to even bigger failures later on.

Which group do we hear from? The “huge success” group of course. But why did the other groups fail? What was it about their context that caused real options to fail? We need to know this for two reasons. Firstly, we need to warn people when it will fail so that they can use it safely? Secondly, we need the failure stories so that we can improve real options for those contexts where it fails, and ultimately cover more contexts? ( An aside: At one conference someone introduced me to an interesting idea. I asked when it failed. “Never. It had not failed them in a decade”. Suffice to say I never tried it. Too risky if the failure states are not known. )

When we do encounter stories of failure, it is normally at a “Non-Agile” event. “We tried that”, says someone at an IIBA or PMI or XYZ event, “and it did not work”. We then work with them to analyse the situation so that we can show that they failed to apply real options correctly, rather than real options failed. In truth, If they applied real options incorrectly, it is a failure of real options most of the time. A failure to warn people what the failure states are.

The pressures in a Community of Solutions result in behaviours that work against the learning in a Community of Needs. After all, why would an expert in a subject admit that they are not the real expert, and the attendee on their course should speak to someone who does it, rather than someone who helps others do it.

So the Agile Community as a Learning Machine is broken. We need an effective feedback mechanism to capture failure stories. To harvest those stories where the context ate the trope.

This is the second post building up the content for my ALE2015 keynote.