Agile - Allan Kelly

Adding value – Who works on what? – part 2 of comparative advantage

Agile, Business / allan kelly / December 20, 2017

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:

Jenny and Joe both work on Equities, they produce seven features and generate $140,000 in revenue.
Jenny and Joe both work on Bonds, they produce seven features and generate $70,000 in revenue.
Joe works on Equities and Jenny on Bonds, the six features they produce generate $80,000 in revenue.
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:

Equities: both Jenny and Joe work on the equities product. Together they will deliver seven features and a total of $294,000 of value.
Bonds: both Jenny and Joe work on the bonds product. Together they will deliver seven features and a total of $67,500 of value.
Specialise: Jenny does five equities features ($240,000) and Joe three bonds features ($49,500) delivering a total of eight features and $289,500.
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.

Adding value – Who works on what? – part 2 of comparative advantage Read More »

Who should work on what? – Comparative advantage part 1

Agile, Business / allan kelly / December 19, 2017

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
Jenny	5	4
Joe	2	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.

Who should work on what? – Comparative advantage part 1 Read More »

When does a Start-Up need Agile?

Agile, Agile Process, Business / allan kelly / December 6, 2017

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.

When does a Start-Up need Agile? Read More »

1% improvement

Agile, Business / allan kelly / November 22, 2017 / 1 Comment

Keeping with the numerical and financial theme of the last couple of blogs I want to turn my attention to improvement and how really small improvements add up and can justify big spending. This also turns out to be the case for continual improvement and continual delivery…

How would you like it if I promised to improve your team by 1%? – I’m sure I can!

How much difference would it make if your team were 1% more productive?

Not a lot I guess.

More importantly, you’re going to have trouble making that sale to the powers that be.

You: Boss, I’d like to hire Allan Kelly as consultant for a few days to advise the team on how to improve.
Boss: How much do you expect them to improve?
You: He guarantees a 1% improvement or your money back
Boss: One Percent? 1%? Just 1%? Whats he charging $10?

No, thats not going to work is it.

People who hold the money like to see big numbers. The problem is, if the numbers are too big they become unbelievable. Those in authority want to see a significant improvement but the bigger the numbers are then the more evidence they want to see that the improvement is achievable. And when the number are big they need to be proven and that can slow everything down.

On the other hand, there are stories of teams winning (and I do mean winning) by focusing on 1% improvements. At Pipeline conference last year John Clapham talked about how the UK cycling team worked on 1% improvements. And I’ve heard several stories about Formula-1 racing teams who work hard to get 1% improvement. After all, Formula-1 racing cars are already pretty fast so getting 1% is pretty hard.

So what is it about 1%?

Surely 10% is better?

The thing is, 10% is going to be better but getting 10% is hard. Getting 1% can be hard enough, getting 10% can be 100 times harder. Even finding the things that deliver 10% improvement can be hard. On the other hand, for the typical software team, there are usually a bunch of 1% improvements to be had easily.

The trick with 1% is to get 1% again and again and again…

The trick with 1% improvement is… iteration: to get 1% improvement on a regular basis and then allow the effects of compound interest to work their magic.

The size of the improvement is less important than the frequency of the improvement. Taking “easy wins” and “low hanging fruit” makes sense because it gets you improving. Sure 10% may make a much bigger difference but you have to find the 10% improvement, you have to persuade people to go for it, you probably have to mobilize resources to get it and so on.

1% should be far easier.

Suppose you can get 1% improvement each week. Over a year that isn’t just more than 50% improvement it is well over 60% improvement – because each 1% is 1% of something bigger than the the previous 1%. Therefore a 1% improvement in week 50 is actually equivalent to 1.6% improvement in week 1.

Here is another spreadsheet where I’ve modelled this.

Suppose you have a team of 5. Suppose the cost $100,000 each per year, thats $500,000 for the team or $10,000 per week (to keep the numbers simple I’m calculating with a 50 week year.)

Now, suppose the team make a 10% value add, i.e. they add 10% more value then they cost, so each year they generate $550,000 of value. That is $11,000 per week.

Next, assume they improve productivity 1% per week. In week one they improve by $110, not much.
Week two they improve by $111, week three $112 and so on.

At this point you are probably thinking: why bother? – even in week 49 the team only add $177 to their total in week 48.

But… these improvements are cumulative. In the last week the team are delivering $6,912 more value than week one: $17,912 of value rather than $11,000. The total annual value added $159,095. That is $11,110 in week one, $11,221 in week two, …. $17,912 in week 47, $17,734 in week 48 and $17,559 in week 49.

The team are now delivering $709,095 value add per year – a 29% increase!

Put it another way: $159,095 is $31,819 per person per year, or $3,181 per week on average, and $636 per person per week.

At first glance this seems crazy: the team are adding 1% extra value per week, even in the last week they only add $177 of extra value compared to the previous week. But taken together over the year the power of accumulation means they are adding over $3,000 per week.

Go back to the start of this piece: you want to convince a budget holder. $177 isn’t even worth their time to talk about it but $3,181is.

Want to buy a book for everyone on the team? $30 per book is $150, do it.

A two hour retrospective? Thats 10 working hours for the whole team, about $2,200, well worth it.

Want to send someone to a 2-day conference, say, $1,000 for a ticket and $4,000 for lost productivity, $5,000 in total. If they come back with one 1% improvement idea then the conference pays for itself in one and a half weeks.

Suppose you invite a speaker from the conference to give a lunch and learn session. Say $1,000 for the speaker and $50 for pizza. If they give the team a 1% idea then it pays for itself that day.

Like it so much you buy a 2-day course? Now your talking big money. Although the $10,000 for the speaker is still less than the cost of having people not work. Five people each on a two day course means 10 days, $20,000 so $30,000 in total. That will take nine and a half weeks of 1% improvements. But then, one might hope that such a course delivers a bit of a bigger boost.

(Is now a good time to plug the agile training I offer? – or is that too blatant a plug?)

The important thing is to make iterate quickly and keep getting 1%, 1%, 1%. There should’t be time for agonising “Is this the best thing we should do?” – “wouldn’t doing X give more improvement than Y?” – just do it! The other ideas will still be good next week.

And don’t worry if it goes wrong. Not every possible improvement will deliver 1%, some will probably go so wrong they damage performance. Just recognise such changes don’t work and quickly back them out.

When you do the numbers it all makes sense.

Now you can call me 🙂

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

1% improvement Read More »

How much did it cost?

Business, Kanban / allan kelly / November 7, 2017

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.

How much did it cost? Read More »

Kanban paradox

Agile, Agile Process, Kanban, Scrum, Xanpan / allan kelly / October 31, 2017 / 3 Comments

For a while now I’ve been seeing a paradox with Kanban. Specifically, Kanban compared to Scrum.

For a team new to Agile – although some regard this as heretical I place Kanban under the Agile umbrella, yes I know its more about Lean than Agile but of cause Agile is itself a Lean method, anyway…

For team, specifically a software team, looking to adopt a new process there is a choice:

Kanban has a very low barrier to entry, to get started Kanban essentially says “visualise your work and manage the result.” Starting Kanban can be as simple as putting up a board and tracking work items. In Kanban visualisation should drive improvement. Change can be incremental and gradual. Change is rooted in learning.
Scrum has a far higher barrier to entry: essentially Scrum says, “Adopt Sprints, designate a Product Owner, appoint a Scrum Master and build out a backlog.” Once these changes are done you can run with Scrum and then the Scrum Master and retrospectives will kick-in and drive further improvement.

Interestingly, neither method says explicitly “Improve your quality.” Yet I always believe a lot of the success of Agile methods is down to good old quality improvement: writing fewer bugs and having fewer bugs to fix means greater predictability and more time to deliver valuable software. But I digress.

It is easier to start with Kanban because it requires less up front change. However that does mean the improvements are slower coming.

Conversely, Scrum drops in, changes a lot and most teams see an immediate improvement. Scrum relies less on subsequent change.

Because Kanban relies more on ongoing change it is more difficult. It is easy to get stuck at the “we built a Kanban board so we are doing Kanban stage.” Change in Kanban requires one to see the need to change, understand what will fix a problem and then follow the change through. That often requires experience. Thus in teams adopting Kanban there is a greater need for a coach, a consultant, someone who has done it before.

Scrum on the other hand makes far more changes upfront and the recipe for improvement is more straight forward. And of cause there are a lot more books on Scrum, blogs on Scrum, Certified Scrum Masters and Scrum experience out there. So while it is harder to get started with Scrum (because more needs to change) there is less need for further change and you change does not require the same level of knowledge.

You see this specifically when you look at statistics. Watching the numbers should be important in both processes but with Kanban it is near essential. Anyone with real understanding of Kanban knows that queuing theory, lead times, possibly weighted lead times, and a bunch of other numbers need to be examined.

Scrum on the other hand doesn’t go much further than a burn-down chart. Yes, making more improvement with Scrum will also benefit from understanding lead times, queuing theory and the rest but you can quite happily use Scrum, and even improve Scrum, a fair bit without understanding these ideas.

So here is the paradox:

It is easier to start with Kanban than it is Scrum without expert knowledge, but it is harder to improve Kanban than Scrum without expert knowledge.

In many ways I prefer Kanban but I find this need for expert knowledge troubling. I suppose I shouldn’t, I’m a consultant, I am that expert, people hire me to help improve their Kanban processes so it does make more work for me.

In the longer run, the Kanban approach is more likely to lead to a genuine all inclusive culture of improvement and is less likely to get stuck in a sub-optimal position – yes Scrum fixes things, but is it the best fix possible?

Looked at like this gives me a new perspective on Xanpan.

I wanted Xanpan to be two things:

An understandable description of actually following an Agile process, specifically a Kanban/XP hybrid processes
An example of how, and why, teams should create their own processes.

The same paradox is here: Xanpan should be easy to start but allow you to improve; creating your own process requires a bit more knowledge that only really comes with experience.

To step back a minute and ask another question: What amount of change can a team handle to start with?

I find that I advocate more initial change than I used to. Because I’m fearful of creating a learned dependency I really want teams to learn to change and improve themselves. But… once a team has decided to change I want to seize the opportunity and install a bunch of changes while enthusiasm is there.

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

Kanban paradox Read More »

Books update: User Stories, Continuous Digital and Project Myopia

Agile, Digital business, Requirements / allan kelly / October 27, 2017 / agile

Someone told me the other day “I can’t keep up with your books” – and you know what? I’m not surprised, it has been a busy couple of months for me on the books front but actually, there has been very little new writing – except with this blog.

First off, “Little Book of Requirements and User Stories” is now available in print.

This is a collection of pieces I wrote for Agile Connection a couple of years back which I compiled into an e-book. Sales of the e-book have been good, especially since I put it on Amazon and so, after a couple of request I’ve created a print version.

Right at the moment I’m amazed that Little Book is ranking as the 46th best seller in systems analysis and design which I think makes it a best seller!

The cheapest way to get the book is to buy thee-book on LeanPub. Amazon (all sites) have both print and ebook versions but they are more expensive. If you would like a copy for free please write me a review on Amazon UK and I’ll post you a copy – first six reviews only!

Next… Continuous Digital and Project Myopia….

Continuous Digital began life as #NoProjects, then Project Myopia, then became Continuous Digital. The name changes reflected the way my own thinking grew and changed. What began as a critique of the project model grew into an alternative model in its own right. In doing so it became something different, hence Continuous Digital.

But the more Continuous Digital stood alone the more the original chapters looked out of place. So I decided a few weeks ago to bundle them into their own book: Project Myopia.

I hope readers will find them complementary although I think they both stand alone. Both are only available as e-books on LeanPub, indeed there is an LeanPub bundle “Rethinking Projects” containing both. That said, right now Continuous Digital contains a coupon which allows readers to download Project Myopia for free. (It won’t be there for much longer.)

Splitting Continuous Digital in two has allowed me to race through my editing. There is still some work to do but content wise the book is pretty much done. It will remain a LeanPub only e-book for a little while longer and then…

Project Myopia would benefit from some more editing but I have no great plans to change it much. The changes I would make are all covered in Continuous Digital anyway.

Please, if you have any comments on any of these books, or suggestions to make them better let me know.

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

Books update: User Stories, Continuous Digital and Project Myopia Read More »

Books update: User Stories, Continuous Digital and Project Myopia

Agile, Digital business, Requirements / allan kelly / October 27, 2017 / agile

First off, “Little Book of Requirements and User Stories” is now available in print.

Right at the moment I’m amazed that Little Book is ranking as the 46th best seller in systems analysis and design which I think makes it a best seller!

Next… Continuous Digital and Project Myopia….

But the more Continuous Digital stood alone the more the original chapters looked out of place. So I decided a few weeks ago to bundle them into their own book: Project Myopia.

Project Myopia would benefit from some more editing but I have no great plans to change it much. The changes I would make are all covered in Continuous Digital anyway.

Please, if you have any comments on any of these books, or suggestions to make them better let me know.

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

Books update: User Stories, Continuous Digital and Project Myopia Read More »

The Solution defines the Problem

Agile, Requirements / allan kelly / October 24, 2017

How many times have you encountered a user/customer/client who describes the thing they want in terms of Microsoft Excel? – “What I want is a macro in Excel to pick up all these data points and then…”

Many a Business Analyst has started from this point and worked back to discover what the clients real “problem” is. Quite possibly the client never considered themselves as having “a problem”. Quite possibly the “problem” would never have been spoken about it the client didn’t have an understanding of spreadsheet technology. And in the days before spreadsheets were invented the task may have been tiring, time consuming and prone to error but, thats just how it was.

Regardless of whether Excel is the solution they finally get, or not, it is only because they can imagine a solution that a problem can be defined. In fact, the Solution defines the Problem.

Excel is not the only example…

I was travelling on the London Underground the other day when this advert leapt out at me: “Estimated bills got you in a spin? Get accurate ones with a smart meter”. What?

Really, I mean: What?

I’ve been paying electricity, gas and other metered bills for over 20 years, not only have I never “got in a spin” about an estimated bill but I’ve never given it two thoughts. Neither can I ever recall anyone saying to me “Gee I hate estimated bills… they are so much hassle…”. OK, maybe some people have but so few that it hardly ranks as a world class problem.

Actually, now I think about it: I prefer estimated bills. It is hassle having a meter reader come to the door and having to show them the meters. And it is even more hassle reading my own meter, finding the box key, writing the reading down, trying to log into a website, doing “forgot my password” …

This advert, this whole product, is a great example of Solution Defines the Problem. Estimated bills are not a problem until you to have a solution.

Yes I know Solution defines Problem is hearsay to some. We are supposed to find the problem and work backwards from the problem to the solution, outside-in.

Yes I know that all you Business Analysts and Product Managers were trained – as I was myself – to look for the problem and then define a solution: a solution that might just happen to be technology based, and might just happen to be software.

And Yes I know to many of you the idea of a company creating “a problem” so they can then solve it is morally repugnant but… lets think about it for a minute.

What problem does the iPhone 8 solve? What was at the front of Apple’s hive-mind when they designed the iPhone 8?

And what problem does the iPhone 8 solve that the iPhone 7 didn’t solve? Or for that matter the iPhone 6? 5? 4?

(I mean “what customer problem”, one could argue the problem the iPhone 8 solves is Tim Cook’s need to have more sales revenue.)

Solving problems is not enough.

I’m not saying outside-in, problem first, innovation and development doesn’t work. Clearly such an approach has work in many cases. What I am saying is: it is not always appropriate; sometimes a more effective way of working is inside-out.

What can the technology do?
How can we make people’s lives better with this?

This approach too has a number of success stories. Rather than condemn it as “wrong” maybe we should be asking “When and where does it work?” and “Which approach is the most appropriate?”

When creating a new thing – be it software, hardware or services – our understanding of the problem evolves as our understanding of the possible solution, or solutions, evolve. One starts off thinking of a solution, or a problem, we seek to understand some more – maybe by building part of a solution or by talking to someone we think have the problem, we learn a little, maybe we continue in this mode or maybe we flip and work on the other side of the equation. And round we go again, iteration.

It is a learning cycle, the question is, what is the fastest way to learn?

I included the solution-problem hypothesis in my Agile Cambridge keynote last month. Afterwards I was e-mailed by someone whose email I’ve now lost (apologies!) and recommended a book: Overcrowded by Roberto Verganti.

Roberto Verganti, takes a similar but different approach to the same question. For him the key is: meaning. At first I wasn’t quite sure if “meaning” was the right word but as I’ve read more I think it is, albeit meaning in a fairly broad sense.

Verganti’s argument isn’t quite the same as mine but it is close enough, he is also arguing for starting with a solution and working backwards. For him the aim is to create new meaning, you might say that he identifies a generic problem “Humans needs more meaning in their world.”

Try the iPhone test in this context too: “What is the meaning of the iPhone 8?”

I’m going to be talking more about this in my keynote to TopConf in Tallin next month, in the meantime please let me know what you think. Madness?

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

The Solution defines the Problem Read More »

Reflections on learning and training (and dyslexia)

Agile / allan kelly / October 17, 2017

German readers might recognise the image above as a Nuremberg Funnel. For the rest of you: the Nuremberg funnel represents the idea that a teacher can simply open a students head and pour in learning.

First off, a warning: this blog entry might be more for me than for you, but its my blog!

Still, I expect (hope) some of you might be interested in my thoughts and reflections on how training, specifically “Agile training” sessions. More importantly writing this down, putting it into words, helps me think, structure my thoughts and put things in order.

Shall I begin?

I’m not naive enough to think training is perfect or can solve everything. But I have enough experience to know that it can make a difference, especially when teams do training together and decide to change together.

One of the ways I’ve made my living for the last 10 years is by delivering “Agile training.” I don’t consider myself a “trainer” (although plenty of others do), I consider myself more as a “singer songwriter” – it is my material and I deliver it. I’ve actually considered renaming my “Agile training” as “Agile rehearsal” because thats how I see it. I haven’t because I’d have to explain this to everyone and more importantly while people do google for “Agile training” nobody searches for “Agile rehearsal.”

Recently I’ve been prompted to think again about how people learn, specifically how they learn and adopt the thing we call “Agile”. One unexpected experience and one current challenge have added to this.

A few months ago I got to sit in while someone else delivered Agile training. On the one hand I accepted that this person was also experienced, also had great success with what he did, also claimed his courses were very practical and he wasn’t saying anything I really disagreed with.

On the other hand he reminded me of my younger self. The training felt like the kind of training I gave when I was just starting out. Let me give you two examples.

When I started giving Agile training I felt I had to share as much as possible with the attendees. I was conscious that I only had them for a limited time and I had so much to tell them! I was aiming to give them everything they needed to know. I had to brain dump… Nuremberg funnel.

So I talked a lot, sessions were long and although I asked “Any questions?” I didn’t perhaps give people enough time to ask or for me to answer – ‘cos I had more brain dumping to do!

Slowly I learned that the attendees grew tired too. There was a point where I was talking and they had ceased to learn. I also learned that given a choice (“Would you like me to talk about Foobar for 30 minutes or have you had enough?”) people always asked for more.

Second, when I started out I used to include the Agile Manifesto and a whistle-stop-tour of Lean. After all, people should know where this came from and they should understand some of the theory, right? But with time I realised that the philosophy of the manifesto takes up space and isn’t really important. Similarly, Lean is very abstract and people have few reference points. To many (usually younger) people who have never lived “the waterfall” it can seem a crazy straw-man anyway.

Over the years I’ve tried to make my introductions to Agile more experiential. That is, I want to get people doing exercises and reflecting on what happened. I tend to believe that people learn best from their own experience so I try to give them “process miniatures” in the classroom and then talk (reflect) on the experience.

These days my standard starter 2-day Agile training course is three quarters exercises and debriefs. My 1-day “Requirements, User Stories and Backlogs” workshop is almost entirely exercise based. I’m conscious that there is still more stuff – and that different people learn in different ways – so I try to supplement these courses with further reading – part of the reason behind printing “Little Book of User Stories” is to supplement “Agile Reader” in this.

I’m also conscious that by allowing people to learn in different mediums, and to flip between them they can learn more and better.

My own thinking got a big boost when I learned about Constructivist learning theory. Perhaps more importantly I’ve also benefited from exploring my own dyslexia. (Reading The Dyslexic Advantage earlier this year was great.)

Why is dyslexia relevant here? Well two reasons…

Firstly, something I was told a long time ago proves itself time and time again: Dyslexics have problems learning the way non-dyslexics do, but the reverse is not true. What helps dyslexics learn helps everyone else learn better too.

Second: dyslexics look at the world differently and we have to construct their own meaning and find our own ways to learn. To me, Agile requires a different view of the world and it requires us to learn to learn. Three years back I even speculated that Agile is Dyslexic, as time goes by I’m more convinced of that argument.

So why am I thinking so much about all this?

Well, I’ve shied away from online training for a few years now – how can I do exercises? how can I seed reflection?

Now I’ve accepted a request to do some online training. I can’t use my existing material, it is too exercise based. I’m having to think long and hard about this.

One thought is to view “online training” as something different to “rehearsal training.” That is, something delivered through the online medium might be more akin to an audio book, it is something that supplements a rehearsal. But that thinking might be self limiting and ignore opportunities offered online.

The other thing is the commercial medium. As my training has got more experiential and better at helping people move from classroom to action it has actually covered less. The aim is to seed change, although the classroom is supplemented the actual material covered in class is less; learn less change more! – Thats a big part of the reason I usually give free consulting days after training.

In a commercial setting where there is a synopsis and a price tag the incentive is to list more and more content. One is fearful of missing something the buyer considers important. One can imagine a synopsis being placed next to a competitor synopsis and the one with the most content for the least price is chosen.

So, watch this space, I will be venturing into online training. To start off with I’m not sure who is going to be learning the most: the attendees or the presenter! (O perhaps I shouldn’t have said that, maybe I’m too honest.)

If you have any experience with training (as a teacher or student), and especially online training, I’d love to hear about them. Please comment below or email me.

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

Reflections on learning and training (and dyslexia) Read More »