Lean Thinking

Tuesday, 21 August 2018 15:51

Rigidity = Fragility

Published in Agile

"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.

Tuesday, 12 May 2015 16:52

Legacy Is Anything Without Feedback

Published in Agile

This post is the result of a conversation I had the other day, over a few after-work beers with Andrew Knevitt. He deserves a large part of the credit (and/or blame) for this for starting the ball rolling. Andrew was bemoaning the amount of legacy he had to deal with and I immediately started talking about code and automated testing. This wasn't what Andrew was referring to though. He was working mostly with business process and was referring to the problem of legacy business process. We all know the problems of legacy code - hard to maintain, fragile, lots of manual testing required. Legacy business processes have similar problems - clumsy, fragile, constantly out of date, lots of manual work required, and so on.

We both agreed that legacy process was a problem but neither of us could come up with a good explanation of what made a business process legacy. It's more than age - some old processes work really well but some brand new ones are out of date as soon as the ink is dry. So what makes a business process legacy? During the course of the discussion, I trotted out one of the more common definitions of legacy code - legacy code is any code written without automated tests. That was when the lightbulb went on for both of us. Legacy business process is any business process without a built-in feedback loop. But not just any feedback loop. A 2 yearly process review cycle isn't enough. It has to be fast feedback.


« September 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