Many organizations practicing “Agile” are actually just running a different flavor of project management. They adopt the vocabulary of Agile—relying heavily on “S” words like Scrum, squads, stories and sprints—but their goals remain fixed on managing team outputs. They create systems designed to control teams and push features rather than building the capacity to quickly adapt.
There’s nothing wrong with wanting to help improve a team’s ability to deliver, but over-optimizing for delivery creates a rigid system that’s more fragile and less agile.
Pursuing greater team throughput by installing practices rooted in command-and-control also creates an environment that will reject practices focused on agile principles like collaboration and team autonomy.
Project Managers in Disguise
“Agile Delivery Leads” takes a project management orientation to work: The idea is to improve how work moves through teams like physical work moving through a factory. Under this model, the Project Manager’s title changes to “Agile Delivery Lead”, but with “Agile” in the title, the responsibilities and management systems are still top-down.
If the goal is to maximize output by having management design, install and control a standardized operating model, your system will have to adopt values and practices that go against the values and practices that enable agility.
The two goals are mutually exclusive:
- Optimizing for Management-driven Throughput: Puts managers in control of how work moves through teams.
- Optimizing for Agility: Improves the system’s to adapt by prioritizing team factors like environment design, psychological safety, and autonomous work groups.
Just like with Product Owners and Scrum Masters, the role of Agile Delivery Lead harms teams when it is implemented as an individual job description rather than a shared group responsibility. Roles like the Product Owner, Scrum Master work best when they act as enablers, helping teams make better product decisions, understanding customers, and improving their collaboration practices.
Assigning an individual to a role—product, code quality, design, architecture—is a common pattern organizations rely on whenever a priority becomes important. But true cross-functionality requires creating teams composed of multi-skilled, multi-disciplinary individuals.
Within a adaptive team, delivery is a shared capability, not a single person’s job.
| Dimension | Delivery-Focused Approach | Agility-Focused Approach |
|---|---|---|
| Primary Goal | Delivery of high-value outputs. | Develop flexibility and the ability to pivot quickly and easily. |
| Team Model | Standardized structures with specialized individual roles. | Flexible, autonomous groups composed of multi-skilled, adaptive individuals. |
| Management Style | Agile Delivery Leads has authority and is responsible for leading agile projects. | Environment designed to enable team autonomy and safety. |
| Learning Model | Fixing immediate sources of delay to go faster. | Questions assumptions, structures and ways of working. |
| Systemic Risk | The system becomes too rigid to change in ways that doesn’t directly support delivery. | Slower initial setup as capabilities are built and existing structures are disrupted. |
| Vulnerability | Fragile to market or environment shifts. | Vulnerable to leadership demanding immediate, positive metrics. |
Over-Optimizing for Delivery Limits Adaptability
There is a fine line between optimizing for delivery and over-optimizing for it. Over-optimizing for delivery promotes a single way of seeing problems, and acts as a filter for what kinds of decisions are allowed. When delivery becomes the only priority, every challenge looks like a delivery problem, and options are judged by their impact on delivery deadlines.
Organizations that optimize for efficiency lose the capacity to change.
Over-optimizing for delivery makes the organization fragile and vulnerable to certain risks:
- Static Delivery Over Discovery: A delivery focus suits teams well when they have an endless backlog of similar features to build. But, it doesn’t help them develop the capabilities to research and decide what to build, nor to recognize when the environment has shifted beneath their feet.
- Dependency Over Autonomy: Having senior management makes product decisions creates clear direction for teams. But relying exclusively on management to make decisions ensures that teams remain dependent, and prevents them from developing their own decision-making capabilities.
- Process Lock-In: A culture built around delivery makes it easier to implement structured, delivery-focused practices. However, those practices become harder to abandon when they stop being appropriate.
Building the Capacity to Evolve
The ultimate risk of “Agile delivery” is calcification. Trying to improve delivery by reinforcing top-down management structures, organizations over-optimize for a single way of working, damaging their ability to flexibility and ability to change.
Organizational agility isn’t found in a product backlog, and it can’t be installed through standardized models or by hiring Agile Delivery Leads. It emerges from the adaptive capacity of multi-disciplinary teams paired with a supportive organizational design. Cultivating this capability requires creating a supportive environment, promoting shared team responsibilities. It requires creating teams safety, giving them autonomy and decision making power.
