The Broken Promise of Agile
Tear Down the Cathedrals, Build the Bazaars - Part 2
Agile promised to empower teams, deliver value, and bring us closer to the people we serve. But today, it often feels like that promise has been broken. Developers feel constrained, customers are distant, and an overemphasis on mindset has diluted its technical roots. How did we get here—and how can we reclaim what Agile was meant to be?
Initially, Agile came with a promise that resonated deeply:
"Deliver twice the work in half the time."
It was a rallying cry for teams to embrace collaboration, iteration, and continuous improvement. But for many, especially in large enterprises, that promise has turned into frustration.
Agile frameworks like Scrum and SAFe often fail to deliver the outcomes they tout because they demand extraordinary discipline and skill while pretending to be universally applicable. Agile has shifted from a movement of empowerment to one of control, leaving many teams wondering: What happened to the freedom we were promised?
A Purpose Lost
Agile’s original promise was straightforward: deliver value quickly, adapt to change, and empower those doing the work. It was a pragmatic and hands-on approach to solving real problems for real people. But over time, that purpose has been obscured by layers of frameworks, certifications, and buzzwords. Instead of fostering innovation and impact, Agile has become about checking process boxes, often leaving teams disconnected from the actual problems they’re trying to solve.
Got it! Here's the restructured section with a similar argumentation flow to the part about "The Forgotten Developers."
The Fixation on Mindset
Agile has increasingly become synonymous with mindset and culture, but this shift has overemphasized aspects that, while important, have led the movement astray. To regain its balance, we need to make an effort to understand why this fixation has taken hold, what it’s costing us, and how we can restore a kind of equilibrium.
Why Is There Such a Fixation on Mindset?
The growing dominance of Agile Coaches and organizational consultants within the Agile community has driven this focus on mindset and culture. These individuals, whether formally trained or self-claimed, often have limited connections to Agile’s technical foundations. Naturally, they concentrate on the areas they can influence, such as team dynamics, psychological safety, and organizational transformation.
This has turned mindset into the centerpiece of Agile, sometimes at the expense of its original purpose: building better products through iterative, adaptive, and technically sound practices. While these cultural elements are vital, they were meant to support—not replace—the technical roots of Agile.
What Do We Lose by Overemphasizing Mindset?
By focusing so heavily on mindset, we’ve sidelined the technical practices that Agile was built upon. Test-driven development (TDD), pair programming, continuous integration, and other engineering disciplines once ensured Agile’s promise of adaptability and quality. Today, these are often treated as optional or are completely absent from Agile conversations.
Instead, the spotlight falls on mindset workshops, maturity models, and theoretical frameworks. This creates an imbalance where Agile becomes more about abstract ideals than practical execution. Without the technical foundation, all the psychological safety and collaboration in the world won’t help teams deliver meaningful, high-quality products.
Finding the Right Balance
This isn’t to discredit Agile Coaches or organizational consultants—many have brought much-needed attention to collaboration and team health. But when cultural transformation takes precedence over technical excellence, we lose the balance that made Agile effective in the first place.
Mindset and culture are undeniably important—they create the environment in which teams can thrive. However, without the technical excellence that allows teams to adapt quickly and deliver value, Agile risks becoming hollow.
To truly fulfill Agile’s potential, we must reconnect with its technical roots while still embracing cultural agility. Striking this balance will enable teams to combine strong engineering practices with the collaborative, adaptive spirit that Agile originally promised. It’s time to integrate both dimensions and create a version of Agile that delivers on its promises.
The Forgotten Developers
Agile was designed to empower developers, the creators of value, to solve meaningful problems. But in practice, many Agile implementations have reduced developers to task executors. Their insights are underutilized, and their creativity is stifled by rigid processes, excessive synchronization, and an obsession with ceremony.
The result is a developer experience marked by marginalization. Instead of being trusted to use their expertise to build great software, developers often find themselves buried under bureaucracy. Agile, which once promised liberation, now feels like just another system of control.
If Agile is to deliver on its original promise, developers need real autonomy and the space to focus on impactful work. Empowerment must move beyond platitudes to tangible action. It must place trust in the people closest to the work.
Why Do Developers Hate Scrum?
The backlash against Agile frameworks doesn’t stem from a dislike of collaboration or iteration. Developers don’t resent Agile principles; they resent how these frameworks are applied in practice.
The shift toward Agile as a task-management system has created a “tyranny of the business”. It reduces developers to executors of predefined work. Instead of solving meaningful problems, they’re locked into a rigid cycle of sprint planning, reviews, and endless standups. Agile’s seductive promise of "twice the work in half the time" often translates to "twice the meetings in half the morale".
Ceremonies and processes intended to create flow often create friction instead. Frameworks like Scrum and SAFe may work in specific contexts, but they’re frequently misapplied, forcing a one-size-fits-all approach on teams with vastly different needs. What works for a five-person startup rarely translates to a 500-person enterprise, yet many organizations attempt to shoehorn everyone into the same mold - with predictably poor results.
Not Everything Has to Be Synchronized
Agile frameworks place a heavy emphasis on synchronization, with standups, sprint reviews, and program increment planning dominating the calendar. While alignment has its place, over-synchronization can stifle productivity and innovation.
Teams often perform best when they’re allowed to operate independently, making decisions locally and working at their own pace. Empowering teams to focus on their specific goals, free from the constraints of rigid alignment processes, fosters creativity and adaptability. Decentralization and trust, instead of excessive coordination, are the keys to unlocking Agile’s potential.
The Forgotten Customers
Agile was meant to bridge the gap between teams and customers, creating a direct feedback loop to ensure that what we build delivers real value. However, in many organizations, this connection has eroded, leaving teams isolated from the very people they aim to serve. To restore Agile’s purpose, we must understand why this disconnect exists, what it’s costing us, and how we can rebuild the bridge between teams and customers.
Why Are Customers Forgotten?
In enterprise Agile implementations, customers are often reduced to abstractions. Instead of direct interaction, teams rely on personas, user stories, and backlog prioritizations filtered through layers of intermediaries. While these tools can provide structure, they also create distance.
Actual users are rarely involved in day-to-day development. The absence of regular, meaningful engagement with real customers leaves teams guessing about needs, priorities, and preferences. This disconnect is further exacerbated by organizational silos, where decision-making is centralized far away from the teams creating the solutions.
What’s the Impact of This Disconnect?
When customers become an abstract concept, Agile loses one of its core principles: delivering value. Without a clear, ongoing relationship with users, teams risk solving the wrong problems - or creating solutions that miss the mark entirely.
This detachment turns Agile into a process-focused exercise rather than a value-driven approach. Teams may excel at sprinting through their backlog but fail to address the genuine needs of their users. The result? Products that don’t resonate, wasted effort, and a loss of trust in Agile as a methodology.
Rebuilding the Customer Connection
To rediscover its purpose, Agile must reestablish a direct line between teams and their customers. This requires breaking down silos and reducing reliance on proxies like personas and backlog refinements. Instead:
Facilitate direct customer interactions: Bring real users into sprint reviews, workshops, and feedback sessions.
Emphasize iterative user validation: Regularly test features and ideas with actual customers to ensure alignment with their needs.
Empower teams to prioritize value: Give teams the autonomy to adapt their work based on direct user feedback, rather than sticking rigidly to predefined plans.
By involving customers more deeply and regularly, teams can ensure their efforts are focused on delivering meaningful, impactful solutions. The eventual goal of Agility (solving real problems for real people) can only be achieved when customers are at the heart of the process.
Reclaiming Agility
Agile doesn’t need more frameworks, certifications, or consultants—it needs a return to its roots. That means focusing on outcomes over processes, empowering developers to make decisions, and reconnecting teams with their customers.
The promise of Agile isn’t dead - it’s just been buried. Reclaiming it requires all of us, as practitioners, to strip away the layers of bureaucracy and refocus on what truly matters: delivering value, solving real problems, and trusting the people closest to the work. Agile was never meant to be about frameworks or certifications; it was about people, collaboration, and results. Together, we can rebuild a system that works. For developers, for customers, and for organizations as a whole. The question is: are we ready to embrace that challenge?