In this conference talk, I discuss one of the most fundamental topics in DevOps: thinking in systems and value streams. When I work with companies on their DevOps transformations, I consistently see the same patterns. The business has bright ideas. They write them into Word documents and Jira tickets. They throw them over a wall of confusion to development. Development builds something and throws it to testing. Testing compares what was specified with what was built (never quite the same), tests something, and throws it to operations. Operations asks “How can we operate that?” and somehow, with great effort, they get it running. Then the customer sees it and says: “What is that? That is not what we ordered.”
From Projects to Products#
The root of the problem is often found in how organizations think about work. In the past, we all did waterfall: scope was fixed, budget was fixed, time was fixed. Then we moved to agile and started working incrementally. But in many organizations, we are still working in projects, just incrementally. What we should be doing is working in products, because that is what our customers actually want.
The difference is fundamental. Projects focus on output: maximizing the number of features, user stories, tasks, or lines of code delivered. Products focus on outcome: understanding the customer need, solving the real problem, changing behavior, and delivering value. One approach counts what you ship. The other measures whether it made a difference.
DevOps helps us make this shift. DevOps is a mindset, a culture, and a set of technical practices that provides communication, integration, automation, and close collaboration across the entire value stream.
DevOps is for Everyone#
The term “DevOps” is completely misleading. People think it is about Development and Operations. Some try to fix it by saying “DevSecOps” (adding Security) or “BizDevOps” (adding Business). But all of these exclude someone. What we really need is something like “DevSecBizArcCompQAOps.” Or we can just call it DevOps, because DevOps is about bringing all people, all processes, and all technology together to continuously deliver value. That is what DevOps is.
Why does this matter? In the year 2000, small companies with funny names like Netflix and Google started experimenting with agile and DevOps. Today they dominate the market. We are seeing the same happening in hardware. Tesla is experimenting with DevOps and agile ways of working, and the impact is massive.
Consider this real example from Elon Musk: in October 2021, he released an Autopilot update to 1,000 car owners with a perfect safety score. That is a canary release for cars. Eight days later, after positive results, he expanded to a larger group. Then a problem was found, and he did a rollback. These are cars driving on roads, and he is doing a software rollback. Many companies cannot do that with normal software. Not even 24 hours later, the fix was deployed. This is what DevOps in action looks like.
Value Stream Mapping#
Before you can improve your system, you need to see the whole system. Value stream mapping is a straightforward and powerful technique. You bring all the people working in a value stream into a room, give them Post-its, and ask: what steps are needed from idea to production?
For each step, you identify who is responsible and measure three things:
- Lead Time: The total time from the end of one process step to the end of the next, including all waiting.
- Process Time: The actual value-adding work time within a step.
- Percentage Complete and Accurate (%C&A): How often the output of one step can be used by the next step without any rework.
The results are often eye-opening. For example, a testing step might have 8 hours of actual work but 336 hours of lead time, revealing massive waiting time. When the code step shows only 60% C&A, that means in 40% of cases, work needs to go back. These bottlenecks become visible, and teams can work systematically to remove them.
The Continuous Delivery Pipeline#
This value stream is nothing else than a continuous delivery pipeline. To understand it, we need to be clear on the terminology:
Continuous Integration (CI): Developers write code on their machines and commit to a source code repository. The CI server builds the code, runs static analysis, security checks, and unit tests. Feedback must reach the developer in minutes, not hours or days. The output is a deployable artifact.
Continuous Delivery (CD): The deployable artifact is automatically installed in a staging environment (a production-like environment), where further tests are executed. Feedback is again given to the developer.
Continuous Deployment: Everything from CI and CD happens automatically, and if all tests pass, the artifact is deployed to production automatically. Most companies do CI and CD. Very few do continuous deployment. That is perfectly fine.
Shift Left: Building Quality In#
In the traditional V-model, tests were written and executed with delayed feedback cycles of three to six months. In agile, we shift left. We use Behavior Driven Development (BDD) to write acceptance criteria in Given-When-Then format, creating executable specifications. We use Test Driven Development (TDD) as a test-first approach. By having specifications in testable format from the start, we write tests before code and catch problems immediately.
The testing pyramid also changes. The traditional approach tried to find all bugs with many end-to-end tests (often manual), some integration tests, and few unit tests. The agile approach is about preventing bugs: many fast unit tests, some integration tests, and only a few end-to-end tests. It is a fundamental shift from finding bugs to preventing them.
Architect for Operability#
Something I see too often: teams build things without thinking about how they will work in production. You build it, you run it, and when it breaks, you fix it as a team. For that, you need monitoring with tolerance thresholds and alerting, a clear notification strategy, and practiced disaster recovery procedures. Not a Word document that is outdated when disaster strikes. Actual practiced procedures.
Cross-team collaboration is essential. Everyone is responsible for a great product. And incident post-mortems are invaluable for continuous improvement. Infrastructure as code, full-stack telemetry (including infrastructure, not just application), feature usage metrics to support business decisions: all of these are needed.
“The biggest obstacle in DevOps transformations? The middle management. They do not want the transformation because it breaks down their silos and they lose some of their power.”
Key Takeaways#
- Move from projects to products. Focus on outcomes (customer problems solved) rather than outputs (features shipped).
- Apply whole-system thinking. Everyone in the value stream needs a clear view of the entire flow, not just their piece.
- Map your value stream. Identify all steps from idea to production, measure lead time, process time, and quality, and systematically remove bottlenecks.
- Automate your continuous delivery pipeline. CI/CD is the automation of your value stream. Build quality in from the start with BDD and TDD.
- Architect for operability. Think about production from day one. Build in telemetry, practice disaster recovery, and use post-mortems to continuously improve.
- DevOps is for everyone. It is not about Dev and Ops. It is about bringing all people, processes, and technology together to continuously deliver value.