Featured in
Architecture & Design

Mini-talks: The Machine Intelligence Landscape: A Venture Capital Perspective by David Beyer. The future of global, trustless transactions on the largest graph: blockchain by Olaf Carlson-Wee. Algorithms for Anti-Money Laundering by Richard Minerich.

Featured in
Process & Practices

In-App Subscriptions Made Easy

There are various types of subscriptions: recurring, non-recurring, free-trial periods, various billing cycles and any possible billing variation one can imagine. But with lack of information online, you might discover that mobile subscriptions behave differently from what you expected. This article will make your life somewhat easier when addressing an in-app subscriptions implementation.

Featured in
Operations & Infrastructure

Mini-talks: The Machine Intelligence Landscape: A Venture Capital Perspective by David Beyer. The future of global, trustless transactions on the largest graph: blockchain by Olaf Carlson-Wee. Algorithms for Anti-Money Laundering by Richard Minerich.

Featured in
Enterprise Architecture

Mini-talks: The Machine Intelligence Landscape: A Venture Capital Perspective by David Beyer. The future of global, trustless transactions on the largest graph: blockchain by Olaf Carlson-Wee. Algorithms for Anti-Money Laundering by Richard Minerich.

How To Pay Down Technical Debt

Paul Tevis is on a team that is four months into a Scrum transition. The project has a significant amount of technical debt, and he is wrestling with the problem of how to track and pay down that technical debt. Tevis writes:

My concerns are (1) as soon as we start tracking non-story tasks we'll lose focus on delivering customer value, And (2) if we don't make these sorts of tasks visible, we won't make progress on them at the rate we need to. What are good patterns you've seen for dealing with technical tasks that aren't directly attached to a story (or that cut across multiple stories)?

What is technical debt? Ward Cunningham coined the term "technical debt" to refer to an obligation that an organization takes on when it decreases the quality of its code base in order to meet short-term goals. Bringing code quality back up invariably costs more to do later on than it would have if quality had been addressed immediately. This extra cost represents the "interest" on the technical debt.

There are a lot of reasons for taking on short term technical debt. I use the analogy of the credit card with a 36% interest rate. You do not want to use that card. But there are times when it makes great business sense to use that card in a short term situation.

Do you really have such a difficult choice to make? I would think that if your 'technical' development requirements are so important and so big, or so many, isn't it a practical thing to do to call a timeout on user-facing development, and get those technical matters squared away and off the table?

Or, is it possible to reassign some developers to get these technical matters done, while the rest of the team continues on the user-oriented stuff? This may affect team velocity, but so what?

Working on the "technical matters" works best when it is driven by stories. The code base is probably in need of work everywhere, but the payoff will be received only where the code is going to be worked on for user-facing reasons. If no stories are going to pass through some crufty area, working on it is largely wasted.

Therefore, I prefer the approach of taking stories as usual (but probably fewer of them), and following the "boy scout rule" of leaving the campground better than you found it. In other words, wherever the stories lead us, let's write more tests, let's refactor more aggressively.

This approach has at least these advantages:

maintains "best sensible" flow of stories;

provides help from all team talent;

provides for whole team to learn how to keep code clean;

focuses improvement exactly where it is needed;

does not waste improvement that "may" be needed;

... and probably more.

And "banshee858" offers this suggestion (with original credit to Tobias Mayer) that dovetails nicely with Jeffries' approach:

List all the technical debt stuff on little post-it notes Adjacent to the Task Board. When a Product Backlog item (PBI) is selected for a Sprint, look at the technical debt pieces and find the pieces that make sense to finish while working on the PBI. Add those to the scope of work for the PBI and estimate how long it will take to complete the feature and the technical debt pieces.

That way you make the technical debt work visible, you can prioritize it and link it to real value.

Technical debt issues should be approached as any other task. I find it helpful to track it in each retrospective using the planning poker cards. Each team member votes on the percieved debt. Track this KPI.If velocity drops and debt rise, then a good PO will prioritize it.

If you cannot express why Technical Debt affects Business Value, then you really have some missing skills/experience on the team.

Business Investors easily understand the impact of technical debt on business value. You just need someone who can talk to them in their language. Hire a business analyst. we don't do much, but the bits we do do make it worth your while. ;-)

It is useless to refactor and clean up code that works and doesn't need to change for a delivery. The best is to continually clean up and improve the design of the code that stays in the scope of our daily tasks to deliver new features, fix bugs or embrace change. This is simply the YAGNI principle, we should only refactor and clean up when we actually need to.

Using this approach also minimize the risk of breaking working features that won't always be validated by developers or the QA that can't always run complete system-wide-real-scale-regression-testing when making changes that are related to a sub set of the system features.