Creating a Technical Debt Payment Plan - Doing The Work

Previously in this series, I've talked about organizations determining if they should fix a problematic system, figuring out what to fix, and determining how to fix it.

By this time in the process, your organization will have agreement and consensus on the need to address the technical debt, will have selected a few high-level value stories or epics on which to focus, and have created a prioritized backlog with work items to actually fix the issues.

Now it's time to move on to getting that technical debt paid off!

Doing The Work

By this point you've spent weeks, if not months, getting through a whole lot of meetings, negotiations, and debate. Thankfully we're at a point where we can look forward to the best thing about being part of a software delivery team: shipping well-crafted, high-value software!

The Outcome

At the risk of restating that last paragraph, the outcome of this phase is working software. Good, quality, high-value software.

Address the Culture

I had an entire section in the last post on this same topic. I've got it here again because it's critical. You will end up in exactly the same position you are now if your organization approaches this new work with the same mindset, constraints, and practices you used in the past.

This phase is all about execution: specifying, writing, testing, and shipping code to solve specific problems. Addressing the culture in this phase is all about accountability and ensuring people maintain the new work habits. As such, the entire team needs to feel safe when they push back on bad habits.

Start first by reminding everyone of the Definition of Done the team agreed to in the previous phase. I've found "Done" the first, best help in many situations over years of experience in many different organizations. Does someone want to skip unit testing work because it's too slow? "Wait, we all agreed on no commits without automated tests. Let's slow down and do this right." Does someone want to start a work item without having a Three Amigos discussion? "Hang on, we know what happens when we do this. We miss critical clarifications that always cost us more time in rework. Let's go grab a tester and BA so we can avoid that. Again."

Doing as much work as possible in pairs is another great way to avoid falling back to old, bad habits. Note that paring doesn't mean just pair programming with two developers. Mature organizations are seeing tremendous gains when work is done via cross-discipline pairing. Teams are seeing better code, higher quality, and more value to the users regardless whether they're grouping a developer and a tester together or getting most of the entire team together for a mob programming session.

Figure Out a Branch Strategy

Many teams prefer to do all work in their source control's main branch. While I understand the value and promise of that approach, sometimes it's just not feasible--particularly when major architectural tech debt is being resolved.

Remember: we're trying to pay down technical debt while continuing to ship new features and value. Sometimes keeping all work in the same branch just isn't realistic, even if you use some form of feature flags to hide incomplete work.

Work out a branching strategy early in this process. Your strategy should be designed to support as frequent merges from master to your working branch. You should also set up your branch work to make it as short-lived as possible. Don't be afraid to approach it as an experiment: come up with an idea, set some constraints and feedback mechanisms, and agree to modify or throw it out as you learn more.

Monitoring Your Progress

Paying down technical debt is a long-term, difficult effort. Make sure you're checking your progress along the way and adjusting as needed.

Monitor the same metrics you used in your early analysis. Are you seeing positive trends in your complexity and dependency metrics? If you're shipping things to users, are they more satisfied with the results? Are your sales figures improving? If not, re-assess your approach and adjust!

Continual Improvement: Keep Learning!

Resolving long-term technical debt problems requires endurance, support across the entire organization, and discipline to stick with new habits even when the short-term payoff doesn't seem worth it.

The entire journey should be viewed as a learning opportunity. The team will learn more and more about how and why they got to this point. Feeding that back into the  culture, process, and methodologies will be a huge boon for the organization.

Need Help?

Is any of this sounding familiar? Are you struggling with this situation yourself? I'd love to chat with you and see if I might be able to help! Drop me a line:

No Comments

Add a Comment