“Are Hardening Sprints Valid In Scrum?”
It’s Not About Right Or Wrong
I try very hard to avoid dogma. If I have learned nothing else over my years in software development it’s that almost without fail there are multiple ways to success. They all come with their pros and cons, but if a particular approach has proven successful for someone then who is to say it’s not the right way for them to do it? If we always did things the “right way” we would never advance.
The question in the title of the article came up a couple of weeks ago in an online discussion I was in in one of the Serious Scrum Slack channels. I have seen this question come up many times over the years and my response up until the last few years would have been no, that’s actually an anti-pattern. Hardening sprints are not something you should be doing. The goal of each sprint is to deliver potentially releasable software. If we require a hardening sprint that means we are effectively doing a waterfall like approach which defeats the purpose of doing sprints in the first place.
I believe the above statement is absolutely true and to be crystal clear I am not advocating the use of hardening sprints. What I have softened on though is the notion that if a team is using hardening sprints then that is something that they must stop doing in short order. Primarily because for teams and orgs who are new to Scrum there can often be substantial obstacles they need to overcome in order to put themselves in a position to deliver potentially releasable software each sprint. When they first start out it may be completely unrealistic that they can do all the things necessary to deliver working software within a 4 week or less sprint.
Understand The Teams Capabilities And Limits
As an example consider testing/QA, an area many teams struggle with when first starting to do sprints. You can only go as fast as maintaining your level of quality will allow. Regression and performance testing are classic for having high transaction costs and take time to automate. The amount of time needed to manually execute the regression and performance suites very often is weeks.
There may be no way all the work can be done in a 4 week or less sprint. In that case maybe a team decides to do a “development sprint” followed by a “hardening or QA sprint”. They are effectively doing an 8 week sprint, but at least they are taking some steps towards where they want to be. Being honest about the maturity level of your process is important. It is what it is.
In the above example is it wrong or invalid for them to do it the way described? I believe that is the wrong question to ask. I think a more useful question in this case would be are they continuously making progress towards automating their regression and performance testing so that the amount of time spent manual testing is getting shorter with each release and are they able to maintain or even improve their quality levels?
If they are consciously working towards being able to do all the necessary work within a single sprint thus eliminating the need for a hardening sprint then they are embracing the necessary principles which is more important than the current state of their process and practices. If the right principles are at work then the process and practices will eventually catch up.
Allow The Team Room To Evolve
I think the danger in getting overly strict is that it can encourage unhealthy decisions and behavior by instilling an all or nothing mentality. Continuing with the example above let’s say the team had a dogmatic SM and told them that their two sprint approach is the wrong way to do it and until they can do it in one sprint it’s an invalid delivery process. In other words you’re not worthy of being anointed a Scrum team LOL.
That’s not likely to produce the outcome the SM would hope. One, that is poor leadership and probably won’t instill healthy motivation in the team. Two, it may encourage the team to do something like attempt to automate all the necessary testing via a big bang effort so they can become a “true” Scrum team. Becoming a ‘true’ Scrum team is not the goal. The goal is to deliver potentially releasable software each sprint.
In my experience trying to automate all your tests in one go is generally not a worthy pursuit. It is very tempting to “just get it all done so we can move on”. However, there is a lot of information that isn’t available to you up front and you often end up going down what turn out to be bad paths. You can easily end up with tests that are brittle and very difficult to maintain which largely defeats the purpose of automating them in the first place. In addition the team is brand new to automated testing and there is a substantial learning curve they need to climb. You don’t want to build all of your test automation when you know the least about automated testing.
I have found that implementation of test automation or any automation for that matter, should be done the same way you implement features, incrementally and iteratively. Implement slices of testing that will help validate the design of your automation approach and integrate well with your CI/CD pipeline. Prioritize them based on value, risk, and the time required just like you do stories.
The point is that teams and organizations need to be given the time and freedom necessary to evolve their skills, knowledge, practices, architecture, org structures, etc. so they can work their way up to delivering potentially releasable software each sprint. Forcing process and practices on teams and organizations that just aren’t ready for them will not accelerate success. It will most likely set them back.
I think the best strategy when starting Scrum/Agile/Lean/Kanban is to focus on what you are capable of doing then incrementally and iteratively work your way forward(Hmm sounds strangely like a Kanban principle<wink>). It will be a far more successful and far less painful journey!
