The success of weekly releases

Back in August last year my team and decided to release our product on Wednesdays.

In fact, I said we were going to release every Wednesday.

At the time, our deployment processes were already automated, we were breaking our work down into small valuable chunks and our automated test suite was comprehensive, trustworthy and performant. However, we were keen to get away from the ‘opportunist’ release process we had fallen into, where we released whenever an opportunity arose. This resulted in an irregular deployment cadence and had the side-effect that we were continually agonizing over whether ‘now’ was a good time to ship. ‘Release Wednesdays’, our initiative to release every Wednesday and only on Wednesdays, was intended to fix that while ensuring the product code was in a constantly shippable state and we didn’t swamp our uses in new version notifications.

So, what happened? Well, since the inception of Release Wednesdays six months ago, we’ve released our product 23 times and have settled into a really solid, comfortable deployment cadence.

When discussing our frequent, regular releases I find myself using the metaphor or a train running to a timetable. It helps to communicate a few key concepts of our approach:

• Releases happen on a deliberate schedule
• A release delivers cargo (features, bug fixes, enhancements) to a destination (the users)
• The team needs to get its cargo ready in time for the next scheduled release. If they miss that, then the release will not wait for them and the cargo has to wait for the next scheduled release.

As an aside, this model is often used in a multiple team environment, where a number of development streams need to be synchronised in order to get a release out of the door.

Release Wednesdays are a success!

We’ve found that there are many benefits of our weekly release cadence:

• Users get valuable new functionality sooner – if we feel that users will get value from a partially complete feature (where the ‘complete’ part has been fully tested), a bug fix or a usability enhancement, then we ship it on the following Wednesday.
• We don’t need to do ‘special’ builds – because our next release is on average only 3.5 days away, we never need to do special (a.k.a. private) build to help individual users get around a problem.
• We are better at releasing – we’ve practiced, we trust our automated tests and we’ve streamlined our process.
• We don’t ship broken releases – even though we release much more often than we used to, we have not shipped a release we have had to recall since we started Release Wednesdays. That’s because we’ve kept the delta between releases small and the risk associated with an individual release low.
• We don’t spend time worrying about when we should release – if it is not a Wednesday, we don’t start the release process.
• We are always releasable – we’ve had to organise our development environment so that we are always ready to release. That means using the likes of feature branches, tiered automated tests and continuous deployment into a test environment.

Our Release Wednesdays initiative has been a great success and it’s something the team are pretty proud of.

However… last week we did not release on Wednesday

This was because our new ‘cargo’ was not ready to deliver to our users. This was not unexpected, because we had estimated that the feature we are working on – the automated clear-up of old deployments on agents – would take two weeks to complete.

It’s quite normal for us to be tackling a feature that takes longer than a week to develop. In the past, in parallel with this feature development, we have also worked on bug fixes or usability tweaks that, when complete, are valuable cargo in themselves. Some features we work on give the user a valuable new capability even if they are only partially complete. So, we ship that cargo on our weekly release schedule.

What has changed over the last few weeks is that the team have become concerned that this parallel development is slowing down the delivery of important features we’d like to give users as soon as possible. This issue came up at our most recent fortnightly retrospective meeting; the team were disappointed that we had not delivered what we had wanted to in the previous sprint. We decided that this was because, between all team members, we had worked on four or five discrete pieces of work at the same time. To tackle this issue, we decided to reduce the work the team is allowed to undertake in parallel to be two work items (stories, bugs or enhancements).

This experiment has had the desired effect, as progress on our current feature has been excellent. We’ve ‘swarmed’ on that one thing – meaning the entire team has worked on developing a single feature. You can see that from the picture below showing the team’s faces on the whiteboard, representing what people are working on. The team members’ avatars (cheesy pictures) are close together (all three rows are for the same feature, btw). In addition, everyone understands the feature at a technical and functional level, and it truly feels like the team’s work.

However, another result of this focus is that because the feature, a two-week sized piece of cargo, was not ready for delivery on Release Wednesday. As we hadn’t worked on anything else, there was no new valuable capability for us to put into the hands of our users.

David, one of the development team, summed this up really well:

“I see it as being a trade-off…

On the one hand we want to progress a number of different things so we have lots of small, valuable stuff to give to users every week. On the other hand we want to finish the most important functionality sooner, getting everyone swarming on the same feature and feeling like a true team.

Because we think about continuous improvement, we’ve decided to change the balance in favour of finishing features, right now. However, we’ll look at what happens and may decide that we want to shift the balance back, or that what we actually want to do is break our features into smaller, valuable parts”

In summary: the team are still committed to Release Wednesdays, we’ve just decided to focus on adding one new feature at a time. Users will get the first one of those features this week. On Wednesday.