Just to remind you, here is the definition of Technical Debt:
Technical Debt consists of deficiencies in the code, technical documentation, development environments, 3rd-party tools, and development practices, which makes the Code hard for the Team to change1.
The most important part of this definition is that Technical Debt is what makes Code hard to change. We usually think of Technical Debt as bad Code ‘inside’ the Product that has an effect on every Team that works with the Code. It’s what keeps the code from being Clean Code. This is what makes Technical Debt different from the other Environmental Variables; it is not external to the Code in any meaningful sense – it is largely an intrinsic part of the Product.
Technical Debt is largely invisible from the outside; it has little or no effect on the functionality of the System – it only affects how hard the Code is to change. The major causes of this ‘internal’ Technical Debt include: lack of tests, bad design, lack of technical documentation, and poor readability. Technical Debt is an invisible, insidious, pernicious killer of our software. It is so important that discussing it pops up throughout Exploring Scrum: the Fundamentals (ES1), and I recommend you go re-read Chapters 3.5 and 4.5 of (ES1) if you are at all confused about it. Technical Debt needs to be managed; if we don’t manage it, it will manage us!
Writing Dirty Code… A Horror Story
Let me tell you a story about what often happens in bad Projects. The Team is writing Code and is constantly creating more-and-more Technical Debt in the form of dirty (or bad) Code2. Now, they probably wouldn’t do this on purpose – they want to use a decent Definition of Done – but they might not understand what Clean Code looks like… or they may be receiving pressure from the Project Leader coming down through their Team Leader.
In any case, they do the best they can: adding functionality one Story at a time, working at an UnSustainable Pace, producing dirty Code with lots of Technical Debt, and adding appropriate Cleanup Stories to the Backlog showing what work needs to be done to clean up the Code (I’m assuming they have enough Courage and value Visibility enough to do this).
So, what’s going on? What’s actually happening?. A likely cause of this scenario is that the Project Leader made a bad assumption of how fast Velocity should be, and is forcing the team to work at an UnSustainable Pace in order to try to meet this unrealistic assumption – and this is what’s causing the dirty Code. The result is not only the dirty Code, but also the addition of Cleanup Stories in the backlog. So what does the Project Leader get in the end?
- Functionality with lots of Technical Debt, causing an even lower Velocity than the Velocity that already wasn’t fast enough, and
- More work to do than was originally planned, because of the Cleanup Stories that were added.
So, not only was the Project Leader’s assumption of what Velocity should be wrong, but now the actual Velocity is even worse than it was. Not only that, but the Backlog has been increased by adding Cleanup Stories. Double Whammy!
Don’t do this.
To learn even more about technical debt and best practices for teams using Scrum you can purchase Dan Rawsthorne and Doug Shimp’s book “Exploring Scrum: The Fundamentals” on Amazon. Stay in touch with 3Back on Facebook and Twitter.
1. From Exploring Scrum, pg. 122.
Jump back
2. This is what Ken Schwaber calls the “Mother of all Problems” – see Schwaber, The Enterprise and Scrum, Microsoft Press, 2007, pgs. 93-97.
Jump back