Hardening Sprints: good or bad?
Hi all
I've been going through Scaled Agile's training material on SAFe, the Scaled Agile Framework. At an operational level I'd say it was broadly compatible with (and consistent with) Scrum.
However there appear to be some exceptions. For example SAFe expressly supports the practice of Sprint Hardening. According to SAFe, a hardened sprint is one which provides "an estimating guard band and resource flexibility for cadence", and is needed because "some tests, validations, docs may not be practical every iteration".
I admit to having used hardened sprints in the past, but I came to the conclusion that it was an anti-pattern. The problem (in my experience) is that it potentially compromises a team's Definition of Done. It instills the belief that things can be played just that little bit faster and looser because trickier things can be "swept up" later.
SAFe claims that hardened sprints are "not an excuse for build up of technical debt". That caveat seems to me like a tacit admission of the problems it can lead to. Even then, technical debt isn't the only gremlin that this practice invites. There's also debt around process, such as not collaborating properly over incremental acceptance.
In short, I reckon that hardened sprints are too difficult to separate from contingency sprints, which I reckon most of us would decry as bad practice. I'd be really interested to hear other people's opinions about this.
I agree that a hardening sprint will compromise the Definition of Done for the team. People will start using it for working on technical debt and code clean up etc...which means that you have to wait till the hardening sprint before releasing the product. This is not in compliance with the Scrum.
Somehow I think people from a standard waterfall background would like to have a hardening sprint similar to last round of testing and bug fixing phase.
The scrum.org training specifically points out hardening sprints as a problem.
A hardening sprint is a period where you take care of technical debt that you've accumulated in prior sprints. Do you think it's a good idea to accumulate technical debt? If not, take care of technical as it occurs. Additionally a hardening sprint is unplannable since one typically doesn't know what it involves.
I agree with Chuck and others. Having said that, I initially thought this was about a different concept, a hardening period. This comes from the Leading Lean Software Development book, which is the concept of a "hardening" period using the analogy of a steel mill.
We've punched, pounded, and worked our tests, the code, etc. and we give it time to cool off and "harden" into a "done done" product/ticket. The way I do this in my own practice is within the sprint itself - each ticket has to to go through this hardening period - and is actually part of the definition of done. If a ticket manages to go from this cooling off step back into development due to unforeseen technical debt - its priority is doubled - and pretty much everything else stops until it's fixed.
Admittedly, it's a new adoption for me and has only gone through a couple of iterations in a formally defined manner, but does offer balance between hubris (nothing wrong with my code) and crippling fear (are we really, really, really, really, sure?).
I think "hardening sprint" makes the whole meaning of SCRUM at loss. SCRUM talks about the dev team to be cross function and "SELF-ORGANIZING" if we wait for this hardening period to get the tech debts addressed that means our team is not SCRUM team. We are trying to make some hybrid in nature wherein we will wait for last "hardening" phase to happen to sort out such validations and verifications issues.
Moreover, team could be prone to wait for this period and slowly would become reactive than being proactive and self-improving.
while you say "hardening", my experience is that this is more about "release readiness" than hardening - i think hardening just comes off a bit more like motherhood and apple pie (who doesnt want to "harden" before they go to production?). in my opinion, any team that is using hardening / release / transition sprints should have an accompanying goal of reducing the need for said category of sprint.
the reality is that for organizations "in transition" there is not an on/off switch for going from long test/uat/deploy phases to potentially shippable. they need some forbearance for improving development, testing, and deployment processes and it's not "anti-agile" to allow for this extra (albeit not ideal) extra sprint. especially if you're using this in the context of SAFe (Leffingwell) which is about scaled agile and may involve the work of multiple (maybe dozens)) of teams with final integration testing required (yes, they should be continuously integrating but that's a high bar in a very scaled agile context)
Chuck's comment about it being unplannable is true from the perspective of using it as a crutch, but if it's a temporary (known) transition step to resolve gaps in cross functional / DoD concerns then it is plannable and reasonable in my opinion.
It may be a step along the path of improvement, but it's not plannable in the sense that you can understand the extent or time involved.
Allowing non-integrated work to leave a sprint is a risk, plain and simple. Avoid the assumptions that come with that decision at all costs.