Technical Debt in Agile

Last post 12:32 pm August 30, 2017
by Olivier Ledru
8 replies
Author
Messages
05:33 pm August 27, 2017

Technical debt accumulates while we concentrating more on features in Agile.

People give less priority for Design review, Code review which leads to issues such as maintainability, performance & security issues 

How to address technical debt of the project while it's being executed in Agile (Scrum)

08:35 pm August 28, 2017

Have a look at these recent blog posts on the site:

08:36 pm August 28, 2017

The Development Team are responsible for increasing quality, and they can do this by setting a Definition of "Done" that prevents new technical debt being added. They should never allow this definition of "Done" to be compromised.

As for technical debt that already exists, presumably it causes problems, such as bugs, or inaccurate or large estimates of new work, etc. If this is the case, then the Product Owner should also see the need for resolving this technical debt, and so it would be reasonable to see items in the Product Backlog to address known problems.

08:48 pm August 28, 2017

If you are using Scaled Agile, you have the IP iteration to take care of all such things and make sure you have enough runway. In case you are not, then as Simon mentioned above, it should ideally be added in your definition of "Done" for every iteration. 

09:59 pm August 28, 2017

In Scrum, an "IP iteration" would constitute an anti-pattern. Each sprint must yield a Done increment of release quality, and no iteration may be used as a sink for technical debt.

07:09 pm August 29, 2017

Even in SAFe, the "Hardening Sprint" was reformulated as "Innovation & Planning iteration".

So the aim in SAFe of the "IP iteration" is not (anymore) to pay back the technical debt.

10:50 am August 30, 2017

Even in SAFe, the "Hardening Sprint" was reformulated as "Innovation & Planning iteration".

So the aim in SAFe of the "IP iteration" is not (anymore) to pay back the technical debt.

I remember the conversations I had with Dean Leffingwell about this, and how a "Hardening, Integration & Planning" sprint became an IP.

Ironically, the statement "If you are using Scaled Agile, you have the IP iteration to take care of all such things" exposes a certain truth. Knocking the H off HIP isn't enough, and never could be. No matter how much you caution against it, an iteration for undone work of any sort will become a sink for technical debt. 

12:06 pm August 30, 2017

From Hardening Sprint to Innovation & Planning Sprint. Smells like euphemism :-)

12:32 pm August 30, 2017

Knocking the H off HIP isn't enough, and never could be. No matter how much you caution against it, an iteration for undone work of any sort will become a sink for technical debt. 

Because of this, I like the more violent approch of LeSS with "official tips" used to highlight some anti-patterns, like "Fake PO" or "Undone work" and "Undone Department" (See https://less.works/less/structure/organizational-structure.html )