Three Steps Through the Thicket

Last week, I wrote about those horrible processes which still exist in most technology functions in most large enterprises - the release process, the production acceptance process, the onboarding process and so on. The process that everybody dreads, no-one seems to be accountable for, which we don’t seem to be able to change, and which stands between us and our code running in production. I suggested that the way to tackle such processes is not simply to optimise and streamline them: such ‘process gardening’ is a never ending battle against a thicket of thorns that grows back every day. Rather, it is to shift from a focus on process to a focus on trust and accountability.

I realise that’s a difficult thing to do. If everyone is telling you that the process stands between the company and catastrophe, then it takes a lot of courage to step away from it. It’s also rarely wise to abandon all of your process: you just want to get rid of those parts that add friction but not value. However, based on my own mistakes and the successes of others, I can offer three suggestions to get started.

Trust a team

It is likely that, somewhere in your organisation, you already have a team which is on the brink of breaking free of your worst processes. They have already adopted new ways of working. They have organised themselves as a cross-functional product team, including their business stakeholders. They have a high sense of ownership and pride in their work.

There is also a strong chance that they are perceived as noisy and irritating. They may be the most vocal in complaining about your processes, and the least tolerant of being overseen, blocked and delayed by people they believe know little about their work.

Maybe you should give them what they want.

At some point you need to pick a team to trust, and it might as well be the team that considers themselves most advanced and most ready to take extra accountability. By trusting a team and letting them lead the way for others, you also gather valuable data, because the next step is to . . .

Trust the data

Although moving away from established processes takes courage, we often don’t have reliable data about why we should be scared. We know (or at least should know) what our current performance is (release frequency, failed changes, incidents and so on), and may set goals to improve this performance. However, all this tells us is how good we are compared to what we have done historically: it does not tell us how good we could be if we worked differently. The performance of that first team gives us a much more interesting point of comparison.

Fortunately, we don’t just have to rely on the data collected from our initial trailblazer teams. Teams have been transforming and measuring their performance for a long time, and, through groups such as the DevOps Research and Assessment (DORA) team, we have years of survey based data. As shown in the fantastic book Accelerate, we can see how some mechanisms which we have relied on for years have the opposite results to those intended, once we have the data. The most striking example is the negative correlation between the involvement of a Change Advisory Board (CAB) in a release process and the speed, success and incident rate of that process.

Data sometimes gives us tough news. If, like me, you have spent time sitting on CABs (or other bodies such as Architecture Review Boards), believing that you were doing the right thing, then it is hard to learn that your time may have been wasted. But the point of collecting data is to help us get past our intuitions and perceive the truth.

However, there is one more step which is going to sound paradoxical . . .

Trust experience

Data may show us that some of our processes are wrong, but that doesn’t mean that everything they contain is worthless. As I wrote last week, these complex, slow processes are often archives of everything that has ever gone wrong. When implemented as checks and approvals, these slivers of corporate memory can rob teams of trust, diffuse accountability and slow things down. But this doesn’t mean that they are worthless.

I believe that we can get value from our horrible processes by mining them for wisdom. If we understand the original intent and history behind all those checks and approvals, we can figure out ways to make them useful to teams. We can build them into our knowledge base, convert them into tools, or build them into our automated tests. We can give teams the chance to act with thoughtfully on the basis of our shared experience, rather than simply trying to achieve compliance with approvals that lack context and purpose.

This article and last week’s are not attempting to argue that all process is bad. Good processes can become crystallised wisdom and help us all go faster, especially when we turn them into code. But we can only achieve this if we start from a position of trust and accountability.

(Views in this article are my own.)