I wanted to start off this blog with a succinct definition of “Hardening Sprint” so we are all on the same page. I couldn’t find one. I found a lot of words on the Scaled Agile Framework site that talk about and apparently justify Hardening Sprints if you want to read that.
I decided to work up a quick definition of a “Hardening Sprint” myself:
A pre-planned iteration in which we will do all the things we should be doing all along, but won’t.
I’m reminded of a particular label that is very common on candy in stores these days.
It’s still candy, being fat free has nothing to do with the fact that it’s just as fattening as it ever was, being pure sugar. So why put that label on it? Simply stated we humans really like to justify bad behavior by lying to ourselves.
Here’s the thing, I don’t get worked up about Hardening Sprints because of the activities in them. They are most likely perfectly legitimate things that we need to do. My problem is that if they are Backlog Items we need to accomplish, then we don’t work on them in a “Hardening” Sprint, we just work on them in a Sprint. That’s all a Sprint is, an time box during which we work on the Backlog Items that we have committed to.
When we plan ahead for a specific sprint in which we will do the things we should have been doing all along we excuse the bad behavior. We tell ourselves it’s OK to put off what we should be doing today because we will just get that in a later phase of the project. That’s just Waterfall, which could be perfectly fine by the way, but if that works for you just call a spade a spade and admit you are still practicing Waterfall. Scrum isn’t the answer to everything.
Odds are in your Scrum project you may legitimately need some sort of release sprint, some period of time to put the finishing touches on everything before it goes out the door. This isn’t any different then any other sprint, but if we are setting side that time for additional testing (which we should have been doing all along) we are admitting we aren’t good enough to fix our process.
We are eating “Fat Free” candy and expecting to lose weight.
Scrum is hard, testing as we go is hard, being committed to solid technical practices is really hard. If we don’t deliver fully functional, tested, deployed, integrated (insomuch as we may be able to in test environments if we can’t push straight to live) pieces of business value with every Backlog Item we complete we aren’t going to be successful in our Scrum practice. Hate to break it to everyone, but Scrum is a disciplined framework that is just flat out hard.
If you are throwing in the towel, and saying to yourself; “We need Hardening Sprints”. I think you are selling yourself and your organization short. You can do it, the technology, frameworks, and practices are there to support you, and your competitors are most likely doing it. So why not you?
Be sure to register for my upcoming agile webinar: Grasping Agility: A Guide to Building an Agile Organization, Wednesday, July 9, 2014 – 8:00-9:00 AM PDT.