Move to continuous delivery

 

But times have changed, and we need to deal with a new normal. Our customers demand working software, and they wanted it yesterday.

If we can't deliver, they go to a competitor. And competition is fierce. With the Internet, we always have global competition.

We have competitors on our stack that deliver a best-of-breed tool for one aspect of the software we built.

We need to deliver fast, and the product we make must be good. And we should do this with our software production being cheap and quality being high.

To achieve this, we need something like Continuous Delivery.

We need to move towards a situation where the value isn't piled up and released all at once but flows through a pipeline.

Just like in the picture, a piece of work is a marble. And only one part of the work can flow through the pipeline at once.

So, work must be prioritized in the right way. As you can see, the pipeline has green and red outlets.

These are the feedback loops or quality gates that we want to have in place. A feedback loop can be different things:

• A unit test to validate the code.
• An automated build to validate the sources.
• An automated test on a Test environment.
• Some monitor on a server.
• Usage instrumentation in the code.

If one of the feedback loops is red, the marble can't pass the outlet, and it will end up in the Monitor and Learn tray.

It's where the learning happens. The problem is analyzed and solved so that the next time a marble passes the outlet, it's green.

Every single piece of workflow through the pipeline until it ends up in the tray of value.

The more that is automated, the faster value flows through the pipeline.

Companies want to move toward Continuous Delivery.

• They see the value.
• They hear their customers.
• Companies wish to deliver their products as fast as possible.
• Quality should be higher.
• The move to production should be faster.
• Technical Debt should be lower.

A great way to improve your software development practices was the introduction of Agile and Scrum.

Last year around 80% of all companies claimed that they adopted Scrum as a software development practice.

Using Scrum, many teams can produce a working piece of software after a sprint of maybe two or three weeks.

But creating working software isn't the same as delivering working software.

The result is that all "done" increments are waiting to be delivered in the next release, which is coming in a few months.

We see now that Agile teams within a non-agile company are stuck in a delivery funnel.

The bottleneck is no longer the production of working software, but the problem has become the delivery of working software.

The finished product is waiting to be delivered to the customers to get business value, but it doesn't happen.

Continuous Delivery needs to solve this problem.