The Second Metric: Cost of Change

After attending a less than impressive presentation on agile metrics by a top metrics guru I was motivated to write this series on real agile metrics. This is the second metric, or,  perhaps better stated the forgotten metric.

Some of the earliest and best writings on what would be later called agile were by Kent Beck and his associates. They wrote extensively about a key goal being to flatten the software development cost curve. That is, the cost to make a change near the beginning of a software development initiative is close to the cost of making the same change later in the software development initiative. A whole series of software engineering practices are required to flatten the cost curve which are included in Kent’s Extreme Programming and totally absent from Scrum.

Flattening the cost curve is important because a vast majority of the cost of corporate IT systems is not during initial development but during long term system maintenance, support, and enhancement. Many IT systems last ten to twenty years or more. For these systems eighty to ninety percent of the cost of the system is likely to occur in maintenance and new features.

The Second Metric in Agile software development is a measure of the difference of a cost of a change over time.  The Second Metric is Cost of Change Delta.

Here is a simply way to understand this metric. Go to any screen in your system and ask the software developers to estimate the effort to add a new field to the screen and to be able to create, read, update, and delete (CRUD) the data.

In traditional Waterfall development models a request for a new data field early in development are very cheap, and the same change later in development is very expensive, perhaps hundreds of times more expensive than an initial change. This is why Waterfall development projects try to get all the requirements right at the beginning and try to get them all in quickly—it saves a great deal of money.
Lets look at two cases, project A & product B.

In project A we observe an estimate to create a new CRUD field on the user interface is $1,000 early in a project. Later, the cost of that same change is estimated at $150,000. Cost of Change Delta is 150x.

In product B we observe an estimate for a new CRUD field on the user interface is $1,250 early in product development. Later, the cost of that same change is estimated at $1,500. Cost of Change Delta is 1.2x.

Project A’s cost of change delta is what is seen on many Waterfall projects, and Product B’s cost of change delta is what is seen on a well-implemented Agile product. The lower the cost of change delta the more likely your software is truly agile.

Want to measure your agility?

Track a cost of change delta over all of your projects and products.

The Second Metric is essential for understanding the agility of your entire system. If your Cost of Change Delta is high you are not particularly agile. It is likely your code base was created with little or no attention paid to key agile engineering practices.

 

I attended a presentation by one of the top agile metric gurus for a leading Agile tool vendor. Their tool tracks user stories, tasks, points, hours and generates charts and reports. Because over 35,000 “projects” have been captured with the tool the company did a great deal of analysis across…
In agile it is said that a user story “Is a place holder for a conversation.” In much the same way, in agile “A metric is a trigger for a conversation.”  Those seeking enterprise agility are almost never interested in stop-light metrics “red—yellow—green.” Instead they are interested in trending metrics.…