The phrase "agile development" has become common fare within the development community. As companies sought out new ways to innovate and optimize from within, Agile provided a new approach towards achieving productive results. Most developers have exposure to Agile in one form or another. Some companies have chosen to jump in while others have adopted select concepts. In either case, the Agile and Lean methodologies have produced frameworks such as Scrum and Kanban which have been well received. Although this might run the risk of over-simplification, Agile focuses on short cycles, fast results, and continued course corrections. After adopting this new mindset, an inevitable question arises. What do we do about technical debt? How does it fit within Agile? Does Agile eliminate or encourage technical debt?
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.
