A Commonplace

What is a commonplace?



I've been thinking about Behaviourist approaches to Agile transformation - and wondering why nobody has said much about this before. A few things to consider:

By sheer luck I ended up sitting on an aeroplane next to a very intense young man who was reading a book about behaviourism. And it lead me to read this book by Aubrey Daniels and to start to think about something called "Operant Conditioning" and how it might be working on the kinds of projects that we call "Agile Transformations."

In operant conditioning there are four ways to get your subjects (normally these subjects were laboratory animals) - to learn.

Positive reinforcement: When the subject behaves in a certain way, that behaviour is rewarded with a positive stimulus - this makes this behaviour much more likely (food, a thank you note, praise).

Negative reinforcement: When the subject behaves in a certain way, that behaviour is rewarded by the ceasing of an unpleasant stimulus - this makes the behaviour more likely (a loud noise stops, the shouting stops, emails copied in to senior management in CAPITAL LETTERS cease).

Positive punishment: When the subject behaves in a certain way they receive a negative stimulus, making that behaviour less likely (a telling off, a loud noise, an electric shock).

Negative punishment: When the subject behaves in a certain way they a positive stimulus is taken away (no food, no praise, no heating).

When I started to think about this, I began to realise that most of the teams that I work are simply desperate to avoid punishment. This is why the members of those teams want you to tell them exactly what to do. If they're doing exactly what they're told, there's much less chance of them being punished.

This is also why members of the teams that you're working with look at you with a look of pure terror when you tell them that now they're a self-organising team and they should address any problems they encounter themselves as a team. That's what you say, what they hear is:

**From now on, you're on your own. We're not going to tell you what to do - which means there's a reasonable chance you might get punished for anything you do.

Operant conditioning also explains why so many managers behave so appallingly on Agile projects and why they obsess with burn downs. Managers have their own punishment structure - maybe we can't see it if we're working with a development team - but it's there. So they want to avoid punishment. Also, if they get positive reinforcement for certain behaviours - shouting at developers makes them seem to work harder, standing over them while they work makes it seem like software is getting done on time, they will do those things more.

So what is an Agile Coach to do? It starts to become clear what an Agile coach's role is once you think about working with software development teams in terms of conditioning.

In contrast "Agile Training" which in behaviourist terms is whole bunch of stimulus in response to no behaviour at all, isn't really training. The challenge there is to elicit the right kinds of behaviours in the hope that they will then transfer to the work setting (not much of a hope) or maybe, simply build the case for an Agile coach. Who might have a better chance of being successful, now he's at least got an idea of what he's supposed to be doing.