Here are the posts in the Agile Economics series:
Gambling Issues	Supply and Demand	Early and Often	Delusions of Grandeur
Scale and the City	Scale 3D	Cost of Change

In the agile world, we’re told to “embrace change”. As we can see in the picture on the right, change can embrace you back, and it can hurt.

But what is the cost of change? And how does agile affect it?

Economically speaking, change has both reasons and affects, and both have economic consequences.

In Winston Royce’s original waterfall document, he said a real waterfall process wasn’t possible, because of feedback between the different stages. That feedback is caused by learning events. We plan something, then we find out something new, that takes us off our original plan, and we have to change course.

What is the cost of the change?

We can divide the cost into 3 categories:

• The cost of the original work (waste).
• The cost of re-work (the correction we’ll have to do)
• The opportunity cost (what we could have done instead of both)

For example, if the developers introduced a bug, there’s:

• The coding time they put into that bug
• The fixing time and re-checking time as rework
• The opportunity cost of the new feature that was delayed.

We usually count these in time or work units, because that’s how we roll. We can convert these to monetary costs if we want.

But that’s not all of it.

There are also the long-term, cultural and social costs that cost with them. For example, with each bug found, the developers and testers don’t trust each other even more. The managers lose trust in the development team. When we lose trust, we put safeguards to replace it. These are bureaucracies and policies that take a toll on the development process, and make work even harder, causing delays and more costs.

However, let’s put the long term effects on the side. They are hard to measure anyway (sounds familiar, hmm). Let’s get back to the three main categories.

Our bug example: A found bug is a learning event. If that bug is found within a sprint, the total cost of fixing it would probably be a couple of days. The longer we get from where the bug was originally coded in, to when it was discovered, we usually pay more for the fix. It takes time to investigate, we break bigger things for the fix, and we have to do it instead of the other important stuff. So the time to the learning event matters economically.

Still, it can be worse. What if it’s not a just bug fix, but a complete feature, or a whole product? The waste gets bigger, the cost is enormous.

And in agile?

Any agile method will tell you that change is inevitable. The “embracing” part is the mind set. Delivering small batches is the practice.

Agile is a lot of things, but the main one is a risk reduction method. In our case, the risk is of wasteful cost of change. By working in small batches (lowering WIP, delivery in a short sprint, or building an MVP as an experiment), we reduce that risk.

Now, is building the MVP waste? If we’re sure of what we’re building, and there’s no need to change, there’s no waste. And we’re building the right product, not an MVP.

But if there is no assurance, we have to invest in learning. We have an idea that we are sure would work, so we build an MVP to test our hypothesis, and it completely disproves the idea. It is sunk cost, in terms of cost of change. But it’s not waste in terms of learning. Plus, it saved us a whole lot of money if we’ve built the whole product we were sure would work, instead.

Going back to our bear hugging metaphor, it is better to be hugged by a lovable bear cub, than by its mother. It hurts a lot less.

At least until she comes looking for it.