Why Your Company Isn't Doing Agile (Even If It Thinks It Is)

The article analyzes why most companies fail at agile transformation — only 4% achieve enterprise-wide agility. The cause isn't bad frameworks, but deep cultural and organizational barriers: a frozen middle management, a cargo-cult imitation of agile, and missing technical practices. In the Czech context, the situation is made worse by a hierarchical culture rooted in the Austro-Hungarian and communist tradition, with the key to success being cultural change rather than the introduction of rituals.

Established technology firms with twenty years of history and dozens of products face barriers in their agile transformation that cannot be overcome by renaming roles. The data shows why most attempts fail — and what to do about it.

In June 2015, the Dutch bank ING placed roughly 3,500 head-office employees "on mobility" — effectively, everyone lost their positions and had to reapply for jobs in a radically reorganized company. The selection committee placed greater weight on culture and mindset than on experience. Entire management layers disappeared.

A year later, ING was deploying software every two to three weeks instead of five or six times a year, and had markedly improved both customer satisfaction and employee engagement. According to McKinsey, it was one of the most successful agile transformations in Europe.

But ING is the exception. Of the roughly 2,500 firms McKinsey studied in 2017, a mere 4% achieved a full enterprise-wide agile transformation. Independently, Cross, Gardner and Crocker found in their own survey of 112 companies that nearly 90% of firms ran into fundamental problems when scaling agile from pilot teams to the whole organization (Harvard Business Review, 2021). For every highly successful transformation, McKinsey counts two that squander the opportunity.

And failure is not a matter of choosing the wrong framework. It is the consequence of deep cultural, organizational, and technical barriers. And in the Central European environment, where a specific historical burden is added to them, these barriers are multiplied still further.

Martin Fowler, one of the most influential voices in software engineering, described in 2009 a phenomenon he called "flaccid Scrum." Teams adopt the rituals — daily stand-ups, retrospectives, sprint reviews — but completely ignore the technical practices: automated testing, continuous integration, refactoring. The result? The source code is an ever-greater mess, but now people talk about it in fifteen-minute blocks while standing up.

Nine years later, at the Agile Australia conference, Fowler hardened his stance. The problem, he argued, is no longer persuading people to do agile. The problem is dealing with faux agile — agile that carries the name but none of the values.

Dave Thomas, co-author of the original 2001 Agile Manifesto, went even further. In his essay "Agile is Dead (Long Live Agility)" he declared that the word "agile" had been abused to the point of being practically meaningless. Ron Jeffries, another co-author of the manifesto, in 2018 called on developers to "abandon Agile" — because typical implementations lead to greater interference in developers' work and higher pressure.

What does this failure look like in practice? Project managers rename themselves scrum masters, business analysts become product owners. Waterfall phases get new labels: "development sprint 1, 2, 3." The firm focuses on doing agile instead of being agile — and that is a fundamental difference. Introducing short daily stand-ups without changing decision-making processes, funding, and organizational structure is cosmetic adjustment, not transformation.

The professional literature has a term for this phenomenon — "cargo cult agile" — a reference to the indigenous peoples of Melanesia who, after the Second World War, built mock-ups of airplanes in the hope of summoning shipments of supplies. Form without an understanding of the essence.

If cargo cult agile is the disease, its cause is usually the organizational structure. Specifically, the phenomenon the literature calls the "frozen middle."

The dynamic is predictable. Top management buys agile transformation because it hears "faster, better, more predictable." Development teams welcome it because they can work more autonomously. Middle management is squeezed between them — their reports become irrelevant, their role seems threatened, and no one is preparing them for the new way of working. McKinsey found that only 13% of people in "stuck" organizational units practice a shared or servant leadership style, compared with 89% among their agile counterparts.

The result is "wagile" — waterfall disguised as agile. Teams work in sprints, but leadership still demands delivery of a fixed scope by a fixed deadline set a year in advance, with progress tracked on a Gantt chart. In extreme cases management fixes all four variables — scope, time, cost, and quality — which is mathematically impossible and leads to a systematic erosion of code quality.

McGregor and Doshi (HBR, 2018) found that such "agile in name only" processes often end up damaging engineers' motivation and productivity. Timothy Clark (HBR, 2022) added that roughly half of all agile transformations fail because cultures built on command and control are fundamentally incompatible with the requirement of psychological safety, without which agile cannot work.

To understand what kills an agile transformation and what enables it, it is worth looking at three concrete cases.

At the turn of the millennium, Nokia had the best mobile technology on the market. An academic study by Vuori and Huy of INSEAD and Aalto University (ASQ, 2016), based on 76 interviews with key managers, uncovered the mechanism of its fall. Within the organization there were two types of shared fear: top management feared the competition and shareholders, while middle management feared their superiors. Middle managers did not pass bad news upward. Top management therefore formed overly optimistic notions of the firm's technological capabilities. It pushed middle management with unrealistic targets. Middle management hid the problems even deeper.

The study explicitly states: less hierarchical structures foster innovation, among other reasons, because they dampen the effects of hierarchy-based fear. Nokia did not fall because it lacked technology — but because its organizational culture did not allow information to flow to where it was needed.

Spotify is the opposite case — not of success, but of myth. The so-called "Spotify model," with its squads, tribes, chapters, and guilds, published by Henrik Kniberg in 2012, became the most-copied organizational structure in the technology world. Yet, as Jeremiah Lee, a former Spotify product manager, described in April 2020, the famous team model was always merely an aspiration and was never fully implemented. Joakim Sundén, an agile coach at Spotify from 2011 to 2017, confirmed: "Even at the time we were writing it, we weren't doing it like that. It was partly an aspiration and partly an approximate description." Kniberg himself repeatedly warned against copying the structure — what mattered was the culture of trust, not the organizational chart.

Firms that renamed teams "squads" and managers "chapter leads" without any cultural change merely demonstrated the imitation approach in its purest form.

Microsoft under Satya Nadella's leadership since 2014 shows that transforming an established firm is possible, but requires the courage for a cultural revolution. Nadella replaced a "know-it-all" culture with a "learn-it-all" culture, abolished forced ranking of employees, tore down the walls between departments, and systematically built psychological safety. It was not about introducing a framework — it was about a fundamental rethinking of how the company thinks.

The Scaled Agile Framework (SAFe) is the most widely used enterprise-wide agile framework — it is used by 44% of organizations according to the 18th State of Agile report (Digital.ai, 2025). It is also the most criticized. Ken Schwaber, co-creator of Scrum, called it dangerous, with roots in the old RUP. ThoughtWorks has explicitly discouraged its use on its technology radar since 2015. Al Shalloway, a former key contributor to SAFe, left after six years with the remark that it would be more apt to call SAFe an improved waterfall than a poor agile.

LeSS (Large-Scale Scrum) is a minimalist alternative whose rules fit on a single page, but it requires a deep organizational redesign. Most firms are not willing to undertake it.

It is telling that 74% of organizations today use hybrid or custom approaches (Digital.ai, 2025). The industry is moving away from prescribed frameworks toward contextual adaptation — which corresponds precisely to the spirit of the original Agile Manifesto.

What demonstrably works is shown by the data from the DORA project (Forsgren, Humble, Kim — the book Accelerate, 2018). Four metrics predict organizational performance: deployment frequency, lead time from committing a change to production, change failure rate, and time to restore service after an incident. According to 2017 data, elite teams deployed 208 times more frequently and 106 times faster than the weakest. More recent editions of the DORA survey have reworked these categories, but the key finding remains: speed and stability are not opposites — the best teams excel at both. The industry, meanwhile, has no fundamental influence — high-performing teams exist in every sector.

Conversely, measuring delivery speed (velocity) across teams is demonstrably harmful. Velocity is a subjective metric based on estimates, which teams can easily inflate — a direct consequence of Goodhart's law: any metric used as a target ceases to be a good metric. Siemens Health Services moved from traditional scrum metrics to flow metrics (cycle time, throughput, work in progress), because the traditional agile metrics did not provide the transparency needed to manage development at its scale — as the Agile Alliance described in a case study.

Firms with a single product have an advantage in agile transformation: they can focus. A firm operating search, e-commerce, maps, e-mail, news, and other services simultaneously faces coordination challenges of a different order.

A key role here is played by Conway's law, formulated in 1968: organizations produce systems that copy their communication structures. Research by MIT and Harvard Business School has confirmed strong evidence for this "mirroring hypothesis" — loosely coupled organizations produce markedly more modular products. In practical terms: if a firm has strong organizational silos, it will have strongly coupled, monolithic systems. And vice versa.

The book Team Topologies (Skelton and Pais, 2019) offers a framework that addresses this problem. It defines four types of teams. Stream-aligned teams own the entire lifecycle of a single product stream and make up 70–80% of the organization. Platform teams provide internal services as a product. Enabling teams temporarily help other teams acquire competencies. Complicated-subsystem teams manage parts that require deep specialization.

As Martin Fowler summarized on his blog: the main benefit of a platform is reducing the cognitive load of stream-aligned teams. Decisions driven by reducing cognitive load are different from decisions driven by standardization or cost savings — and it is precisely here that firms err most often.

A complementary approach is InnerSource — the application of open-source principles to proprietary development inside an organization. PayPal, a pioneer of this approach, achieved a marked reduction in development time and costs. The principles are simple: open repositories visible to the whole company, transparent discussion and code review, and the role of trusted committers enabling contributors from other teams. For a firm with dozens of product verticals, it is a way to share solutions without central control and to break down silos organically, from the bottom up.

All the barriers described above exist globally. In the Czech Republic, however, a specific cultural burden is added to them that cannot be ignored.

Hofstede's cultural dimensions — a standard analytical tool in cross-cultural management — reveal a structural difference. The Czech Republic's power distance index is 57, markedly higher than in the cultures where agile originated: Denmark 18, Sweden 31, the United States 40. The Czech uncertainty avoidance index reaches 74 — compared with Denmark (23), Sweden (29), or the USA (46).

What does this mean in practice? According to an analysis by World Business Culture, Czech management has historically been characterized by a paternalistic style reflecting the hierarchical, bureaucratic nature of the former state enterprises. Managers kept their distance from subordinates and issued direct instructions that were expected to be carried out without question. The consequence is a lack of initiative — subordinates have no authority to go beyond direct instructions. This, according to analysts, is still apparent in larger, locally managed Czech enterprises.

The roots reach deeper than 1989. Czech managerial culture carries three layers of bureaucratic tradition: Austro-Hungarian institutionalism; the communist system — where ambitious managers who took risks beyond the plan met with the system's resistance, and citizens learned not to voice dissenting opinions — and the post-communist transformation, which demanded the exact opposite of the previous values: initiative instead of obedience, individual responsibility instead of collectivism.

A study of the organizational culture of Czech enterprises (PMC/NIH, 2019–2021, a sample of 962 firms) found that adhocracy culture — the type most compatible with agile innovation — is the least represented of all four types in Czech firms (21%), while clan (32%) and hierarchical (25%) cultures dominate.

Academic research by Doležel, Buchalcevová and Menčík of VŠE Prague confirmed the dominance of so-called "truncated Scrum" in Czech firms — incomplete implementations in which firms select the rituals but omit the principles. A survey by Cerebra.cz identified the main barriers: resistance to changing the organizational culture (53%), a general reluctance to change (42%), and fear of losing managerial control (30%).

A synthesis of the research by McKinsey, DORA, academic studies, and real transformation cases points to five conditions, without whose fulfillment an agile transformation in a large established firm is doomed to fail.

Leadership must lead by example. McKinsey reports that organizations that invest in leader development during transformations are 2.4 times more likely to achieve their performance targets. Only 15% of executives actively shape agile practices (Digital.ai, 2025). ING succeeded because its entire board engaged personally — including a visit to Spotify and participation in the redesign of the organization.

Continuous integration and delivery automation are a technical condition. Fowler's "flaccid Scrum" shows that without automated testing and continuous delivery, agile is powerless against technical debt. McKinsey estimates that technical debt can account for as much as 40% of large enterprises' technology assets.

The organizational structure must match the desired architecture. Conway's law is not a recommendation — it is inevitable. A firm with product silos will have a siloed architecture. Team Topologies offers a concrete way out, but it requires the courage to abolish management layers and to create cross-functional teams responsible for the entire product lifecycle.

Measure outcomes, not outputs. DORA metrics and flow metrics predict organizational performance better than velocity or the number of story points. Velocity as a key performance indicator is a direct invitation to game the numbers.

Transformation requires working with culture. Allegro, one of the most successful Central European technology transformations, summarized it at the PMI conference: at the outset they focused on the mechanics of Scrum, but that is only 20% of success; the remaining 80% is culture and people. In the Czech context this means actively working with the legacy of the past — building psychological safety, rewarding initiative instead of obedience, and creating an environment where it is acceptable to say "I don't know" or "this isn't working."

The agile transformation of a large established technology firm is not a project with a defined end. It is a change to the organization's operating system. Nokia shows what happens when a hierarchy of fear suppresses honest communication: a firm with the best technology on the market loses, because its culture does not allow information to flow. Microsoft under Nadella shows that even an established firm can go through a cultural revolution — if leadership means it seriously.

For a large Central European technology firm with a hierarchical tradition and a dominant local position, the situation is specifically difficult. Hofstede's dimensions reveal the structural barriers. The academic finding of the dominance of "truncated Scrum" confirms that imitation agile is the default state in this environment.

But for precisely that reason, a real — not cosmetic — transformation is an existential choice. The alternative is a gradual drain of the best people to global firms with a more modern culture, a deepening of technical debt, and a loss of the ability to innovate at a time when artificial intelligence and the cloud are rewriting the rules of the game.

The question for the leadership of such a firm is not "whether" to transform. It is "whether they have the courage for the depth of change that it requires."

Methodological note: The article draws on academic studies (Vuori and Huy, ASQ 2016; Doležel et al. 2019; the OCAI studies 2019–2021), industry reports (McKinsey 2017/2018/2022, Digital.ai State of Agile 2025, DORA/Accelerate 2018), primary sources (Fowler, Jeffries, Thomas, Kniberg, Lee, Sundén), and case studies (ING, Nokia, Microsoft, Allegro, PayPal). Data and sources were verified as of February 2026.

Transparency of creation

The concept, structure, and editorial line of the article are the work of the author, who prepared the content outline, set the key theses, and directed the entire creative process. Generative AI (Claude Opus 4.6, Anthropic) was used as a tool for research, fact-checking, and fleshing out the author's draft.

The author verified the key findings and approved the final wording. No part of the text was published without conscious authorial control. Factual data were verified against the publicly available sources cited in the text.

The procedure complies with the transparency principles of EU Regulation 2024/1689 (AI Act). #poweredByAI