Who should work on what? – Comparative advantage part 1

CoachiStock_000009613557XSmall-2017-12-19-17-55.jpg

Returning to my theme of numerical and economic analysis of software development, I’d like to address that old chestnut:

Shouldn’t every developer work on the software where they are most productive?

We can model this question using a bit of economic theory called Comparative advantage – which is also the economics that justifies free trade. However, while this model will give us an answer it also raises a number of questions which are outside the model. In this case the model gives us a structure for examining the issues rather than providing an answer.

By the way, this discussion is going to span two blog posts, or perhaps three.

Lets set up the model with a simple case. As before there are some assumptions needed, its when we examine these assumptions that things get really interesting.

Imagine a small trading desk. The desk invests in corporate bonds and equities. Jenny has been working for the desk for some years and has written two applications for trading imaginatively called Equities and Bonds. She wrote Equities after Bonds and prefers Equities and is more productive on Equities.

Measured in features Jenny can produce 5 new Equities features or 4 new Bonds features in one week. (We’ll assume that all features are the same size for now.)

The company hires a new developer, Joe. He is new to the code bases he can only produce 2 Equities features or 3 Bonds features a week. Thus Jenny is the most productive developer on both apps.

Features per week
Equities
Bonds
Jenny5
4
Joe2
3

Now comparative advantage theory tells us not to look at the total output of either party but at the relative output. In other words:

  • For Jenny every bond feature costs 1.2 equities features. Equally Jenny can produce one equities feature at a the cost of 0.8 (4/5ths) bonds features.
  • For Joe every bond feature costs 0.66 (2/3rds) equities features. Or, to put it the other way round, Joe’s equities features cost 1.5 bond features.

Looked at this way, relatively, Jenny is a better (more productive) Equities developers and Joe is the most productive Bonds developer.

Think about that.

During one week Jenny can produce more Bonds features than Joe but when measured in terms of the alternative Joe is the more productive Bonds developer. This is the important point. You might say “look at everyones individual strengthens.” Relatively Joe is better at Bonds.

Together Jenny and Joe could produce 7 features for either product. If Jenny works where she is stronger, Equities, and Joe works where he is strongest, Bonds, then together they will produce 8 features. If they both worked on their weaker product then they will only produce 6 features combined but four of those six would be Bonds features.

So, it seems the case solved: Everyone should specialise and work on the product where the individual is relatively strongest. Although this is not necessarily the same as “who is the best developer” for a product.

But… things are more complex. Now we have the model we can start changing the assumptions and see what happens.

First off, we could relaxed the assumption about all features being a different size. However this doesn’t make any real difference. It doesn’t matter how big a feature is, Jenny is always 20% more productive on Equities than Bonds and similarly Joe is 50% more productive on Bonds than Equities. Using different size features complicates the model without creating new insights.

Varying the size of features doesn’t change the integrity of the model but it does make a difference if we start to look at throughput and consider time.

So lets relax the time assumption. What happens if Joe is in the middle of a Bonds feature and another feature gets flagged up as urgent. Should Joe drop what he is doing and pick up the urgent Bond feature?

The model doesn’t answer this question. The model is only measuring output. If we are attempting to maximise output then changing work part way through the week only makes sense if the both pieces of work – the part done original and the urgent interrupt – can still be completed by the end of the week.

So one needs to ask: is the feature urgent enough to justify Joe halting his current work and doing the new feature? Then perhaps returning to his current work?

Possibly but in making one feature arrive faster another would be delayed. Statistically there is little difference because the differences cancel each other out. Which itself demonstrates how managing by numbers can be misleading.

And what is Joe couldn’t finish both pieces by the end of the week? Would it make sense to reduce overall efficiency to expedite some work?

What if Jenny becomes available, should she work on Bonds? Even though she is relatively less productive at Bonds and would thus delay even more Equities features?

These questions can be answered in many different ways but answering them depends on what you are trying to maximise. And lets also note that in real life the data is unlikely to be so clear cut

On average Joe takes two and a half days to complete an Equities feature while Jenny completes one Equities feature a day. On average Jenny can complete her current feature and a second one before Joe could. But it doesn’t take much to invalidate that answer, in particular if feature sizes vary things change.

What if Jenny is working on an over-sized feature? – well call it urgent #1. Suppose urgent #1 is twice as big as urgent #2 and she has just started #1. Jenny will take three days to finish both features. If goes starts urgent #2 he will have it finished in 2.5 days, during that time Jenny will have urgent #1 finished. Looked at this way it makes sense for Joe to work on the highest priority even if it takes him longer.

And what happens if Equities has three, or more, urgent features? Even with Joe working more slowly than Jenny all the urgent features will be delivered sooner if Joe works on Equities too. Again, total productivity would be impacted but what is more important: total productivity or rapid delivery?

If efficiency is your objective then all is well, simply understand the relative efficiency of individuals and do the maths. (Except of course, understanding the efficiency of any individual isn’t that straight forward.) Adding time dependent features complicates things, the comparative advantage model helps show the cost of urgency although it cannot answer the question.

It is entirely possible, even likely, that efficiency is not the only concern, it may not even be the primary concern. Rather the timeliness of feature delivery may be more important.

Specifically, I have assumed that all features are about the same effort but I’ve assumed they are also the same value. Efficiency has been measured as quantity of units produced is a poor measurement compared with efficiency in value delivered. I’ll turn my attention to value in the next blog.

But before I leave this post, one more assumption to surface.

In this model Joe and Jenny are completely independent. There work does not impact the other and they share no resources. What if they did?

What if both Joe and Jenny handed their completed work to the same Tester? Or they both needed use of s single test environment? Or their work needed to be bundled into a common release?

In such cases the shared resource – the tester, the environment, the release schedule – would become the constraint on productivity. This is getting towards Theory of Constraints space.

For Joe and Jenny to work at their most productive not only would that bottleneck need enough capacity to service them both it would actually need more capacity to cope with the variation and peak load (when Jenny and Joe delivered at the same time.)

Providing that extra capacity at the bottleneck would allow Joe and Jenny to work at their maximum throughput but would introduce waste because the extra capacity would sometimes be idle. To tackle that question one needs a far more complex theory: Queuing Theory – which I’ve discussed in previous posts, Utilisation and non-core team members and Kanban: efficient or predictable, you decide.

Read more? Subscribe to my newsletter – free updates on blog post, insights, events and offers.

When does a Start-Up need Agile?

iStock-625433778Medium-2017-12-6-16-28.jpg

I started writing another piece on more economic and agile/software development but it got to long, so right now, an aside…

Back in 1968 Peter Drucker wrote:

“Large organizations cannot be versatile. A large organization is effective through its mass rather than through its agility.”

Last week I presented “Agile for Start-ups” here in London for the third time. Each time I’ve given this talk it has been largely rewritten – this time I think I’ve got it nailed. Part of the problem is I tend towards the view that “Start-Ups don’t need Agile”, or rather they do, but agile comes naturally and if it doesn’t then the start-up is finished. Its later when the company grows a bit that it needs Agile. And notice here, I’m differentiating between agile – the state of agility – and Agile as a recognised method.

New, energetic, start-ups are naturally agile, they don’t need an Agile method. As they grow there may well come a time when an Agile method, specific Agile tools, are useful in helping the start-up keep its agility. Am I splitting hairs?

For a small start-up agile should be a natural advantage. On day one, when there are two people in a room making the startup it isn’t a question of what process they are going to follow. At the very beginning a start-up lives or dies by two things: passion and a great idea. In the beginning it should be pure energy.

In many ways the ideas behind Agile are an effort to help companies maintain this natural agility as they grow. Big, established, companies who have lost any natural agility seem to resemble middle aged men trying to recapture a lost youth.

So when does a start-up need to get Agile? – a more formal way of keeping fit as it where.

Not all day-1 start-ups are pure passion, ideas and energy. Some need to find their thing. They need an approach to finding their reason for being. Agile can provide that structure.

And start-ups which are taking a Lean Start-Up approach also need a method. They may have passion and energy in the room but the lean startup market test driven approach demands discipline and iteration. Lean Start-Up demands you kill your children if nobody wants them.

When I look at Lean Start-Up I see an engineer’s solution to the problem of “What product should our company build to be successful?” The engineered solution is to try something, see what happens, learn from the result, maybe build on the try or perhaps change (pivot) and repeat.

In both these cases a start-up needs to be able to Iterate: Try something, see what happens, learn from it and go round the loop again.

You can generalise these two cases to one: Product Discovery through repeated experimentation.

That requires a discipline and it requires a method – even if the method is informal and subject to frequent change. It can be supplemented with traditional research and innovation approaches.

The next time a start-up can benefit from Agile (as in a method) is as it grows: as it becomes a “scale-up” rather than a start-up. This might be when you grow from two to three, or from 10 to 13, or even 100 to 130 but at some point the sheer energy driven nature of a start-up needs to give way to more structure.

This probably coincides with success – the company has grown and survived long enough to grow. Someone, be they customers or investors, is paying the company money. It is no longer enough to rely on chance.

The problem now is that introducing a more defined method risks damaging the culture and way the start-up is working – which is successful right now. So now the risk of change is very real, there is something to loose!

Just as the company can think about the future it needs to risk that future. But no change is also risky, with growth the processes and practices which brought initial success may not be sustainable in a larger setting.

This is the point where I’ve seen many companies go wrong. They go wrong because they decide to become a “proper company” and do things properly. Which probably means adding some project managers and trying to be like so many other companies. They give up their natural agility.

Innovation in process goes out the window and attempts to turn innovative work into planned projects are doomed. Show me the project plan with a date for “Innovation happens here” or “Joe gets great idea in morning shower” or “Sam bumps into really big contact.”

It is at this point that I think Agile methods really can help. But those approaches need to be introduced carefully working with the grain of the organization. Some eggs are bound to be broken but this shouldn’t be a scorched earth policy.

Start-ups and scale-ups need to approach their products and Agile introduction as they do their business growth: organically. Grow it carefully, don’t force feed it, don’t impose it – inspire the staff to change and let them take the initiative.

It is much easier to do this while the team is small. Changing the way one team of five works is far easier than changing the way four teams of eight work. Its also cheaper because once one team is working well it can grown and split – amoeba like – and later teams will be born with good habits.

Unfortunately companies, especially smaller ones, put a lot of faith in hiring more people to increase their output and thereby postpone the day when the team adopt a more productive and predictable style of working.

This might be because they believe new hires will have the same work ethic and productivity as the early hires: they probably won’t if only because they have more to learn (people, code, processes, domain) when they start.

Or it might be because the firm doesn’t want to loose productivity while they change: in my experience, when the change is done right short term productivity doesn’t fall much and quickly starts growing.

It might just be money saving: why pay for training and advice today? – yet such advice isn’t expensive in the scheme of things, certainly delaying a new hire by a couple of months should cover it.

Or it might just be the old “We haven’t got time to change” problem. Which always reminds me of a joke Nancy Van Schooenderwoert once told me:

“A police officer sees a boy with a bicycle walking along the road at 10am.
Police: Excuse me young sir, shouldn’t you be in school?
Boy: Yes officer, I’m rushing there right now.
Police: Wouldn’t it be faster to ride your bike down the hill?
Boy: Yes officer, but I don’t have the time to get on the bike.”

Read more? Subscribe to my newsletter – free updates on blog post, insights, events and offers.

1% improvement

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…

ImprovementGraph-2017-11-22-11-40.jpg

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 🙂

Read more? Subscribe to my newsletter – free updates on blog post, insights, events and offers.

How much is it worth? – more about money

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.)

Thus:

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 mix units.

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.

Read more? Subscribe to my newsletter – free updates on blog post, insights, events and offers.

How much did it cost?

iStock_000002297977XSmall-2017-11-7-15-48.jpg

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.

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”

Or maybe:

“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”

I know measuring value is hard but we have to try. If nothing else, estimate value the same way you estimate effort.

Read more? Subscribe to my newsletter – free updates on blog post, insights, events and offers.

Tax the data

iStock_000008663948XSmall-2017-10-6-13-19.jpg

If data is the new oil then why don’t we tax it?

My data is worth something to Google, and Facebook, and Twitter, and Amazon… and just about every other Internet behemoth. But alone my data is worth a really tiny tiny amount.

I’d like to charge Google and co. for having my data. The amount they currently pay me – free search, free email, cheap telephone… – doesn’t really add up. In fact, what Google pays me doesn’t pay my mortgage but somehow Larry Page and Sergey Brin are very very rich. Even if I did invoice Google, and even if Google paid we are talking pennies, at most.

But Google don’t just have my data, they have yours, your Mums, our friends, neighbours and just about everyone else. Put it all together and it is worth more than the sum of the parts.

Value of my data to Google < 1p
Value of your data to Google < 1p
Value our combined data to Google > 2p

The whole is worth more than the sum of the parts.

At the same time Google – and Facebook, Amazon, Apple, etc. – don’t like paying taxes. They like the things those taxes pay for (educated employees, law and order, transport networks, legal systems – particularly the bit of the legal system that deals with patents and intellectual property) but they don’t want to pay.

And when they do pay they find ways of minimising the payment and moving money around so it gets taxed as little as possible.

So why don’t we tax the data?

Governments, acting on behalf of their citizens should tax companies on the data they harvest from their users.

All those cookies that DoubleClick put on your machine.

All those profile likes that Facebook has.

Sure there is an issue of disentangling what is “my data” from what is “Google’s data” but I’m sure we could come up with a quota system, or Google could be allowed a tax deduction. Or they could simply delete the data when it gets old.

I’d be more than happy if Amazon deleted every piece of data they have about me. Apple seem to make even more money that Google and make me pay. While I might miss G-Drive I’d live (I pay DropBox anyway).

Or maybe we tax data-usage.

Maybe its the data users, the Cambridge Analyticas, of this world who should be paying the data tax. Pay for access, the ultimate firewall.

The tax would be levied for user within a geographic boundary. So these companies couldn’t claim the data was in low tax Ireland because the data generators (you and me) reside within state boundaries. If Facebook wants to have users in England then they would need to pay the British Government’s data-tax. If data that originates with English users is used by a company, no matter where they are, then Facebook needs to give the Government a cut.

This isn’t as radical as it sounds.

Governments have a long history of taxing resources – consider property taxed. Good taxes encourage consumers to limit their consumption – think cigarette taxes – and it may well be a good thing to limit some data usage. Anyway, thats not a hard and fast rule – the Government taxes my income and they don’t want to limit that.

And consider oil, after all, how often are we told that data is the new black gold?
– Countries with oil impose a tax (or charge) on oil companies which extract the oil.

Oil taxes demonstrate another thing about tax: Governments act on behalf of their citizens, like a class-action.

Consider Norway, every citizen of Norway could lay claim to part of the Norwegian oil reserves, they could individually invoice the oil companies for their share. But that wouldn’t work very well, too many people and again, the whole is worth more than the sum of the parts. So the Norwegian Government steps in, taxes the oil and then uses the revenue for the good of the citizens.

In a few places – like Alaska and the Shetlands – do see oil companies distributing money more directly.

After all, Governments could do with a bit more money and if they don’t tax data then the money is simply going to go to Zuckerberg, Page, Bezos and co. They wouldn’t miss a little bit.

And if this brings down other taxes, or helps fund a universal income, then people will have more time to spend online using these companies and buying things through them.

Read more? Subscribe to my newsletter – free updates on blog post, insights, events and offers.

MVP is a marketing exercise not a technology exercise

MVP-2017-10-2-11-03.jpg
… Minimally Viable Product

Possibly the most fashionable and misused term the digital industry right now. The term seems to be used by one-side-or-other to criticise the other.

I recently heard another Agile Coach say: “If you just add a few more features you’ll have an MVP” – I wanted to scream “Wrong, wrong, wrong!” But I bit my tongue (who says I’m can’t do diplomacy?)

MVP often seems to be the modern way of saying “The system must do”, MVP has become the M in Moscow rules.

Part of the problem is that the term means different things to different people. Originally coined to describe an experiment (“what is the smallest thing we could build to learn something about the market?”) it is almost always used to describe a small product that could satisfy the customers needs. But when push comes to shove that small usually isn’t very small. When MVP is used to mean “cut everything to the bone” the person saying it still seems to leave a lot of fat on the bone.

I think non-technical people hear the term MVP and think “A product which doesn’t do all that gold plating software engineering fat that slows the team down.” Such people show how little they actually understand about the digital world.

MVPs should not about technology. An MVP is not about building things.

An MVP is a marketing exercise: can we build something customers want?

Can we build something people will pay money for?

Before you use the language MVP you should assume:

  1. The technology can do it
  2. Your team can build it

The question is: is this thing worth building?and before we waste money building something nobody will use, let alone pay for, what can we build to make sure we are right?

The next time people start sketching an MVP divide it in 10. Assume the value is 10% of the stated value. Assume you have 10% of the resources and 10% of the time to build it. Now rethink what you are asking for. What can you build with a tenth?

Anyway, the cat is out of the bag, as much as I wish I could erase the abbreviation and name from collective memory I can’t. But maybe I can change the debate by differentiating between several types of MVP, that is, several different ways the term MVP is used:

  • MVP-M: a marketing product, designed to test what customers want, and what they will pay for.
  • MVP-T: a technical product designed to see if something can be build technologically – historically the terms proof-of-concept and prototype have been used here
  • MVP-L: a list of MUST HAVE features that a product MUST HAVE
  • MVP-H: a hippo MVP, a special MVP-L, that is highest paid person’s opinion of the feature list, unfortunately you might find several different people believe they have the right to set the feature list
  • MVP-X: where X is a number (1,2, 3…), this derivative is used by teams who are releasing enhancements to their product and growing it. (In the pre-digital age we called this a version number.) Exactly what is minimal about it I’m not sure but if it helps then why not?

MVP-M is the original meaning while MVP-L and MVP-H are the most common types.

So next time someone says “MVP” just check, what do they mean?

Read more? Join my mailing list – free updates on blog post, insights, events and offers.

Definition of Ready considered harmful

Small-iStock-502805668-2017-09-6-12-58.jpg

Earlier this week I was with a team and discussion turned to “the definition of ready.” This little idea has been growing more and more common in the last couple of years and while I like the concept I don’t recommend it. Indeed I think it could well reduce Agility.

To cut to the chase: “Definition of ready” reduces agility because it breaks up process flow, assumes greater role specific responsibilities, introduces more wait states (delay) and potentially undermines business-value based prioritisation.

The original idea builds on “definition of done”. Both definitions are a semi-formal checklists agreed by the team which are applied to pieces of work (stories, tasks, whatever). Before any piece of work is considered “done” it should satisfy the definition of done. So the team member who has done a piece of work should be able to mentally tick each item on the checklist. Typically a definition of done might contain:

 

  • Story implemented
  • Story satisfies acceptance criteria
  • Story has been seen and approved by the product owner
  • Code is passing all unit and acceptance tests

Note I say “mentally” and I call these lists “semi formal” because if you start having a physical checklist for each item, physically ticking the boxes, perhaps actually signing them, and presumably filing the lists or having someone audit them then the process is going to get very expensive quickly.

So far so good? – Now why don’t I like definition of ready?

On the one hand definition of ready is a good idea: before work begins on any story some pre-work has been done on the story to ensure it is “ready for development” – yes, typically this is about getting stories ready for coding. Such a check-list might say:

 

  • Story is written in User Story format with a named role
  • Acceptance criteria have been agreed with product owner
  • Developer, Tester and Product owner have agreed story meaning

Now on the other hand… even doing these means some work has been done. Once upon a time the story was not ready, someone, or some people have worked on the story to make it ready. When did this happen? Getting this story ready has already detracted from doing other work – work which was a higher priority because it was scheduled earlier.

Again, when did this happen?

If the story became “ready” yesterday then no big deal. The chances are that little has changed.

But if it became ready last week are you sure?

And what if it became ready last month? Or six months ago?

The longer it has been ready the greater the chance that something has changed. If we don’t check and re-validate the “ready” state then there is a risk something will have changed and be done wrong. If we do validate then we may well be repeating work which has already been done.

In general, the later the story becomes “ready” the better. Not only does it reduce the chance that something will change between becoming “ready” and work starting but it also minimises the chance that the story won’t be scheduled at all and all the pre-work was wasted.

More problematic still: what happens when the business priority is for a story that is not ready?

Customer: Well Dev team story X is the highest priority for the next sprint
Scrum Master: Sorry customer, Story X does not meet the definition of ready. Please choose another story.
Customer: But all the other stories are worth less than X so I’d really like X done!

The team could continue to refuse X – and sound like an old style trade unionist in the process – or they could accept X , make it ready and do it.

Herein lies my rule of thumb:

 

If a story is prioritised and scheduled for work but is not considered “ready” then the first task is to make it ready.

Indeed this can be generalised:

 

Once a story is prioritised and work starts then whatever needs doing gets done.

This simplifies the work of those making the priority calls. They now just look at the priority (i.e. business value) or work items. They don’t need to consider whether something is ready or not.

It also eliminates the problem of: when.

Teams which practise “definition of ready” usually expect their product owner to make stories ready before the iteration planning meeting, and that creates the problems above. Moving “make ready” inside the iteration, perhaps as a “3 Amigos” sessions after the planning meeting, eliminates this problem.

And before anyone complains saying “How can I estimate something thing that is not prepared?” let me point out you can. You are just estimating something different:

 

  • When you estimate “ready” stories you are estimating the time it takes to move a well formed story from analysis-complete to coding-complete
  • When up estimate an “unready” story you are estimating the time it takes to move a poorly formed story from its current state to coding-complete

I would expect the estimates to be bigger – because there is more work – and I would expect the estimates to be subject to more variability – because the initial state of the story is more variable. But is still quite doable, it is an estimate, not a promise.

I can see why teams adopt definition of ready and I might even recommend it myself but I’d hope it was an temporary measure on the way to something better.

In teams with broken, role based process flows then a definition of done for each stage can make sense. The definition of done at the end of one activity is the definition of ready for the next. For teams adopting Kanban style processes I would recommend this approach as part of process/board set-up. But I also hope that over time the board columns can be collapsed down and definitions dropped.

Read more? Join my mailing list – free updates on blog post, insights, events and offers.

What if it is all random?

iStock-512907832Small-2017-08-10-12-37.jpg

What if success in digital business, and in software development, is random? What if one cannot tell in advance what will succeed and what will fail?

My cynical side sometimes thinks everything is random. I don’t want to believe my cynical side but…

All those minimally viable products, some work, some fail.

All those stand-up meetings, do they really make a difference?

All those big requirements documents, just sometimes they work.

How can I even say this? – I’ve written books on how to “do it right.”
I advise companies on how to improve “processes.” I’ve helped individuals do better work.

And just last month I was at a patterns conference trying to spot reoccurring patterns and why they are patterns.

So let me pause my rational side and indulge my cynical side, what if it is all random?

If it is all random what we have to ask is: What would we do in a random world?

Imagine for a moment success is like making a bet at roulette and spinning the wheel.

Surely we would want to both minimise losses (small bets) and maximise wheel spins: try lots, remove the failures quickly and expand the successes (if we can).

I suggested “its all random” to someone the other day and he replied “It is not random, its complex.” And we were into Cynefin before you could say “spin the wheel.”

Dave Snowden’s Cynefin model attempts to help us understand complexity and the complex. Faced with complexity Cynefin says we should probe. That is, try lots of experiments so we can understand, learn from the experiments and adjust.

If the experiment “succeeds” we understand more and can grow that learning. Where the experiment “fails” we have still learned but we will try a different avenue next time.

Look! – it is the same approach, the same result, complexity, Cynefin or just random: try a lot, remove failure and build on success. And hang on, where have I heard that before, … Darwin and evolution; random gene mutations which give benefit get propagated and in time others die out.

It is just possible that Dave is right, Darwin is right and I am right…

Today most of the world’s mobile/cell telephone systems are built on CDMA technology. CDMA is super complex maths but it basically works by encoding a signal (sequence of numbers, your voice digitised) and injecting it into a random number stream (radio spectrum), provided you know the encoding you can retrieve the signal out of the randomness. Quite amazing really.

Further, provided the number sequences are sufficiently different they are in effect random so you can inject more signal into the same space.

That is why we can all use our mobile phones at the same time.

Put it another way: you walk into a party in London, in the room are Poles, Lebanese, Germans, Argentinians and the odd Brit. They are all talking in their own language to fellow speakers. Somehow you can hear your own language and join the right conversation. Everything else is random background noise.

Maybe the same is true in digital business and software development…

Perhaps it is all complex but it is so complex that we will never be able to follow all the cause and effect chains, it is so complex that it looks random. Dave is right with Cynefin but maybe there is so much complexity that we might as well treat it as random and save our time.

Back to CDMA and London parties, faced with apparent randomness there are useful strategies and signals can still be extracted.

Perhaps the way to deal with this complexity is not to try and understand it but to treat it as random. Rather than expend energy and time on a (possibly) impossible task accept it as random and apply appropriate strategies.

After all, if we have learned anything from statistical distributions it is that faced with actual and apparent randomness we can still find patterns, we can still learn and we can still work with, well, randomness.

Programmer’s Rorschach test

The picture above, I recently added this picture to Continuous Digital for a discussion of teams. When you look at it what do you see:

An old style structure chart, or an organization chart?

It could be either and anyone who knows of Conway’s Law shouldn’t be surprised.

When I was taught Modula-2 at college these sort of structure charts were considered superior to the older flow charts. This is functional decomposition, take a problem, break it down to smaller parts and implement them.

And that is the same idea behind traditional hierarchical organizational structure. An executive heads a division, he has a number of managers under him who manage work, each one of these manage several people who actually do the work (or perhaps manage more manager who manage the people who do the work!)

Most organizations are still set up this way. It is probably unsurprising that 50 years ago computer programmers copied this model when designing their systems – Conway’s Law, the system is a copy of the organization.

Fast forward to today, we use object oriented languages and design but most of our organizations are still constrained by hierarchical structure, that creates a conflict. The company is structurally decomposed but our code is object oriented.

The result is conflict and in many cases the organization wins – who hasn’t seen an object oriented system that is designed in layers?

While the conflict exists both system and organization under perform because time and energy are spent living the conflict, managing the conflict, overcoming the conflict.

What would the object-oriented company look like?

If we accept that object oriented design and programming are superior to procedural programming (and in general I do although I miss Modula-2) then it becomes necessary to change the organization to match the software design – reverse Conway’s Law or Yawnoc. That means we need teams which look and behave like objects:

  • Teams are highly cohesive (staffed with various skills) and lightly coupled (dependencies are minimised and the team take responsibility)
  • Teams are responsible for a discrete part of the system end-to-end
  • Teams add value in their own right
  • Teams are free to vary organizational implementation behind well defined interface
  • Teams are tested, debugged and maintained: they have been through the storming phase, are now performing and are kept together

There are probably some more attributes I could add here, please make your own suggestions in the comments below.

To regular readers this should all sound familiar, I’ve been exposing these ideas for a while, they draw on software design and Amoeba management, I discuss them at greater length Xanpan, The Xanpan Appendix and now Continuous Digital – actually, Continuous Digital directly updates some chapters from the Appendix.

And like so many programmers have found over the years, classes which are named “Manager” are more than likely poorly named and poorly designed. Manager is a catch all name, the class might well be doing something very useful but it can be named better. If it isn’t doing anything useful, then maybe it should be refactored into something that is. Most likely the ManagerClass is doing a lot of useful stuff but it is far from clear that it all belongs together. (See the management mini-series.)

Sometimes managers or manager classes  make sense, however both deserve closer examination. Are they vestige from the hierarchal world? Do they perform specialist functions which could be packaged and named better? Perhaps they are necessary, perhaps they are necessary for smoothing the conflict between the hierarchal organization and object oriented world.

Transaction costs can explain both managers and manager classes. There are various tasks which require knowledge of other tasks, or access to the same data. It is cheaper, and perhaps simpler, to put these diverse things together rather than pay the cost of spreading access out.

Of course if you accept the symbiosis of organization and code design then one should ask: what should the organization look like when the code is functional? What does the Lisp, Clojure or F# organization look like?

And, for that matter, what does the organization look like when you program in Prolog? What does a declarative organization look like?

Finally, I was about to ask about SQL, what does the relational organization look like, but I think you’ve already guessed the answer to this one: a matrix, probably a dysfunctional matrix.