Move to continuous delivery
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.
Our competitors on our stack deliver a best-of-breed tool for one aspect of the software we built.
We need to deliver fast, and our product must be good. And we should do this with our cheap software production and high quality.
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.
We want to have these feedback loops or quality gates 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 will end up in the Monitor and Learn tray.
It's where the learning happens. The problem is analyzed and solved so it's green the next time a marble passes the outlet.
Every workflow goes through the pipeline until it ends in the value tray.
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.
The introduction of Agile and Scrum was a great way to improve your software development practices.
Last year around 80% of 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.