If your process doesn’t change, you’re doing it wrong
By: Mark Ridley
Tags: Agile, Process Improvement, Management, Software Development

Photo by Waldemar Brandt on Unsplash

I’ve recently been reading Creativity, Inc, Ed Catmull’s description of the history of culture and processes at Pixar. Pixar’s journey, from a 3D rendering startup to its current place at the centre of the Disney empire has been influenced by luminaries like George Lucas and Steve Jobs, and more so by the incredible talents of those that have lived and worked within the company.

One particular piece stood out to me in Ed’s writing, early in the book. As it happened, I had just been having a number of conversations about people’s experiences with frustrating, static process that they felt unable to change.

Ed describes two early Pixar aphorisms — “Story is King” and “Trust the process”. It’s this latter I want to focus on. Ed describes the painful (nearly straight to video) birth of Toy Story 2 and the tortuous journey that the project went through. In particular, the process that had worked so well on their previous films was failing them. As Catmull puts it;

“Trust the process” had morphed into “Assume the process will fix things for us”. It gave us solace, which we felt we needed. But it also coaxed us into letting our guard down and, in the end, made us passive. Even worse, it made us sloppy.”

Most people will be familiar with the pain Ed is describing. In software development teams, process is everything. We enter into religious arguments over Waterfall vs Agile, PRINCE2 vs SAFe, Scrum vs Kanban. These arguments can rage from the very top levels of the organisation, demanding programme and portfolio governance, right down to the newest team members joining a squad. All too often, we forget that the process — as important as it is — should represent the current best known way of delivering value.

One of the most thought provoking experiences of my professional life was a day spent at the Toyota factory in Burnaston, near Derby in the heart of England. In a plant where an Avensis or Auris comes off the production line every 63 seconds, Toyota workers are shaving tenths of seconds from the processes that they use to build the cars. They do this without computers, without project managers but, instead, with the skill and insight of the people actually doing the work.

For Toyota’s production line the process is beyond critical. Without absolute repeatability, each of the hundred or so manned workstations would fail to perform their part of the build process in the required 63 seconds — every worker must complete their piece of the build in less time than it takes for the car to roll off the end of the production line. If any station stalls, the line stops and alarms sound across the factory. The line, very simply, must not stop.

Why then, in an environment where tenths of seconds matter and process is to be painstakingly followed, do we look to Toyota for an example of process change? Because Toyota workers are taught — even indoctrinated — with the spirit of ‘kaizen’, or change for the better.

Let me give you one real example from Burnaston. Imagine in front of you a car door, with the window down. Looking at the metal frame of the window, you’ll notice a rubber surround running all the way around the frame, there in part to prevent you garrotting yourself when picking up drive-thru burgers.

The workers fitting this rubber surround follow a process, repeated hundreds of times in a shift. The car door arrives in front of the worker, the rubber part arrives next to them, the worker installs the rubber around the doorframe and then pokes their head through the window to check from the outside that the seal is seated correctly. When this is complete, all within those 63 seconds, the door moves on to the next station for the next part of the process.

But, this isn’t the process we saw when we visited the factory. The worker we watched didn’t poke his head through the window. Instead, he flicked his eyes to a strip of mirror that had been strategically placed on the far side of the door to reflect the exterior. No more head poking, a second or two saved off the process, and importantly for Toyota’s health and safety, a potential repetitive strain hazard removed.

And where did this improvement to the process come from? Naturally a smart, creative factory worker, who realised that by looking in a well positioned mirror he could save himself, and his fellow workers, the task of clambering part way through the window.

We heard many stories like these — household vacuum cleaners being strapped to industrial robots, less fuel being put into cars to drive them off the line, new recruits suggesting improvements to tool storage based on their previous careers as butchers— each a process change that made the company more efficient.

Trust the process? Absolutely, but only until a better way is invented.

The ideal is that every company works like this, with employees always able to suggest and enact improvements. Maybe some companies manage this, but I’ve seen too many processes tolerated whilst someone in the company vociferously complains about them.

In one example, I was looking to improve a customer experience function — I had gone, in Toyota terms, to the Gemba, the place where the work is done. It was clear that the teams doing the work were passionate, committed and overworked. Just sitting with them for an hour was an enlightening experience, hearing about the work they did and the daily frustrations they had.

What stays with me from this visit was the experience of a young apprentice. Smart, outspoken and only working the job for a couple of months, she would keep half an ear on the conversation I was having with her team lead and occasionally pipe up with a complaint or piece of advice. Almost every time, she told us something insightful and valuable, and yet these nuggets of wisdom were not yet enshrined in the process. I asked the apprentice if she had been trained on the processes she was following. As quick as a flash she replied, “Yeah, but as soon as we’re out of training we stop doing it like that. We all know the better way of doing it”.

So the process had been informally improved by word of mouth amongst a few workers, but the trivial step of updating the ‘process’ — changing the training guides and updating managers — was missing.

This is the critical competence that most companies are missing. We talk about autonomy as if it’s something that can be achieved just by committing to the ideal in a management meeting. But real autonomy is a slippery eel of a thing, that must be lived and re-enacted regularly. In this case, the team knew the answers, but felt the process wasn’t theirs to improve.

In other teams, I’ve heard of significant problems from following processes that are almost entirely mythical — “Our backlog refinement takes half a day, but we have to do it because Scrum says so”.

Often our processes exist simply because they have been there longer than we have. Sometimes they were introduced to solve a specific problem, or someone senior in the organisation felt that a process was needed. It’s critical that we remain conscious and aware of the processes we follow, and are allowed the opportunity to question and challenge their existence and appropriateness.

Later in Creativity, Inc, Ed describes an ambition to change the film production process to make it leaner and more efficient whilst making Finding Nemo. But Ed admits that this had almost risked the quality of the film, and muses;

“Making the process better, easier, and cheaper is an important aspiration, something we continually work on — but it is not the goal. Making something great is the goal”

The golden rule of process change is experimentation. It would be a terrible shame to replace one process with another, with no data to indicate the new process is in some way superior. Wherever possible, we should allow teams to propose their own changes, encourage them to set up an assumption to test that their proposed new process is better than the one it replaces. If we can experiment, analyse and prove the benefits of a new process over an old one, we should be more confident that the change is a good one.

But let’s remind ourselves why we have processes at all — they should represent the current state of the art in completing a task to an appropriate quality and as efficiently as possible. They are a valuable tool in ensuring consistency, in training people to do their jobs, and in ensuring the correct flow of value between teams. Processes, rather than being bureaucratic red tape, are the best way we know how to do a job.

When you’re following a process, by all means trust it. But as soon as you are able, change it for the better.