Few terms generate as much debate in c-suites right now as Agile and agility. It seems that every week I find myself talking about this concept with an executive who wants to understand what these terms mean and what real value they can bring to a global organization. In some part this level of interest is because from Accenture to McKinsey, the best management consulting firms are doing their best to take what had been an obscure software term and make it into a c-level management imperative. These are just some of the recent attempts to give advice on an often-confusing subject:
- McKinsey: The five trademarks of agile organizations
- Accenture: FORMULA WON: A NEW WAY TO MEASURE CORPORATE COMPETITIVENESS
- Bain: HOW AGILE IS YOUR ORGANIZATION?
All this consulting activity raises two questions for me: what exactly are Agile and agility and what value, if any, do they have for today’s global corporate leaders? Before I address these questions, I’ll provide some background for those not familiar with the origins of the Agile revolution.
Agile, as we think of it today, got its start not in the halls of a famous university or think tank but, strangely enough, at a ski resort in the Wasatch mountains of Utah. It was at the Snowbird lodge that seventeen distinguished programmers got together to try to improve the way in which software was created. Not surprisingly, all the participants were men (none of the women invited accepted, since, as the story goes, they thought the meeting was going to be a waste of time).
Once at Snowbird, the programmers vented their frustration on an approach known as “Waterfall” development. In this methodology, in use for decades (and still in use today), software was built sequentially, following a very detailed project plan. In other words, teams built software programs much the way workers in an assembly line build cars: one part at a time, with all the pieces adding up to one coherent pre-designed whole that is not altered or rethought along the production line.
The Waterfall approach worked (and still works) well in some cases but not in others. Indeed, when it failed it did so with spectacular consequences. As a 2017 Atlantic piece on the history of Agile noted:
“People would come up with detailed lists of what tasks should be done, in what order, who should do them, [and] what the deliverables should be,” remembers Martin Fowler, the chief scientist at ThoughtWorks, who attended the Snowbird meet-up. “The variation between one software and another project is so large that you can’t really plot things out in advance like that.” In some cases, the documentation itself grew to be unwieldy. A few of the people I spoke with shared horror stories: an entire bookshelf’s worth of requirements in binders or an 800-page document that had been translated across three different languages.
Another Snowbird participant, Ken Schwaber—the cofounder of Scrum and founder of Scrum.org—says Waterfall “literally ruined our profession.” “It made it so people were viewed as resources rather than valuable participants.” With so much planning done upfront, employees became a mere cog in the wheel.
To the engineers at Snowbird, the waterfall approach was not just a bad way of creating software, it was a dehumanizing phenomenon—one that treated coders as interchangeable cogs in a machine. Indeed, it was as much the demoralizing aspects of Waterfall development as the technical drawbacks that inspired the group assembled to define a new way of working. So it was that after three days of discussion and debate, they produced a manifesto for a new way of thinking about software development.
They described their model, interestingly enough, as a set of preferences, that spoke not just to technology but to the humans who made it. Their new approach valued:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
From this core philosophy, the attendees derived twelve supporting principles that tried to provide guidance on how software should be created (e.g., “Deliver working software frequently, from a couple of weeks to a couple of months” and “Business people and developers must work together daily throughout the project.”)
When they were finished, the group debated a name for their creation. “Lightweight” was one label they used during the meeting, but to some that came across as a negative term. In the end, they went with “Agile” (“Adaptive” was the other finalist). As a last step, they, posted their ideas on a crude web site and invited anyone who agreed with their ideas to add their name to the manifesto.
An Agile process. Image: Computer History Museum
As the Atlantic piece also notes, no one was prepared for the reaction their work would receive: “We put that thing up, and it just exploded,” says Dave “PragDave” Thomas, a coauthor of The Pragmatic Programmer and an adjunct professor at Southern Methodist University. “That site was actually a focal point, if you’d like, for people who want to say, ‘Yes, I agree with this.’ And I think that’s one of the reasons it took off.”
From that first day until when signing closed in 2016, twenty-thousand people added their names to those of the original seventeen. Indeed, in the fifteen years that had passed, the software development world had embraced Agile so completely that it become not just a dominant technical methodology but a way of running a startup and even of seeing the world. Indeed, it was the success of Agile-based management within the most successful startups that propelled the term out of the technology and venture capital domains and into the lexicon of global corporations. Stunned by the success of the most successful and disruptive startups, boards, CEOs, academics and consultants wanted to know not just what these disruptors did but how they did it.
Looking back, for me the most relevant point to take away from the origin of agile is that from its inception in 2001 agile was both a philosophy (the core values) and a way of working (the twelve principles). To this day many executives who are fans of Agile and agility talk about the “Agile mindset” as something distinct from Agile “methods,” with some executives placing greater importance on the former and some on the latter. Indeed, I think that this duality is a major reason that many management thinkers still struggle with even a basic definition of “organizational agility.” Even McKinsey, which is usually clear-headed about management ideas, has a hard time with the topic. This explanation from McKinsey’s Wouter Agina about what makes agility work is a good example of the difficulty of making specific claims about what organizational agility is or how to do it:
A question on the mind of many is what they can do to become more agile. There are three domains in the operating model that we have found are very important for that: process, structure, and governance.
Governance, for us, is about decision making. We need speed in decision making, but why do we need stability? Well, we need stability to make good decisions but also to get fast decision making. What has to be stable, for instance, is that you have empowered the people lower down in your organization with a clear mandate that they can take the decisions that they should be taking close to the customer. That has to be clear and it has to be a stable element of your operating model.
- More management options over fewer
- Faster execution (of any selected option) over slower
- Working (imperfect) solutions over theoretical (perfect) designs
- Responding to markets over following a set strategy
Let’s take a simple example to illustrate my definition. Having two suppliers providing the same critical material creates satisfies the first condition. Being able to quickly move buying from one supplier to the other satisfies the second condition. Put together, this sourcing tactic makes the buying organization more agile than a counterpart that does not share that optionality. Now, as any CPO will tell you, acquiring and maintaining this extra agility requires investment, so agility, in my view, comes at a direct cost (something that’s missing from many discussion on the topic). It’s a cost worth bearing in many circumstances, where the value of agility exceeds the cost of attaining it.
Another example of agility at work is the increasing use of contract workers and (sometimes) proprietary “gig economy” platforms. There is a significant investment required to be able to stand up and use effectively a gig worker model. However, the benefits created by having on-demand workers with a variety of profiles that will work in a task-based model is significant for many companies. For them, expanding the option set of laborers and being able to move seamlessly from one profile to the next is specific agility enhancement that makes strong business sense.
For many readers, my definition of organizational agility will recall options theory, which is no accident. For me, an agile organization simply has more usable and efficient options than less agile ones, and the organizations that buy the best and most useful organizational options are those that get the most value from their agility investments.
Returning to the original Agile manifesto, we can see similar thinking in the group that put it together. Their problem with Waterfall development was its rigidity, its determinism, its assumption that a course once set was almost inevitable. In other words, waterfall development eliminated options at the start of a project, usually in search of minimizing development costs. The Agile way worked in short bursts, constantly striving to maximize options along a development project. That is the basic nature of agility in any context: the efficient investment in optionality to maximize the probability of success.
In thinking about large corporate organizations, agility can take many forms, including outsourcing, postponement in product design, the use of gig workers as well as reconfigurable supply chains. What all these tactics have in common is a strategic mindset that understands optionality and a management team that (a) looks for expanded possibilities at all times and (b) creates organizational structures that can select and execute the best given option faster than the competition. Again, agility is more than expensive than rigidity, but when understood and deployed correctly, especially in today’s uncertain world, it’s an organizational characteristic worth understanding, considering and in many cases deploying inside the best companies.
Of course, no management practice is without flaws and detractors, and Agile/agility have their share. No one would argue that one should make nuclear power plants with Agile, nor should we develop regulatory structures that are constantly shifting for the sake of “regulatory agility.” Indeed, perhaps the most valid complaint about Agile, even among executives who support it, is that Agile has become extremely commercialized (with consultants and advisors offering vague or even conflicting advice) and that agility is sometimes used as a new label for old behavior. As one CDO friend said to me recently, “sometimes what people claim is Agile is really ‘wagile,’ i.e., the same old waterfall approach masquerading as Agile.”
Ironically, while as the idea of Agile gains in importance in management circles, some of Agile’s founders have started to lament how their concepts have evolved. Dave Thomas, one of the seventeen Snowbird alumni, wrote in 2014 about what he sees as the problems with today’s version of Agile:
Once the Manifesto became popular, the word agile became a magnet for anyone with points to espouse, hours to bill, or products to sell. It became a marketing term, coopted to improve sales in the same way that words such as eco and natural are. A word that is abused in this way becomes useless—it stops having meaning as it transitions into a brand.
Jon Kern, another Agile founder agrees. “You get a lot of people, just snake-oil salesmen—folks that say they’re doing Agile when it’s Agile in name only,” he told The Atlantic. Kern compares Agile to yoga, arguing his practice is personal and that he doesn’t “try to tell other people how to practice.” That same Atlantic piece also noted that “Agile is a philosophy, not a set of business practices. The four bullets outline a way of thinking, a framework for prioritizing all the complicated parts of a project. They don’t tell you what software to buy or how to hold your daily team meeting.”
All the debates surrounding Agile and agility certainly can lead to confusion, and even exhaustion, with the topic for many executives. While this frustration is understandable, smart managers should not let the noise and hype obscure the real value that comes from adopting both the Agile mindset and agility when understood as investments in efficient optionality. In short, when treated as a vague mantra, organizational agility can be easily (and rightly) dismissed. However, when understood as a serious discipline that correctly expands management optionality when needed, the term should be understood and adopted across the c-suite.