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!
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
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
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.
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: Jim@GuidepostSystems.com.