Why changing your company’s culture helps make continuous delivery work. Part 3

This is the third of three blog postings on the concept of continuous delivery. This is an important process that can help SaaS companies improve their efficiency. The first installment explained the concept and listed reasons why companies need to pay attention to it. The second post listed the core practices of successful continuous delivery. This final posting in the series explains how to get the most out of the process by focusing on team culture.

As I explained in my two previous blog postings, continuous delivery is a combination of processes, tools and culture which, taken together, deliver incremental added value to customers by regular release of software improvements like features and bug fixes.

Up to now, I’ve focused more on the benefits of continuous delivery, as well as on tools and processes. Today, I want to focus on culture.

Corporate culture is about how a company works. Does it value competition over cooperation? Does it reward creativity among its employees, or does it push conformity? Does it accept or even encourage failure, or does it punish it?

Continuous delivery not only needs tools and processes to be successful, but also a culture that embraces the challenges inherent in the process.

We found that we needed to adapt our team culture in order to successfully adapt to continuous delivery. Here are three lessons we learned about how to create a corporate culture that can turbocharge the continuous delivery process:

1. Empower teams to take ownership of the process

Giving priority to fixing failures in builds and automated tests is often where teams can start to build a culture that embraces continuous integration and delivery.

However, you need to go beyond that and have the teams take ownership of the process, monitoring the health of releases and being ready to roll back changes or apply patches.

For example, we rotate the release management role in the team. Each scrum team takes a turn at owning the releases in each sprint. This has not only increased the awareness of the release process, but also improved the release process over time by allowing different people to come up with new ideas and deal with the pain points.

In addition, by dealing with the challenges of releases, software developers have come to truly embrace the idea that when they merge their code changes into the master branch, it has to be ready to be released. That’s because if it’s not, it’s going to cause a lot of issues for someone downstream in the process. They also think more about how the features and fixes need to be monitored after they are released.

2. Embrace monitoring and measuring

No SaaS company can successfully embrace continuous delivery without keeping a close watch on how things are going. As with other aspects of the agile development process, you have to monitor and measure your progress.

That means paying attention to metrics.

A few of the metrics you can use to measure the continuous delivery process are:

• cycle time for releases
• cycle time for release rollbacks and patches
• number of releases
• number of incidents
• number of introduced bugs
• number of test failures on master branch.

The following visualization shows how we track our number of releases and incidents. The next visualization shows the number of introduced bugs versus our target. These visualizations are two of the several metrics shown on our development team dashboard.

3. Embrace failure - but react to problems quickly

Make sure you build a culture in which failures are acceptable, but are dealt with immediately. In a culture in which people are not allowed to fail, they will not take risks. And if people don’t take risks, progress in all areas is not going to come quickly.

It’s a bad sign if your builds and tests never fail. It either means your continuous integration system is not doing anything useful for your team, or your team is not moving fast enough. They should fail occasionally, and that’s OK. In fact, these systems are in place to allow for failure and prevent issues downstream.

But if your continuous integration system remains in a state of failure long enough for the team to consider that to be an acceptable state for the system to be in, it becomes useless and people ignore it.

One final word about corporate culture:

For continuous delivery to work, the changes in corporate culture have to be embraced by the company as a whole, and not just the development team.

For instance, in a traditional culture, the first iteration of a project usually focuses on getting a proof of concept together.

In a continuous delivery culture, the first iteration should be dedicated to building the deployment pipeline skeleton, and then demonstrating that the deployment to test and the production environment work as expected by deploying the smallest possible user story to a production-like environment.

If this first step is done right, then the project is set for success and the future iterations can all be demonstrated to the stakeholders in a production or a production-like environment iteratively, incrementally and frequently.

Ali Pourshahid, PhD, is Director, Software Development, at Klipfolio. He can be reached at @ali_pourshahid