Technical Debt: In an Agile World
Concerns about Agile's effect on long-term objectives have been raised, but it neither eliminates nor encourages technical debt. Although technical debt can be reduced with good practices, it is unavoidable. It cannot be completely eliminated. Armed with this knowledge, structure and visualization are necessary for proper administration.
There are many benefits to Agile, but arguably the most important one is the Silver Mirror. Agile forces companies to look within their own processes and it exposes troublesome areas. Before starting down the road of tackling technical debt, it must be properly tracked. Each situation should be entered in as a user story and placed into a separate "technical debt" backlog. There have been some arguments within the Agile community about entering technical debt as a user story. Simply put, if the change adds business value, direct or indirect, it should be a story. If it doesn't add value, then it is not truly needed. Let's leave the argument of "value" for another day. Think of technical debt as a feature set and treat it as such. Break the items down into immediate consumable stories with proper point allocations.
The two forms of technical debt, strategic and non-strategic, can include but are not limited to: code clean-up, restructuring concepts, unit test coverage, database problems, etc. Tackle debt for what it is, not who/what created it. All team members should be encouraged to contribute to the backlog. Advocate open conversation about code with team members to help drive out additional stories. It's important to remember that the backlog is never complete. It is always changing as new challenges arise while other debt is paid off. Like a garden, continuous grooming is key to a weed free backlog.
With a proper backlog in hand, it's time to engage the product owner. Technical debt is a fuzzy concept to most non-technical individuals; therefore, some education may be required. Additionally, a visual representation of the backlog must be maintained. One option is to chart the total number of points in the backlog from sprint to sprint. However this information is visualized, it should be reviewed on a continuous cycle. In a Scrum environment, the Sprint Review Meeting is a perfect venue. Another option is to place a printed version of the report on a Scrum or Kanban board. Keeping the backlog in the forefront is crucial.
The final step is implementing a strategy for tackling the backlog. As a member of the development community, it's a developer's responsibility to build a clear and tactful case (click here for more info). Depending on the company, this may require more or less conviction. Regardless of the situation, request a model that provides continued focus on reduction. If possible, place it on the product's road-map. The approach can manifest itself as a certain number/percentage of stories to be completed per sprint or release cycle. Concerns may arise about impacts to productivity as velocity and feature addicts foresee less direct results. This is where proper preparation pays off. When a product owner understands the concept and can sift through stories, he/she can assess a proper business risk/impact. This can be a helpful ally because as stories pile up, the impact will begin to outweigh the product's output.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)