Free Your Team From the Burden of Technical Debt
By: Mark Gray
Tags: Programming, Leadership, Product Management, Technology, Agile

How Technical Debt Is Abused

Working with and coaching many teams from many sectors for far too many years, I have found that technical debt always gets misused in the same ways.

Teams — or especially tech architects — quoting that you should “spend 20% of your time on technical debt.”

Maintaining a technical backlog.

Ensuring that 20% of the team’s capacity is expended on tech debt items every sprint.

There is a fundamental misunderstanding of a quote from Martin Fowler summarized as “teams spend about 20% of their time working on Tech Debt.”

This quote should be viewed in conjunction with the earlier quote from Fowler. The intention is to quantify on average how much time the team spends dealing with tech debt when implementing a change.

The tech architect or manager often uses the 20% argument and a technical backlog to justify getting the work they want into a sprint instead of following the correct practice of assessing the items alongside all the other backlog items and then only working on the items that deliver the most value.

Technical debt gets used as a convenient catch-all instead of adding technical stories to the backlog. The backlog should contain technical stories as well as all the exciting new features. The following are often wrongly generalized as tech debt:

Identified issues

Lack of process or poor process (e.g. configuration management tool)

Features that are wrong or delayed (things we should have done in release X but)

UI issues, inconsistencies, or bad experience

Enhancements (including performance)

Lack of skills within the team

Changes resulting from architecture decisions

Incorporation of new coding standards or practices

All of the above represent work that the team may need to complete. The product backlog is the correct place for these items.

The issues above usually occur in a team or organization that has not fully embraced Agile thinking. If a separation has been maintained between the technical and business aspects, or if the Product Owner is only performing what they consider the sexy part of the role, then the product backlog may only contain the new features for a product. With everything else considered as a technical problem that is of no interest to the Product Owner, these items are then formed into a Technical Backlog.

This is usually justified by stating that the Product Owner has no technical knowledge. Therefore, how can they judge the relative merits of the technical items against the business ones? The answer when working in a Agile manner is simple: All items on the backlog should be refined by the team as a whole.

The team has the technical knowledge and can therefore have the relevant conversations to ensure they get prioritized correctly.

During the early stage of an Agile adoption, the team and organisation struggle with the concepts of openness and transparency. This is especially apparent when transitioning from a “command, control, and blame” culture. In these circumstances, the technical backlog becomes a mechanism for hiding uncomfortable truths. The product backlog only contains the new features used in reviews and communications with stakeholders. All the issues and problems are contained in the technical backlog, which is kept within the team and never communicated to the stakeholders.