​​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 hamster-in-a-wheel effect.

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 item.

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.