Technical debt workshop
Understand what is technical debt? and how to deal with it
This workshop is a 2 hours workshop you can run in your team during a retrospective or ad-hoc to align on this concept.
Here is the facilitation support :
Connection : 3 words
Ask to the participants :
In solo : Write down three words that you associate to the expression "Technical debt"
In pair :
Share your thoughts
Agree on a definition
All together :
Share your thoughts
Agree on a definition
Concepts
What is Technical debt ?
“Some problems with code are like financial debt. It's OK to borrow against the future, as long as you pay it off.” - Ward Cunningham
Technical debt describes what results when development teams take actions to expedite the delivery of a piece of functionality or a project which later needs to be refactored. In other words, it’s the result of prioritizing speedy delivery over perfect code.
Difference between Bad code & Technical debt
Symptoms
Accumulate bugs
Add a new functionality will cost a lot of money : reduced velocity
How do we create this debt ?
"We don’t have time!"
One thing we hear the most in teams is the lack of time as an explanation of technical debt creation :
“No time to rethink the design of this class, just keep adding new stuff to it!”
“I didn’t have time to write the unit tests”
No time to think about how someone else will fix or extend the code
…
Other causes
Poor Conception : No time for architecture and design.
Poor Business understanding : It is impossible to design something you do not understand...
Poor Scheduling / Underestimating : No testing effort in estimations.
Bad Development Practices : Development team needs to have a set of practices and conventions so that there is a little or no significant difference in design and implementation from feature to feature.
Outdated Technology : As technology evolves, software standards become higher every day : No technology watch, innovation time
No team rules / conventions
Only Michel knows this piece of code, no one else can update it (SPOF
…
The technical debt creation can be deliberate or inadvertent. That's what Martin Fowler explains with the Technical Debt Quadrant :
Read more about it here : https://martinfowler.com/bliki/TechnicalDebtQuadrant.html
Some examples of technical debt
Source Code Formatting
Bad naming : Source code is not understandable by anyone.
Low/No Test Coverage : Tests ensure that each part of the code is behaving the intended way.
Code duplication
Lack of Modularity : Some code sometimes serves different business logic. The more codes developers write, the more lack of modularity can bottleneck.
Code Complexity : Complexity can be measured in several different ways, but it measures the dependence and path length to perform an operation. A long path leads to complex code.
No automation : Deployments and tests are done manually.
Concrete practice : Dice of debt
Dice of debt is a serious game that demonstrates the importance of managing technical debt. It has been documented on the agile alliance website here : https://www.agilealliance.org/dice-of-debt-game/
How to play ?
Material
Everything is available here : https://www.agilealliance.org/wp-content/uploads/2016/04/Dice-of-Debt-materials-AA-v2.pdf
Context
You are a scrum team that rocks.
Your mission : create the highest amount of new software value by the end of the project.
You have a strong dead line : 10 sprints of 2 weeks.
Technical debt can reduce that value dramatically.
Rules
Sprint = 1 turn
You have a finite capacity in each sprint represented by 12 dice
8 dice to create new value (NV)
4 dice for technical debt creation (TD)
You must run the technical debt dice at each turn.
Technical debt reduction measures
You can lower the burden of technical debt during the game by investing in some reducing tech debt measure :
Continuous integration (CI)
Test-driven development (TDD)
Code review
Increase test coverage
Cost
Benefits
Each investment in a TD-reducing measure reduces your NV dice for a few turns.
Get the associated effect
Scoring sheet
Tracking sheet
How to play ?
At each turn (x 10) , each team must :
Choose a strategy (use the investment effort or no)
Roll the NV dice
Roll the TD dice
Update the score sheet
Update the tracking sheet
Small retrospective
What do we need to adapt ?
Conclusion
Debrief the game with the participants
How to debrief a game ?Explain what the trends are indicating
You will always face some Technical Debt
Some amount is to be expected (Unintentional)
The amount of technical debt will never be zero
BUT it has to be manageable.
How to manage it ?
Ask questions to the participants / small technical retrospective :
Which examples of technical debt do you identify i our code base ?
How do you materialize it in the backlog ?
How can we improve the management of the technical debt ?
How could we reduce it ?
A concrete action that we could implement tomorrow
Measure things
We can easily measure things that can help us quantify our technical debt :
Functionalities : Measure the performance of the system for each period of time (iterations) by measuring the number of functionalities (User stories) done / delivered.
Bugs : Number of "stuff" to fix in the code : bugs, fixes.
Technical debt : Number of refactoring or technical improvements identified by the team.
The definition of this measure can differ from one team to another and it’s fine. The only things is that this definition must be constant for the team.
Use static code analysis tool
Tools like Sonar can give an idea on the health of your code base (some trends to follow). It calculates technical debt indicator :
Make the debt visible
Create items in a backlog for everything that is identified and monitored by the team as a subject for refactoring or technical improvement.
Invest
Dedicate time to technical debt reduction and prevention.
Technical retrospective : Focus on the technical/architectural improvement
Objectives : Find technical improvement actions / prioritize technical items.
Questions during those sessions :
Where are the defects?
Where are the 'hard bits' ? What makes them hard ?
Where are the 'easy bits' ? What makes them easy ?
What keeps changing ? Why ?
Could we better quantify our technical debt ?
...
Apply the boy scout rule
Use great development practices
There are a lot of them in XP
Some of those practices :
Follow Clean Code rules
Test Driven Development
Static code analysis
Pair/Mob programming
Knowledge sharing
Code review
Mentoring
Coding style guides
...
To go further :
Communicate the Effects of Technical Improvements to Non-Technical Stakeholders : https://codescene.com/blog/communicate-technical-improvements-to-non-technical-stakeholders/
Culture code by Octo : https://www.octo.com/publications/culture-code/
Last updated
Was this helpful?