I am a big fan of continuous delivery and deployment. You might have seen me write about it a few times before. When I first bring the idea up with clients, there is hesitation. One might even call it fear. The benefits are huge, allowing you to reap the return on investment immediately, but the big question is “how”. How does an organization switch to a continuous delivery model?

1. Embrace your fear

In most organizations, a lot of process has been built up over time in order to prevent bad things from happening instead of enabling good things to happen. Instead of facing our fears, we bottle them up and hide from them, leading to a culture of risk-aversion.

I am averse to risk as well, but sometimes I let myself face down those demons and do things that are less comfortable for me. Like deploying to a production environment every few weeks, no matter what.

If teams can band together and face this fear, they will find that processes will naturally adjust to make this new way of delivering software work for the team.

2. Find your comfort zone

Adjusting a schedule is one thing, but keeping the team from losing their minds is another. It may take automated regression testing, manual testing in a sandbox, daily builds, live monitoring tools, rollback procedures, feature toggling, etc. Each team will need to find what makes them comfortable with the process.

Your team probably doesn’t need to do every single thing that is considered to be “the right thing to do”. Code coverage with your unit tests is awesome, but there is a budgetary cost to achieving it. If those unit tests aren’t making you feel the warm and fuzzies needed to be confident in a deployment, then what value is the team receiving? Alternatively, it could be the team doesn’t feel manual testing is enough and the unit tests and automated regression tests are what really makes everybody sleep well at night.

Find what does it for your team. Then do it!

3. Adopt some form of agile backlog management

You can do continuous delivery in an old-school waterfall model, but it is going to hurt. Find a flavour of backlog prioritization and requirements definition that will give you the ability to define what you need as you need it and re-prioritize on the fly. If you can have it in production within a few weeks, why spend the months defining detailed requirements in advance for everything you might build?

To support a continuous delivery model, you probably need to look for an agile model that will let you do the following:

• Relative sizing between features to allow the team to plan delivery
• Ongoing prioritization to make sure the next thing delivered is the most important
• Continuous evolution of requirements to allow for portfolio management to gradually drill down to implementation details.

Implementing a process model with these features will allow the team to rapidly react to requests and deliver more often.

4. Measure and Learn

Once the team is able to deliver all the time, there needs to be a way to ensure that what is being delivered is working. Make sure that some form of monitoring is in place to ensure the goals of the organization are being met. Track what is working well and what is not working well for both the application and the process. Review the data regularly!

Regular review of this information will permit the team to learn and adjust what is being delivered. At this point, you have continuous improvement! Instead of investing heavily in months and months of work and not being sure it will pay off, you can begin your review immediately and adjust on the fly before completing all the work that was planned for a year.

Have you made the switch to a continuous delivery or deployment model? What challenges did you face in making the change?