Last time we talked about irregular releases and
why they happen. So without
further ado, let's pick up where we left off.
Sprint strategy continued
It's sometimes tempting to introduce code freezes of some sort, meaning a date after which it
isn't allowed to introduce any new code to the sprint's version (only defect fixes are allowed).
While in general this idea is not bad, setting a fixed date reduces a team's maneuverability and
often hinders effectiveness. Fixed code freezes are a waterfall-ish attempt to create a
feeling of control. Needless to say, this is often not an idea of the development team itself,
but rather some company process. Code freezes rob the team of one of the biggest values of
agile—adaptability and room to find creative ways to become more effective.
Risk in items must be evaluated individually for each sprint backlog (based on size, complexity, technical sophistication etc.). The team must then decide on the latest reasonable time frame for starting final testing. That means, for instance, that for a big item
that time frame might be around the middle of the sprint, whereas for a tiny change it is half a day
before the end of the sprint will suffice. After that moment it is risky to
include this item in the sprint's product increment. Again, the team must evaluate individually the amount of risk involved in additional work is after they finish the implementation of a story and start
final testing—and plan for this accordingly. Attempting to set a one-size-fits-all code freeze
date will usually lead to the date being too early for items of small complexity and way too
late for more complex items.
The beauty of frequent releases
At the end of the sprint, the product owner decides if he wants to actually release the sprint's
version or not. It may not be necessary for many reasons, but he always needs to have the option
to do so. It is generally advantageous to release as often as possible. Releasing frequent small
batches of features induces far less risk of something major going wrong and makes a potential
roll-back not that painful. And it's great for planning too, because there is usually no
“invisible” debt that would otherwise need to be done before a major release.
Typical symptoms of accumulating technical or business debt are so-called hardening sprints,
release sprints, bug fix sprints or whatever you wish to call them. Their goal is to remove any
debt before actually being able to produce a version that is potentially releasable. This is a
strong smell, as it indicates the inability to produce working versions regularly. It cures
symptoms, but the underlying habitual problem is still there.
It basically means that until the hardening sprint happens, the team has never truly had a
working, potentially releasable version of the product. If it had, the bugs (or debt of any
sort) would already be removed and there would exist no need for an extra time-out to fix stuff.
In my opinion this often happens due to an unconstructive pressure put on the development team to
deliver new stuff quicker, created by some external factor. I've seen product owners and even
scrum masters push teams to plan more stuff for a sprint without any underlying justification
stemming from the team's past velocity. It creates a false sense of progress, but with a great
amount of uncertainty. It leads to overcommitments and naive planning, ignoring the fact that
there is “invisible” work that always emerges: defects found, teeny tiny tweaks, refactoring
here and there, small changes, analyses, backlog refinement activity. Ignoring this leads to the
There is no reason to have so called hardening sprint(s) before release if you knowingly don't
push any debt ahead of you. How can you do any sort of release planning if you don't know how
many problems will appear when you actually attempt to create a releasable version after
many months of development? It is always more valuable (and, needless to say, stress-free) to
have a working, debt-free version after each sprint regularly (with seemingly less new
features), but knowing there are no skeletons hiding in the closet. Finding out problems as
early as possible to know how far you've come and how far you need to go, that's what agile is
about. That's the transparency everyone talks about, right?
What about bugs?
The Scrum team should understand that Done means that the team is reasonably convinced there is
no more work to be done on the new delivery. No to-dos. No bugs. No technical debt. No wording
that needs to be tweaked, no graphics that is just provisional. But realistically, software is
never bug-free. It can happen that a defect is discovered right before a sprint release. It's
tempting to block the whole release because of it.
There's an article coming up on managing defects in agile product development, but in short it is
always a good idea to ask yourself if the discovered bug is a regression compared to the last
productively used version. If not (meaning the bug already exists in the current live version),
there is rarely a reason why not to release an update even though it does not fix the defect.
And this discovered defect is then prioritised in the backlog in the same way as any other
It's a long way
I'm not saying it's easy to achieve regular releases. My experience shows that it's not, but that does not mean the scrum team should give up on it.
Adopting this habit and values gives the product owner a great amount of predictability for
future planning because he knows that he will get something to release on a regular basis. It
also relieves the pressure of something getting postponed for a later date than planned, because
everyone knows that in a short time it's going to be released anyway. Things just suddenly get
much more tidy.