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?