Author: Allan Kelly

Allan Kelly from Allan Kelly Associates

In my last two posts – Who should work on what? part1 and part 2 – I’ve tried to apply the comparative advantage model from economics to the question of which software developer should work on what. The model has come up with two different answers:

• If productivity (measured by quantity of features is the goal) then it probably makes sense for everyone to work on the product that they are comparatively most productive on (comparatively being the key word here.)
• If value produced in the goal then it may well make sense for everyone to work on the most valuable features (or product) regardless of personal strengths.

Along the way I’ve highlighted a number of difficulties in applying this model:

• If common resources are being used, or if doing one piece of work impacts another, then the model doesn’t work.
• There is no consideration of time or urgency in the model. When urgency enters the picture then productivity may well suffer.
• Over time things may change: backlogs will stratify and people will learn.
• Operating this model in practice requires data which is usually unavailable and so getting the data would itself take time.

At this point it is tempting to throw ones hands up in the air and say: “We’ve learned nothing!”

But I don’t think so. I think there are lessons in here.

Right at the start of this I knew this was a difficult question to answer, trying to answer it has shown just how hard it is to get a definitive answer. There are still more assumptions which could be relaxed in this model and still more variables that could be added.

The model has also shown how important it is to have a sense of value. Not only between products but between features. That in turn demonstrates the importance of both valuing work in the backlog and regularly reviewing those valuations.

However, the first big lesson I think that needs learning here is: you have to know what your intention is.

You need to know what you are trying to optimise.
You need a strategy.

For example:

• Do you want to maximise the quantity of features delivered?
• Do you want to maximise the value delivered? (probably measured in money)
• How much do you want to allow for urgent work? And to what standard are you going to hold those requests?
• Do you want to promote specific knowledge (so one person can become more productive in one domain) or spread knowledge around (so many people can work on many different things)?

In many this is going to be a self-fulfilling prophecy, the result will be what you put in. That is, if people only work on one product then moving people between products will get harder and less productive. If people follow the value then value delivered will increase as people become more productive in the products with the higher value.

Knowing what your intention is should be the first step to formulating a strategy. And having a strategy is important because answering that question – “who should work on what?” – is hard.

To answer that question rationally one needs to create a model, a model far more complex than my model, then calculate every variable in the model – plus keep the variables up to date as they change. Then to apply that model to every work question which arises.

Phew.

Alternatively one can formulate a rule of thumb, a heuristic, a rough guideline, a “good enough” decision process. This might sound a bit amateurish but as Gerd Gigerenzer says in Risk Savvy:

“To make good decisions in an uncertain world, one has to ignore part of the information, which is exactly what rules of thumb do. Doing so can save time and effort and lead to better decisions.”

To build up such rules of thumb requires experience and reflection, something which might be described as intuition.

So to answer my original question in terms an economist would recognise: It depends.

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

The post Conclusion: Who works on what – Comparative advantage part 3 of 3 appeared first on Allan Kelly Associates.

Allan Kelly from Allan Kelly Associates

In my previous post I tried to use the economic theory of comparative advantage to answer the question:

Who should work on what? or Shouldn’t every developer work on the software where they are most productive?

The economic model gave an answer but more importantly it provided a framework for answering the question. As I examined the assumptions behind the model it became clear there are many other considerations which deserve attention.

Perhaps the most important one is: value.

The basic economic model looks, perhaps naively, at quantity of goods produced. Really, one should consider the value of the goods produced. Not only did the model assume that every feature is the same size but it also assumed that all features have the same value.

Flipping back to the basic model, lets assume that each Bonds feature generates $10,000 in revenue while each Equities feature generates $20,000. Now the options are:

1. Jenny and Joe both work on Equities, they produce seven features and generate $140,000 in revenue.
2. Jenny and Joe both work on Bonds, they produce seven features and generate $70,000 in revenue.
3. Joe works on Equities and Jenny on Bonds, the six features they produce generate $80,000 in revenue.
4. Joe works on Bonds and Jenny on Equities, the eight features they produce generates $130,000 in revenue.

Clearly option #1 is the one to choose because it generates the greatest revenue even though Joe would be more productive if he were to work on Bonds. Adding value to the basic model changes the answer.

Now, again there is an assumption here: all features produce the same value. That is unlikely to be true.

Indeed, over time if no work is done on Bonds it would be reasonable to assume the value of the features would increase. Not that all features would increase in value but failure to do any would mean some of those in the backlog would become more valuable. In addition new requests might arise which may be more valuable than existing requests.

Further, while the value of Bonds features would be increasing the value of Equities might be falling. This follows another economic theory, the law of diminishing marginal utility. This law states that as one consumes more of a given product the added utility (i.e. value) derived from one more unit will be less and less.

So now we have exposed another assumption in the model: the model is static. The model does not consider the effects over time of how things change – I’ll come back to this in another context later too.

Over time the backlogs for both products will stratify, each will contain some items which are higher in value than average and some which are lower in value.

Lets suppose each product has its own backlog:

• Equities backlog contains seven features with the values: $60,000, $54,000, $48,000, $42,000, $36,000, $30,000 and $24,000.
• Bonds backlog contains another seven features with the values: $32,500, $10,000, $7,000, $6,000, $5,000, $4,000 and $,3000.

Now there are (at least) four options open:

1. Equities: both Jenny and Joe work on the equities product. Together they will deliver seven features and a total of $294,000 of value.
2. Bonds: both Jenny and Joe work on the bonds product. Together they will deliver seven features and a total of $67,500 of value.
3. Specialise: Jenny does five equities features ($240,000) and Joe three bonds features ($49,500) delivering a total of eight features and $289,500.
4. Value seeking: Jenny does her five equities features but Joe delivers one bonds feature, one equities feature and gets to go home early. In total they deliver six features and $302,500.

The highest value option if #4, which delivers $13,000 more than if they specialise. That might seem counter intuitive: the option that delivers the most money delivers the least features. And again it shows deciding work in the absence of value can be misleading.

The second best option is for both to do Equities only, this delivers $8,500 more than specialisation. Adding value to the basic model isn’t a big change but it has changed the answer. When output was measured in features then specialisation looked to be the best option.

Returning to the question of the static model, there is one more assumption to relax: Learning. Economist J.K.Galbraith pointed out that the comparative advantage neglects to factor in learning, and I’ve done the same thing so far.

Assuming Joe specialises in Bonds and spends most of his time working there he will learn and in time he will become more productive. Suppose after a year he can produce 5 bonds features in the time he takes to produce 2 equities features – a 66% improvement.

Now how to the numbers stack up? What is the revenue maximising choice now?

And perhaps more importantly, how long would it take before Joe’s increased output paid for all the time he spent learning?

But, another what-if, what if Joe had specialised in Equities instead? He would now be more productive on a product with higher value features.

Again the question “Who should work on what?” needs to consider intent. Which product do you want Joe to learn? Which product is expected to have the highest value? Are you maximising value or quantity?

As usual, you can argue with my model and question my assumptions but I think that only demonstrates my point: these things need thinking about.

If you want you can continue relaxing the assumptions and do more what-if calculations – for example I’ve assumed Jenny and Joe cost the same. Nor have I factored in risk or cost-of-delay. This model can get a lot more complicated. I’ve also assumed that partially done features have no value at all, each week starts afresh and no work carries over.

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

The post Adding value – Who works on what? – part 2 of comparative advantage appeared first on Allan Kelly Associates.

Allan Kelly from Allan Kelly Associates

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.

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.

The post Who should work on what? – Comparative advantage part 1 appeared first on Allan Kelly Associates.