Lean Thinking

Dave Martin  

Dave Martin

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.

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.

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.

31 March 2015

Too Big To Fail

Published in Lean 1 comment

The project is huge. It's been running for years. It's late. It's getting later every day. No-one can remember why the project started in the first place. No one is sure why we are still pushing ahead, but the project refuses to die. Money is thrown at it. The project team becomes larger and larger. It becomes harder and harder to get any other projects funded because MegaProject is sucking up all the available money and people. The project has become Too Big To Fail.

We've all seen something like this at one point or another (preferably from a long way away) - a huge project, lumbering on year after year, never delivering anything but consuming every part of the organisation it touches. Everything is diverted into making sure this project doesn't fail. Those on the outside (and many on the inside) wonder why the decision isn't made to kill it off. The original business case has long since evaporated. The project will never deliver the benefits it was supposed to. Why doesn't management pull the pin? The answer is simple - the organisation has fallen prey to the sunk cost fallacy, also known as the gambler's fallacy.

I am working with a team that has a great VMB. It's the first thing people say when they walk past and see a stand-up in progress - "what a fantastic VMB" they say. And it is indeed fantastic. It represents the team's work really well. It's clear and easy to understand. It shows obstacles and what the team is doing to overcome them. It really assists the team in their stand-ups. It facilitates discussions between the team and its stakeholders.

The next question people invariably ask is -"can we set up our board like that?" Of course they can. The VMB design isn't proprietary to the team. Anyone can use it. So they do. Copies of this fantastic board are springing up everywhere, but pretty soon they come back and say "there's something wrong. Our stand-ups don't flow as well as yours and the board just doesn't work. Have we copied something wrong?" Yes they have. They have copied the wrong thing entirely. The thing they haven't realized is that my team's fantastic board, and the fantastic stand-ups and discussions it facilitates, has nothing at all to do with the layout of the board, and everything to do with the performance of the team.

Calendar

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