Technical Debt

Sometimes, the development team faces a situation where the development team feels to deviate from good practices that result in an unpredictable overhead. The reasons could be:

• Deadlines to deliver are close.

• Someone else takes decision on behalf of the team to not follow good practices.

• Unclear Definition of Done to some of the team members.

Such teams are not self-organized and under pressure create an overhead to maintain the product that accumulates to Total Cost of Ownership of the product and sometime affect the quality of product increment delivered.

Such short term gains lead to Technical Debt.

Scrum Master and Technical Debt

• Scrum Master should remind the development team about their commitment to focus on delivering a quality product increment. Also, to showcase courage to say No, in case a decision is taken by someone outside the team that impacts the quality and add overhead to the team. 

• Scrum Master should advise the team to be open and make sure, in case technical debt exists, then the technical debt and its impact is made transparent.

Accountability of Technical Debt

While delivering the product, at some point a consensus gets auto-generated and the development team is seen as a feature driven factory. While they provide relative estimate on the requirements considering all the good practices like doing Test Driven Development, the stakeholders may take decision to not write the unit tests and do it post the product delivery. Such decisions fail the purpose of writing unit tests, add technical debt and take away self-organization from the development team.

Even though someone else took the decision to create the technical debt, but paying it off becomes responsibility of the development team. The development teams pay it off along with developing new user stories. Irrespective of the person who takes the decision, Technical Debt is owned by the development team. It cannot be declared Product Owners responsibility to add it to the scope of the product and prioritize/negotiate about it from the stakeholders.

There is always a possibility to deliver the product to the customer with technical debt. Technical debt does not mean that some work is left it just means it is not of the quality expected by the customer. The development team may have used hard code values rather than configuration files or chose a shortcut to meet the deadline but the product solution is not scalable.

If I can deliver my increment, does Technical Debt hold any value?

• Yes, it holds the value, a negative value and as long as it exists, the development team has to pay interest on this value.

• The negative value may not make an immediate hit on the product decisions but at some it may become only importance.

So be very vigilant of the trap.

Development Team and Technical Debt

Scrum encourages transparency, so the development team should showcase due diligence to make technical debt transparent by:

• Utilizing sprint review to remind the stakeholders of the technical debt, and what is the cost of delay.

• "You can't manage what you can't measure"; so track the technical debt.

• Push back the decisions that can cause the burden on development team.

• If technical debt is accumulated, the development team should maintain a healthy credit score by paying minimum amount every sprint.

Technical Debt and Velocity

As a Scrum Master, did you fall into trap of celebrating increase in team velocity. Paying of the technical debt can create wrong understanding of team's productivity. The development team velocity could be increasing and it can create wrong impression that the team is getting mature, or improving the speed to deliver the product. But in reality the development team is paying off the technical debt which gets accounted into product delivery efforts. 

The technical debt is a negative value. If a team delivers 400 story points to deliver a minimal viable product and 100 story points were dedicated to technical debt, then:

Actual feature story points: 400-100 = 300 story points

The team carried the burden of 100 story points worth of the technical debt.

Ideas to make technical debt transparent:

• Product backlog is single source of truth:

As the term suggests, this debt is technical and defining it will require all the technical insights. But, if it is in product backlog, then Product Owner should understand the nature, impact and effort related to the technical debt.

• Maintain Wall of Technical Debt:

Visualization is the key to improvement. Maintain a wall in the team space, and if virtual, maintain a risk register to details the impact, effort for the technical debts to enable the scrum team to make informed decisions.