This article is based on a piece originally published on opensource.com. Attribution is preserved; some sections have been expanded for clarity.
Understanding DevOps Beyond the Buzzword
Many engineers first encounter DevOps when they observe one of its outcomes—a deployment pipeline that ships to production dozens of times a day, or an environment that shrugs off infrastructure failures—and then ask: how did they do that? It is entirely possible to implement DevOps practices without understanding their theoretical roots, but knowing why those practices work is the difference between leading a transformation and copying one.
Impressive anecdotes—production systems that absorb chaos-engineering failures while sustaining thousands of releases per day—are real, but they make a weak standalone business case. On their own, they amount to proving a negative: the system appears resilient because a catastrophic failure has not occurred yet. A stronger argument for DevOps requires tracing its intellectual lineage.
The Agile vs. DevOps Confusion
A perennial debate in the industry concerns the relationship between Agile and DevOps. Common positions include:
- DevOps is a subset of Agile
- Agile is a subset of DevOps
- DevOps is an extension of Agile—it starts where Agile ends
- DevOps is simply the new version of Agile
None of these framings is entirely wrong, and none is entirely right. To resolve the confusion it helps to go back further—to the manufacturing principles that gave rise to both.
DevOps Roots in Lean Manufacturing
DevOps makes far more sense when viewed through the lens of lean manufacturing, which itself descends from Henry Ford’s production innovations and the Toyota Production System’s refinements of them. In their book Lean Thinking, James P. Womack and Daniel T. Jones distil lean into five principles:
- Specify the value desired by the customer.
- Identify the value stream for each product and eliminate wasteful steps.
- Make the product flow continuously through value-added steps.
- Introduce pull between steps wherever continuous flow is possible.
- Manage toward perfection—continuously reduce the steps, time, and information needed to serve the customer.
The core lean concept relevant here is single-piece flow: moving one item at a time through a process is orders of magnitude faster than batching many items together. The “Penny Game” is a well-known exercise that demonstrates this. If a batch of 20 pennies takes two minutes to reach the customer, the customer waits the full two minutes before receiving anything. If each penny moves individually, the first penny reaches the customer in roughly five seconds, and all 20 arrive within about 25 seconds—a dramatic reduction in time-to-value.
Where Agile Fits In
Not everything in software development is as predictable as a penny sliding across a table. Software tasks carry high variance and frequent surprises. This is where agile methodology picks up where lean alone falls short.
Agile focuses on awareness, deliberation, decision, and action in the face of a constantly changing reality. Frameworks like Scrum increase awareness through ceremonies such as the daily standup and the sprint review. When a team discovers new information, the framework permits—even encourages—course correction. For this to work well, teams must be self-organizing within a high-trust environment. High-performing agile teams achieve a fast flow of value while continuously adapting, eliminating the waste of moving confidently in the wrong direction.
The Economics of Batch Size
To understand the compounding power of DevOps, it helps to understand the economics of batch size, a concept explored in depth in Donald Reinertsen’s Principles of Product Development Flow. Reinertsen illustrates this with a U-curve optimization: total cost equals transaction cost plus holding cost, and the optimal batch size sits at the bottom of the U.
A grocery-shopping analogy makes this concrete. If you live 30 minutes from a store and need eggs, the 30-minute round trip is your transaction cost. Eggs spoiling in the refrigerator represents your holding cost. For most people, a dozen eggs is the optimal batch. But if you lived next door to the store, your transaction cost would be nearly zero, and you would buy smaller quantities more often—enjoying fresher eggs and using less refrigerator space.
Apply this to organizational decision-making. In traditional hierarchical organizations, decision authority is centralized, which means decisions are large, infrequent, and made by few people. Agile decentralizes decision-making to the teams with the best awareness and information, effectively reducing the transaction cost of each decision. Lower transaction cost shifts the optimal batch size to the left on the U-curve—smaller, more frequent decisions become economically rational. The business value of faster, more frequent decisions is difficult to overstate.
Where DevOps Fits In
DevOps is most visibly associated with automation. Returning to the U-curve model: through automation, transaction costs for testing and deployment approach zero, making those activities effectively free per unit. This shifts the optimal batch size further left still—smaller and smaller increments of work become viable. Smaller batches are:
- Easier to understand and reason about
- Faster to test and review
- Clearer in terms of “done” criteria
- Lower in variance and deployment risk
- Faster to troubleshoot and roll back if something goes wrong
Combined with strong agile practices, automation enables feature development to approach true single-piece flow—delivering value to customers continuously rather than in large, risky releases.
DevOps is also commonly described as breaking down the wall between development and operations teams. Development teams create new features; operations teams keep systems stable. Friction arises because new features introduce change, which increases the risk of outages that operations must handle. DevOps is not simply about getting people to collaborate—it is about making frequent changes safely in inherently complex environments.
Organizational Culture and Safety: Westrum’s Research
Researcher Ron Westrum studied why some organizations are safer than others—primarily in aviation and healthcare—and found that culture is predictive of safety outcomes. He identified three cultural archetypes:
| Culture Type | Information Handling | Safety Outcome |
|---|---|---|
| Pathological | Information is hidden or suppressed | Lower safety |
| Bureaucratic | Information processed through rules | Moderate safety |
| Generative | Information actively sought and shared | Higher safety |
High-performing DevOps teams cultivate a Generative culture through lean and agile practices. Westrum’s framework demonstrates that speed and safety are not trade-offs—they are complementary properties, two sides of the same coin. When batch sizes for both decisions and deployments become very small, information flows faster, waste decreases, and risk is reduced simultaneously.
When teams are trusted to make their own decisions, the tools and techniques most associated with DevOps—automation, continuous integration, continuous delivery—emerge naturally. Transaction costs fall further, and near-single-piece flow becomes achievable, creating the conditions under which high-performing organizations deploy thousands of times per day.
Flow, Feedback, and Continuous Learning
DevOps does not stop at optimizing flow. The DevOps Handbook (Gene Kim, Jez Humble, Patrick Debois, and John Willis) describes a second dimension: fast feedback loops. This means building telemetry across the entire value stream so that problems surface quickly and teams can respond before small issues compound into outages.
A third dimension is continuous learning and experimentation. Borrowing the kaizen bursts of lean manufacturing and the retrospectives of Scrum, high-performing DevOps teams institutionalize improvement at every level of the organization. The goal is not to achieve a static “DevOps state” but to build a self-improving system that gets better over time—a software equivalent of the lean manufacturing revolution that transformed physical production industries in the twentieth century.
How to Start: The DevOps Assessment
For teams beginning a DevOps transformation, a structured assessment is a practical first step. The assessment should evaluate a consistent set of dimensions known to differentiate high-performing DevOps teams from average ones—covering areas such as deployment frequency, lead time for changes, mean time to restore, change failure rate, team autonomy, and cultural indicators aligned with Westrum’s model.
The assessment process typically follows these steps:
- Baseline the current state across all relevant dimensions.
- Identify weak or absent team norms that limit performance.
- Prioritize quick wins—focus areas with high probability of success and high potential impact. Early wins build momentum and organizational trust in the transformation.
- Experiment rapidly—generate ideas, implement them at small scale, and measure the result.
- Reassess periodically on the same dimensions to track improvement and identify the next high-impact focus area.
- Build internal ownership—a coach’s goal is to make themselves unnecessary by embedding continuous improvement into the team’s own practices.
A good DevOps coach consults, trains, mentors, and supports until the team owns its own improvement cycle—reassessing, experimenting, and learning independently.
Summary: Why DevOps Matters
DevOps is not a product to purchase or a job title to assign. It is a strategy that synthesizes lean manufacturing’s flow principles, agile methodology’s adaptive decision-making, and Westrum’s generative culture research into a coherent operating model for software organizations. The result is an organization capable of delivering value to customers faster, safer, and more reliably than one relying on traditional development and operations silos.
Understanding why DevOps works—not just what its practitioners do—equips engineers and leaders to adapt the strategy intelligently to their own contexts, rather than copying practices without understanding the principles behind them.