Agile teams do not need hardening sprints and in fact, they should be discouraged to use this approach.
Many agile teams, specifically in software development, will use hardening sprints as the moment where technical debt is dealt with, where work to prepare a release is finally done, and integration of code inter-teams get addressed and tested and fixed. That was also common in the SAFe adoption, so it belonged to a framework that many companies followed.
Hardening sprints, however, are not only unnecessary, they can be harmful as this can become the dumping ground of tidying up what should be neat in the first place.
In this post we’ll cover why it’s not a good idea to use hardening sprints, and I’ll bring your attention to potential causes of using a hardening sprint; the biggest one being going through the “motions” of agile without understanding them. Prime spot for an agile coach to help!
So without further ado, let’s get into it.
It’s a sign of poor agile adoption
Using hardening sprints can be a mindset issue. Thinking in waterfall or horizontal breakdown of features while operating in “sprints”. Yes, in quotes.
When people are used to more traditional styles of project management, gate phases and non-collaborative ways of working they might just understand the “sprint thing” as a moment of focus to codebut not consider that in agile you aim for small, constantly potentially releasable, integrated code. That’s the use of agile.
When you finish a sprint or iteration you are expected to have functional, potentially shippable code ready.
Understanding done as “not yet releasable”, incomplete pieces of software or product makes hardening sprints seem acceptable. Understanding sprints as something you rush through quickly and get a pile of stuff “almost done” is another reason. It’s actually quite ironic, as you code fast to be done by the end of the sprint, but the done is not fully done. If that makes sense.
When planning is still done in phases or when the work is broken down in very big chunks you risk seeing people plan for a hardening sprint.
Also, when you truly accept that iterations or sprints have a meaning, a goal you won’t see a need for a hardening sprint. You can’t call a “fix issues and iron things out” objective as meaningful. Not when you could have just planned and worked towards getting things smoothed out iteratively as you go.
It delays quality and risk clearance
One of the most important ideas behind delivering increments of a product via iterations or sprints is to deliver value early and often.
Because those increments tend to be small, so that you can be thorough while not taking months to deliver something, you can focus on quality.
All these together, de-risk your product early.
Hardening sprints open the door to lowering the standards of technical excellence, because by definition, “stuff gets ironed out” later. In fact, it means we plan for lack of quality in this scenario. I know it can feel extreme to read this, but just consider: you are planning for things that are not yet done that are paramount on your code, such as quality built-in, tests, technical debt, release scripts, what have you.
What kind of culture and products can be produced by this approach, where quality and the ability to release are delayed?
How about aiming for no defects from the get-go and create the environment technical and cultural that can produce that instead?
The whole idea behind any agile approach is that at the end of an iteration you have in your hands a potentially shippable product. If you are still fixing things as you prepare to release, that is very late. You eliminated very few risks till then. The cost of fixing problems is still high, because a several sprints have run and you still have in your hands, not done, the technical aspects of what a release demands.
It’s poor feedback loop
Sprints are iterations. Iterations are important feedback loops, which mean you assess if what you are doing is line with what is required, both in terms of product quality and stakeholder expectations.
At the end of iterations, you want to be confident moving forward. Or changing direction if you detected that is what’s needed. You can make that type of decision because you are making the necessary changes as you go.
Two things are wrong in an approach of hardening sprints for the feedback loops.
One, you are delaying adaptations and learning, because you are relegating those to the moment of “hardening”. You keep increasing the list of things to attack later. You are delaying effective solutions from the get-go, because we have “fixing time” at the hardening sprint.
That impacts the second thing, which is that you did not show your stakeholders stuff that is fully done. Technically and practically, as you prepare later on, some of the things you showed might need to change, because something else was not yet implemented. It could be visual, it could be in the interoperability of the product, it could be a whole feature. You now got your stakeholder asking you those silly sentences during product review such as “is it done-done”? How can you have done that is not done?
A final piece of this puzzle is the risk of poor inter-team collaboration. Because you have that fixing time as a full sprint before the release, most commonly than not, teams will integrate code and fix integration issues at that time only. So plainly speaking they have been working in silos, offering stakeholders and themselves a partial view of everything that is being prepared but not delivered. And when the hardening sprint comes it’s a madness of overcommunication or blaming because someone believed it costs too much to integrate sooner.
What do you coach for?
I prefer to ask the question “what to coach for” instead of “how to fix it” because the avenues for fixing the need for a hardening sprint can be multiple. So I’m going to lay out a few for you.
A common misunderstanding is understanding sprints or iterations as mere cycles, like weeks or the months, instead of feedback loops. That mean, people could very well just take a TODO list and divide that into the upcoming weeks and call it “working in sprints”. And they do.
But iterations go beyond tackling TODO lists, and they aim at something. Agile iterations exist so that at every single one you could potentially release your product. Or end all development there, no further coding. Is it hard to operate like this? Of course! You have to fight mere aimless execution of tasks and be intentional and consider each piece of work that a teams accept!
Another big reason is the vulgarisation of business terms such as value. Value is not a relative concept in business. Value expresses a monetary term or something of equal wight in the eyes of the customers. From that perspective, not a single piece of undelivered work has value. Value has not yet been realized when things have not been delivered to a customer. So technically, you did not win yet.
A third reason can be the need to rush without being fast. OK, that may have sounded weird, so let me put it in another way. Rush to finish “stuff” at the end of sprints. Although, the list of “stuff done” makes you feel fast and speedy, since no actual value has been delivered, the team, department, or organization is actually not shipping fast. Instead, to ship fast, you actually need to slow down what you think you can do in sprints or iterations. Your shipping fast now must mean that you only consider value. So before, maybe you had done 3 pieces of functionality, yet they all need to be ironed out in a future hardening sprint. Now, you finish only one functionality per sprint. But you finish it. In its entirety. With value. That is the actual speed that matters.
You are probably noticing the patterns here. Quality early on, de-risking early on, slowing down the pace to a sustainable cadence.
Basically, pay attention to the thinking patterns that seem to be off and try and figure out what a corresponding agile principle could be strengthened here. How do they see technical excellence as something that can be delayed? How do they (mis)understand value and its early delivery? How is this approach of done-not-done helping them (or not) to be accepting of change? How do they view collaboration?
And off you go.
This is not a dogmatic approach, as many different implementations can be put in place per each principle. It is you helping your teams and departments to live the mindset that they chose to espouse.
Just remember: from teams to their managers, someone at some point will feel a conflict as they accept the agile routines and techniques faster than they could grasp the thinking patterns they need to enable. And that is totally normal. Be prepared to help them navigate that part of understanding the missing pieces and you will be on your way to creating highly performing teams.
