6. Agile: Increasing Cohesion of Teams · Coupling

Why Agile Felt Different

Waterfall often delayed learning until late integration or release. By the time consequences appeared, requirements had hardened, timelines were committed, dependencies had spread, and redesign had become expensive. Agile emerged as a response to that timing problem.¹

Its central idea was simple: shorten the distance between decision and feedback. Instead of long planning cycles, large releases, and delayed integration, Agile encouraged short iterations, incremental delivery, continuous reprioritization, and regular retrospection. The goal was not merely speed. It was learning earlier, while systems were still easy enough to change.

A Parallel Outside Software

A similar pattern appears in hospital care delivery. When treatment planning, bedside observation, and outcome review happen in separate departments over long intervals, learning slows. Problems repeat because information travels slowly, ownership fragments, and redesign happens far from operational reality.

Now compare that to a stable care team that meets daily, reviews outcomes continuously, adjusts protocols quickly, and stays close to patient consequence in real time. The structure changes. Responsibility becomes clearer. Feedback arrives faster. Adaptation becomes part of normal operation instead of a delayed administrative process.²

That was Agile's deeper contribution: not simply faster delivery, but faster learning inside boundaries capable of acting on what they learned.

Agile Increased Team Cohesion

One of Agile's biggest structural changes was strengthening cohesion at the team level. Cross-functional teams compressed the distance between planning, implementation, testing, and near-term feedback.³

Instead of work moving rigidly through long handoff chains, the same team could discuss priorities, implement changes, observe outcomes, and adjust behavior within short cycles. When this worked well, ownership became easier to see. The same boundary making decisions also absorbed more of the immediate consequences. Learning became less ceremonial and more operational. Problems surfaced sooner. Adjustments happened faster. Teams felt closer to the reality they were shaping.

This is one reason Agile often felt dramatically better than older delivery models even before organizations fully understood why.

Feedback Rhythm Changed

Agile also changed the rhythm of feedback. Large integration events gave way to shorter cycles, demos, test automation, regular retrospectives, and more frequent releases.⁴ This increased temporal coupling. Consequences arrived sooner.

But faster cycles alone do not guarantee learning. A team can move quickly while still avoiding difficult reality. Velocity metrics can replace outcome understanding. Sprint completion can replace redesign. Ceremony can replace reflection. At that point, speed becomes throughput theater: visible motion without proportional improvement in system learning.

Product and Engineering Moved Closer Together

Agile also changed the relationship between product and engineering. In stronger implementations, priorities were no longer fixed entirely upfront. Product goals, technical constraints, operational realities, and user feedback became part of ongoing negotiation instead of isolated planning phases.⁵

This improved local adaptability. Teams could respond to new information without waiting for large-scale replanning cycles. But this local flexibility introduced another problem. A team could become highly adaptive inside its own boundary while remaining only weakly connected to broader system consequences.

What Agile Did Not Fully Solve

Agile improved cohesion inside teams more consistently than it improved coupling across organizations. As systems scaled, dependencies between teams increased, platform constraints emerged, operational burdens accumulated, and cross-team coordination became more expensive.⁶

Each team could learn quickly locally. The larger organization could still struggle to form a coherent shared picture of operational risk, dependency chains, runtime consequence, and system-wide fragility.

This explains why many organizations experienced Agile as both successful and frustrating at the same time. Teams became faster. Delivery improved. Local ownership strengthened. And yet incidents still repeated, coordination friction still grew, operational failures still spread across boundaries, and runtime reality often remained distant from development teams. Strong local cohesion did not automatically produce strong system coherence.

The Remaining Distance

Agile shortened feedback loops inside the team boundary. But runtime consequence often still lived somewhere else: operations, platform engineering, security review, production support, and incident response. The organization had solved part of the learning problem. Teams could adapt faster internally. But many systems still separated builders from operational consequence.

That remaining distance set up the next shift. The question changed from "How do teams learn faster?" to "How do the people building systems stay close to the consequences those systems create?"⁷ That question leads directly into DevOps.

What Agile Revealed

Agile revealed something important that extends far beyond software. Systems learn differently when feedback arrives earlier, ownership remains local enough to adapt, and redesign happens while consequences are still fresh. But Agile also revealed the limits of local optimization. Healthy teams alone do not guarantee healthy systems. Large organizations still need cross-boundary coupling, operational visibility, consequence return, and coordination structures that preserve learning instead of merely synchronizing activity.

That tension becomes the center of the next chapter.

Bridge to Chapter 7

Chapter 7 examines DevOps as an attempt to restore operational coupling: bringing builders closer to runtime reality, shortening the distance between deployment and consequence, and reducing the fragmentation created when operations and development evolved as separate worlds. Teams learn differently when they experience the systems they build after release instead of only before it.

Agile strengthened learning inside teams by shortening feedback cycles and increasing local ownership. But large systems still struggled when runtime consequence remained outside the team boundary.

Agile Manifesto (2001) and early Agile-method literature on reducing long-cycle planning delay. ↩
Donald M. Berwick, "Developing and Testing Changes in Delivery of Care," Annals of Internal Medicine 128, no. 8 (1998): 651-656. ↩
Alistair Cockburn and related Agile writings on cross-functional teams, local ownership, and adaptive scope management. ↩
Kent Beck and iterative-development literature on short-cycle feedback and test-driven adaptation. ↩
Martin Fowler and product/engineering collaboration literature on incremental planning and continuous reprioritization. ↩
DORA research and large-scale Agile practice literature on limits of team-local learning under inter-team dependency load. ↩
Gene Kim et al., The DevOps Handbook, on extending feedback and ownership beyond team cadence into operations. ↩