Technical Investments over Technical Debts?
The concept of Technical Debt is a Software Development analogy comparable to monetary debt. There are several published information regarding technical debts, its causes, and its impact. I would like to use same analogy and coin Technical Investments those "tasks" that do not add direct value or increment but will make creation of value easier in succeeding sprints and prevent/reduce impact of Technical Debts in the long run. I am afraid however that most of these "investments" will just be methods of reverting back to Big Upfront planning/preparations that cost too much and might not be needed in the long run.
I would like to tap your extensive experience, based on what you have implemented in your teams, on what are effective Technical Investments that do not cost too much development effort and are usually implementable in a sprint (no more than 1 month):
- Team building? Such as Establishing house rules.
- Establishing Coding Guidelines, Repositories and Check-in/Check-out rules?
- Setup Continuous Integration Environment: "Hello World" on Full C.I. at Sprint 1 day 2
- Cross training when time permits (such as shadowing an expert in 1 area to share the skills to other members)
What Technical Investments do you recommend that helped you increase velocity and prevent/reduce technical debt?
Might it be best to view those “technical investments” as a kind of runway which allows agile delivery to continue without impediment? Just enough is done to mitigate significant risk during the next few Sprints, and no more. For example, maintaining sufficient “architectural runway” is something which is widely understood.
The examples you give sound like perfect examples of the continous improvement tasks which should be the result of a Sprint Retrospective.
I hate the term "Technical Debt" because, similar to the author of this post, in my mind it associates with a credit card debt. The team gets into technical debt when, for example, instead of fixing bugs they work on new features, and and the bugs are accumulating. Then the team not only has to deal with the ongoing development and the associated new bugs, but also "pay interest" on the old bugs. I pay off my credit cards every month and pay no interest - that's how I want my team to operate.
Oftentimes however, my SCRUM master calls Technical Debt things that we logged as nice to have's or various housekeeping items to explore for future improvement. In monetary equivalent, it looks to me like "if I had more money, I could have invested into these very interesting programs, but I do not have that money yet, and I'll invest when I have it". It is like calling those initiatives "debt" just because I could not get to them.
I think that the word "debt" has a bad connotation exactly because of its association with financial debt, I think it is demoralizing and demotivating the team, especially when there is a lot of it. If we actually left some important bug for later, I'd call it for what it is and encourage the team to "pay it off ASAP". On the other hand, I avoid calling everything that's not the mainline development Technical Debt. Does the above make sense from the agile terminology perspective? Is there a better term for things that are not really debt?
+1 Julian.
The newly-updated Scrum Guide now requires at least one process improvement idea each sprint (Kaizen). Such ideas/experiments are often identified during a team's Sprint Retrospective.