Lean Thinking

Dave Martin  

Dave Martin

21 August 2018

Rigidity = Fragility

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

Published in Agile 1 comment

Vampires are lame. There it is, standing at your front door, cape, fangs, the full works. You have opened the door, it's looking at you, getting hungrier and hungrier. It's starting to drool. You are looking at it from inside. Giving it the finger. Perfectly safe. Why? Because according to the stories, vampires need permission to enter. You are perfectly safe as long as you don't say "please come in". Of course if they catch you out in the open later without a front door to give you protection, you might just regret giving them that finger.

So why am I telling you this? Because coaches have something in common with vampires. Capes? No. Because we descend on organisations and suck them dry? No. It's because we also need permission before we can do what we are there to do. We need permission to coach. But surely, I hear you say, you have permission. After all, you have been hired to coach, therefore you have permission to do so. Sadly, it's not that simple. What we usually have is permission to be there, not permission to coach.

Last time we looked at refactoring. How real refactoring isn't re-writing big chunks of legacy code, it's cleaning as you go. Making sure the code you write now is clean. But what do you do about those big lumps of legacy? They weren't written with "clean" in mind, they were written with "hack it together to meet the date" in mind instead. It's messy and it's slowing you down. What do we do about it?

Well, we need to refactor it. But how, if we can't spend the whole sprint rewriting a big chunk of it? We need to stop thinking big - think small instead. Use the Boy Scout Principle - leave the camp ground cleaner than when you found it. When scouts leave a camp ground, they spend a few minutes cleaning up. Not just their rubbish but anything else they can find left by previous campers. And crucially, they don't try to clean up the whole forest, or even the whole camp-site - that would take weeks - they just clean up the area they were using.

10 July 2018

Clean = Fast

Whenever I mention refactoring in an organisation, I usually get the same response - "Yes, we know it's important, but we don't have time. We need to move fast. We can't afford to go back and keep tweaking things, we have to keep moving forwards". On the surface that's a reasonable sounding argument. It doesn't matter whether your organisation is big or small, established or startup, the imperative is to move fast. Get things done. Those customers won't wait, you either give them what they want now or someone else will. In an environment like that, who has time for refactoring?

I'd like to challenge that thinking. Not the bit about having to move fast, that's a given these days. No, the bit I want to challenge is the bit about refactoring being incompatible with being fast. To me, refactoring is not an impediment to being fast, it's an enabler. I think the view that refactoring slows you down stems from a serious misinterpretation of what refactoring is.

I have had quite a few comments over the years that I have been running this blog along the lines of - "OMG! Wall of text" or "What's the takeout here?" or "Why don't you make this an easy to read list? " or "Can you summarise into a few bullet points? " or just the basic "TL:DR". This worries me a bit. Not just because people aren't reading my stuff, but because I think this points to a much deeper problem. I think this points to the reason people and organisations find it so hard to change.

My posts are always between 800 and 1200 words. That's not exactly a wall of text. If you print it out, it's about a page and a half. The reading time is about 5-10 minutes. Maybe 15 if I really make you think. That's not a large amount of time. But yet many of us feel unable to invest that amount of time to read something. If it's hard to find time to read a short blog post, what about longer format work? An essay? A book? 200 pages? 50,000 words? I know a lot of people who tell me that they barely have time to read tweets these days. What does this say about our capacity to absorb and process new information?

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