Waterfall and Agile are not just two flavours of project management. They are two fundamentally different ways of dealing with uncertainty. If you understand that, the rest follows.
Waterfall: Linear and Sequential # Waterfall is a linear sequential life cycle model. The team only moves to the next phase if the previous one finished successfully. Requirements first, then design, then implementation, then testing, then deployment, then operation. Each phase has a hand-off and a sign-off. Each phase produces a document that the next phase consumes.
The third way to introduce DevOps is to create a culture of trust that supports experimentation and risk-taking. This is the Third Way in Gene Kim’s Three Ways framework — and it is what puts the team on a learning curve steep enough to outpace the competition.
The second way to introduce DevOps is to build a strong flow of feedback going in the opposite direction of the value flow — from customers and production back into the business and into development. This is the Second Way in Gene Kim’s Three Ways framework, and it is what stops the First Way from optimising in the dark.
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.
