Wednesday, April 01, 2009

Hardening Sprints and Dead Frogs

Teams will often schedule a "hardening sprint" at the end of a release. The purpose of the hardening sprint is to add a level of polishing and testing to the game that doesn't normally occur every sprint. An example of a hardening sprint task is to conduct an eight hour smoke test of the game to catch any problems that don't occur when the game is played for a few minutes.

Unfortunately the hardening sprint can end up becoming a dumping ground for work that should be done every sprint. This should be avoided as it postpones the team and customers from evaluating the value features that should be emerging every sprint.

I like to think of a hardening sprint the same way I think about detailing a car. I have a couple of sons, so I’m often cleaning out rocks and once living organisms they collect and forget weekly. Every month I’ll pull out the shop vacuum, rags and hose to give it a quick cleaning.

Every several months I’ll treat myself to getting the car detailed. I’m always amazed at how the detailers will clean out every nook and cranny in the interior. They even clean out the dirt from areas as obscure as the folds of the boot at the base of the shifter. Of course a week later all evidence of this cleaning is gone.

I don’t polish the shifter boot once a week. I don’t have the time or the need to clean to that level so frequently. On the other hand, I don’t put off cleaning out the rocks and wildlife from my car for the detailers. I don't think they'd appreciate cleaning out mummified frogs.

A hardening sprint at the end of the release is like having your car detailed. It’s important that it only be thought of as the extra bit of polishing detail that you don’t do every sprint. It shouldn’t be a dumping ground for bugs, tuning and stand-in asset work that should be tackled every sprint.

So don't leave the dead frogs for the hardening sprints!


Mike Cottmeyer said...

This is always a tough question to answer for teams "should I/can I schedule a hardening sprint?"

The problem is that while teams are transitioning to agile... they are building their CI environment... they are trying to get their test coverage where it needs to be... they are learning how to do things the right way.

Problem is that right now, their environment is not safe enough to go without a hardening sprint. They don't want a hardening sprint , but they literally cannot get confident enough in the short term to go without one.

I probably need to a whole post of my own about this.. but if a team needs a hardening sprint... I say let them have it. If they are still doing a hardening sprint a release or two from now... that is a problem. I encourage teams that need this to use the duration of the hardening sprint as a key agile adoption metric.

How long did we need when we started, how long did we need 6 months in, how long do we need now? If the number is not getting progressively smaller, we have a problem... the team is too complacent and has probably only adopted agile in name.

Clinton Keith said...


In the game development world, there are a number of subjective elements that can't be used to entirely eliminate a hardening sprint however. Sometimes we'll want to schedule a playtest group to come in just before we start it to determine what really needs to be addressed to bring the game up to a true release.

Most games only have one true release after 12-24 months of development. A hardening sprint can be used to introduce and use surrogate customer feedback.