Over a million developers have joined DZone.

Technical Debt: In an Agile World

· Agile Zone

Learn more about how DevOps teams must adopt a more agile development process, working in parallel instead of waiting on other teams to finish their components or for resources to become available, brought to you in partnership with CA Technologies.

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.

Discover the warning signs of DevOps Dysfunction and learn how to get back on the right track, brought to you in partnership with CA Technologies.


Published at DZone with permission of Zac Gery, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}