Agile – The Broken Learning Machine

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.