Implementing the Flow Principle: Continuous Delivery and Value‑Stream Optimization in DevOps

The translation of the DevOps Handbook is now complete, and the author shares the core content of the first of three articles that introduce the three‑step DevOps workflow described in the book.

The Flow Principle aims to create a smooth value stream from development to operations, reducing the risk of changes in production by adopting continuous delivery practices.

Key technical practices include building a stable automated deployment pipeline, running automated tests to keep code always deployable, committing to the main branch daily, and designing architectures that enable low‑risk releases.

The article lists essential practices: laying the foundation for the deployment pipeline, implementing fast and reliable automated testing, practicing continuous integration and testing, and achieving low‑risk releases through automation and architectural decoupling.

By integrating QA and operations tasks into the DevOps team’s daily work, organizations can reduce firefighting, improve quality, and increase competitiveness.

For detailed technical practices, refer to the third part of the DevOps Handbook (chapters 10‑13), which describes five technical practices.

Stop starting. Start finishing. – David J. Anderson.

Local goals such as feature completion rate, defect detection/fix ratio, and operational availability are highlighted, emphasizing the need to reduce hand‑offs in the value stream.

Value‑stream metrics to track include total lead time, total value‑adding time, and the percentage of work completed accurately.

For greenfield projects, metrics are collected daily from CI/CD tools and displayed on dashboards for the whole team.

Goldratt’s five‑step method for addressing constraints in the value stream is presented: identify the system constraint, decide how to exploit it, consider the whole system, elevate the constraint, and repeat.

Typical constraints in traditional teams are listed: environment setup, code deployment, test preparation and execution, tightly coupled architecture, etc.

The article then discusses waste elimination, naming common wastes such as half‑finished work, extra steps, unnecessary features, task switching, waiting, defects, manual operations, and “hole‑filling” activities.

Finally, it connects the three‑step DevOps workflow from "The Phoenix Project": the first step focuses on a left‑to‑right flow with small batch sizes; the second step creates a rapid feedback loop from right to left; the third step builds a culture of experimentation, risk‑taking, and continuous improvement.

References: Gene Kim, Kevin Behr, and George Spafford, “The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win.”