2010-09-28

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?

5 comments:

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.

Ehud

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?

LinkWithin

Related Posts with Thumbnails