Once upon a time, there was a project that was supposed to be done at the end of the month. There was a full Product Backlog, some of which was well defined into twelve Stories, and an enthusiastic Team ready to tackle the four week-long Sprints it was expected to take to finish the project. Confidence was high, and the predicted due date seemed to be no problem. Flip the hourglass with the sands of time; enter: Reality.
Once upon another time, a college student was given a credit card. Charge all you want and pay it off at the end of the month and it was like getting an instant, interest-free loan. Payday is the 30th (read: end of the month), so let’s get some shoes.Again, enter Reality.
Both of these scenarios, when adding the cosmic constant called Reality, are the beginning of accruing debt. In Scrum terms, technological debt is that work that is NOT done when trying to hit a predicted due date once reality enters the picture and starts to pump chaos into the well-sculpted predictions made at the beginning of the project. Another way to look at technological debt is to think of it as credit card interest. If the Team can hit the predicted deadline dead on (pun intended), no debt accrues. But any deviation beyond the due date creates a situation where, when normal business pressures come to bear, compound interest starts to make things interesting.
Let’s expand my first example. Sprint week one: an Impediment arises that chews up four hours of productive time during the Sprint, causing the third of three Stories to not be completed properly. Planning Scrum for week two: this issue bubbles up to the surface and is taken into account by using the second week Sprint to finish the work not completed on the first week’s third story. This causes the Team to lose Velocity and only complete two stories in the second week. The Team now completes the second Sprint, and has a total of five Stories complete in a quality manner — code is solid, all testing is done, and the work is up to par. Now, halfway through the project, this is noted, but optimism is still high, and somewhere in the next two Sprints, this extra Story needs to get done on top of the remaining six . This is not yet technological debt, but it should be cause for concern for the Product Owner, the ScrumMaster, and the Team. Interest is looming.
As the two final Sprints are planned and executed, somebody comes up with a fabulous idea of a shortcut to keep the project on track to be delivered on the predicted date. These ideas are usually along the lines of not completing due diligence on testing, outputting hacked code, skipping code reviews or full QA, or otherwise not doing high quality work. Project is delivered, client and Product Owner look like heroes, and everyone is happy, right? Wrong.
Technological debt — or interest — exists in the product itself. The entire Team — Product Owner, ScrumMaster, and Team Members, all know that within the delivery lurks something that was not up to par, and may come back to haunt them later. Extrapolating my second example — including the introduction of reality — at the end of the month, it is more important to pay all of your rent and only part of the credit card bill, so your $300 pair of shoes only gets $250 dumped on the bill. Waiting until the end of the next month to pay for your new clogs will actually cost you $75 more, not the $50 that it would have taken had you paid the whole thing promptly before the interest rate started getting that rear-naked choke hooked in. Technological debt works the same way. Your shoes just cost you $325. Next month, as the compounding really gets rolling, they will be a $350 pair of shoes, all the while losing value while you are wearing them to your Scrums every day.
Back to example one: client is so happy with the delivered product, they want it installed on all three of their websites, and expects that it should be an easy chore. We delivered them a quality, scalable, perfectly-factored product, right? Unless the technological debt is addressed immediately in the new estimates — probably a whole week’s worth of Sprint on top of this new client request — the problem is not just going to sit there and be a static problem value; it is going to gain interest. As the product is scaled, built upon, sold as-is to other clients, this debt is accruing interest. As long as this debt is ignored, it will continue to compound and cause problems in the future, especially in terms of codebase. Technological debt really gets good when the programmer who put the hack into code in the first place either is no longer with the Team or doesn’t remember what was done to create the problem in the first place. Time is the factor that is compounding — in this case, to find the problem and fix it. The sharpest pain in the process of catching up on technological debt is that there is nothing that can be sold to the client as an upgrade or a new feature; this was supposed to be done in the name of Quality last month…or six months ago,,,or whoever the dude was that built this code in the first place.
One of the central concepts of Scrum is honesty. Honesty within the Team is crucial, and in the case of this example of technological debt should have been clear communication to the Product Owner that due to the Impediment, the project needed another week to be delivered with the quality that the client deserved. If the client could not wait one more week for a quality product, then the Team has to get a Business Owner involved — usually to OK overtime, working lunches, and otherwise reducing other responsibilities in order to retrieve the additional time to do it once and do it right. In the case of the shoes, you would have saved your money and purchased them the 15th of the next month when you could drop $300 in cash and not absorbed any debt in the first place.