Why every software team should get into the habit of daily releases

I’ve written in the past about the importance of continuous delivery, and how learning to do daily releases has helped Klipfolio’s agile software development team improve both its product and its processes.

But just how critically important continuous development and daily releases are came into sharp focus for me recently when I read The Power of Habit by Charles Duhigg. I realized, as I read the book, that after we got into the habit of doing daily software releases, there was a cascade of positive outcomes for our team all along the line.

We had in effect created what Duhigg in his book calls a ‘keystone habit’.

Today, I want to advocate for daily releases and continuous delivery by showing how getting into the habit of doing them benefited us.

What is a keystone habit?

Duhigg is a New York Times business reporter. His book starts by looking at the science of habits – why they exist, and how they can be changed.

He goes on to argue that the key to success in anything from losing weight to creating an exceptional company is understanding how habits work. And, by detailing the experience of successful individuals, sports teams and corporations, he says that learning to implement what he calls ‘keystone habits’ can, in the words of his book’s website, “earn billions and mean the difference between failure and success, life and death.”

I found the book fascinating and I highly recommend it to anyone who is interested in the topic and wants to learn how to use habits to transform their life.

Duhigg’s notion of keystone habits really caught my attention.

According to Duhigg, these are the habits that underlie our daily behaviour and in turn influence other habits we have and the way we work and play.

I’m a big believer in the power of routine and I’ve written about it before. If you are interested in a personal perspective on how habits can transform your life, this article has a good summary of some of the keystone habits anyone can use as an individual.

However, when they are considered from a business perspective, that the idea of keystone habits gets interesting.

In this Huffington Post blog, Duhigg himself writes about how in 1987 Paul O’Neill, the CEO of the Aluminum Company of America (Alcoa), turned the company around, and created an impressive trickle-down effect of improved habits all around, by focusing on just one thing: making the company safer.

Duhigg writes that “O’Neill’s success at Alcoa is just one example of a keystone habit, a pattern that has the power to start a chain reaction, changing other habits as it moves through an organization. Keystone habits, I found in writing my book, can influence how people work, eat, play, live, spend, and communicate.”

That is a powerful message.

As I pondered its meaning, I realized that at Klipfolio we had created a similar chain reaction by introducing continuous delivery to production and daily releases.

The keystone habit: daily releases and continuous delivery to production

It’s only when I looked back at how we used to work that I realized that our keystone habit was the adoption of daily releases and continuous delivery to production.

Once we had made the change, it resulted in a cascade of other changes that transformed our Klipfolio agile software development team – for the better.

In retrospect, it all seems so logical: You simply can’t do a daily release unless you follow a number of best practices in your development cycle as well as your continuous deployment pipeline. For daily releases to work, we had to change other habits.

The habits we created - and those we broke

Here are the habits and best practices that we developed after we decided to make daily releases to production a keystone habit of our team. It’s important to note that, in addition to adopting new habits, we also had to eliminate some behaviours that were preventing us from reaching our goals.

• We share the burden for daily releases among several people
  We used to have a single designated person to do the releases. That limited the team’s ability to act and learn. So now we have at least two people per scrum team who can do the daily releases. We rotate the role with every sprint. Each person who takes a turn takes notes on things that can be improved in the release process. This has resulted in incremental improvements in the release process over time. Because everyone shares in the daily releases burden now, we all look for opportunities to improve things.
• We document the process better
  Our release process used to be a combination of manual steps and scripts and was not well documented. We have now improved both automation and documentation. Most of the process is automated, but the parts that are still manual are now well documented.
• We have created a culture of testing
  Writing automated tests was not part of our culture. We did a complete turnaround in that regard. We’ve transformed the culture of not requiring or wanting to write unit tests to a culture in which people advocate for above 90 percent unit test code coverage in new projects. This has created quality-driven development habits like code reviews and automated testing, continuous integration and more.
• We’ve automated where we can
  This has meant automating all tooling and processes, including building environments infrastructure, with code. For example, where before we had only one test environment that could be used by specific people, and a test environment that had to be provisioned manually, we now have more test environments than developers in the team and they are all built by code.
• We release in small increments as soon as possible
  We used to hold back large features for a long time until they were “ready.” But we’ve found there are benefits to continuous and incremental delivery of small shippable increments, including better break down of features, user stories and user validation along the way, as well as frequent use of feature switches (read more here).

This has not only impacted the dev organization but also transformed the business to think differently and be comfortable with small increments and feedback-driven product development.

While not all of the above habit changes are must-haves in any journey towards building the daily release habit, when you start that journey you'll seek improvements in the quality of your releases and you’ll start tracking various agile metrics. Somewhere along the way the other habits I mentioned above will start to feel inevitable and part of the journey.

That's why I think daily releases are the keystone habit of great software development teams and why I highly recommend to make it a habit of your organization.

See also:

• Continuous delivery: What it is, why it works - and why you need it
• How to ensure quality in continuous delivery
• Key metrics for agile development teams
• A software development manifesto
• How do dashboards help agile software development teams?