Lean Thinking

Written by Published in Agile

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

Written by Published in Agile

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.

Written by Published in Agile

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?

12 June 2018

The Cost Trap

Written by Published in Agile

Time to close out our series on common traps with a look at probably the most common trap organisations fall into. I don't think I have ever worked for an organisation that wasn't caught to some extent in this trap. What I'm talking about today is the cost trap. You get into this trap by having the wrong sort of conversations - conversations about cost. "How much will this cost?" That question has lead most organisations astray. Why is that? Surely how much it costs is an important question. And indeed it is. The problem occurs when that's the only question you ask. Cost is important, but there is something else you need in order to make a good decision. There is half the information missing. That other half is value. "What will I get in return?"

Let me put it this way, if I were to ask you "would you rather I took $10 from you or $50?" I suspect most of you would chose $10 (and for those who wouldn't, you are very generous, please leave your name in the comments below...). If, on the other hand, I asked "Would you rather I took $10 and gave you back $50 or took $50 and gave you back $500?" I'm guessing most of you would pick the $50. Just focusing on the cost would drastically lower your return. But this is what most organisations do. To be fair, most organisations do consider value, particularly at the top levels of the organisation. Every idea starts with a cost/value decision. ROI is a key consideration. But as work moves down the organisation, the discussion starts to become less and less about value and more and more about cost. The point at which the organisation falls into the cost trap is the point where the value part of the discussion vanishes and the discussion becomes entirely about cost. Often, this is where an idea becomes a project and is handed over for delivery.

Calendar

« 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