Lean Thinking

Written by Published in Agile

Faster, Better, Cheaper. That's the way agile is usually sold. Faster delivery, with better quality and lower cost. That's the pitch I hear over and over from people trying to get organisations on board with agile. It's an attractive pitch too. Who wouldn't want something faster, better and cheaper? The only problem with the pitch is that it's not really true. Not initially anyway. Agility will eventually get an organisation delivering faster, better and cheaper but, at least initially, it will be slower and more expensive (it will usually be better quality though). It may well stay slower and more expensive for a long time if the organisation has to overcome a lot of legacy (not just code but culture and processes as well).

So when the organisation goes to measure its new agile initiative and finds that it's not getting what it was sold, questions get asked. And well they should. The first is usually "Why?", to which the standard answer is "cultural change is hard....", the next is usually "When?", to which the answer is usually a shrug and some more about how hard cultural change is. This is often the point where the senior leaders that were really keen on agile, suddenly stop being keen on agile and organisational support vanishes. Given the length of time it takes a big organisation to get to faster, better, cheaper with agile, we really do ourselves no favours by using that as our selling point. What we need is something we can have an immediate (or at least relatively quick) impact on, that is also going to have a positive impact on the business. Fortunately it exists - risk. Agility should be sold as a means of reducing risk.

Written by 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.

Written by Published in Lean

So last time I talked about large companies and some of the reasons why they make sub-optimal decisions. Not bad decisions, but ones that aren't as good as they could be. The main reason for sub-optimisation was centralisation of decision making and the main reason for centralisation was the need for control. In particular the control on spending money. With no central control of funding, anyone could spend a bunch of company money and the company would soon be broke.

If decentralised decisions are more optimal because the person making them has more information than someone further from the coal face, but centralisation is required for spend control, what are large companies to do? Are they doomed to make sub-optimal decisions forever? Fortunately, no. There are ways of maintaining centralised control of spend while allowing decentralised decision making about where to spend money. There are, in fact, many ways to do this and we will look at one of them now. I'm calling it outcome based funding; I'm sure the financial folks have a fancy, official name for it, but outcome based funding will do for now.

Written by Published in Lean

Everyone who has ever worked for a large company knows that they make really silly decisions. Completely illogical decisions. Decisions so monumentally ridiculous that you wonder how the company actually manages to survive as a going concern, let alone turn a profit. It's seemingly obvious to everyone in the organisation, except the senior executives who are making the decisions. Good projects aren't funded, bad ones are. Good teams or departments are restructured but poorly performing ones aren't. Opportunities are lost. How do they continue to make money with all these bad decisions? And why do smart executives continue to make them?

The answer of course is that big companies very seldom make truly bad decisions. What they make are a lot of very sub-optimal decisions. Decisions made are seldom illogical, there is a lot of reasoning that goes into them. Unfortunately, that logic and reasoning is based on very poor information. The decisions they make are good enough to stay in business and continue to make significant amounts of money. They just aren't the best decisions possible. The real question isn't "how can companies still make money while making poor decisions" but "how much more money could they make if they made better decisions". Looking at the reasons why companies make sub-optimal decisions can point us to ways to make better ones.

Calendar

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