Keep Shipping…Early & Often

Release early, release often is a devops mantra preached for a while by many devops advocates. This ties in nicely with Agile principals of tight and frequent feedback loops amongst developers, testers and more importantly users.

However a team who’s used to releasing less often, who prefers to release well rounded full features worked over weeks if not months, might not jump head first in to this idea. Especially if there are no obvious issues with the status-quo. For example, I have worked in a domain where most of the features were seasonal in usage — i.e Certain features don’t get used immediately when released, rather they get used at a specific time of the year. It’s easy for such a team to see no point of rushing towards production when in reality users were not going to use them anyway. Are there any benefits of doing frequent releases for such teams? If so, what are the tools and processes we can use to get the team to a point where they feel they can do this safely and consistently?

To understand the value of a new method or tool, you should probably try to put it in a context where its value is not that obvious. For example, frequent releases sound exactly what a social media or a fintech startup wants, however a government agency may see them as undesired disruption to a well oiled machine (albeit one that works very slowly). It’s exactly in those less obvious situations where you should try and unearth their value.

Benefits

1. Improves team focus
2. More responsive to customer needs by exposing issues & opportunities early
3. Fail fast and fail cheap (Critical in pivoting your feature/product)
4. The definition of done is more clear and plain to see
5. Encourages more collaborative team culture to get things done
6. Move teams towards being cross functional

Issues

1. Work is not ready within period — half cooked features
2. Extra time pressure on the team
3. Justifying the value to other stakeholders
4. Higher perceived failure rate

Although as an industry we keep talking about continuous delivery, many organisations are not ready or don’t even see the value of that Utopia. That’s why I feel the move towards frequent releases needs to be gradual. With it, the value can be delivered to the organisation incrementally without having to fight a huge backlash.

Releasing often doesn’t mean that you go ahead and buy a bunch of tools and services and get them to work. The shift of culture is by far the toughest hurdle you need to get over and no amount of tools and services alone is going to get you there. What I recommend is to move slowly towards this goal. If your team is doing monthly releases, yeah — aim for fortnightly and then weekly. But if your team is doing a release every 6 months, then you can’t expect them to adapt to weekly releases straight up.

Best Practices and Tips

1. User stories that follow KISS

Writing independent, deliverable stories is not easy. Especially when you break down a big feature, stories can become disconnected pieces of functionality that don’t bond well together. Most of the time the order at which they can be worked on and delivered is also not evident. However it’s a key part of the puzzle. Don’t shy away from putting that extra effort to getting this right. It takes a few sprints to get the hang of it, so don’t give up if it doesn’t quite work at first.

2. Feature Flags

Invest on a modern feature flag system. Don’t build — just buy. There are several good products around. I have personally used “Launch Darkly” and it’s very good. This helps settle your team’s nerves when features are not ready for the release. Use them to drive home the difference between deployment and release. To help teams accept the fact that not everything will be fully finished end of each sprint.

Incomplete features used to translate in to delayed releases, but not any more. With feature toggles you can now separate deployment from release.

3. Build and Deployment Pipelines

Only do builds and deployments via a pipeline. Not manually. Even if it means you don’t quite have the solution yet. Building and improving the pipeline should be part of the sprint and with every release it’ll get better. Every change to your product — be it code, database, warehouse or backups — should be delivered via a pipeline. When releasing often, it should be something that you can do over and over in quick succession without thinking too much. Pipelines empower you to do just that.

Tip : Building the pipeline should be the first thing you do. Pick a template project for the tech stack of your project and just push it via a pipeline to your infrastructure of choice — cloud or on-prem. You will be surprised how much this exposes your implicit assumptions on how your software should run.

4. Encourage team to help each other and celebrate collaborations

One of the worst effects of working on lengthy releases is that team members tend to get lost in their own bubble of work. With short releases, work is bite sized and everyone understands what the other is doing and can potentially pitch in and help. This is highly evident at the start amongst developers and testers. Ask each other who needs help and jump in on the opportunity. Recognize and appreciate team members who do this more often.

5. Communicate Early…Communicate Often

Frequent releases are not possible without frequent and honest communication. It’s extremely critical that risks and issues are discussed often and early. This paves the way for a game of jigsaw puzzle where stories can be exchanged/toggled off/pulled out/reverted early without putting the release at risk.

6. Razor sharp focus on Work In Progress

The work during a sprint should flow from Left to Right moving from one stage to another (eg: Analysis -> Active -> Resolved -> Deployed -> Testing -> Closed), at a consistent speed. A good sign of an unbalanced team is when work piles up at one or two stages. A team lacking testing focus will end up piling work under “Testing” while developers pump one story after another. In this instance developers are highly efficient, but the team as a whole is performing poorly. By having and honouring Work in Progress (WIP) limits, you push the team towards assisting each other to keep the pipeline moving.

Once you taste the success of frequent releases, you’ll never go back. It is a great skill to have as an individual, a team and an organization.