As of 2016 The Agile Alliance came up with a fun and interesting way to engage parties into taking care of technical debt as early as possible. It is called the Dice of Debt game and a recipe can be found here .
Every developer knows that each decision they make entails allowing for or fixing technical debt. It is a much more spoken subject nowadays than it used to be and yet it is wildly misunderstood; because technical debt is not bugs, it is not maintenance. It can cause those, though. The actual concept was introduced by Ward Cunningham, a pioneer in XP and Design Patterns. There are many definitions around, but here is mine:
Technical debt is any code or infrastructure put in place that we know beforehand will require rework.
Think of a situation where you need to deliver code fast . This is important in many cases:
- A serious bug or threat discovered in the system needs a fix ASAP, even if not the ideal implementation;
- A certain feature has a very aggressive time to market and the benefits of getting that feature out are significantly more positive than waiting for robust code to be developed;
- A certain law or regulation with a target date to go live forces a project to complete most of the work by such date.
Code that gets old overtime because of technology changes or due to new business direction is NOT technical debt. This is legacy and it is impossible to avoid. That is also something worth a whole different discussion.
What I like about everybody speaking about tech debt now is because a certain culture of “this is a dirty hack” or “that is nasty code” sometimes develops among code purists or people that do not need to put out code that actually solves a real-world problem. Most of the time software is just complex and despite that you better get something out of the door before someone else does it. You might need and MVP or a set of basic functions available to conquer your market first or to just test out most of the challenges a real system usage will take or even to start integrating with other bits of software. And all the time compromises are needed, so it is not about someone writing “bad code” or being a bad developer. This is just the reality of professional software development.
It is normal to accumulate technical debt. It is a debt because just like a business sometimes has not enough money but needs to make significant improvement in the market. In such case, they borrow money. The same is possible for a piece of software, but in this case, the company is buying time. And just like a monetary debt, there is nothing wrong with it, but it needs to be repaid and there are interests over it. Everybody needs to understand a decision is being made to incur into technical debt and that time and effort will be required to restructure the code that just went out quickly. In a Scrum team that means future Sprints will be spent rearranging code instead of producing new funky features. And as long as all the discussion never strands away from the Product Owner and the team this should be normal part of the business.
What sadly happens sometimes is that this time to come back and reclaim the code ends up being postponed or simply never taking place. That makes everybody else stuck with lots of maintenance code, endless bug fixing, costly monitoring and inability to evolve a feature.
To remind people or to explain to those who are unaware, the Dice of Debt game comes in handy: You have sheets and dice, so a perfect set up for something that reminds D&D.
The rules are simple: you have 12 dice. You can decide how many will be used for technical debt and how many for making a feature. Roll your dice. You also have a sheet with a few technical debt reduction techniques, such as increasing automated tests, simplifying code and the likes, and they all have a number of sprints, or rounds, indicating the number of times they must be applied and what to do with your dice for the next few rounds. After that you can decide how many dice to use again and which technique to chose for the next rounds.
You end up with two results. One sheet that shows numeric values on how many points your dice rolls collected for the technical debt reduction and one that shows that in a plotted chart, for those who are more visual.
The complete rules and materials can be downloaded from the Agile Alliance website.
The analogy I like is to think about is the dice is your team and how you distribute their tasks as far as scope goes. Say you put 8 dice as feature and 4 as technical debt. There is so much the numbers can do to help you if you do not use anyone to work on repaying the debt. And there is the element of randomness that gives you better or worse numbers, in the same way you can have sprints where people get sick, or too many production issues just disrupt the teams velocity.
This game is a great workshop to introduce the teams, the PO and anyone in the company on what is technical debt and how important it is to start repaying them soon enough.
#velocity #game #DiceofDebt #technicaldebt #estimates #Scrum
