Understanding Fake Agile: Definitions, Laws, and Common Pitfalls
The article examines the concept of "fake agile," defines true agility through three core laws, distinguishes genuine from nominal agile practices, discusses the limitations of scaling frameworks like SAFe, and highlights how agile principles extend beyond software development to whole‑organization operations.
I now use the WeChat signature "Don't mention concepts, just solve problems," whereas before 2013 my signature was "Don't mention agile, just solve problems," reflecting how agile methods had become a past trend at Tencent while many problems still needed solving.
The article is based on a quote by Martin Fowler (originally published on Forbes by Steve Denning) about recognizing and dealing with "fake agile".
(Image unrelated to Tencent, from a friend.)
A company invited me to speak about "fake agile" and asked how to identify and handle it. Like wearing flamenco clothes without knowing the dance, many so‑called agile examples are superficially related but miss the essence.
Surveys by Deloitte and McKinsey show that over 90% of senior executives value agility, yet fewer than 10% believe their companies are truly agile, creating a gap that fuels consultants and coaches claiming to be agile.
The term "agile" is often thrown around without consensus, applied to any organization lacking substantive agility requirements, while truly agile companies may avoid the label and use their own terminology.
1. Defining "Agile"
Agility consists of three core components; unless an organization follows all three "laws," it cannot truly claim to be agile. These laws apply to whole‑company or business agility, requiring a unified pace across the organization.
2. The Three Agile Laws
Customer Law : Focus on delivering value to the customer as the ultimate goal.
Small‑Team Law : Assume work is done by small, self‑organizing teams with short cycles, always delivering customer value.
Network Law : Continuously eliminate bureaucracy and hierarchical layers so the company operates as an interactive network of teams, all striving to increase customer value.
These laws cover operational agility (improving existing business) and strategic agility (creating new products/services), independent of specific jargon or branded processes.
3. Agile Without Labels
Many of the most successful companies (Amazon, Apple, Facebook, Google, Netflix, Microsoft) exhibit strong agility but rarely use standard agile terminology; their business agility is a key factor in their high valuation.
4. Early Stages of Agile
Agility is a journey; no company implements all elements on day one. Early‑stage agility, sometimes called "early agile," is incomplete but not fake. Over time, firms aim to master all three laws and achieve strategic agility.
Different companies follow different paths; for example, Microsoft began with small agile teams about a decade ago and only spread the practice organization‑wide after Satya Nadella became CEO.
Amazon embraced a customer‑obsessed mindset from its IPO in 1997, adopting the "two‑pizza team" model around 2002, illustrating a different early‑agile trajectory.
5. Is Agile Only About Software Development?
The 2001 Agile Manifesto, with its four values and twelve principles, guides millions of developers, but its wording is limited to software, making it insufficient as a definition of business agility.
When agile thinking spreads to non‑technical parts of an organization, friction with slower, bureaucratic units often arises.
6. Stalled Agile Journeys
Many organizations see agile succeed in development teams but fail to gain senior‑management support, leading to conflicts between fast‑moving dev teams and slower traditional departments.
Management may eventually shut down agile initiatives, dismissing coaches and claiming "we are already agile," causing the agile journey to stall or go underground.
Without agility, companies cannot develop and adjust software quickly enough for the digital world, prompting renewed agile efforts years later.
Being "agile only for software" is not fake, but limiting agile to software shortens its lifespan due to inevitable conflicts with other departments.
7. Brand‑Driven Agile
Hundreds of agile "brands" exist, each using specific terminology to differentiate their products, creating confusion and often focusing only on the Small‑Team Law while neglecting the Customer and Network laws.
Emphasizing a single branded variant as the answer distracts from agile's core purpose: a fundamentally different way of operating as a networked organization.
8. Large‑Scale Agile Frameworks: SAFe
Scaled Agile Framework (SAFe) is a prominent "brand agile" that tries to reconcile agile teams with corporate back‑office functions, but it often re‑introduces bureaucracy and marginalizes the customer.
SAFe can undermine true agility by allowing management to claim agility while preserving existing hierarchical processes.
9. Agile Lite
"Agile‑lite" appears in HR contexts, applying agile tools without the underlying mindset, resulting in ritualistic practices lacking genuine agility.
10. Closing Thoughts
As the saying goes, "There are a thousand DevOps, each solving a different problem." If a user says the approach solved their problem, then it was the right choice.
Continuous Delivery 2.0
Tech and case studies on organizational management, team management, and engineering efficiency
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.