Hardening Sprint - Manna from Heaven or a Witches Brew?

Question

In Dean Leffingwell's Scaled Agile Framework there exists the concept of a hardening iteration E.G. after three sprints of two weeks duration, we have a hardening sprint of one week.

In this short sprint we can pay back some of the technical debt accrued over the previous sprints, ensure more rigorous integration testing is carried out and the set up, tear down procedures are quality reviewed. Time can also be factored in for any training requirements that were uncovered over the prior three sprints.

Admittedly, if we have a mature DOD on the delivery of a sprint work item there should be a decent level of quality but sticking to the principle that we deliver only what is required to satisfy the criteria of each story will eventually lead to known duplication in the code base. Good developers will naturally want to improve their code base so having a hardening sprint will ensure they can concentrate on moving WIP in the main sprints but the address any wider re-factorings periodically.

I recently attended a conference where Rachel Davies of Unruly Software explained that their XP developers have every Friday as Golden Time where they are free to re-factor the codebase and learn new technology. That works out at one day in 5 as opposed to the one day in seven by having 3*2 week sprints plus a hardening sprint.

I believe this is a good approach to paying the technical debt in a managed fashion. Technical debt will become more expensive to repay the longer the project continues in the same fashion as a story becomes more costly to change once we have delivered.

I know the idea of a hardening sprint is anathema to agile purists but I think it works well in our pragmatic scrumban approach.

I think the issue is similar to that around the validity of having a Sprint Zero which ruffles a few feathers.

So, Question is:

Is a Hardening Sprint a good idea, if not why and how would one address the concerns outlined above?

Answer 1

Hardening Sprint should only be for stabilizing the system and getting it ready for release

In my previous job we ran a one week hardening sprint prior to deploying the content of 2 or 3 two-week sprints to a production web site. At that time we were doing manual regression testing. There was not enough regression testing done within the sprint to be sure it is shippable. So, during the hardening sprint all we did was regression testing. If any bugs are found, we will fix them and verify them.

Eventually we hired a team member with test automation skills, built a regression test suite. We also used some of these tests to run load and stress testing. Then we did away with the hardening sprint.

Mike Cohn advocates the same thing, "The release sprint is not a dumping ground for sloppy work; rather it is a place where some hardening of the system can occur."

If you are doing code refactoring during the hardening sprint, I would say that is a red flag or to use your own term a "witches brew"! You are creating more chances for regression issues.

So, you may need a hardening sprint when you are on training wheels. Once your engineering practices improve to assure a shippable increment in each sprint, you can drop it.

Answer 2

Whether it's good or bad idea depends on how you manage risks connected with it.

From what I have experienced the risks are:

• refactoring effort is often hard to estimate and leads to planning problems
• it's hard to define acceptance criteria for the refactor
• there is a lure to deliver half-ass stories (rather than half-done) at the end of the sprint with belief that "we can fix it later". That is especially true for Golden Time that happens right after the sprint

Another thing to bare in mind is that someone have to manage backlog items related to refactoring. More items in the backlog means more time spent on debating whether this refactor is more important than the other one.

Answer 3

A hardening sprint is a tool. If you use the tool correctly it is a good idea. If you use the tool without knowing the problem you are trying to solve it may or may not be a good idea.

That's a vague answer so in practice:

If you have a team that isn't ready to continuously build quality into their product (i.e. they have accrued a ton of tech debt or the business is not allowing enough slack to prioritize tech debt, learning, and CI into the regular iterations) then a hardening sprint is a good tool to address the tangible issue that product quality is suffering or the delivery team is not given enough time to learn and improve.

I'd argue it is ideal to shoot for teams that deliver high quality and have time for CI in every iteration (if you're in a Scrum world) or continuously (if you're in a Kanban world). I'd say hardening sprints are an intermediary solution to getting to a sustainable development model. They are also great for bringing light to quality problems since having a hardening sprint for a few weeks can be a costly pill for management and the team to swallow when they have 1-4 weeks of 0 business value delivered.

The downside of the hardening sprint is that hardening sprint activities are usually more efficient and/or effective to address right when the problem occurs. There is a ramp-up cost associated with hardening iterations that is lower if quality/CI are built into each iteration or work item.