#87-Managing Legacy Debt in Agile Projects

An agile approach focuses us on business value, constant improvement, and building quality into everything we do.  But what about the older systems that we have inherited?  That is the focus of this week's episode.

Transcript

Managing Legacy Debt in Agile Projects 

Here the use of the word legacy simply means “from the past.” Unless you are engaging in a startup project that is starting from literally nothing, you have some degree of legacy debt. 

This might be code that was written under older standards, not tested and not particularly testable, and difficult to extend, tune, and maintain. It might be a system that is based on older architecture that has been eclipsed by better options, or that has outgrown the capabilities of that older system. It could be documentation that has gotten radically out of date with the systems as they have grown and changed, or documentation that you are hesitant to rely upon because you're not sure if it is still accurate. It could be many things. 

But ignoring legacy debt is like ignoring the check engine light in your car. The longer you wait the more likely that serious damage can be incurred, that light may start flashing, and eventually the entire system may become unusable. At the very least, it may become increasingly expensive to maintain. 

If you want to be agile in your approach to legacy debt, you do not want to try to tackle it in one big, massive effort. Just as we develop new behavior, we want to improve our legacy systems incrementally over time. Here I want to examine the steps involved. 

The first step is in identifying where your legacy problems are. I strongly recommend that you do this collaboratively as part of requirements analysis at the beginning of any increment of work. The focus should be on determining where the pain points are with the legacy systems as we attempt to move forward with new development.

Here is where agile metrics are particularly useful: lead time, cycle time, and number of defects reported from the field. I covered these in detail in a previous episode but since you will be measuring them already, they will be available for this discussion.

This will generate a list of tasks for legacy improvement that can be tracked and prioritized just like any other work in an agile process. 

Next you need to balance the effort you place into legacy improvement against the effort you place in creating new value.  In my experience a number between 10 and 20 percent is usually correct, but your mileage may vary if your legacy issues are more profound and if they are causing more damage to your progress. 

As with most requirements, I recommend that you begin by performing commonality-variability analysis on your legacy problems and then write acceptance tests to capture the goals in improving them. See the transcript for a link to a webinar describing commonality-variability analysis in detail. 

There will usually be a lot of tasks involved when dealing with legacy limitations. How should you focus your efforts? I think high priority should be given to those things which need to be changed because of new requirements. Most legacy systems are not tested, or not particularly well-tested, because they are difficult to test. The refactoring tasks associated with them should be focused on making them more testable, then bringing them under quality tests, and then changing them safely.  Remember that changes in an agile process must always follow this rubric: 

1. Change the test

2. Watch it fail

3. Change the system 

4. Watch the test pass without changing it again  

This is only possible when the test exists.

You also want to make sure that you are not introducing new problems for the future, and this means adopting a kind of Hippocratic Oath when it comes to legacy systems: 

“First, do no harm.”

Or another way to think of it is to say that we must behave like boy scouts on a camping trip: leave the area as good as you found it, or at least a little bit better. 

Approaching your legacy debt in this way ensures that you do not impede progress on new requirements, but also that you are gradually reducing the cost of that debt.  It is focused on value, as all agile approaches should be.

But we must be constantly improving our process.  That’s part of agile too.  This means we must consistently ask what is working and what is not, under the assumption that what worked yesterday may not be working anymore.

Next week I will discuss agile retrospectives and feedback loops.  Catch you then!

Recorded Webinar on Commonality-Variability Analysis:

https://www.projectmanagement.com/webinars/863805/commonality-variability-analysis