The Agile Architect

Reducing Agile Project Costs With Amortization

The Agile Architect explains how to reduce the cost of large efforts while immediately realizing the benefits. His secret: amortize!

• By Mark J. Balbes, Ph.D.
• April 17, 2012

"Amortize" is my new favorite word. Over my last few projects I've come to realize just how important the concept is (and it sure as heck is fun to say!).

At any point in a project, your development team may be confronted with a problem or initiative that traditionally takes considerable effort up front. The question I am always asking myself these days is, "How do I amortize the cost of this over time so I can start getting the benefits faster while paying for it as I go?"

Note that amortization is not technical debt. With technical debt, you are getting a benefit now that carries a future cost. Often that cost is higher than if you paid it at the time you incurred the debt. Neither is amortization simply a delaying tactic. Rather, amortization is the idea of only paying now for the things that you need now. Efforts that appear to be large are broken down into smaller chunks, and only those that are currently needed are addressed and paid for. With amortization, you don't incur technical debt because you pay as you go. Likewise, you are not delaying addressing a real and immediate need.

Amortization is already a natural part of agile. The traditional up-front efforts of requirements analysis, software analysis and design have been amortized over the life of software development through the use of emergent design, test driven development and the focus on stories rather than function points. The traditionally last-in-line effort of testing has similarly been amortized through the same techniques.

That's all awesome but what else can we amortize? Here are some examples.

Infrastructure Creation
In starting a new project with a new team, there is considerable infrastructure that needs to be put in place. Workstations need to be set up. Automated testing tools need to be decided on and put in place. The build server needs to be set up and an automated build created.

Well, not really...

At the start of a new project, you won't have any code or tests. As you develop your first stories, you'll certainly want to practice continuous integration; developers constantly committing their code and updating from the code repository while keeping all automated tests passing. But you don't really need a build server, at least not at first. The developers can accomplish the same goal (making sure all tests continue to pass) at the development workstations or manually on the target platforms.

Initially, the build server is a convenience. At some point, and it may be fairly quickly or may be never depending on the project, the build server becomes essential to maintaining the passing tests. This tipping point usually happens when the time it takes to run all the tests is longer than the developers are willing to wait.

What's your process for risk management? Don't sweat the details. Put a thin process in place and adapt as you learn. It might be sufficient to identify and review risks at your project retrospectives. As you understand the risks better, you can determine how you will monitor and mitigate them. But why try to guess up front?

What metrics is your team going to track and where? You'll almost certainly want to track velocity and story burn-up. Add other metrics as you discover you need them, e.g. to monitor risk. Don't spend time up front inventing metrics or using metrics from your last project "just because."

And now that you know what the metrics are, what tools will you use to track them? Unless you've got something ready-made, this can be a tough decision. Are you tracking in an Excel spreadsheet, on a wiki, in SharePoint? Do you install tools to collect metrics for you like VersionOne or Rally? Avoid the overhead of investigating, acquiring, installing and learning a new tool by collecting your metrics manually at first. Once you understand what metrics you want to track, why you want to track them, where you find the data and how you collect the data, you'll have a better understanding of the features you'll need in your tools. By amortizing the cost of making and implementing the decision over time (understand/collect metrics now, evaluate tools later, install and learn the tool, integrate the tool into the team process), you can make a better decision at the right time to make it.

Story Creation
Any new project needs to create its backlog of stories and size them in order to determine project scope. Scope plus velocity provides the metrics to determine how much value the project is delivering and whether the project is on time. But you don't need all the stories in order to start development. In fact, you just need the first one. While that story is being developed, the rest can be written. Pretty soon, you'll have your initial story backlog, but the team didn't have to wait for it to get started.

Payment of Technical Debt
It's not uncommon when starting a new agile project to inherit a code base that was developed with more traditional techniques. In this case, the team immediately inherits a large amount of technical debt. To pay back this debt up front is usually cost prohibitive. My previous column, "Dealing with Technical Debt: An Agile Horror Story," discusses how to pay back this cost little by little.

Design and Architectural Vision
The idea of amortization can also be applied to more abstract concerns. We all know that "big design up front" doesn't work well and that agile techniques allow you to follow a practice of emergent design. Sometimes, though, the technical problem is not that straight-forward. Let me give you an example.

One of my projects has a large mapping component. Think Google Maps but without requiring Internet connectivity. GPS-enabled devices that connect to our system report their position and display on the map in real time. We had built our map tool using a mapping engine that had since become out of date. This made it hard for us to continue adding new features. But since we had a large number of custom features, it would be very difficult and costly to switch to another map tool.

Then our moment of opportunity came. Our users were asking for a new feature on the map. Rather than displaying a static map with devices moving around on it, they wanted to be able to lock the display to a specific device. In this way, the device would stay at the center of the screen with the map and everything else moving relative to it. So once again the team was sitting around discussing how to implement the story by shoehorning it into the existing functionality, all the time wishing we could be working with a modern mapping engine.

I wish I could say what happened next was my idea because it was absolutely brilliant. One of the members of the team suggested that we build this new capability as a new tool called a Device Tracker. Once the map is moving, most of the tools we have become irrelevant. For example, you aren't going to try to draw on a moving map. This meant we wouldn't have to rebuild much of the existing functionality. And since it was a new tool in our system, we could use the new mapping engine. This would give us the experience with the new engine while continuing to maintain our old map tool.

And that's exactly what we did. We've had two years of supporting both tools, all the while continuing to improve the capabilities in the device tracker and amortizing the associated costs over that time period. With our next release, we finally will have enough capability in the device tracker to also use it as our full-featured map tool. We didn't have much overhead in supporting both tools, the cost of moving to the new tool was spread out over two years, and our customers were never without all of their features. In fact, even now they don't realize we switched map tools on them.

Final Thoughts (and a Word of Caution)
Using all of the techniques described above and more (I can't tell you all of my secrets, now can it?), I recently started up a new development project with a new team. We wrote the first story on day one and were developing it on day two. In parallel, we continued to mature both our story backlog, our processes, and our infrastructure, all amortized over the subsequent six weeks.

One thing to be wary of is how amortization can cause your metrics to lead you to the wrong conclusions. In the example above, we initially had an artificially low velocity. For the first six weeks, we were continuing to work on start-up activities that took away from our development time. Although our velocity looked disappointing on paper, we had at least a three-week head start over an up-front effort to create all the infrastructure we needed to support the project. As the weeks went by, our velocity continued to climb as the amortized start-up costs continued to decline.

The concept of amortization fits in with the agile philosophy of thinking while doing rather than thinking and then doing. So the next time you face a big decision that looks like it requires a large, up-front effort, regardless of what it is, ask yourself, "How can I amortize this?"