Normalisation of deviance
James Aylett, Wednesday 16th March, 2016
If you’re using an agile approach to manage your project, you’ll have adopted a number of principles which guide the way you work. One of these is that the process itself (along with tools and other working practices) can be changed by the team:
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Typically this is done during team retrospectives, driven either by impediments the team has encountered, or opportunities to improve, which are often identified by ideas from outside the team.
Successive process changes can take a team away from the workable zone of practices. Worse, because of a concept called normalisation of deviance, the team may not even be aware when this has happened: unless something is called out consistently, over time a team may become so accustomed to something that they no longer consider it to be a deviance.
However, because in general it’s impossible to predict the best way for a team to work — and because that may in any case change over the lifetime of a project — it is important to be able to explore changes to process with confidence. There are a couple of techniques you can use here.
Retrospective lookbacks
In your team retrospective, look back at the retrospective notes from a few retrospectives ago; two or three is a good distance. You can then review both the changes you made then, and the reasons for them. This gives the team a clear opportunity to ‘self correct’ a detail of their process which is no longer appropriate (and perhaps never was).
Note that some people recommend that the only documentation you keep of retrospectives is the outcomes: the changes you want to make going forward. If you do this, you’re throwing away the ‘documentation’ behind that change, which makes fully evaluating your process in future much harder. If we don’t accept zero documentation for our code choices, we shouldn’t accept zero documentation for our process choices.
Get an outside view
As much as review of how and why you got to your current process may help teams to identify problems, it doesn’t directly attack the issue of normalisation of deviance. For this, it’s a good idea to get someone from outside the team to review where you are. Their fresh perspective can help highlight problems, and help to identify deviance.
It’s increasingly common for companies to arrange ‘field trips’, where teams from different companies spend time learning from each other, and this can be a good source of the input needed. Alternatively, consultants with experience of a range of different companies and their processes can provide not only an outside view but also ideas and possible solutions from across the industry.
It’s important to remember that having a process detail that isn’t working is not a failure of anybody. Even if it never served the team well, it may have been an entirely reasonable thing to try. What’s important is identifying and changing them rather than letting them continue to damage the team.