Managing Technical Debt in an Agile Project

Do you have a product owner who doesn’t want to admit to technical debt? “Give me another feature! And another feature! Just keep giving me features! It’s feature time, baby!” Once a product owner has the heady feeling of seeing features one after the other, it’s difficult for that product owner to consider anything other than features in an agile project.

I can understand when a product owner wants features first. But if you are working on a legacy product, you have technical debt. The product owner must also rank technical debt.

Technical debt is what you owe the product in unfinished work: for example, incomplete architecture, insufficient automated tests, insufficient refactoring, design that can’t be extended. Sometimes you have technical debt because you rushed through a feature. Sometimes it’s because you didn’t see where the architecture or design was going. Maybe you don’t have enough testers. Whatever the reason, you have it. If you don’t address technical debt, eventually it prevents your project team from adding features.

But some product owners have “feature-itis”, an inability to see the technical debt. If you have a product owner like that, you will work with both the project team and the product owner to manage the technical debt.

Because any project team who doesn’t manage its current and legacy technical debt, will eventually discover that it is impossible to produce features. It’s a slippery slope. Here’s what an agile project manager can do to work with a project team and a product owner.

Help the Project Team Avoid Any Current Technical Debt

As a team produces features, the team must discuss what done means, so they don’t incur any current technical debt. They must address architecture debt, design debt, test debt, any kind of technical debt they can imagine. A product owner who has “feature-itis” might push the team to take shortcuts and push for shorter delivery times for features. Teams might want to please that product owner and push themselves to take shortcuts to deliver features.

As the agile project manager, if the team wants to appease the product owner, you can offer the voice of reason. You could say, “Are we meeting our definition of done? If not, why not? Is our definition of done sufficient for our product? Will we be able to make progress with this definition?”

Your job is not to play traffic cop—not at all. The team is self-managing. Your job is to help facilitate the team and to remind them of team norms. Your job is to make sure the team has demos and retrospectives and make sure that the team commits to reasonable commitments and delivers on their commitments.

One of the problems I see with “feature-it is” product owners is that team members worry so much about pleasing the product owner that they don’t always perform their good engineering practices. They don’t always perform all their testing when they should. They don’t always pair when they should. They don’t always ask for help on their designs.

You, as the agile project manager, might be able to help by keeping the product owner at a safe-enough distance from the team so the team can breathe a little. For one team, the product owner was literally in the team room every minute of every day. You might think this would be great. But he wasn’t developing tests or acceptance criteria or grooming the backlog. He was asking whether the story was done yet. And, the stories were not small enough that even with swarming, the entire team couldn’t finish them in one day.

That project manager helped by working with the product owner to groom the backlog to decrease the story size until the stories were small enough that the entire team could complete one story in less than one day. That took the “are you done yet?” pressure off the team and allowed them to use the engineering practices they needed to use to avoid incurring any more technical debt.

Manage the Legacy Technical Debt

A more common problem is how to manage technical debt that you encounter as you add more features to a system. Imagine this scenario: You want to add an additional part of feature to an existing product, say the ability to save a voicemail as part of a cell phone application. You can already hear the voicemail, now you want to save it. As you add the “save” part of the feature, you realize you have technical debt, and you need to decide what to do.

Do you refactor as you go, cleaning up? Or, since it’s a legacy product, and it’s been around for ten or more years, and since you have significant redesign work, you make a card and put it on the backlog and wait for the product owner to rank the work?

This example may be clear—you have to have the functionality. But how you fix it is not clear. Do you do a little fixing, papering over the problem? Do you do a redesign? There is no right answer. One thing you do not do is to behave like an ostrich and avoid the problem.

This is why I am a fan of addressing small problems when they are small. But with a legacy system comes legacy debt, which tends to be large. So you need to talk to the product owner and convince the product owner that he or she cannot avoid all technical debt. It is in the product owner’s best interest to at least do some spikes (small timeboxes) worth of work to understand the extent of work required for more of the technical debt.

If they can, it’s great if the project team can deliver some fixes out of the spikes. That’s a big if. They can’t always do so, and don’t let anyone demean them if they can only deliver an estimate. An estimate is what you need out of a spike. If you can get small fixes, that’s great, but not expected.

The real issue is you need to have the product owner own the backlog of technical debt as well as the features. I like to have the product owner address this technical debt in the product backlog. When I have a reluctant product owner, a product owner with “feature-itis,” I ask the product owner to put the technical debt on the product roadmap.

Ask for a Product Roadmap

When the product owner creates the roadmap, the project team can see the product vision. That allows the project team to see where fixing some of the technical debt fits. The project team can have this kind of conversation with the product owner, “If we don’t fix this kind of debt in front of this feature or set of features, we won’t be able to deliver this kind of feature then.”

Note that the entire project team has to be involved in this conversation, because technical debt is not limited to architectural debt. Technical debt can be automated test debt; or lack-of-clarity-around-design debt, so that if the product owner wants new features over there, no one understands how to safely change that part of the code.

What About Defects?

I haven’t been clear about the difference between technical debt—what you owe the system in terms of delayed refactoring or delayed completeness in some form, and outright mistakes, defects. I’ve met some product owners who wanted to postpone fixing defects in lieu of producing more features, too.

Sometimes, in certain markets, for short time periods, it can make sense to postpone fixing defects. But, the longer you postpone fixing defects, the worse they are to fix. The more debt those defects accumulate. As the rest of the code evolves, those defects become more difficult to fix. The worse everyone’s memories are about why we wrote the code this way.

As an agile project manager, you can help both the project team and the product owner.

For the project team, help them realize that the most helpful definition of done is one that includes fixing defects as soon as anyone on the team discovers a defect. So if someone discovers a defect in this iteration, the team fixes that defect in this iteration. That’s it—no muss, no fuss. The team can decide whether to log the defect in a tracking system or not. Some teams leave room in their iteration for defects discovered in this iteration for stories they complete in this iteration. They assume they will discover issues, and rather than log them, they fix them. They log defects for stories they completed in a previous iteration.

For the product owner, explain that the project team should leave the code or tests cleaner than they found it every time they enter a piece of code or tests. If they stumble over a defect and they realize what the problem is, and in order to implement this feature, if they can fix it, they should. They should also get review, either from pairing or after the fact, but they should not leave the defect for later. Cleaning up the development code base or the test code base as they proceed is something they should want to accomplish. It’s okay if the project team has a time limit on the cleanup. So, if someone realizes it’s a 30-minute fix, it’s okay to make that fix, even though it will be an hour review and another test to write. But if it was going to be a two-hour fix, that might be outside the limit for this team. What’s key is that the project team agreed in advance on what was acceptable.

Everything Depends on Reasonable People

As always, everything depends on everyone being transparent and reasonable. Product owners acquire “feature-itis” because they see steady progress from project teams. It’s a relief! We can understand how a product owner can contract “feature-itis.” But, without paying attention to technical debt or defects, “feature-itis” will cause more technical debt.

An agile project manager can facilitate the discussions and the resolution between the project team and product owner to move from “feature-itis” to a great product. Use the transparency and all of your influence tools to help the product owner and the project team to make progress with every feature and iteration to better the product.

© 2012 Johanna Rothman. This article was originally published on Gantthead.com

Tags: , , , , , ,
Previous/Next Posts
« »

Submit a Comment

Your email address will not be published. Required fields are marked *