Lean Thinking

Tuesday, 28 April 2015 18:24

Outcome Based Funding

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.

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.

Tuesday, 31 March 2015 12:05

Too Big To Fail

Published in Lean

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.

Tuesday, 17 February 2015 00:00

The Measurement Fallacy

Published in Agile

As soon as someone starts looking at the topic of metrics, the measurement fallacy pricks up its ears (I always imagine it looking somewhat rodent-like with mangy fur, evil eyes and sharp teeth) and gets ready to emerge from its hole behind the database server. When people start discussing what should be measured in order to keep track of a process, it gets ready to strike. Most people have fallen prey to it at one point or other. Mostly without ever knowing they have been bitten. The bite is painless. The only symptom is that the bitten suddenly assumes that because we can measure something, it must be important. More serious cases assume that the easier something is to measure, the more important it must be. This dreadful scourge is responsible for making Lines Of Code the primary measure of developer output for years.

It's a typical case of a severe bite - we can measure lines of code. Therefore it must be an important measurement. It's really easy to measure so it must be a really important measurement. Therefore we must measure it and use it to drive developer behaviour. Once it sets in, it's hard to shift. Despite the fact that the behaviour it drove - writing masses of wordy code to inflate your LOC counts and never, ever remove code - was completely counterproductive, the LOC (or KLOC) still hangs around to this day.

Wednesday, 11 June 2014 00:00

Estimation Part 7 - Recap

Published in Agile

Over the last 6 posts, I have been looking at estimation. First, we looked at why we estimate, then we looked at some of the pitfalls in traditional estimation methods - the way we mistake accuracy for precision. Then we looked at some of the Agile estimation techniques - story points and T-Shirt sizes and the way they are designed to overcome the accuracy vs precision problem. We saw that while they generally do a good job, they also have some fairly serious pitfalls of their own. In the last two posts, we looked at taking T-Shirt sizing one step further and allowing only two sizes - small and extra-large (too big). By doing this we saw how the main pitfalls in the agile estimation techniques were overcome. We also looked at some of the main objections to story counting and my arguments on how these objections can be overcome.

I'm not the only person to come up with this technique. It's doing the rounds at the moment under the name "No Estimation Movement". Apparently I'm part of a movement. Cool.

Calendar

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