“Yes, we know that this is not done right yet. We have some rework to do and we have three more feature Sprints with a significant backlog. We will take care of this rework in the hardening Sprint.” Sounds familiar? What is a hardening Sprint? Why do we plan for a hardening Sprint? Hardening Sprint is an iteration that happens before release readiness. It is a common practice irrespective of the methodology one follows. The term ‘hardening’ comes from ‘code-hardening’ – providing some finishing touches, making some minor adjustments to make things better on code base. The goal is to improve structural quality and fix some defects too. It is not about delayed refactoring. Hardening Sprint does not include implementation of new features – obviously! Hardening Sprint is to tie all the loose ends, fix defects and make sure that the product is ready for release. No new features but finishing touches, key improvements, and defect fixes. Period.
In large-scale Agile projects, even if we adhere to this norm, we know there are enough challenges. This is mainly because of what is involved in hardening the software created by multiple feature teams. And when we violate the purpose by introducing new features or major changes, we eventually face a whole lot of challenges.
When we go through a whole lot of challenges in a hardening Sprint because of reasons such as introduction of new features or user stories or major changes to architecture/design components or any change that rattles the compatibility of components, we must admit that probably it is because of the problem of procrastination. Procrastination results in some of these - insufficient planning or re-planning, ineffective prioritization, inadequate story grooming, weak design, postponed decisions, too many changes, fuzzy acceptance criteria, and so on. All these could make a hardening Sprint harder to execute.
When we are in feature Sprints to deliver user stories or features, we tend to give importance to things that are immediate and urgent (not necessarily important). We tend to do quick fixes. We accumulate technical debt. Eventually, we lose focus on long-term goals or vision.
“Giving up on our long-term goals for immediate gratification is procrastination.” This is what Dan Ariely says in Chapter-6 of his book ‘Predictably Irrational’. In this chapter he has given multiple examples on why we can’t make ourselves do what we want to do.
In large-scale Agile or projects cross-functional teams align and exhibit certain behavior. Sometimes, the power of dissent is forgotten or ignored.
What can we do? We can do many things to make a hardening Sprint meaningful and valuable. Here some ideas.
- Identify the factors that make a hardening Sprint harder. Learn from experience. Check if certain bad smells are repeating when you are working on a subsequent release. If yes, find a fix.
- Define the scope of Hardening Sprint 2 or 3 Sprints ahead in the release cycle. Assess the need for any corrective action – such as one more feature Sprint or abandoning low-priority features.
- Assess technical debt (including testing debt – such as lack of adequate testing or lack of adequate automation).
- Assess environment issues that may lead to a backlog of work items in the hardening Sprint.
Try all these at the end of Sprints. Don’t procrastinate and look at all these just before the hardening Sprint begins!