There has been much controversy over whether hardening sprints are necessary or not. See our agile experts discuss the pros & cons of hardening sprints, and learn why a co-founder of agile once threatened to revoke Bob Galen’s agile badge.
Dean Leffingwell introduced an agile requirement term known as release trains in which you do a recent execution where you wouldn’t necessarily deliver a product in the sprint but you would deliver a product at the end of a release train. When he talked about the release train there was a sprint at the end of the release train focused on testing so you would test during each sprint. He later introduces the concept of a hardening sprint. In this instance, it didn’t align with extreme programming, Kanban, or Scrum specifically; it was just a concept of – if you iterate development involving a major large-scale system development or enterprise development it would make sense to have a test focused sprint at the end.
One experience with a past client, which at the time was the largest implementation of Scrum with over 100 teams, they were introducing stabilization sprints (sometimes referred to as hardening sprints) into their current practices when we arrived to help them with their implementation endeavors. However, the cautionary tale is this organization found that as they transitioned teams from Waterfall projects to Scrum sprints and Scrum projects, the developers who had finished up the development would start sprinting, but in the Waterfall testing phase the testers where still engaged which kept them from being engaged in the initial sprint. In efforts to help alleviate or make sure there was enough testing, the client found that it was necessary to do some “testing type sprints” or stabilization sprints. They would do a normal sprint where there was some testing done but the full breadth of testing was actually done in the stabilization sprint. A big driver was the lack of automation, essentially, they were doing what is now coined as “Scrummerfall”.
“Hardening sprints are not a get out of jail free card to not do testing sprint by sprint, i.e. the hardening sprints will extend if you defer all testing to the hardening sprint. There is a relationship between the length and focus of hardening sprints vs. how much testing you’re doing by the sprint and how much automation you have. Ultimately this organization lacked both test automation and enough involvement so the hardening sprint did not serve as beneficial.” – Agile expert, Bob Galen
The difference is if your test automation, integration tests, or your test suite is not built out, that’s on your organization… but, it’s something you can overcome. So, a hardening sprint may be an external vendor that may never go agile… or with a regulatory environment; those are context in which hardening sprints always make sense.
“Other things, beyond testing, happen in hardening sprints. When training our customer support staff we would do DevOps readiness, transition like deployment tests, checklists, operational readiness, customer support readiness, and marketing readiness. Although hardening sprints are primarily focused on testing or qualification or getting it ready for deployment it a nice opportunity to do other things.” – Agile expert, Bob Galen
Short answer – no. However, agile is. More specifically in regulatory and external vendor contexts as well as contexts where there’s a hardware integration component. You’re creating a time to integrate and collaborate with others outside your organization and for that reason it makes for a good application of the agile principles. It helps bring other parts of the organization on board with this notion of agile philosophy or values. Hardening ultimately can be used to meet people where they are, instead of forcing an organization to do a potential product increment every 2 weeks in which you have to deploy to the customer.
To follow up with another note pertaining to the client from the example earlier – They were in a position where there was business pressure on delivering on a certain schedule. This was a large organization that was fully Waterfall at the time. They could not snap their fingers and instantly become Scrum. This in fact was the very reason we were brought in to help them, to help them steer clear of the things they needed to move away from. The organization has to make a notion to “meet the client where they are”. As a coach you want to bring everyone on board as quickly as possible, but in reality, it’s going to take time. Overall, you need the tools to meet the people/clients where they are (i.e. release train, hardening sprint, sprint zero) based on the size of the organization and its context.
>> Subscribe to Zenergy on Youtube for more videos