The DevOps Evolution Model

Purpose

The DevOps Evolution Model illustrates how organizations progressively reduce lead times and feedback cycles by moving previously “undone” work into the Definition of Done (DoD). It helps teams visualize their current development and delivery flow, understand where learning occurs too late, and identify the steps required to shift work upstream. The model is a key tool in Value Stream Identification and Value Stream Optimization, providing a shared language for assessing maturity, identifying improvement opportunities, and aligning on a realistic and valuable target state. It embodies the principle of Shift Left and guides organizations in their journey toward continuous learning, continuous integration, and ultimately continuous delivery.

How to Use the Model

The DevOps Evolution Model describes four maturity stages that reflect how much undone work remains outside the Definition of Done. Progressing through these stages shortens feedback loops, reduces batch sizes, and lowers the cost of change. As maturity increases, defects are caught earlier, integration becomes more frequent, and predictability improves. The shift from late learning to continuous learning enables organizations to improve flow efficiency, reduce rework, and accelerate their ability to deliver value. Each stage of the model highlights the current characteristics of the delivery system, the impact that level of maturity has on flow and quality, and the next set of improvements needed to evolve toward continuous delivery.

Model 1 – Undone Work Outside the Definition of Done

Characteristics
Teams work in iterations, but a substantial portion of finalization work still occurs outside the Definition of Done. This “undone work” typically includes postponed defect fixes, manual testing, documentation, security and compliance checks, and validation of non-functional requirements such as performance or reliability. Because these activities are carried out only after features are declared “complete1 ,” learning happens late in the process, and essential quality and readiness work remains invisible during development.

Learning happens late because validation is postponed until after development.

Impact
Feedback loops are long, and critical issues are often discovered late in the development process. As a result, integration becomes complex and unpredictable, and release readiness can vary widely. Large hidden queues of unmeasured work tend to accumulate at the end of each release cycle, causing delivery delays and reducing transparency. Because learning occurs so late, the cost of change increases significantly, lead times grow, and teams have low confidence in their ability to deliver reliably.

Goal for Next Stage
The next step is to identify, categorize, and make the hidden undone work visible. This enables teams to begin shifting selected activities into the Definition of Done, bringing validation, testing, and quality assurance closer to development where issues are cheaper and faster to address.

Model 2 – Shift-Left: Moving Undone Work into the DoD

Characteristics
Teams begin to incorporate previously postponed activities into their Definition of Done, moving testing, documentation, and compliance work earlier into the iteration. Automation begins to replace manual steps, and collaboration increases as developers, testers, and operations share responsibility for quality and readiness. By integrating more learning and validation activities upstream, teams gradually reduce the scope and unpredictability of work left until the end of development.

Impact
As more previously postponed activities move into the DoD, feedback cycles become shorter, and defects are found earlier when they are cheaper to fix. Rework effort decreases, and the release process becomes more predictable. Hidden queues begin to shrink because teams address issues closer to the moment they are created. However, some undone work often remains outside the iteration, particularly system-level validation, integration with external components, or domain-specific checks that cannot yet occur earlier in the flow.

Goal for Next Stage

The aim now is to further reduce undone work by expanding automation and integrating testing, build, and deployment processes. Teams work toward producing a potentially releasable increment each iteration, with a Definition of Done that reflects a broader and more complete view of readiness.

Model 3 – Integrated Iteration: Minimal Undone Work

Characteristics
At this stage, undone work has been reduced to a small set of activities that fit within each iteration. Automated tests, continuous integration, and stable environments support near-continuous validation. The iteration Definition of Done and the release Definition of Done are closely aligned, and system demos provide an accurate representation of production readiness. Teams can integrate across components regularly and deliver at the end of every iteration with minimal effort.

Impact
Lead time decreases significantly, and feedback becomes fast and reliable as validation is performed continuously throughout the iteration. Flow efficiency increases because most integration and testing activities are automated and embedded into the normal workflow. Integration issues, when they occur, are smaller in scope and easier to resolve. Delivery becomes predictable, and teams can confidently demonstrate production-ready increments at the end of every iteration, with only a few specialized activities still occurring outside the iteration.

Goal for Next Stage
The goal is to eliminate the remaining undone work and fully align the iteration and release Definitions of Done. Achieving this alignment enables continuous delivery and ensures that every completed work item is ready for deployment.

Model 4 – Continuous Delivery: No Undone Work

Characteristics
All activities required for release are now fully integrated into the Definition of Done. Build, test, security, and deployment processes are automated and seamlessly embedded into the development workflow. Every feature, story, or code change can be deployed independently through continuous delivery pipelines. The boundary between development and release disappears—the work is considered done as soon as it is deployable.

Impact
The value stream achieves fast, reliable, and continuous flow, as all activities required for release are fully integrated into the development process. Lead time is minimized and quality remains consistently high, with defects rarely escaping into later stages. Because every change is deployable independently and safely, teams can release on demand with a high degree of confidence. The organization gains exceptional responsiveness, allowing it to react quickly to customer needs, emerging opportunities, or market changes.

Goal for Continuous Improvement
The focus shifts to sustaining automation, technical excellence, and architectural clarity while continually refining feedback loops and flow performance. Continuous improvement efforts concentrate on maintaining resilience, reducing variability, and ensuring that teams can deliver safely and reliably on demand.

The main reasons organizations remain in Stage 1 often stem from their waterfall-based origins, characterized by large batch sizes, rigid handoffs, and high transaction costs. Progressing to more advanced stages requires the adoption of DevOps practices- particularly a high degree of automation and a mature development process that builds quality in from the start rather than attempting to test it in later. The Value Stream Optimization article is discussing how this improvements can be implemented,

Choosing the Right Target Stage

Selecting the appropriate maturity stage is ultimately a business decision that must balance market needs, delivery expectations, and acceptable levels of risk with the organization’s technical and operational realities. Factors such as team capacity, automation readiness, architectural constraints, regulatory requirements, and the cost–benefit economics of shifting work upstream all influence what is feasible and valuable. This balance is especially important in cyber-physical systems, where hardware availability, long integration cycles, and specialized testing environments impose natural limits on how far and how quickly learning can be moved earlier in the flow. The right target stage is therefore the one that maximizes value flow while remaining both achievable and economically sound.

Why Organizations Remain in Stage 1

Many organizations remain in Stage 1 because their structures, processes, and systems originated in traditional waterfall environments where large batch sizes, sequential handoffs, and manual validation are the norm. Legacy architectures, siloed teams, inconsistent environments, and limited automation make it difficult to shift work upstream without substantial investment. Cultural factors, such as limited ownership of quality or fear of change, can further slow improvement. Without clear visibility into undone work and its impact on lead time, quality, and predictability, organizations often continue operating in a mode where learning occurs too late and integration remains painful. Progressing beyond this stage requires investment in engineering excellence, automation, Lean-Agile practices, and a commitment to building quality into the process rather than attempting to inspect it in later.

Conclusion

The DevOps Evolution Model helps organizations understand how undone work affects flow, quality, cost, and predictability. By making these dynamics visible, teams can choose realistic improvement targets and sequence investments in automation, architecture, and capability development. When used in conjunction with the Assembly Line Model and value stream optimization practices, the DevOps Evolution Model becomes a powerful guide for building fast, reliable, and sustainable value streams.

References

  1. These tasks are performed often only after a so called something like „feature complete“ milestone. ↩︎

Author: Peter Vollmer – Last Updated on November 19, 2025 by Peter Vollmer