“The more social networks one joins the less one interacts with any one social network”
Please don’t create another social network. If you need a social network please piggy back on an existing one: Facebook, LinkedIn, Instagram, Pinterest, ….
If you think you need a social network – perhaps to challenge one of the existing ones? – remember Google Plus.
And make sure you know why you will succeed where Google failed.
Almost certainly you have less resources than Google.
Almost certainly you have a smaller existing user base then Google.
Almost certainly Google will see you as a competitor (as will Facebook, and LinkedIn/Microsoft, Instagram…)
So unless you are in fact the Google evil-empire don’t even think about it. And if you are Google remember you already failed, twice – remember Orkut?
Only a company as rich as Google can maintain the pretence that Google Plus was not an abject failure.
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.
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.
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.
My last post – How much did it cost? – tapped something inside me. Time and again I notice how people in the technology business, indeed, even business in general, are quite capable of using the words of business, management, finance and money without really understanding them. Even people in managerial positions don’t seem to understand the concepts they are advancing.
To complicate matters because digital work often follows different laws even if one does grasp economic concepts they are misapplied. Exhibit 1 is Diseconomies of scale, many of those charged with “managing” software development still assume economies of scale and therefore make things worse not better.
So, thats all by way of saying, here is another blog, indeed perhaps a short series, about economic and financial matters.
One of my bête noire is people talking about Return on Investment but failing to either back it up with numbers or appreciation of how to increase it. There is low hanging fruit here, in most organizations it is quite easy to increase your return on investment simply by writing a value on your work items (user stories, product backlog items, use cases, …) rather than the whole package (project) – see my Estimating business value: Value poker and Dragons Den post.
Low hanging fruit #1: Before you put an effort estimate on any work item write a value estimate first.
Lets talk Cost benefit analysis and Return on Investment, ROI.
ROI is often an idea honoured in the breach rather than reality. Rather than just use the words try and use numbers. While I see teams who put effort estimates on their stories and almost as often hear complaints that teams “cannot estimate accurately” I seldom see value or ROI on a story.
Perhaps the most common way of calculating ROI – at the project level usually – is simply:
ROI = (Benefit – Cost) / Cost
Usually expressed as a percentage, e.g. suppose a piece of work costs $25,000 and generates $35,000 in revenue, a surplus of $10,000. (Notice I’m not calling “profit”, the problems with profit could be the subject of a blog all by itself, technically this might be called “free cashflow” but surplus will do for now.)
ROI = ($35,000 – $25,000) / $25,000 = 40%
If you have a real piece of work which has a 40% return then stop faffing about and do it! In real life opportunities this good are probably too good to be true.
Now three points here. Firstly, if you haven’t done this calculation then simply doing it is better than not doing it. Even a rough calculation is better than none and any calculation will seed discussions.
Low hanging fruit #2: If you don’t have an ROI calculation then do one.
Second, I’ve used dollars here, I could have used pounds sterling, euros, or any other currency. In fact, if you want an indication of whether doing X is more valuable than Y or Z the units don’t matter. And importantly you can mixunits.
Look at that calculation again, I could rewrite it as:
ROI = (Revenue / Cost) -1
ROI = ($35,000 / $25,000) – 1 = 0.4 = 40%
Suppose I use value estimation using “business points” rather than dollars:
ROI = (35,000bp / $25,000) – 1 = 0.4 = 40%
Yes I know this is inexact, mixing units isn’t ideal but… it gives a rough guide which is good enough for many purposes, e.g. initial prioritisation.
Low hanging fruit #3: Prioritising using an approximate rule-of-thumb is better than not doing it. Don’t let perfect be an obstacle.
Third, the simplest approach just outlined is better than nothing and its quite usable over the short term near future, e.g. the next two weeks, or even the next six weeks. However once you start looking months out, an especially once you start looking years out you need to think again.
Once you start looking over longer period you need to consider, well: Time.
The fruit aren’t so low hanging from here on…
Specifically you need to consider: inflation (today’s money is worth more than tomorrow, usually) and the “risk free rate”, that is, “how much money could you make just from interest by putting the money into a safe bank account and waiting.” (Economists usually reference US Government bonds as the safest place but I’ll let you decide what you consider safe these days.)
Right now, November 2017, with very low interest rates and almost as low inflation this can seem pointless. And it probably is if you are planning the next couple of months. But if you are thinking a whole year into the future, let alone five or 10 years then it is very very important.
There is a third aspect of time that shouldn’t be ignored either: not all the costs are incurred at once, and not all the revenue occurs at the same time.
A small, $25,000, piece of work may well all happen in the next month but if that $25,000 was part of a bigger $250,000 “project” lasting 10 months then these things start to become important. And if it is part of a $1,000,000, 40 month, 3 year project than the rate of spend, dates of revenue, inflation and risk-free (interest) rate all become important.
Suppose this work will generate $2,000,000 (I’ll keep the numbers simple). The ROI calculation above would give a return of 50% – amazing but definitely wrong!
The simple ROI calculation above assume all the money is spent in one go and all the revenue arrives in one go which is clearly wrong!
What type of deal is it when I ask the bank to borrow $1m today and promise to pay back $2m in three years? – by the way I’m not even considering the risk inherent in doing work here or the cost of delay.
If we are going to put a value, a percent or dollar figure, on that deal one needs to consider time. Which means one needs to have a view on how the figure is arrived at. I know the engineer inside me thinks “there should be a single unambiguous value but it isn’t like that.
There are two commonly used calculations: Net present value (how much is it worth to spend $1m today and get $2m in 40 months time) and Internal Rate of Return (IRR, what is the percentage return on spending $1m today and getting $2m in 3 years?).
I’ll stick with these two calculations but there are others – Microsoft Excel offers IRR, MIRR, XIRR, NPV, XNPV plus PV and NV if you want to get really fancy. And there are others, each one contains its own assumptions and you need to decide which is best for you.
Now, according to Excel, if the safe bank rate is 0.5% (the current Bank of England rate, 0.04% per month) then the return on spending $1m today is only $697,337. (Calculation #1, IRR = 1.79% which seems ridiculous low but right now I can’t see any mistake in my calculation. IRR is an odd formula anyway which can produce two different values at the best of times and goes to show you need to understand what the calculations are.)
Notice, that assume you have $1m, if you need to borrow it and are paying closer to 4% a year then the return is just over $750,000. So actually, where you get the money from changes the rate of return too!
Now, suppose that instead of spending all $1m on day-1 it is spent $25,000 a month for 40 months. So, at the start of month one $25,000 is spent and $975,000 sits in a safe bank account. At the half way point half of the $1m is still resting in a bank account earning interest. It should be unsurprising to learn that the NPV is higher under this scenario. Indeed Excel gives and NPV of $774,00. (Calculation #2)
You can play what-ifs here, suppose all the expenditure occurred in the first 20 months but benefit still didn’t accrue until month 40, then NPV is $750,000.
Things get even more interesting if we change the assumptions about when benefit accrues. Suppose spending runs at $25,000 a month, and after month 20 revenue the product earns $100,000 per month for the remaining 20 months ($2,000,000 in total). Now NPV is just short of $843,000. (Calculation #3).
Take that to the extreme and assume $50,000 is delivered every month … well we can’t! One of the quirks of IRR, or at least the Excel version, is that there must be at least one month when more is spent than earned (negative net cash flow.) Again, one needs to understand the models built into the calculations.
So lets assume in month 1 there is no revenue but in month 40 there is twice as much, $100,000. (This allows me to keep the total net benefit at $2m). Now NPV is $911,897 but curiously IRR is 100% – from suspiciously low to suspiciously high. (Calculation #4)
I have posted Excel spreadsheet online and you can plug in your own numbers – and maybe someone can check my IRR calculation!
I could continue with these modelling assumptions. There are many ways I could extend the model, change the assumptions or otherwise interrogate the model. Notice though, every time I relax an assumption I replace it with another or sometimes several. For example, the revenue patterns above might strike you as unreal and you might change them to ones you think are more realistic, but in doing so you are also making assumptions.
Notice: I haven’t even started on the effects of inflation. Really I should be “deflating” the projected cash flows, i.e. $100,000 earned in month 40 is not $100,000 in future (2021) money which given the effects of inflation is going to be less than $100,000. Again, one would need to take a view on what inflation will be during the next four years. (If we assume US inflation runs at 3% a year between now and 2021 then $100,000 in 2021 prices is only worth $88,850 today – play with one of the inflation calculators on the web.) And if we are deflating future revenue shouldn’t we deflate future costs?
Now notice something else.
I haven’t talked about Agile, Lean, iterations, digital, Scrum, Kanban, continuous delivery or anything else that we normally talk about but isn’t it obvious?
Whatever you call this: delivering something early improves the return.
Nor have I talked about risk, changing requirements, user feedback, market testing or many of the other things that often get talked about. I’ve don’t deny all those benefits but I’ve deliberately kept this in numbers.
That my friends, is the business case for early and iterative delivery.
An interesting question came up at an event last week:
“My Kanban team has been asked by accounts to put a cost on each story that is done. How do I calculate this?”
My initial thought was: easy, and it is easy to give a simple answer to this question but if you unpack the question and the motivation behind it things get more interesting. Although the question was asked about a Kanban team most of the answer applies equally to Kanban, Scrum or Xanpan teams but contrasting the Kanban and Scrum approach offers an interesting insights.
So, first off the easy answer:
Select a period of work, say a month.
Count how many things (the things you want to know the cost of, stories, backlog items, tickets) got done (what ever your definition of done) during that period, e.g. 6 user stories might have been completed in the month.
Calculate the burn-rate for your team, e.g. if you have 5 team members who each cost $100,000 a year then the monthly burn-rate for the team is $41,666.
Divide your burn-rate by the number of items done, e.g. $41,666 / 6 = $6,940.
This approach adheres to the maxim “It is better to be roughly right than exactly wrong” – which is often credited to John Maynard Keynes but I believe it actually comes from philosopher Careth Read.
Although you might see many things potentially wrong with this crude calculation it has one redeeming feature: it is quick and therefore the cost of doing this calculation is low.
If you want you can improve on this calculation with more data. At the aggregate level you could consider a longer period with more items. Or you might calculate the statistical distribution and provide a range of answers.
Alternatively if you record the start and end dates of the work you could make this calculation more fine grained:
Work on an item starts on 1 November 2017 and completes on 6 November, 4 elapsed working days
The daily burn rate for the team is $1,923 per day (based on the same team of 5 and 260 working days per year)
Therefore a 4 day story cost: $7,692
Now notice, this figure is $700 higher than the previous figure. Which is the right answer?
As an engineer you want to know the actual figure, there should be an equation here, right?
Well yes, there should, but as with any equation you need to make some assumptions. Accountants know this, just ask them about “exceptional” items on the balance sheet and you will find out how subjective accounting is.
By the way, notice this second calculation is also fast and cheap. Were we to ask everyone who touched the story to record the time spent then two things would happen. Firstly those who recorded their time would be less productive in doing the work itself so the cost of knowing the cost would increase.
Second, you are replacing one set of assumptions with another. Namely: that people can accurately record or recall the time they spend doing something. They can’t, so the figure is subjective again, check out my Notes on Estimation and Retrospective Estimation if you don’t believe me.
Back to accounting…
Now the question that arises is “why even ask this question?” – surely recording costs at such a detailed level is waste itself? What value is knowing the cost of each small piece of work?
Now I agree with this, and I would hope you have a conversation with those asking the question as to what they are trying to achieve, what are they going to use this data for? – what they are going to use the data will influence how you calculate it.
But, if you are leading a team and are approached by an accountant with the question “how much does each item cost?” I would advise you not to open the waste question there and then. My advice is to comply with their request in the most efficient manor, i.e. calculate it by one of the methods above.
Let me suggest that were you to immediately move to the question of “Why are you asking me this?” let alone “Answering your question is waste therefore I will ignore it” is likely to create more problems than it will solve.
For better to answer such questions, win some credit and trust then later return with the bigger questions. And since there are different ways to come up with a number you have an opportunity:
“Bill, you know those ticket costings I’ve been giving you for the last three months?”
“Sure, Betty, they are really useful for the capex/opex report.”
“Well Bill, I think there is a better way of calculating them can we talk about how you are using them?”
The fact that there is some ambiguity in the question and answer is an opportunity to have a discussion. First though, you need to win the right to have the discussion.
Now back to the original question.
The motivation behind the question was in part because Scrum teams assign estimates to stories and these estimates can be used as proxies for cost. In terms of accuracy such an approach is wild, at best it is little more than a random number generator for most teams and at worst it will distort both the estimate and the cost calculation. Numbers based on such estimates are unlikely to be accurate at all.
However the techniques described above will work just as well for a Scrum team as a Kanban team. You probably want to work at the Sprint level:
A team of five did 3 stories in a 2 week Sprint (10 working days)
Each team member costs $100,000 a year therefore each Sprint costs $20,000
Each story cost $6,666 ($20,000 / 3)
Such an approach is going to be far more accurate than anything based on estimates and probably more accurate than anything based on time recording. Again you could use more data to build up an even more accurate picture.
Now my big BUT…
This is all about COST.
Everything so far has been about cost. And I know most teams deal in cost. I know most of you are constantly asked “how much will it cost.”
But I also know there there is someone, somewhere, who will promise to do the same thing for less. While you are on the cost side of the equation you will always loose.
What we should be doing is considering Value. How much are these work items worth?
Rather, or in addition, to reporting cost you want to be reporting Value added:
“Bill, here are the figures from the last month, in total we did 10 items at a cost of $41,000 and we added $86,000 to sales”
“Bill, here are the figures from the last month, in total we did 10 items at a cost of $41,000 and we added 1,000 site views”
“Bill, here are the figures from the last month, in total we did 10 items at a cost of $41,000 and we made 500 children smile”