Transition to Agile, Large Technical Debt, Small Project

Many months ago, Rebecca asked an interesting question about technical debt in projects. She asked,

How to start when there’s a really big mess? In that case, small, just being a professional clean-up acts may not even make a dent.

Of course, as with any good question, the answer is, “it depends.” And the biggest flavor of depends is whether the project is large or small and if the project is collocated or distributed. For the sake of argument, let’s assume it’s small and collocated.

When you transition to agile and you have a reasonably size codebase, chances are quite good that you’ve been working on the product for a while. You have legacy code. You might have legacy tests. You certainly have legacy ways of thinking about the code and the tests. How do you work yourself out of the technical debt you have accumulated over time? Can you approach the work in the way I outlined in Thoughts on Infrastructure, Technical Debt, and Automated Test Framework?

Yes and No. Let’s assume that for some small set of features you can eat some small pieces of debt. And, you have so much debt, that there are some areas of technical debt that you just do not want to touch those areas of code, or that if you touch those areas, you know you are going to wade into quicksand. You know you have to create more tests than you have “time” to create. That is, the size of the story is significantly smaller than the size of the debt, even with swarming.

Now, what do you do?

You tell people. You tell the product owner. You tell your colleagues. Me, I would probably write some tests for the code anyway, because I would want to know the next time I wade into quicksand. But I have much more gray hair experience now than I did when I was younger, so I make different choices about the product.

If I was a project manager for this project, I would want to know, because I would want to manage the risk. In my experience, that much technical debt affects a team’s ability to produce features. And, if I was a product owner, I would want to know, because the technical debt would affect our ability to do anything with the product.

And, this is a case, where you might want to consider having three backlogs as a funnel into one backlog for an iteration. Read Might Three Backlogs Be Better Than One? And, make sure to read all the comments. They are quite insightful.

The idea is you still only have one backlog for the an iteration. But you have visibility into all the work you have to do that you want to rank for the product.

It’s easy in hindsight to say, “Don’t get into that situation.” Well, duh. But organizations are in this situation. And, they need help. I still think the best answer is to pay off the technical debt is to work in small features and pay off the debt as you find it. That way you never pay off more than you need to, you never do more architecture work than you need to, and you never have this strange backlog issue.

On the other hand, some people don’t realize how much debt they have. Anything that helps them see what they have is useful. But maybe there is a better way. Maybe you have a better way?

Let me summarize:

  1. Pay off technical debt when you implement a story, if you can.
  2. Swarm to start and finish a story. This will help you avoid and pay off debt.
  3. Write more tests to expose the debt, so no one is surprised in the future.
  4. Expose the debt by creating a debt backlog so the debt can be ranked in preparation for iteration planning.
  5. When planning an iteration, take the top item off the debt backlog. Do pairwise comparison of that item with the top item on the feature backlog. Which item has more value? Put that item on the iteration backlog. Continue until the team says, “Stop, we cannot do more in this iteration.”
  6. Your very last solution is rearchitecting. Why? Because it prevents you from making progress in the project. Read Startup Suicide – Rewriting the Code. It’s not just suicide for startups.

Always make sure the technical debt is visible. That is key to managing it. Whether you like my solution(s) or not, make the debt visible. And, if you don’t like any of my ideas, please do comment. Heck, comment if you do like them. I would love to know what you think.

About Johanna Rothman

I help managers and leaders do reasonable things that work.
This entry was posted in agile and tagged , , , , . Bookmark the permalink.

11 Responses to Transition to Agile, Large Technical Debt, Small Project

  1. YvesHanoulle says:

    Hi Johanna,

    I wrote a blog post about this, some time ago:
    http://www.hanoulle.be/2010/04/cleaning-a-kitchen-a-good-metaphor-for-refactoring/

    I think that small refactorings can get you very far. (The other know way to say this, is the BoyScout rule: leave the camp place nicer then you found it…

    y

  2. Johanna says:

    Yves, yup, I agree. When I taught my daughters to cook, I taught them to clean up as they proceeded. Otherwise, you have a whole pile of dirty dishes at the end, when you are so tired of cooking. But if you clean as you go, it’s not so tiring.

  3. Jason says:

    I’d just like to quickly speak up and say that these tips constitute a real and valuable piece of guidance. They are appreciated. Thank you.

  4. LazyFan says:

    This is already dealt with by Scrum.
    In the Scrum approach you are supposed to put at least one task into every sprint that will deliver a technical only requirement. In this case it could be a task that solves some technical debt.

    Now that’s ‘at least one’ you can always do more if you have some big technical debt issues to resolve.

  5. Johanna says:

    Jason, my pleasure!

  6. Johanna says:

    Hi Rickard. Yes, it is already dealt with by Scrum, if you put it into the backlog. Sometimes, the problem is framing the story as a way to deliver the story as delivering end-user value. Some product owners have what I call feature-itis. See http://www.jrothman.com/blog/mpd/2011/06/do-you-have-feature-itis.html . Feature-itis prevents people from seeing technical debt. The backlog forces transparency. And, you don’t have to like my proposed solution!

  7. Steve says:

    While devs understand technical debt they for the most part don’t see things in terms of agile. They see it in terms of stress. This was a good book that helped me in the company that basically was a sinking ship and no one was going to save it…
    http://www.manning.com/baley/

  8. Pingback: Transition to Agile, Large Technical Debt, Small Project - PM Hut

  9. Nils says:

    Very nice post. Thanks for the valuable tips!

  10. Pingback: Large Technical Debt, Small Project | Brent Sordyl's blog

  11. Steve Zhang says:

    Just want to comment another bad example of rewriting code, from Joel:
    http://www.joelonsoftware.com/articles/fog0000000069.html

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>