Release Wednesdays

This Wednesday, one of the teams I work with shipped a new version of their product – the DLM Dashboard – for the 10th Wednesday in a row. That’s 10 releases in the 10 weeks we’ve had of 2015 so far. Which is pretty cool.

One of the notable things about that release record is that we haven’t shipped on any other occasion in 2015. That’s because we made a working agreement to release only on Wednesdays. Imaginatively, we call this initiative Release Wednesdays. Yes, it’s a thing.

As a result of putting Release Wednesdays at the heart of how we develop and deliver software, we’ve optimised our projects, processes and practices so that we can to release frequently and deliver new features incrementally. Interestingly, in addition to increased pace of delivery and user feedback the weekly cadence gives us, we’ve found many of these optimisations to be beneficial in their own right.

Before I highlight some of those optimisations, here’s a quick synopsis of ‘why’ we have Release Wednesdays:

We release every week because:

• We want to give our users valuable enhancements as quickly as possible and get timely feedback on the direction we are taking the product.
• We believe in keeping the delta between releases small and the risk associated with an individual release low.
• We think practice makes perfect and that the more often you release the less frightening it is to do so.

We only release on Wednesdays because:

• We want to have a ‘deliberate’ release process, not an ‘opportunist’ one.  An opportunist release process results in an irregular release rhythm; sometimes there might be three releases in a week, sometimes one a month. You release when you can. A deliberate approach to frequent releases means a regular, sustainable rhythm.
• It keeps us honest. In order to achieve our goal, we need to be able to keep our build ready for release continually.
• We don’t have to think about when to release. An opportunist release process means that you need to continually agonise over whether ‘now’ is a good time to do a release or not. That decision can take time, effort and (possibly) a great deal of thought. Agreeing to release every Wednesday means that our ‘when should we release?’ problem is solved.
• We don’t want to drown our users in updates. We think that one release a week is frequent enough for users to get their hands on the latest work we’ve done and give us timely feedback, without the update notification becoming irritating.

How we’ve optimised our approach for Release Wednesdays:

• The team are responsible for the releases – they decide when things are shipped. In parrallel, I’ve encouraged them to buy into a weekly release cadence and do my best to coach them when they discover obstacles to delivering stories. Without the team being behind this initiative, it was not going to work. Once the team had tried it and liked the momentum we achieved, the approach was here to stay. Now, getting then current story done in time for next Wednesday is hugely motivation for the group.
• We’ve streamlining our release process – automating everything we can and simplifying everything else. For example, we rely on automated testing to prove builds and, thanks to an internal tool, we can deploy to Production with the click of a button. See my post from 2013 about the benefits of automated deployments.
• We break our work up into small, incrementally valuable user stories. This is so that they can be integrated into our weekly cadence – each story should be around a week to two week’s work for the team. This is obviously a bit of a black art, so we’ve had to think a lot more deeply about the scope of our user stories and their relative value. We have found that we have a much more ‘agile’ backlog and a good feel for what we can achieve in a week.
• We keep the product code in a continually releasable state. This is a working agreement and has pushed us to use separate branches for each feature, user story or bug fix, so that the root of our source control repository only has work that is fit for immediate release. An additional benefit of this is that any parallel streams of work (e.g. a new feature and a big fix) are isolated from one another and so can be shipped independently.
• We apply the Agile Release Train technique, which has brought it’s own benefits – #NoEstimates, Team-driven scope management and clear planning horizons. See my recent post on the Release Train for more details.

Just to be clear, almost all of these optimsations have caused us problems from time to time. For example, we sometimes find it difficult to keep within the bounds of our small stories and the pressure of always want to get something finished for the next Wednesday can feel relentless if we are not mindful of it. It’s also fair to say it’s not going to work in every environment, with every kind of software development project. However, we build a COTS product which is installed on hundreds of client machines across the world and it works well for us. I really beleive the benefits of a deliberate, weekly release cadence far outweigh the disadvantages.

I’d encourage other teams to experiment with Release Wednesdays – well, to try deliberate releases on a day of your choice at a fixed cadence (weekly, fortnightly, even monthly). We probably shouldn’t all choose Wednesday. If the enitre world released their software on the same day, it might be a bit wierd.