understanding faux agile

Is Fake Agile is the new Six Sigma? “Agile is eating the world” surveys by Deloitte and McKinsey today show that more than 90% of senior executives give high priority to becoming agile, while less than 10% see their firm as currently highly agile. The gap between aspiration and reality has led to a vast number of managers, consultants, and coaches claiming to be agile and offering to help firms become agile. Most instances of supposedly agile management have as much relation to real Agile as someone wearing flamenco costumes and talking about flamenco, without having mastered flamenco dance steps or displaying a feel or flair for flamenco music.
 
Defining an agile organization
Agile is first and foremost an organizational mindset that manifests itself in 3 main components, which include both operational agility (making the existing business better) and strategic agility (generating new products and services and so bringing in new customers). 
 

• The law of the customer: an obsession with delivering value to customers as the be-all and end-all of the organization.
• The law of the small team: a presumption that all work be carried out by small self -organizing teams, working in short cycles and focused on delivering value to customers—and
• The law of the network: a continuing effort to obliterate bureaucracy and top-down hierarchy so that the firm operates as an interacting network of teams, all focused on working together to deliver increasing value to customers.

 
Agile Without The Labels
The definition recognizes that some of the most successful agile implementations use home-grown terminology. In fact, these firms don’t even call themselves agile and shy away from standard agile vocabulary. Consider that most of the largest and fastest-growing firms on the planet—Amazon, Apple, Facebook, Google, Netflix, and Microsoft—are recognizably agile in much of what they do, even though they don’t use any of the standard agile vocabulary. Their business agility is an important reason why they have become the most valuable firms in the world.
 
Early-Stage Agile
Agile is a journey and mastering the various facets of agile takes time and skill. When a firm is in the early stages of the agile journey, one might call it “early-stage agile”, or agile that is incomplete. If the journey proceeds well, then the firm will gradually master all the three Laws of Agile as well as strategic agility. The journey never ends: firms go on finding new ways to become ever more agile.
 
The sequence of the journeys of firms can differ. For instance, Microsoft began with small agile teams at the end of the 2000s (Vista was a great example of a huge waterfall failure). It continued experimenting on a steadily growing scale in the period 2008-2014. It was only after this period when Satya Nadella became Microsoft’s CEO that the approach began to spread to the whole organization and one could think of Microsoft as a firm that was beginning to exemplify business agility. 
 
By contrast, Amazon embraced an obsession with the customer from the outset of its stock market debut in 1997, with an explicit commitment to devote itself to giving primacy to generating customer value and achieving market dominance. It was only five years later—around 2002—that Amazon embraced “two-pizza teams” and began to link the teams together in a network rather than a top-down hierarchy. 
 
Agile in name only
In order to truly understand whether a firm is agile or not, it’s more revealing to look beyond what firms are saying and look at how they are operating. Many firms are implementing the ceremonies and processes of “agile” but without the agile mindset. In other words, they are doing agile without being agile. 
 
As an example, Wal-Mart in the period before 2016 had many supposedly agile teams but was not getting much benefit from the effort. The teams were executing agile processes, but managers lacked the agile mindset. It was only in 2016 when Walmart bought Jet.com and recruited Marc Lore to lead the Wal-Mart effort that things started “moving at the speed of a start-up" and benefits started to flow. Within a year, Wal-Mart had massively expanded the products available online, was offering free two-day delivery without customers having to pay for membership of Amazon’s Prime and deploying its stores as fulfillment centers. Better financial results soon followed.
 
Agile for software only
For many agilists, the Manifesto for Agile Software Development of 2001 is the North Star of the agile movement. Its 4 values and 12 principles have been a guide to hundreds of thousands of software developers interested in “uncovering better ways of developing software by doing it and helping others do it.”
 
The Agile Manifesto is often also the starting point for those seeking to spread the message of agile beyond software development and so also becomes an important reference for business agility. A gathering in 2011 of 10 of the original signatories of Manifesto showed no inclination to change a single word of the Manifesto or expand it to go beyond software. The Manifesto now has the status of an iconic historical document, akin to Magna Carta or The Declaration of Independence. Although these historical documents do not say the last word on their respective subjects today, they remain as permanent beacons for those who come afterward.
 
Yet the fact that the wording of the Manifesto is limited to software development makes it less than adequate as a definition of business agility. In fairness to the drafters of the Manifesto, they weren’t thinking of business agility. Their preoccupation was more about making the world safe for software developers.
 
But restricting agile to software development becomes a problem. When agile thinking takes over software development in a traditionally managed organization, it inevitably begins to run into conflict with other parts of the organization that are moving less rapidly and less flexibly.

Stalled Agile Journeys
We see more and more examples where Agile becomes an increasingly important dynamic of the software development group but ultimately fails to win support from the top management. Initially, the fact that software development is operating in an agile fashion, while the rest of the organization is functioning much more slowly and inflexibly in a traditional bureaucratic fashion, isn’t too much of problem: the management is happy to see the faster production of software.
 
But as the agile spreads through the organization, the tension between the two different modes of operation can start to become a source of tension.  It’s not that “agile for software only” is fake agile. It’s not. It’s just that when agile management is limited to software only, it has a limited life expectancy. Conflicts with the rest of the organization are inevitable. Agile and bureaucracy are mutually incompatible: in the end, only one will survive.
 
Branded Agile
There is also agile in the sense of the various agile brands promoted by consultants and trainers, of which there are hundreds. And often there is an insistence on using particular terms and specific named processes, which are defined in this way for the commercial purpose of distinguishing their offering from competing consultants and trainers.
 
Many of them focus on the implementation of the second law of agile: the law of the small team, because it is the easiest thing to train. They often give zero attention to the laws of the customer and the law of the network.
 
It’s not that small teams aren’t important. It is crucial. But it’s not enough. Unless the firm moves on to implement the other two laws, any gains from agile teams are likely to evaporate and be swallowed up by the bureaucracy.
 
The other problem is that an emphasis on any particular variant of Agile as “the answer” and the insistence on using the particular branded labels, processes and terminology, tends to distract attention from the underlying substance of agile as a fundamentally different way of running an organization, a new kind of management, not simply the wares of a particular consultant firm.
 
Scaling Frameworks: SAFe
A particularly unfortunate form of “branded Agile” concerns scaling frameworks. These are schemes aimed at helping firms that have some teams implementing Agile practices and want to resolve the tension between the agile teams and the back-office systems of the organization (such as strategy, planning, budget, HR, Finance) which are typically monolithic and bureaucratic.
 
The challenge is usually presented as one of “scaling up agile.” The issue here is that if the firm is thinking about " scaling up agile", it is already on the wrong track. The challenge of genuine agile is how to descale big monolithic, internally focused systems into tasks that can be run by small self-managing customer-focused teams.
 
A particularly worrying variant is the Scaled Agile Framework or SAFe. Essentially this is codified bureaucracy, in which the customer is almost totally absent. It is now pervasive in large firms because it gives the management a mandate to call themselves agile and keep doing what they have always done. Essentially it subordinates the agile teams to the bureaucracy, rather than doing what is necessary to achieve business agility, namely, namely, transform the big monolithic internally-focused systems into arrangements where the budgets, HR, Finance and so on are flexible and externally focused in support the Agile teams in operations. The insignificant role of the customer in the chart above is indicative of the problem. SAFe is the epitome of faux agile. 

Without an Agile mindset, Agile remains an inert, lifeless set of ceremonies

---

Let me know what you think! 
DM me @philippemora on IG and Twitter
​My name's phil mora and I blog about the things I love: fitness, hacking work, tech and anything holistic. 
​
Head of Digital Product
thinker, doer, designer, coder, leader