Skip to main content

Technical Investments over Technical Debts?

Last post 02:54 pm February 5, 2018 by Timothy Baffa
4 replies
02:02 am February 1, 2018

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?


07:03 pm February 1, 2018

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.


07:50 am February 2, 2018

The examples you give sound like perfect examples of the continous improvement tasks which should be the result of a Sprint Retrospective.


02:22 am February 5, 2018

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?

 


02:54 pm February 5, 2018

+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.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.