Continuous Delivery - An overview of our consulting framework

November 22, 2016

Change is painful! However you try, the effects of change only make it tougher before it gets easier/simpler. 

Implementing Continuous Delivery in any organisation is no different.

Continuous Delivery is building a pipeline for software delivery in a way that the production deployments are prioritised according to business needs. It changes the way the team works. The goal is to move IT deployments from being a voodoo thing to a reliable and fast way to solve customers' problems.

Because of the obvious business benefits it brings, CXOs want to move to this way of working.

But - yes, but here as well. The typical question follows, "I understand, but how do I get started?".

Automation is the right and common step for most organisations. The problem with automation without analysing the actual constraint(s) makes it longer to see impacts that most companies have the patience.

Our Framework

Here is our framework you could apply to implement Continuous Delivery in your team.

The framework, extracted from the book Toyota Kata, focusses on problems, solutions and feedback.

Phase 1: Plan

Stage 1: Understand

The first step for any improvement is to understand the current situation.

Observing software delivery, analysing business rationale and asking questions help to understand the current state of IT delivery better.

Asking questions to understand the initiatives the team had tried in the past, understanding what worked and what didn't will help build a good picture of software delivery process and business needs/constraints.

It is recommended not to jump to a solution at this stage.  

Risks

• Trust -  difficult to get the trust of people to share their challenges and opinions
• Interruptions - doing it without disrupting the day-to-day operations of the team

Stage 2: Define

This stage involves defining the current state, the ideal state and identifying the next step for improvement. 

An effective way is to draw the entire value stream, highlight the constraints and prioritise the most immediate constraint to be tackled.

Risks

• Local maxima -  possible to get stuck with the immediate problem you see without getting a 360° overview. Drawing the entire value stream should help to avoid this problem.
• Trust - This continues to be a risk for people to bring up their concerns and opinions

Phase 2: Do

Stage 1: Deliver

Define potential solutions for the problem that is previously identified. This is where it gets complicated.

As tackling each constraint is a big hairy project, you will need an Understand, Define, Do and Improve stage for every constraint you have identified.  

You can think of it as one Deming Cycle inside another Deming Cycle.

Risks

• Local maxima -  still a risk at this stage
• Interruptions - Bringing in the improvements without disrupting the day-to-day operations of the team

PHASE 3: CHECK + ACT

Stage 4: Improve

This stage is to analyse results from the experiments, measuring what improved and what needs to be changed.

Apply the changes to improve the next Understand->Define->Do->Improve cycle.

Risks

• Wrong Analysis or Measurements - The right analysis of the results is the key over here. Defining early what needs to be measured should solve this problem.
• Safety - People may not speak up: An environment that fosters safety to share feedback should improve

If you've read this far, only makes sense for you to try this out in your organisation.

We'd love to hear your experiences. Please add them as comments.