Lean Thinking

Written by Published in Agile

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.

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.

29 May 2018

The Urgency Trap

Written by Published in Agile

Continuing on with our series on common traps that organisations can fall into, it's time to look at the Urgency Trap. What's that? It's a particularly common trap and unlike most of the other traps where agile techniques tend to help avoid them, the urgency trap is one that agile teams can fall into even more easily than traditional teams. It's also a particularly dangerous trap because it can lead otherwise great teams into other traps, like the rebuild trap we looked at last time.

But what is it? Take a look at your current backlog. Now take a look at your team's long term goal. How much stuff at the top of the backlog is stuff that is strategic and aligned to your long term goal. How much is stuff that's short term, tactical and is at the top of the backlog, not because it gets you closer to your goal but because it's urgent? That bug fix. That urgent tweak to a feature that someone demanded. That urgent update to the terms and conditions because someone in legal found a problem. What's the ratio? More than 50% long term and strategic? Trend is steady? You are probably OK. Less than 50%? Percentage of urgent work is creeping up and displacing more and more strategic work? Welcome to the urgency trap.

15 May 2018

The Rebuild Trap

Written by Published in Agile

Another post in my series about common traps that organisations can get themselves into. This week we will look at a really common one. I think I have seen this in one form or another at every organisation I have ever worked for. It's really easy to get into. Once you are in it, it's really hard to get out of. But fortunately, once you know what you are looking for it is really easy to avoid. It's the rebuild trap.

It works this way - the product or process you are working in is becoming old and inefficient. The code base is old and riddled with tech debt. Technologies have gone out of date. It's becoming slower and slower (and more and more expensive) to add new features or other changes. Finally the organisation throws up its hands and announces that the system will be re-built. Everyone cheers. Out with the old, in with the new. A team is stood up. Everyone fights to be on the sexy new rebuild team rather than the boring old legacy maintenance team. Work begins and...never ends. The new system never gets delivered. The old one never gets replaced. Large amounts of money are spent with no result. The other possible outcome is that the new system eventually gets delivered, very late and with vastly less functionality than the one it replaces. What went wrong?

Written by Published in Agile

I have been looking recently at some of the common traps organisations can get into. Today it's time for the efficiency trap. "Hang on", I hear you say. "What's wrong with efficiency? Efficiency is a good thing...right?" Well, yes, but exactly what are you efficient at? Are you efficient at delivering things or efficient at achieving business goals? "But wait?" you say. "Aren't they the same thing? Don't we achieve business goals by delivering things?"

The answer there is "not always". It's really easy to deliver things that don't actually deliver business outcomes. Features that no one uses. Products that don't sell. Or at a smaller scale, designs that never get implemented. Business cases that never get funded, and so on. This is where the efficiency trap gets us. We fall into the trap of thinking that the more stuff we produce, the better. We mistake efficiency at producing outputs with efficiency at producing outcomes.

Calendar

« August 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 31