Introducing "Slack"

Over the last few years of working in agile teams, I have struggled with reducing technical debt. Most of the projects I've been a part of, teams are so focused on “getting things done” that taking the time to focus on fixing technical debt was out of scope. As you can imagine, these projects started off fast, but quickly got bogged down by our technical debt. This lead to cutting more corners (increasing our debt even further) to maintain our velocity, or convincing our product owner to take an iteration or two to focus solely on reducing our debt. None of the techniques I have tried were successful: adding technical stories to the backlog were constantly ignored or pushed back as lower priority, midnight projects just caused me to become burned out, or just ignoring it simply made the problem worse.

I had begun to think this was an issue which was endemic to Scrum.

Last week, I participated in the Art of Agile Planning and the Art of Agile Development, expertly lead by James Shore (author of The Art of Agile Development) and Diana Larsen (author of Agile Retrospectives). This course is chock full of advice, ideas and lessons on agile projects (I can't recommend this course enough if you're lucky enough to have an opportunity).

During the sessions, James Shore repeatedly stressed that reducing technical debt was not a task to be done in huge blocks of time, requiring technical stories and after hour work, but rather an on going activity. Reducing technical debt should be done in the same manner as TDD and refactoring, small incremental steps (wow is this a common theme across agile). James took this philosophy one step further and recommended we also introduce “slack” (I don't like the term because of it's negative connotation or it's closeness to sand bagging, but I can't come up with a better term).

What James recommends is that you take your velocity and if it went down in the previous sprint, you cannot take on more points than what was accomplished previously. Also, for several sprints to follow, you cannot raise your velocity either. As your team is working on stories, they look for areas where they can reduce their technical debt. Only when the team agrees that they can increase their velocity after they feel their debt is manageable (if not paid in full). Teams will find that their velocity is higher than it had been before introducing “slack”, and will also continue to rise to areas which are higher then they ever previously attained. This entire cycle may take a few months, but as in paying your credit card debt, will pay for itself.

What do you think of this idea? Would you be willing to try this on your team? Have you tried it on your team? If so, what were your results?