Technical Debt in Agile
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)
Have a look at these recent blog posts on the site:
- Using a "Technical Debt Register" in Scrum, March 26, 2017
- The Product Backlog and Technical Debt, April 5, 2017
- Managing Technical Debt, May 1, 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.
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.
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.
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.
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.
From Hardening Sprint to Innovation & Planning Sprint. Smells like euphemism :-)
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 )