Things done well and with care, exempt themselves from fear.
— William Shakespeare
The hardening iteration in the Big Picture (and as I’ve described at length in Agile Software Requirements) has always been a source of fear, comfort, concern, (sometimes even loathing), and occasionally, all of the above combined. Emails in the form of “that isn’t agile, teams will use it as an excuse to defer technical debt”, and “big-company dummy, don’t you know you should be shippable every day”, and “of course you have to have it, when else can you do the final field testing we can’t do in our environment” and “anyone who doesn’t think you need a hardening sprint has never worked on a really big software program” have found their ways into my inbox since the Big Picture was published. In any case, since the framework is nothing if not pragmatic, let’s consider the hardening sprint from three aspects.
- Stuff you must do, and probably can do only in hardening
- Stuff you should be doing earlier, but have to do in a hardening sprint for now
- Stuff you absolutely should have done earlier, and for which you are using the hardening sprint as a waterfall crutch
Let’s look at each of these individually.
Stuff you can probably only do in hardening
In many environments, there are a number of things that must be done, and can only be done (efficiently) during hardening. To name five:
- Final exploratory and field testing
- Validate solution against release, quality, and standards governance, and any marketing/sales/deployment/operations requirements
- Develop deployment, installation documents
- Create release deployment package
- Create release communications
In addition, in high assurance environments, you’ll probably also have to finalize and “sign” product requirements and software specifications, and also finalize traceability artifacts and other documentation of quality as required by regulatory requirements or internal Quality Management Systems.
Stuff you should be doing earlier
In addition, especially in the first year or so of transition to agile, the hardening sprint may be used legitimately for a number of other things. These may include:
- Final cross-component integration and/or integration with third party or customer components
- Final, integrated, system level testing
- Final System Quality requirements testing (testing nonfunctional requirements (NFRs) such as performance, reliability, accuracy, load, scalability, etc.)
- Finalize localization across all required languages
- Finalize user documentation
Stuff you absolutely should have done earlier
And finally (and hopefully only for those just transitioning to agile) , five examples of some of the stuff “you know better than to defer to the hardening sprint (don’t you?).”
- Final system integration
- Elimination of P1, P2 defects that remain
- Automate remaining manual test scripts
- Deferred regression testing
- Update user documentation
Hardening Sprint Cadence and Summary
When it comes to cadence and length of the hardening sprints, while the Big Picture appears to indicate periodic hardening sprints just prior to program level PSI/release boundaries, the reality is a lot more flexible and (a little more complicated). But let’s state it clearly:
Agile Teams can place hardening sprints anywhere, if and when, they are needed.
So long as you are not “doing the stuff you should have done earlier,” and you are continually lightening the stuff in the “should be doing earlier” pile, then you are increasingly agile and on the right track.
Scaling Software Agility 