This article is based on an interview originally published on jaxenter.com with Jan Schilt, co-owner of GamingWorks and speaker at the Microservices Summit, discussing the Phoenix Project simulation and common DevOps adoption challenges.
Why DevOps Adoption Stalls
Many organizations recognize the value of DevOps in principle but struggle to translate that recognition into lasting change. Some teams never get started because they lack a clear definition of what DevOps actually requires — from their tools, their processes, and their people. Others launch a DevOps initiative only to watch it slow down under the weight of organizational friction, unclear goals, and cultural resistance.
According to Jan Schilt of GamingWorks, most of these struggles can be traced back to four concrete obstacles. Understanding what they are — and having a practical strategy to address each one — is the first step toward a successful DevOps journey.
The Phoenix Project: A Foundation for the Conversation
Before diving into the obstacles, it helps to understand the mental model that Schilt and many DevOps practitioners use as a reference point: Gene Kim’s novel The Phoenix Project.
The book follows Bill, an IT manager tasked with rescuing a critically over-budget and delayed IT initiative. Bill’s breakthrough comes when he applies manufacturing flow principles to IT work. His approach unfolds in three stages:
- Flow: Visualize all work in progress. Make the pipeline visible so the team can see where work is moving and where it is stuck.
- Feedback loops: Bring teams together across silos. Encourage quality to be addressed at its source rather than passed downstream. Each step in the flow should deliver value and return feedback to the previous step.
- Continuous learning and experimentation: Build a culture where teams constantly improve based on what they observe, rather than following fixed procedures in a changing environment.
These three principles — flow, feedback, and continuous learning — map directly onto the obstacles that real organizations face when adopting DevOps.
The 4 Main Obstacles to DevOps Adoption
1. Genuine Cross-Functional Teamwork
DevOps requires assembling a team from multiple disciplines — development, operations, QA, security, and often the business side — all working together toward a single value stream. This is harder than it sounds.
Most organizations have deep-rooted functional silos. People are hired, evaluated, and rewarded within their discipline. Asking them to share ownership of a delivery pipeline with colleagues from other departments demands new skills: communication styles, shared vocabulary, mutual accountability, and a willingness to own problems outside one’s traditional remit.
Without genuine teamwork, DevOps squads become multi-department committees rather than integrated delivery units — and the friction between silos continues to slow delivery.
2. Building Real Flow in the Delivery Process
Understanding that work should flow is not the same as actually creating flow. Teams must map their value stream, identify bottlenecks, limit work in progress (WIP), and back all of this with strong visualization — typically a Kanban board or an equivalent tool that the whole team actively uses and trusts.
Without visible, managed flow, teams default to reactive, interrupt-driven work. Priorities shift constantly, context switching erodes productivity, and nobody has a clear view of what is blocking value from reaching the customer.
Practical flow work includes: holding daily standups focused on blockers, running regular retrospectives, and enforcing WIP limits even when stakeholders push back.
3. Embracing Continuous Experimentation and Learning
DevOps is not a destination with a fixed set of procedures to follow. It is an ongoing improvement journey in which teams continuously test hypotheses, measure outcomes, and adapt. This is profoundly uncomfortable for people and organizations that rely on documented processes and defined work instructions for predictability and audit compliance.
Teams that cannot tolerate uncertainty will resist the feedback-driven iteration that DevOps depends on. They will wait for perfect requirements, avoid deploying until every edge case is handled, and treat every failed experiment as an indictment rather than a data point.
Building psychological safety — the understanding that well-designed experiments that fail are valuable — is essential infrastructure for DevOps, just as much as a CI/CD pipeline is.
4. Applying Agile, Lean, and ITSM Principles in Practice
Most DevOps practitioners are familiar with Agile, Lean, and IT Service Management (ITSM) concepts in the abstract. The gap between knowing and doing is wide. Teams may understand Kanban theory but struggle to enforce WIP limits under pressure. They may know what a retrospective is supposed to achieve but run them as status meetings instead.
Translating management principles into consistent daily practice requires deliberate repetition, coaching, and experimentation in real conditions — not just classroom knowledge.
How to Overcome These Obstacles
Invest in Foundational DevOps Training
Start by ensuring the team shares a common language and baseline understanding. Foundational programs such as DevOps Foundation or DevOps Fundamentals courses establish that common ground. For teams ready to go deeper, more advanced programs cover how DevOps principles interact with organizational structure, service management, and measurement strategy. Pair any training with hands-on exercises — theory retained without practice decays quickly.
Choose a Low-Risk Value Stream to Start
Resist the urge to transform every team and every pipeline at once. Instead, identify a single value stream — a specific process, service, or customer-facing product — that carries lower risk and has a team of willing early adopters. A contained experiment with a motivated team produces tangible results and generates internal advocates who can coach other teams later.
Build Time for Learning into the Plan
No team gets DevOps right immediately. Schedules that leave no room for errors, retrospectives, or course corrections guarantee frustration. Plan deliberately for learning cycles. After each sprint or deployment window, run a retrospective: what worked, what did not, what will the team try differently next time?
Use Simulations to Accelerate Practical Understanding
One reason organizations like GamingWorks have developed DevOps simulations — such as one built around The Phoenix Project — is that real-world learning is slow and costly. A simulation compresses the DevOps learning curve into a controlled environment where teams can experience a realistic workload, build and manage a Kanban board, practice standups and retrospectives, apply automated testing scenarios, and feel the consequences of high WIP and poor flow — all without risking a production system.
Participants come away with experiential knowledge of what DevOps actually feels like in practice, not just what it looks like in a slide deck. That experiential grounding helps teams connect the principles to their own organizational context before they begin their live implementation.
Let Early Adopters Coach the Next Wave
Once the first value stream is working well, the team that went through it becomes your most credible internal resource. Engineers and operators who have solved real DevOps problems in your specific environment are far more persuasive coaches than external consultants. Structure a deliberate knowledge transfer program so that early adopters help onboard subsequent teams, reinforcing their own learning in the process.
Summary
| Obstacle | Root Cause | Primary Remedy |
|---|---|---|
| Cross-functional teamwork | Deep organizational silos, misaligned incentives | Intentional team formation, shared goals and ownership |
| Creating real flow | Invisible work, unlimited WIP, reactive culture | Kanban boards, WIP limits, daily standups focused on blockers |
| Continuous experimentation | Risk aversion, need for fixed procedures | Psychological safety, blameless retrospectives, small experiments |
| Applying Agile/Lean/ITSM in practice | Gap between conceptual knowledge and daily habits | Coaching, simulations, deliberate practice with real feedback |
DevOps adoption is not primarily a technology problem. It is a people, process, and culture problem. Addressing it requires honest diagnosis of which obstacles are most acute in your organization, a focused starting point, and the discipline to build learning into the process from day one.