The promise sounded simple: adopt Agile methodologies, and your organization will move faster, deliver better products, and respond to change like Netflix or Spotify. Except that’s not what happened. Research shows that 47% of Agile transformations fail, with some studies finding failure rates approaching 67%. The problem isn’t Agile itself. The problem is that organizations expect a framework to compensate for fundamental execution discipline they never built in the first place.
I’ve watched this pattern unfold across financial services and other industries. Teams adopt Scrum ceremonies religiously. They hold daily standups, run retrospectives, falsify Jira reports, defraud stakeholders, and plaster Kanban boards on walls. Yet velocity stays flat, technical debt compounds, and release cycles remain glacial. Leadership blames the methodology. The methodology was never the issue.
The Cargo Cult Problem
“Cargo cult” describes performing rituals without understanding their purpose. It means imitating the form while missing the substance. The term comes from Pacific islanders who, after observing WWII airstrips bring supply planes, built replica runways hoping to summon cargo through mimicry alone. In software, cargo cult Agile means adopting ceremonies without the underlying discipline that makes them effective.
Research from Engprax found that 65% of software projects using Agile requirements practices failed to meet deadlines, budgets, or quality standards. By contrast, projects using disciplined requirements engineering approaches failed only 10% of the time.
What separates these outcomes isn’t sprints or standups. It’s whether teams maintain rigorous requirements discipline, psychological safety to surface problems early, and structured processes to prevent burnout. These capabilities aren’t installed by adopting Agile. They’re built through deliberate operational discipline.
Consider Spotify’s transformation arc. Companies worldwide copied the “Spotify Model” after Henrik Kniberg’s 2012 whitepaper. What they didn’t copy was the engineering culture underneath. Anders Ivarsson, co-author, later admitted the framework was “part ambition, part approximation” that Spotify wasn’t fully implementing even at publication. By 2017, as the company tripled to 3,000 employees, Spotify had quietly abandoned the model. Leadership transitioned back toward traditional management.
The model failed because Spotify granted teams autonomy without ensuring baseline technical excellence, standardized collaboration patterns, or clear accountability. Squads spent energy negotiating working arrangements rather than solving customer problems. Dependencies became coordination nightmares. The autonomy supposed to accelerate delivery instead fragmented it.
When Frameworks Become Theater
A large bank rolled out SAFe across all IT departments, appointing dozens of new roles: release train engineers, value stream managers, scrum-of-scrums coordinators. The transformation added ceremony. It introduced PI planning sessions and complex portfolio boards. But it failed to remove existing approval layers. Developers reported that dependencies remained as painful as before. The framework labels changed. The execution discipline didn’t.
This is “Zombie Scrum” in action. Teams perform rituals while nothing fundamental shifts. They celebrate delivering 100 story points without asking whether those points produced customer value. They’re output-driven when they should be outcome-driven.
Jeff Sutherland, co-creator of Scrum, identified decision latency as a primary cause of Agile project failure. In analyzing enterprise transformations, he found 95% operated under Waterfall leadership despite adopting Agile team practices. Professor John Kotter stated he’s never witnessed a successful Agile transformation led by Waterfall-style management. The ceremonies don’t matter if decisions require six approval layers, budgets remain annual, and HR policies reward individual heroics over team outcomes.
What ING Netherlands Got Right (And Still Struggled With)
ING Bank Netherlands offers a more nuanced case study. It demonstrates both the power of committed execution discipline and the limitations of even well-executed transformations. In 2015, facing existential threats from fintech competitors and rapidly evolving customer expectations, ING embarked on a comprehensive reorganization that would affect 3,500 staff members at group headquarters.
The transformation wasn’t cosmetic window dressing. Leadership made a decision that would have been unthinkable at most banks. They put all headquarters employees “on mobility,” effectively terminating everyone’s current role and requiring them to reapply for positions in the new structure. Bart Schlatmann, then COO of ING Netherlands, later recalled: “I still remember January of 2015 when we announced that all employees at headquarters were put on ‘mobility,’ effectively meaning they were without a job.”
Selection criteria for the new roles weighted cultural fit and agile mindset over tenure, domain expertise, or previous performance ratings. This wasn’t a gentle evolution. It was a forcing function that communicated how serious leadership was about fundamental change. Many organizations claim they want transformation while protecting existing power structures and comfort zones. ING chose disruption.
The structural changes were comprehensive. The bank reorganized into approximately 350 squads of 8 to 10 people each, grouped into 13 tribes. Each squad was cross-functional, including IT engineers, product specialists, UX designers, data analysts, and marketing professionals. Squads owned specific customer journeys end-to-end rather than functional components. They selected their own frameworks (Scrum, Kanban, or hybrids) and operated with genuine decision authority over their work.
The measurable results were substantial. Product development cycles that previously averaged 18 months dropped to 3 to 6 months for major features, with smaller improvements completing in 4 to 6 weeks. Time-to-market for new digital services accelerated dramatically. Their mobile banking app achieved a 20% increase in user satisfaction scores within the first year of transformation. Net Promoter Scores in certain product areas jumped 60 points, from negative 30 to positive 30. That’s a swing that typically takes years to achieve through incremental improvement.
Customer retention improved significantly, with a 20% increase in active digital banking users across key markets including the Netherlands and Germany. The accelerated delivery of digital capabilities enabled ING to capture market share, adding an estimated €1 billion in new deposits annually through digital channels alone. By 2022, ING reported net results of €3.67 billion, reflecting the compounded efficiency gains and enhanced customer experience from sustained agile practices.
Employee engagement told a similarly positive story. ING’s annual Winning Performance Culture scan showed marked improvements in autonomy, collaboration, and innovation metrics. Cross-functional collaboration improved markedly as traditional silos dissolved. Teams that had spent years operating in departmental isolation were suddenly solving customer problems together daily.
But even ING’s leadership acknowledged significant limits and ongoing challenges. These leaders had invested more heavily and thoughtfully in transformation than most banks would dare. As the transformation scaled, patterns emerged that no amount of framework adoption could solve.
When organizational pressure increased (regulatory demands, market volatility, competitive threats), employees reverted to old behaviors. The command-and-control instincts that years of hierarchical conditioning had embedded didn’t disappear just because org charts changed. Hierarchy crept back in subtle ways: senior people dominating squad discussions, informal approval processes emerging around major decisions, tribal leaders becoming de facto middle managers despite having no formal authority.
Workload became unsustainable. Feikje Dunnewijk, Director of Talent and Learning in the HR tribe, observed: “There is a ‘new normal’ of having a lot of work and we still face the challenge of finding a sustainable pace as a team.” The problem wasn’t lack of productivity. Squads were delivering more than ever. The problem was that continuous delivery, continuous improvement, and continuous learning created continuous cognitive load without corresponding increase in capacity.
Leaders also observed a tendency toward short-term incremental innovation over radical reinvention. While squads excelled at rapid iteration on existing products, the structure didn’t naturally generate breakthrough thinking. One leader noted that squads “leaned toward short-term innovation” even when given autonomy to pursue bigger bets. ING addressed this by maintaining a separate innovation unit focused on partnerships with startups and exploration of disruptive ideas. They acknowledged that the squad model, for all its strengths, had built-in constraints.
Perhaps most tellingly, ING’s transformation leaders warned against premature scaling. Mandy Brouwer, Expert Lead for Learning & Way of Working in the HR tribe, argued: “Implementing agility before all the learnings have been transcribed and captured in the Netherlands is a risky move. There is barely time available to absorb changes brought about by our agile transformation. There are too many reorganizations and employees are far too busy.”
What ING demonstrated was that structural change, even when backed by leadership commitment and substantial investment, isn’t sufficient by itself. The bank invested over 1,000 manager-days in Agile leadership training during year one alone. They redesigned onboarding to immerse every new employee in customer-facing work, spending a full week at the Customer Loyalty Team call center taking actual customer calls to build empathy and shared context. Leadership didn’t delegate culture change to training programs. They role-modeled the behaviors they expected: ownership, empowerment, customer-centricity, transparency.
They created informal workspace designs to encourage collaboration, reduced formal meetings, shifted from input-steering (tracking activity) to output-steering (measuring outcomes), and implemented quarterly business reviews where tribes publicly shared both successes and failures. Everything was designed to reinforce the new operating model.
Even with this investment, ING faced the paradox that Jeroen Valbracht, their transformation leader, articulated: “The real transformation is on leadership and mindset. The real challenge at all levels is learning how to work and collaborate within this new way of working, with the new roles, methods and tools. This cannot be codified for risk of killing the very essence of Agile.”
This is the uncomfortable truth about transformation. The parts that matter most cannot be templated, documented, or rolled out via change management playbooks. How people think, how they make decisions under pressure, how they collaborate when stakes are high. These elements resist codification. ING succeeded because they built execution discipline first, then wrapped Agile structure around it. Organizations trying to reverse that sequence discover that frameworks without discipline produce nothing but expensive chaos.
The Discipline That Actually Matters
If Agile frameworks don’t fix execution, what does? Based on evidence from successful transformations, failure pattern analysis across industries, and my own experience building high-reliability infrastructure in regulated environments, five disciplines separate high-performing teams from those performing Agile theater:
1. Uncompromising Technical Standards
Every Spotify engineering talk emphasizes technical excellence and craftsmanship. Yet companies copying Spotify’s org structure routinely ignore this foundation, treating it as separate from “the Agile transformation.”
If your lead time from code commit to production is measured in months, if developers haven’t internalized clean code principles, if deployment requires manual coordination across six teams, no organizational model will help you ship quality software faster. In Agile environments, poor technical discipline becomes more visible and painful.
Consider the Horizon IT system deployed by Fujitsu for the UK Post Office. This was one of the first large-scale projects using Rapid Application Development, an early Agile methodology. The system became infamous for catastrophic failures leading to wrongful prosecutions of hundreds of sub-postmasters.
During the public inquiry, Fujitsu engineers testified that absent robust requirements engineering and design processes directly caused technical problems. The pressure to deliver working software quickly led teams to skip fundamental design validation. As technical expert Charles Cipione summarized: “If you don’t have a good design, it’s not going to work properly.”
Agile’s faster iteration cycles don’t fix bad engineering fundamentals. They expose them faster and at scale. Teams lacking discipline in testing, requirements validation, error handling, and design rigor ship defective software more frequently when they adopt Agile, not less.
In building observability infrastructure for financial platforms serving 160+ institutions, technical standards weren’t negotiable. Every service required structured logging to standardized schemas. Every deployment needed automated health checks and rollback capability. Every performance test required baseline measurement and regression detection. These weren’t Agile practices. They were engineering fundamentals enabling Agile to work safely at scale.
2. Empirical Process Control That Actually Controls
The Agile Manifesto emphasizes “responding to change over following a plan.” Most organizations interpret this as permission to abandon planning and measurement discipline entirely. They confuse adaptability with chaos.
True Agile transformation requires shifting from input steering to output steering. Input steering means tracking hours logged, story points committed, lines of code written, meetings attended. Output steering measures customer outcomes, business impact, and value delivered. This sounds obvious until you examine what most organizations actually measure and reward.
Do performance reviews evaluate individual productivity metrics? Do people get promoted based on how many projects they led rather than outcomes achieved? Do budget cycles lock annual funding regardless of quarterly learnings? Do compensation structures reward extra hours rather than efficient value delivery? If yes to any of these, you haven’t transformed measurement and incentive systems. You’ve relabeled them.
ING succeeded partly because they fundamentally restructured performance management. They eliminated most middle management roles. This wasn’t cost-cutting. Those roles represented input-steering infrastructure incompatible with output-steering squads. They shifted from individual performance ratings to team outcome assessments. They changed compensation to reflect squad delivery rather than personal activity.
This created tensions. High-performing individuals who thrived in the old system struggled when success became collective. Managers whose value came from coordinating handoffs found themselves obsolete when squads owned end-to-end delivery. The transformation was painful precisely because it was real. It changed what people optimized for, not just what they called their meetings.
3. Distributed Decision Authority With Clear Boundaries
Autonomy is Agile’s most seductive promise and most dangerous trap. Give teams freedom to self-organize, the thinking goes, and innovation flourishes. In practice, autonomy without boundaries creates fragmentation, duplication, and coordination nightmares.
ING learned this when squads initially spent enormous energy negotiating working arrangements rather than solving customer problems. Which tech stack should we use? How do we handle shared data? When do we synchronize releases? Without clear answers, every interface became a negotiation. Decision latency compounded.
Effective autonomy requires ruthless clarity about what remains fixed versus what stays flexible. The interfaces between squads must be stable and predictable. This means standardized collaboration patterns, shared architectural principles, common data schemas, agreed service-level expectations. Internal squad processes can vary widely. Tool choices, meeting cadences, workflow visualization, methodology selection can all differ.
A financial services firm that successfully implemented Agile at scale created explicit standards for common collaboration scenarios. They built templated requests for platform team work. They implemented dependency tracking with defined SLAs. They established escalation paths for prioritization conflicts that didn’t require executive intervention. These standards weren’t bureaucracy. They were infrastructure that reduced coordination overhead from bespoke negotiation to routine operation.
4. Aggressive De-risking Through Incremental Validation
Agile’s fundamental insight is that building the right thing matters more than building things right. The only way to know if you’re building the right thing is tight feedback loops with real users encountering real problems.
Yet most Agile transformations layer sprint ceremonies over waterfall thinking. They still expect teams to gather all requirements upfront, estimate entire projects months in advance, and commit to detailed roadmaps that become obsolete in weeks. They treat sprints as mini-waterfall cycles rather than risk-reduction experiments.
The discipline that separates high performers is structuring work to validate the riskiest assumptions first, expose integration problems early, and course-correct before investments compound. This requires psychological safety to discuss problems when they emerge and organizational support for taking small, reversible steps rather than big-bang launches.
When leading performance testing for a major Azure migration, we didn’t wait for the full migration plan before validating assumptions. We instrumented the pilot workload with Dynatrace, established baseline metrics, and ran controlled experiments testing our hypotheses. We discovered our assumptions about network latency were wrong and our database tier wouldn’t scale as expected. These discoveries would have been catastrophic at full deployment but were manageable in pilot.
This is Agile working as designed: failing fast on small bets to de-risk large ones. But it only works if your organization genuinely supports learning from failure rather than punishing it. If retrospectives feel like blame sessions, if leaders demand certainty in estimates, if planning processes require committing to outcomes before validating feasibility, you’re performing Agile theater while maintaining waterfall discipline.
5. Relentless Focus on Sustainable Pace
The Agile Manifesto’s twelfth principle states: “Agile processes promote sustainable development.” This is the most overlooked discipline in transformations and reveals whether leadership understands what they’ve adopted.
ING’s leaders admitted candidly that workload became unsustainable as they scaled agility. Employees reported being “far too busy” to absorb organizational change while maintaining delivery pace. When pressure increased, teams reverted to old behaviors because they lacked mental space for new ones.
This is a fundamental tension in continuous delivery. If every sprint is packed to capacity, when do teams improve craft, reduce technical debt, learn new techniques, or think strategically about architecture? The answer for most teams is: they don’t. They accumulate debt until velocity grinds to halt, then blame Agile for not delivering speed.
High-performing teams treat slack capacity as essential infrastructure, not waste. Slack capacity means explicit time for learning, debt reduction, process improvement, and innovation. They recognize that continuous improvement requires continuous thinking time. They load sprints to 70% to 80% of theoretical capacity, reserving buffer for necessary work that doesn’t fit user stories.
This discipline requires leadership courage. When sprint planning reveals the team can commit to three stories instead of five, weak leaders demand the team “find a way” to commit to all five. Strong leaders ask what constraints prevent full capacity and whether those constraints should be removed or accepted as sustainable pace limits.
Sprint velocity means nothing if teams burn out, if top engineers leave for companies that respect work-life balance, if accumulated debt forces complete rewrites. Sustainable pace isn’t about being nice. It’s about maintaining the organizational capacity to think, learn, and adapt that makes Agile valuable.
The Uncomfortable Reality
The data on Agile transformation failure hasn’t improved.
The Standish Group’s analysis shows 41.62% of projects succeed, 46.92% are late/over-budget with unhappy customers, and 11.46% fail completely. MIT Sloan research found that 67% of terminal failures led to bankruptcy or acquisition.
The most successful companies (Microsoft, Amazon, Apple) all use Scrum, but they didn’t achieve success by copying frameworks. They built execution discipline first, then selected methodologies that reinforced it.
The lesson isn’t to abandon Agile. The lesson is to stop expecting methodology to substitute for operational excellence. Scrum won’t fix a culture that punishes failure. Kanban won’t solve decision latency if executives operate like a command hierarchy. Standups won’t improve alignment if people lack shared context about success.
What To Do Instead
Start with the boring fundamentals that actually matter:
Measure what matters. Track cycle time from commit to production. Monitor deployment frequency and mean time to recovery. Instrument decision-making latency. These metrics reveal execution discipline better than story points ever will.
Fix incentive structures. If individual productivity metrics dominate performance reviews, teams optimize for individual output over collective outcomes. If annual budgets lock funding regardless of learning, you get Waterfall execution with Agile labels.
Invest in technical excellence. Code review discipline, automated testing, continuous integration, and observability aren’t Agile practices. They’re engineering practices Agile assumes exist. Without them, you’re building on sand.
Create genuine psychological safety. This doesn’t mean everyone is nice. It means people can surface bad news, challenge assumptions, and admit mistakes without career consequences. If retrospectives feel like performance reviews, you don’t have safety.
Protect cognitive capacity. Stop celebrating teams working nights and weekends. Stop loading sprints to 100% capacity. Build in explicit slack for learning, innovation, and technical debt reduction. Burnout is an execution failure, not a motivation problem.
Agile methodologies provide useful scaffolding for disciplined teams to move faster. They don’t create the discipline itself. That requires leadership willing to change how they make decisions, fund work, measure performance, and reward behavior. It requires engineers who take pride in craft. It requires organizations that value sustainable excellence over quarterly heroics.
The companies that “get” Agile aren’t the ones with elaborate ceremonies. They’re the ones that built execution discipline so strong that Agile’s lightweight structure was enough to channel it. For everyone else, copying frameworks without fundamentals creates expensive theater.
The choice isn’t between Agile and discipline. It’s between Agile with discipline and Agile without it. One delivers Netflix and Spotify. The other delivers cargo cult ceremonies that look productive while execution deteriorates.
Nabeil Sarhan focuses on enterprise technology delivery, platform scalability, and program management. He holds an M.Eng. from MIT, an MBA from Bryant University, and certifications including CSM, CSPO, and SAFe ASE 6.0.
Nabeil Sarhan, MBA, is a dynamic technology delivery manager with over 15 years of experience in tech, cybersecurity, and computing scalability. He excels in leading diverse teams and delivering enterprise-class systems across industries such as healthcare, finance, and retail. Nabeil’s passion for solution design, systems architecture, and performance optimization makes him a sought-after consultant. He holds degrees from Harvard, MIT, and Bryant University. Connect with Nabeil on LinkedIn