Lean Thinking

21 August 2018

Rigidity = Fragility

Written by  Published in Agile
Rate this item
(0 votes)

"We need to harden this process...make it more robust. Too many things are slipping through the cracks". How many times have you heard statements like that? Things that don't fit the process take extra time to resolve, so we make sure that the process covers as much as possible. As issues arise, we tighten the process still further. Spell out the entry criteria. Map the process steps in great detail. The problem is, of course, that no matter how much detail we have in the process, things still don't always fit so we document and harden even more.

We create processes and because we are humans working with incomplete information, there are gaps. Our natural instinct then is to fill in the gaps. Tighten the process. Specify, document, enforce. The problem is that this simply doesn't work. The real world conspires against us. Customers don't always want the standard product. You may have a carefully documented 30 day SLA but that doesn't help a bit when a key customer rings up and says "We know it's usually 30 days but we really need it in 10, can you please help? If not, your competitor has said they can do it in 10 days." You may only sell in lots of 100 but what happens if a good customer rings up and asks for an extra 35 because they have had a spike in sales but don't have the space to store another full hundred? The more rigid we make our processes the more often they break down.

Rigid processes are fragile. They are brittle. They are prone to sudden breakage and when they break, they break down completely. Rigidity = fragility. As soon as a rigid process encounters an edge case - something that falls outside the usual - it breaks catastrophically. No one knows what to do. The process gives no guidance. People run around doing things in a mad panic until the edge case is resolved.

We can try to prevent edge cases but we will fail. Even pure manufacturing processes, with automated assembly lines and everything specified to fractions of the millimetre, still have to deal with edge cases. What happens when the parts tray the robot is expecting turns up empty? What happens if the screw shears off while driving it, due to a flaw in the metal? What happens when the welder suffers a fault? When the gas pipe blocks? When the hydraulic line bursts?

We can never specify away all edge cases. The more we try, the more rigid and therefore fragile our processes will become. What we need instead is flexibility. Flexible processes are strong and resilient. They bend when edge cases happen, rather than breaking catastrophically. They have some give to them.

So how do we build flexible processes? Well, we start the way we always do - by documenting the process. The regular process. The happy path that we know will happen most of the time. Then, when something happens that falls outside that happy path, don't make the process more rigid to design out the edge case. Instead start building in flexibility to accommodate the edge case. A customer asks for an expedited order. Don't respond with a firmly worded email spelling out the standard SLA, instead look at whether an "expedite" state could be added to the process with WIP limiting used to stop it being abused.

Process steps not being followed all the time? Don't respond by documenting them to the nth degree and putting some kind of process police in place to make sure each and every one gets followed. Look at why they aren't being followed. Are they inefficient? Are they inappropriate? Has the process hit its use by date? Are there better ways of doing the same thing? Give people expected outcomes and let them define their own detailed process steps.

What happens in the case of an error? People make mistakes. We can try to design errors out of the process but we will fail. Instead, design in graceful failure modes. Customer order gets lost. Have someone contact them, apologise, ask them to resubmit and expedite the new order. Machine breaks down. Have a spare standing by or have a maintenance crew on standby.

Processes left to their own devices tend to become more rigid and inflexible over time. That's just the way they work. If no one looks after them, they begin to decay. They become inflexible because no one is building in flexibility. They become out of date because no one is making sure they are still relevant.

Above and beyond everything else, build in the ability for the process to change itself. Build in feedback mechanisms, regular reviews, or (even better) a continuous improvement mechanism. Let the process evolve and change. That way it stays flexible. A process without feedback will become more rigid over time. It will also become more out of date over time. A rigid, out of date process is bound to break catastrophically, and probably sooner rather than later. Feedback allows a process to stay flexible.

Respond to process failures by building in flexibility rather than more rigidity. Flexibility means strength. Your processes will respond to edge cases by bending rather than breaking.

Leave a comment

We reserve the right to modify or remove comments that we deem to be offensive.

Make sure you enter the (*) required information where indicated. HTML code is not allowed.

You need to complete the Captcha in order to submit, but sometimes it doesn't load properly. You will need to refresh the page until it does and unfortunately that will clear anything that you have already entered. If you've already written a comment, please copy it first, then paste it into the comment field when the Captcha has loaded correctly.

Calendar

« November 2018 »
Mon Tue Wed Thu Fri Sat Sun
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30