Hardening sprints? Sorry, you’re not Agile.

We do a series of sprints to build our product, then we do 4-8 weeks of hardening sprints to really test our code and get the bugs out before we deploy it in production.
Guess what? You’re not Agile, and you’re not doing Scrum. You are using the jargon, maybe because it’s fashionable, or maybe because you’re Agile practices are misguided. But you’re not Agile.

In fact, you are doing Waterfall, masquerading as Scrum. You probably did a lot of big up front analysis and design, followed by a coding phase (your early “sprints”), followed by a testing phase (your “hardening sprints”). You are masquerading as Scrum by using the Scrum jargon: terms like Sprint, Burndown, and Product Owner. You are applying that jargon to Waterfall. Some people call this Cragile. I call it Shcrum.

The problem with “hardening sprints” is that you are lying. You make believe your imaginary burndown during the initial sprints shows that you are approaching Done. But it’s a lie--you aren’t getting any closer to being ready for Production until you begin your Test phase. You wrote a pile of code that you didn’t test adequately. You don’t know how good it is, you don’t know how much work you have left to do, and you don’t know how much longer it will take, until you are deep into your Test phase.

I don’t mind that you’re doing Waterfall. Just don’t call it Scrum or Agile. And don’t do it on my team, because I don’t want my team to suck.

If you need “hardening sprints” before you can deploy in Production, you’re not Agile, and you’re not doing Scrum. What is stopping you from being Done at the end of each sprint?


meggers said...

Sometimes I wonder if the size or complexity of a product impacts the ability to be agile. Or perhaps it's testing rigidness (needing regression test and smoke test all functionality even if you never touched it to begin with). Testing might be the biggest roadblock to being agile. Because you could test forever and ever and never be "done", because testers are often required to show coverage reports and statistics which often say very little about the quality of the new functionality, and because testers are often in defensive mode (covering their asses so a higher up doesn't come back to them with "why didn't you catch this"), and because agile doesn't leave room for estimating all the extra testing tasks that don't fall into neat user stories (for example: product installation, setting up the automation suite anew, tool updates, environment setup)

Anonymous said...

I like your site Richard.
You ARE an OK guy.


Dzmitry Sukhau said...
This comment has been removed by a blog administrator.
Dzmitry Sukhau said...

Could you please tell how QA could ensure quality of software without full-tests at least on releases?

Richard Kasperowski said...

Hi, Dmitry! I'm thinking of your Definition of Done: are you getting everything Done by the end of every sprint? If you are, then you've done the full testing, and you're ready for release.

Does your team have a Definition of Done? Does it include everything you need to do to be able to release your software?

einLiterVollmilch said...

I know, that's an old topic. But one thing that just came to my mind while reading Dzmitrys comment: like Richard says, it's important what you consider "done". In the best case "done" means, that a feature is really working, which of course means it's properly tested. But there's another dimension: can you consider a feature "done" if it breaks anything else? Guess you wouldn't. So a requirement for declaring it "done" is as well, to make sure, it doesn't break anything. That means having regression testing in place. And with fully testing every new feature and regression testing everything with every new feature, you've done full-tests when you release.

Edward Rod said...

Yes - I think E2E testing is needed somehow to make sure your system flow correctly from start to end. By going with an Agile approach you are just doing unit testing or integration testing, which is fine to test the code and delivered feature, however, when it comes to an user perspective, you need to make sure things are not broken and that they are flowing fine when put as a whole. Therefore, I think a hardening phase is needed.

Richard Kasperowski said...

Hi, Edward! Thanks for the comment!

I'm curious: what would it take for you to be able to do all of the testing a user would expect every sprint?



Related Posts with Thumbnails