The topic of hardening sprints is much-discussed among Agile practitioners – sometimes in purist indignation but more in expressing helplessness, I feel! Let’s first understand what a hardening sprint is – it is an additional sprint that some Scrum teams run at the completion of all the earlier “regular” sprints. Over time, the hardening sprint becomes accepted as inevitable by organizations and a dragon impossible to slay.
Here is our take on an approach that can help such organizations to muster the courage and will to at least cut the dragon to size if not eliminate it.
Step #1:
So, where do we start? With gathering data and assessment, of course!
In organizations, hardening sprints (let’s call them HS) would have come about for a variety of reasons – from integrating external interfaces & dependencies and performance testing to simply many sundry things (like documentation for regulatory compliance etc.) that need to be done. So, the organization should first look the reasons for HS, what gets achieved in the HS and get a common understanding of the across business leaders, product management, engineering and Scrum teams. This step then provides the basis for further collaborative actions to reduce the effort and elapsed time spent in the HS.
Step #2:
Armed with the above understanding of contributing reasons for the HS, the next step is to find as many options as possible to address them – to work around them, work through them and kill them if there is half a chance! Dismember the dragon, as it were!
Let us take a couple of examples of how this might be done in terms of reasons and possible actions:
Example 1:
- Scrum teams often mark stories complete because of the pressure to deliver although the Definition of Done (DoD) may not be fully met or does not fully cover aspects like integration and deployment. This team behavior may have been conditioned to just get through the sprint review purely from a feature delivery perspective.
- The above team conditioning is, in many cases, the pressure from the product management folks who often come up with some “must have” feature additions to an existing feature being implemented in a sprint. These feature extensions may be traced back to suggestions arising from a product preview with an important current customer or a big potential prospect. Such feature extensions can work overflow (typically testing) to subsequent sprints and finally into a hardening sprint – a catch-all for all such undone work from earlier sprints.
- The situation above needs intervention jointly by leadership, product management and engineering to address team perceptions and reinforce the principle & spirit of the DoD. Leadership needs to walk the talk and support the team in striving for “end-to-end” quality while still being responsive to time-to-market considerations. Engineering management needs to keep track of the incidents of “feature extensions” and the conscious trade-offs made between the team and product management so that HS is not viewed in isolation by stakeholders.
Example 2:
- Here is another example which may be more on the “hard” side of things in terms of reasons for HS. Teams may be genuinely hampered by the lack of the right test environment including volume data, tools, automation, service virtualization etc. and hence unable to fully satisfy all aspects of the DoD.
- In this case, the solution may seem simple – leadership to sponsor & support through test automation, training and may be DevOps tools to “shift left” work.
- Although simple in concept, these are significant initiatives in themselves and need to be assessed in terms of investments and the resultant reduction in HS effort & duration.
Step #3:
Step #3 is about inspecting and adapting – reviewing the actions taken in step #2 above. One should be prepared to accept that not all actions may succeed as much as expected. Lessons would necessarily be learnt and other actions & course corrections need to be initiated. Back to the good old Plan-Do-Check-Act cycle!
In summary, our submission is for organizations to address the pain of HS rather than be resigned to it as the dragon that cannot be slayed. You can start NOW in your organization with an assessment & analysis of your HS in recent releases. It should be a high priority initiative as part of an organizational “improvement backlog” to be addressed by a task force of people from across Scrum teams, Product Management, Operations and other key stakeholders. We have seen such initiatives – with ground-up analysis and actions from the leadership in terms support, investments and coaching – making significant reductions in HS effort & time. Agile coaches can be champions in such a task force and make their coaching more outcome-based! But that is another story for a later time!
