Agile and Operations: When Two Necessary Goals Collide
- Bill Holmes
- 2 minutes ago
- 3 min read
“A system must be managed. It will not manage itself.” W. Edwards Deming
“The performance of a system depends more on how its parts interact than on how they perform taken separately.” Russell Ackoff
When Agile first began to gain traction, it felt different.
Project managers and CTOs could see the value quickly. Short feedback cycles produced usable results sooner. Teams that were trusted to make local decisions moved faster and surfaced problems earlier, when they were still inexpensive to correct. Compared to long, sequential delivery models, the contrast was hard to miss.
But in most large organizations, Agile did not arrive as a fully understood operating model. It arrived cautiously, almost as a controlled experiment. A few teams were allowed to try it. A pilot project here, a contained effort there. And for those teams, it often worked remarkably well.
The rest of the organization, however, did not change overnight.
There was a deeper challenge that many organizations underestimated. One of the central promises of Agile is not just developing software quickly, but moving it into production quickly, learning from real users, and enhancing it in that same environment. The feedback loop depends on that cycle continuing without long delays.
In large enterprises, operations had a very different mandate. Their responsibility was to keep critical systems running, often supporting millions of users or essential business functions. Stability was not simply a preference; it was the job. Changes to production were approached cautiously, release windows were tightly controlled, and the safest system was often the one that was left alone.
That mindset was not wrong. It was rational, and in many cases necessary. But it stood in direct tension with the continuous integration, continuous delivery, and shared ownership that a true DevOps environment requires.
Development teams were being encouraged to move faster, while operational processes were designed to slow change down. Agile teams could accelerate within their boundaries, yet the path to production often remained the longest and most uncertain part of the journey.
This was not a failure of Agile, and it was not resistance for its own sake. It was a structural reality. Teams could move quickly, but the systems they depended on still required coordination, sequencing, and shared timing. Progress at the team level did not always translate into progress at the system level.
This is the environment in which scaling frameworks began to emerge. SAFe, in particular, was designed to answer a practical question: how do you preserve the adaptability of Agile teams while managing the realities of large, interconnected systems and operational constraints?
Because once more than a handful of teams contribute to the same product or value stream, informal coordination begins to break down. Dependencies surface late. Integration becomes risky. Decisions made in isolation are revisited at precisely the wrong moment, when the cost of change is highest and schedules are least flexible.
SAFe addresses these problems by introducing alignment mechanisms that operate at the system level rather than the team level. Cadence and synchronization create a predictable rhythm across teams. Program Increment planning establishes shared commitment points and exposes dependencies early, while the architectural runway helps ensure that teams are not forced to stop and redesign critical foundations in the middle of delivery. DevOps and Release on Demand extend this alignment all the way to production, addressing the very bottleneck that early Agile adopters encountered.
None of this replaces Agile teams. It makes their work sustainable in environments that are larger, more interconnected, and far less forgiving of improvisation.
In the next article, I will look at a question that comes up frequently: if SAFe introduces more structure, how does it avoid recreating the heavy governance models that Agile was meant to escape? That balance is one of the most misunderstood aspects of the framework.