James King

A long time ago, people suggested doing “hardening sprints.” During these sprints, we would slow down to recover every 3-4 sprints.

It’s an anti-pattern to make things worse as you sprint along and then hope to fix it later. Firstly people add stuff to the sprint because it looks like free time. Secondly everything that decays takes a lot longer to fix after it has decayed. Thirdly, it made people secretly re-implement waterfall with delayed testing and lots of bugs.

But mysteriously, it seemed to work with some teams. They would pause, review their plans, clean their workspace (test environments, desks or whatever).

The ultimate conclusion became the “engineer’s sprint”. The team got to define a backlog of things they found hard and spend a sprint on them.

In theory we should do this continually with refactoring, retrospectives and empowerment to continuously improve.

But sometimes we seem to accept things that should not be the norm. We accept test environments having bad data. We allow manual data fixes to be needed. We tolerate deployments getting harder over time.

Maybe it is worth ditching a retrospective one sprint and replacing it with a retrospective. The difference being

• We skip asking “what worked well and what didn’t”; and
• We add a story mapping session or a root cause session. The purpose is to find something the team would add to the backlog. Then they can work on something for themselves as the customer.

Then add the “team story” to the next sprint. If the team are brave, let the team have a whole sprint. They can go back and do a make-over on something they wrote. Alternatively, they can focus on some process that is getting painful.

Anyway I am too busy right now, but maybe one day I will go back to do it again.