The first way to introduce DevOps is to optimise the value flow from development, through operations, all the way to the customer. This is the First Way in Gene Kim’s Three Ways framework — and it is where every transformation should start.
Continuous Deployment is the final, most aggressive step in the CI/CD progression. CI proves the code builds and the unit tests pass. Continuous Delivery proves the artifact works in a production-like environment. Continuous Deployment removes the last manual checkpoint: if every test along the way is green, the change goes straight to production. No “deploy” button, no Friday-afternoon release window, no human in the loop for the final step.
Continuous Integration ends with a tested artifact. That sounds great, but a green build does not mean the software actually works in a realistic environment. Unit tests run in isolation. Integration tests run against mocks. Until you put the software somewhere that looks like production and exercise it under real conditions, you have not really proven anything. Continuous Delivery is the step that closes that gap.
In traditional software development, software is merged and tested by all developers in one big single integration step that usually takes weeks or even months. Since this only happens every few months, this step is very time-consuming.
In traditional software development, integration was a single, painful event. Every developer worked in isolation for weeks or months, and at the end the team merged everything in one big bang. The integration step took weeks, sometimes months. Conflicts piled up, bugs hid in the seams between modules, and nobody could say with confidence whether the system actually worked. Continuous Integration was invented to make that pain disappear.
A value stream is the path that value takes from the first idea all the way into production. It is the sum of every step, handover, and wait in between. In this video, I walk through a simple seven-step approach for identifying a value stream, measuring how it really performs, designing a target state, and then improving it step by step. The numbers in the example are simplified on purpose, so the method shines through more clearly than any single result.
At first glance, a DevOps transformation seems to be a major undertaking for any company. But with the right approach, you can keep the process lean and agile.
Insight in brief # Start small with a small to medium sized project or product. Select the right people to ensure sufficient credibility and influence. Continuous improvement is key to success.
A DevOps transformation is not magic. Any company can do it. What makes the difference is who you put on the first team — because that team has to deliver the proof that DevOps actually works in your context.
The DevOps business case rarely fails because the technology does not work. It fails because nobody can explain, in money terms, why doing it faster matters. Here is the version that lands with a CFO: a dollar today is worth more than a dollar tomorrow, and a feature in production today earns money that a feature in next quarter’s release does not.
Everyone is talking about DevOps. What organisation doesn’t want to develop software more efficiently? So what exactly is the business case for DevOps?
Insight in brief # Value is only created when the product or feature reaches the customer side. Economic concept: “A dollar today is worth more than a dollar tomorrow.” Focus on rapid Value creation so that You can offer customers Value as quickly as possible.
If you ask a development team where value is created, you will hear a dozen different answers. In the planning workshop. In the sprint. At the demo. At deployment. They are all wrong — and getting this wrong is what makes most DevOps business cases fall apart on contact with the CFO.
Companies today are confronted with the challenge of enhancing efficiency while lowering costs. Changes to products often take much too long to reach end customers on the market. A consistent DevOps approach can aid this process.
