Keeping with the numerical and financial theme of the last couple of blogs I want to turn my attention to improvement and how really small improvements add up and can justify big spending. This also turns out to be the case for continual improvement and continual delivery…
How would you like it if I promised to improve your team by 1%? – I’m sure I can!
How much difference would it make if your team were 1% more productive?
Not a lot I guess.
More importantly, you’re going to have trouble making that sale to the powers that be.
You: Boss, I’d like to hire Allan Kelly as consultant for a few days to advise the team on how to improve.
Boss: How much do you expect them to improve?
You: He guarantees a 1% improvement or your money back
Boss: One Percent? 1%? Just 1%? Whats he charging $10?
No, thats not going to work is it.
People who hold the money like to see big numbers. The problem is, if the numbers are too big they become unbelievable. Those in authority want to see a significant improvement but the bigger the numbers are then the more evidence they want to see that the improvement is achievable. And when the number are big they need to be proven and that can slow everything down.
On the other hand, there are stories of teams winning (and I do mean winning) by focusing on 1% improvements. At Pipeline conference last year John Clapham talked about how the UK cycling team worked on 1% improvements. And I’ve heard several stories about Formula-1 racing teams who work hard to get 1% improvement. After all, Formula-1 racing cars are already pretty fast so getting 1% is pretty hard.
So what is it about 1%?
Surely 10% is better?
The thing is, 10% is going to be better but getting 10% is hard. Getting 1% can be hard enough, getting 10% can be 100 times harder. Even finding the things that deliver 10% improvement can be hard. On the other hand, for the typical software team, there are usually a bunch of 1% improvements to be had easily.
The trick with 1% is to get 1% again and again and again…
The trick with 1% improvement is… iteration: to get 1% improvement on a regular basis and then allow the effects of compound interest to work their magic.
The size of the improvement is less important than the frequency of the improvement. Taking “easy wins” and “low hanging fruit” makes sense because it gets you improving. Sure 10% may make a much bigger difference but you have to find the 10% improvement, you have to persuade people to go for it, you probably have to mobilize resources to get it and so on.
1% should be far easier.
Suppose you can get 1% improvement each week. Over a year that isn’t just more than 50% improvement it is well over 60% improvement – because each 1% is 1% of something bigger than the the previous 1%. Therefore a 1% improvement in week 50 is actually equivalent to 1.6% improvement in week 1.
Here is another spreadsheet where I’ve modelled this.
Suppose you have a team of 5. Suppose the cost $100,000 each per year, thats $500,000 for the team or $10,000 per week (to keep the numbers simple I’m calculating with a 50 week year.)
Now, suppose the team make a 10% value add, i.e. they add 10% more value then they cost, so each year they generate $550,000 of value. That is $11,000 per week.
Next, assume they improve productivity 1% per week. In week one they improve by $110, not much.
Week two they improve by $111, week three $112 and so on.
At this point you are probably thinking: why bother? – even in week 49 the team only add $177 to their total in week 48.
But… these improvements are cumulative. In the last week the team are delivering $6,912 more value than week one: $17,912 of value rather than $11,000. The total annual value added $159,095. That is $11,110 in week one, $11,221 in week two, …. $17,912 in week 47, $17,734 in week 48 and $17,559 in week 49.
The team are now delivering $709,095 value add per year – a 29% increase!
Put it another way: $159,095 is $31,819 per person per year, or $3,181 per week on average, and $636 per person per week.
At first glance this seems crazy: the team are adding 1% extra value per week, even in the last week they only add $177 of extra value compared to the previous week. But taken together over the year the power of accumulation means they are adding over $3,000 per week.
Go back to the start of this piece: you want to convince a budget holder. $177 isn’t even worth their time to talk about it but $3,181is.
Want to buy a book for everyone on the team? $30 per book is $150, do it.
A two hour retrospective? Thats 10 working hours for the whole team, about $2,200, well worth it.
Want to send someone to a 2-day conference, say, $1,000 for a ticket and $4,000 for lost productivity, $5,000 in total. If they come back with one 1% improvement idea then the conference pays for itself in one and a half weeks.
Suppose you invite a speaker from the conference to give a lunch and learn session. Say $1,000 for the speaker and $50 for pizza. If they give the team a 1% idea then it pays for itself that day.
Like it so much you buy a 2-day course? Now your talking big money. Although the $10,000 for the speaker is still less than the cost of having people not work. Five people each on a two day course means 10 days, $20,000 so $30,000 in total. That will take nine and a half weeks of 1% improvements. But then, one might hope that such a course delivers a bit of a bigger boost.
(Is now a good time to plug the agile training I offer? – or is that too blatant a plug?)
The important thing is to make iterate quickly and keep getting 1%, 1%, 1%. There should’t be time for agonising “Is this the best thing we should do?” – “wouldn’t doing X give more improvement than Y?” – just do it! The other ideas will still be good next week.
And don’t worry if it goes wrong. Not every possible improvement will deliver 1%, some will probably go so wrong they damage performance. Just recognise such changes don’t work and quickly back them out.
When you do the numbers it all makes sense.
Now you can call me
| Published on Java Code Geeks with permission by Allan Kelly, partner at our JCG program. See the original article here: 1% improvement Opinions expressed by Java Code Geeks contributors are their own. |
