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:
I worked with two teams just recently that were described by other people as being “beaten down.”
When you work with a new team, they always want to know what is “best practice”.
Common feedback on courses and workshops is that the material hasn’t been tailored to the specific circumstances of the particular project that the attendees are working on. When I first started, somebody made this very clear to me saying “I want you to tell me exactly what I can do to make sure my project doesn’t fail.”
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.
An Agile coach needs to encourage the right behaviours (i.e. provide positive reinforcement) from the team, when the team does do some self-organising, it should be encourage.
An Agile coach needs to ignore or actively inhibit bad behaviours either by the team or by management (they especially need to wean management off of the “I feel bad, I shout, everybody runs around and stays late, I feel good.”
Agile coaching is training, encouraging the behaviours you want to see, discouraging the behaviours you don’t want to see. This combined process of encouragement and discouragement is called “shaping” in the behaviourist literature.
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.