This article summarizes a talk by Dave Farley and Jez Humble at DeliveryConf, as reported by InfoQ. The original talk reflects the state of Continuous Delivery practice as of early 2020.
Three Pillars of Continuous Delivery Success
Ten years after the publication of Continuous Delivery by Dave Farley and Jez Humble, the two authors took the stage at DeliveryConf to reflect on progress made and lay out what they believe the next decade must look like for CD to mature across the industry. Their central argument: succeeding with CD is not a purely technical problem. It demands simultaneous progress across three deeply interrelated dimensions—technical performance, organizational performance, and cultural performance.
Research from DORA (DevOps Research and Assessment) supports this framing. Technical practices can lead the way, but they cannot drive lasting change on their own. Organizations that neglect the human and structural dimensions of delivery will hit a ceiling regardless of how sophisticated their tooling becomes.
What the Deployment Pipeline Actually Means
A common misreading of Farley and Humble’s original book is that teams should build a separate pipeline for each environment. Farley called this an anti-pattern. The deployment pipeline is meant to be a single mechanism: changes enter at one end, and releasable software emerges at the other. The goal is the continuous delivery of ideas—fast, validated feedback from real users telling you whether your assumptions were correct.
In the decade since the book was published, several practices have grown up around this core model, including distributed tracing, chaos engineering, and traffic shifting (canary releases and feature flags). These techniques all serve the same underlying purpose: reducing the risk and cost of change while accelerating the feedback loop.
“Teams need to have a great story on these technical practices to have great technical performance, which is a necessary driver for CD.”
— Dave Farley, DeliveryConf
Technical Performance: Engineering Discipline at the Core
Farley frames software development as fundamentally about two things: learning and managing complexity. Effective CD practices must optimize for both.
- Optimizing for learning: Use fast feedback loops, work incrementally, and run controlled experiments. The smaller the batch size, the quicker you learn whether a change delivers value.
- Managing complexity: Apply sound architectural principles—modularity, separation of concerns, high cohesion, and loose coupling. These properties make systems easier to change safely and independently.
“It’s about engineering—applying rational scientific thinking to solving practical problems within economic constraints.”
— Dave Farley, DeliveryConf
Organizational Performance: Structure Enables Autonomy
Even technically excellent teams will struggle to deliver continuously if the organizational structure works against them. Farley defines organizational performance as building team structures that enable genuine collaboration and sufficient autonomy. Teams that must constantly coordinate with other teams to ship a change are structurally constrained from practicing CD.
Farley referenced The Art of Action by Stephen Bungay as a useful model for understanding this challenge. Organizations pursue outcomes through plans and actions, but three gaps inevitably appear: a knowledge gap (not knowing enough to plan perfectly), an alignment gap (people acting on different interpretations), and an effects gap (actions not producing the expected outcomes). These gaps cannot be eliminated, but they can be reduced—through tighter feedback loops, smaller batches of work, and clearer intent communicated throughout the organization.
Cultural Performance: The Hardest Problem
Cultural performance—how teams behave, how diversity of thinking is valued, and how technical rigor is maintained day-to-day—is the dimension most frequently underestimated. Farley referenced a Harvard Business Review article arguing that the biggest impediment to adopting agile practices is not a lack of methodology, evidence, or proof of concept. It is executive behavior.
“Organizations can’t succeed at doing CD on one of these aspects without the others.”
— Dave Farley, DeliveryConf
The audience discussion at the end of the session surfaced practical strategies for influencing executive behavior:
- ROI and cost analysis: Quantifying the business value of CD—reduced lead time, lower failure rates, faster recovery—gives executives a concrete case to evaluate. This is often a necessary starting point.
- Reframe the conversation: Farley argued that you will not win senior leaders by talking about deployment pipelines. You win them by talking about the organization’s ability to evolve and respond to market change.
- Generate an emotional response: One audience member pointed out that ROI alone rarely changes culture. The classic observation applies here: culture eats strategy for lunch. Leaders need to feel the urgency of change, not just see a spreadsheet justifying it.
Humble’s Expectation: Real Continuous Integration First
Jez Humble stressed that one of his most important expectations for the next decade is straightforward but widely ignored: teams should actually practice Continuous Integration as it is defined. That means developers integrate their work into a shared mainline branch—or merge feature branches into the mainline—at least once per day. When the build breaks, it is fixed within approximately ten minutes. Reliable, automated tests validate every change.
Without this foundation, the rest of the CD pipeline is built on unstable ground. Long-lived feature branches, infrequent merges, and flaky test suites are among the most common reasons CD initiatives stall before they deliver value.
Feedback as the Engine of Innovation
Humble also emphasized that fast feedback is not just an operational concern—it is critical to innovation. Most new ideas turn out to be wrong. The faster an organization can find that out, the less waste it produces and the sooner it can pivot to something better.
In Accelerate, Humble, Nicole Forsgren, and Gene Kim describe the goal of modern product delivery this way:
“Product delivery is about building an engine that gives you quality feedback promptly, enabling a deterministic flow from development to production—this is the engine where product ideas bake in.”
— Accelerate, Forsgren, Humble, and Kim
Key Takeaways for Practitioners
- A deployment pipeline is a single end-to-end mechanism, not a separate pipeline per environment.
- Technical, organizational, and cultural performance are inseparable. Invest in all three or expect diminishing returns.
- Reduce knowledge, alignment, and effects gaps by working in smaller batches and communicating intent clearly.
- Architects and engineers should optimize for learning (fast feedback, incremental work) and for managing complexity (modularity, loose coupling).
- Genuine CI—daily integration into a shared mainline with fast automated tests—is a prerequisite for everything else.
- To influence executives, speak in terms of business agility and market responsiveness, not deployment frequency metrics alone.
Source: InfoQ coverage of DeliveryConf, featuring Dave Farley and Jez Humble.