Creating a Technical Debt Payment Plan - How Do We Fix It?

Previously in this series, I've talked about organizations determining if they should fix a problematic system, and figuring out what to fix. Walking through the steps means at this point an organization will have agreement and consensus on the need to address the technical debt and will have a few high-level value stories or epics on which to focus. Now it's time to start breaking out an actual backlog of work items.

How Do We Fix It?

Creating backlog items for a technical debt payment plan should be done differently than how you've created other backlogs. After all, part of the reason you got to this point with an out of control system is how you've done your work previously. You have to acknowledge the bad decisions and practices that got you to this point--and work to change them.

The Outcome

At the end of this phase, you will have a backlog of well-sized work items. Moreover, the team will create these new work items with the mindset of changing the dynamics that got your organization to this point. 

Address Your Culture

You'll be doomed to end up in the same spot you're currently in if you fail to openly and honestly address the culture, habits, and philosophies that got you to this point. Avoiding this situation means you need to address several things immediately to get a reliable, accurate backlog built.

Changing culture in a software delivery organization isn't easy, and it's certainly far outside the scope of this individual post or of the more extensive series. That said, I'd encourage your organization to have an ongoing conversation about critical factors such as

  • Communication. Is your organization willing to have more interactions with the stakeholders and users down to the delivery team? What about better conversations within the delivery team itself?
  • Software craftsmanship skills. Organizations finding themselves in deep technical debt problems often have team members who need dramatic improvement in their understanding and practice of software craftsmanship. Time for skills improvement needs to be part of the broader schedule, and that includes the related short-term impact on delivery velocity.
  • Modern testing practices. Mature, modern delivery organizations don't have separate "quality assurance" teams that perform testing one or more sprints/iterations after development is complete. Instead, mature organizations have testers integrated directly with the folks writing code. Testing is performed while work is done, not after.
  • Proper sizing of work. Mature organizations have learned the critical value of sizing work items as small as possible, optimally to a day or two of effort. Decompose larger work items into smaller, less risky parts.

Create a Common Definition of Done

It's critical that backlog items are an honest, realistic representation of the effort required for each work item. I've found it very helpful for key players in the organization to spend time agreeing on what "Done" means before detailing out work items. Taking this step ensures the entire organization, from the stakeholders down, agrees to a common set of standards for marking every work item as complete and ready (or deployed to) production.

A Definition of Done can vary from team to team; however, here are a few things I like to see included. "Done" means each work item:

  • Acceptance criteria clearly stated
  • Three Amigos conversation for each and every work item
  • Meets static code analysis minimums for things like complexity, size, dependencies and coupling, etc.
  • Has testing as appropriate completed. ("As appropriate" because testing differs for different things.)
  • Passes all stages of the delivery pipeline
  • Has appropriate documentation completed
  • Has had support, ops, and other cross-organizational groups briefed and trained as needed

"Done" may also mean "in use by customers in production." 

Defining and Sizing Work Items

With a solid Definition of Done in place, the team can proceed on to creating the actual backlog work items. Accountability across the entire team is critical at this point because the team is going to have to change how they do their work. Old habits must be shed, and new ones learned. It's critical to have a safe environment where intense discussions and disagreement are not only welcome but expected. I've found having a facilitator available during this initial work item breakout phase can be a huge help in keeping the conversations productive.

Build work items by creating a deep understanding across the entire delivery team of just what's needed to address the issue at hand. It's critical to pay particular attention to issues like architecture, code complexity, internal dependencies, and lack of automated testing when breaking out work items. When working on a tech debt paydown work item teams generally spend even more time at the whiteboard mapping out problems and potential solutions. Testing, both manual and automated, becomes even more critical as the team proposes significant changes to system internals.

Work items prepared for the backlog all need to take into account the effort needed to meet the group's Definition of Done standards. Work items also need to be appropriately sized, as per the discussion earlier in this post. Paying attention to diverse input is especially critical when sizing. Too often more senior team members forget how difficult and time-consuming a task can be--and it's dangerous to size tasks based only on that senior developer's (or tester's!) view.

The Outcome

Having gone through all of this phase of the process, you should have a backlog of actual work items or user stories. These items should be properly sized with honest, open acknowledgment of the time and resources needed to do the work properly. Management and the business side must be forthright and understanding that work item estimates are just that: estimates. There's a reason they're not called exactimates. The team must feel safe that they will get time and support when, not if, they find previously undiscovered problems, rather than being punished for breaking a schedule.

Up Next

The last post in this series will be about actually doing the work, and the importance of keeping each other accountable for following the new practices to keep the system from falling into the same state it's currently in.

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

No Comments

Add a Comment