Don’t Disrupt Agile. Drop it!

It's time to leave "Agile" behind and embrace the Post-agile era.

What Agile Hath Wrought

Much has transpired in the 19 years since the original publication of the “Manifesto for Agile Software Development.”1 After nearly two decades, the word “Agile” now saturates conversations in the software industry and has even overflowed into the popular business vernacular. These days, nearly every company seeks recognition for its ability to “do Agile” in its workplace. Surely such efforts reflect noble intentions. Yet software engineers share an abundance of stories regarding the challenges and frustrations of enduring the real consequences of such intentions. Countless tales tell of processes and practices that have resulted in greatly reduced agility and ever-simmering frustration, contrary to stated goals.

As words enter the general vocabulary, their use and meaning morph over time. Sometimes we hardly notice the difference, even in the wake of significant impact from the change. While ignored by or hidden from many, such alterations of meaning have occurred in reference to the word “Agile.”

Targeting agility as a goal for software teams has diminished over time, being replaced instead with efforts to "do Agile" by following prescribed, formulaic practices.

The title of the manifesto that catalyzed the movement employed “Agile” as an adjective. Over time, however, “Agile” has shifted into common use as a noun. This semantic shift has profoundly impacted the way software engineers, development managers, and the industry in general understand, experience, and influence the trajectory of the movement. Targeting agility as a goal for software teams has diminished over time, being replaced instead with efforts to “do Agile” by following prescribed, formulaic practices.

Successful businesses recognize the need to adapt in the face of market competition, industry complexity, and the relentless turbulence of the technology landscape. They do not measure success by conformity to a set of methodologies or practices, regardless of intriguing names or prestigious sounding certifications. The hallmarks of adaptability live and breathe within software teams that deliver real value to customers efficiently, effectively, frequently, and predictably. With that being said, the software industry should collectively pause and reflect on the good, the bad, and the ugly in the history of misguided attempts to “do Agile.” The time is long overdue for an industry-wide reconsideration of Agile and what it hath wrought.

As a case in point, while recently surfing the Web, a deliciously insidious example of the bad and ugly side of Agile slapped me across the face. There before my eyes, in an impossible-to-ignore 52-pixel “Extrabold” font,2 stood the tantalizing headline, “Become an Agile expert for just $39.”3 Expertise on the cheap? What luck! In fairness, the courses for sale appear to require actual study rather than providing a certificate to those who simply fork over the dollars. But “expert”? In what rational universe does mere completion of a course make one an expert, regardless of price paid or time spent in a class? Can anyone believe such snake oil can actually deliver on its false promises? I wish I could say no, but history tells the real story. These promises exist and persist for the simple reason that individuals and organizations want to believe them, and they affirm their status as true believers by forking over real time and money.

What’s in a Name?

Even some of the original signatories of the “Manifesto for Agile Software Development” have distanced themselves from what Agile has become. For example, Dave Thomas penned an essay in March 2014 entitled “Agile is Dead (Long Live Agility).”4 He lamented at that time that “the word ‘Agile’ has been subverted to the point where it is effectively meaningless.” He also pointed out that employing the word “Agile” as a noun is “just plain wrong.” While I believe I came to the same conclusion independently, the possibility exists that I came across Thomas’s essay six years ago and the idea burrowed into my subconscious, only to emerge at the opportune moment.

Ironically, even the progenitors of Agile jumped overboard years ago. In the meantime, the string ensemble plays “Nearer, My God, to Thee”5 as the expansive sea of remaining passengers hum along while the ship sinks ever deeper. The meaning has changed, but the haunting melody lingers.

Changes in language surely affect our perception of reality. Notice the subtle shift in language when people speak of the Agile Manifesto. The original title, “Manifesto for Agile Software Development,” emphasizes “Software Development,” with “Agile” functioning as a modifier describing a way of approaching software development. Shortening the title has the effect of radically altering the meaning, shifting focus to the word “Agile” and employing it as a noun. Can this change alone account for what Agile has become? Hardly, but meaning matters and our perception of meaning becomes our reality.

Humans have an innate tendency to treat a tool as the tool. Given the tool at our disposal, we convince ourselves it must be the right one or, at least, the best we might conceive of at the moment.

Humans have an innate tendency to treat a tool as the tool. Given the tool at our disposal, we convince ourselves it must be the right one or, at least, the best we might conceive of at the moment.6 Agile as a noun has filled that role marvelously, taking a prestigious (notorious?) position as the de facto goal toward which all software teams must strive. Contrarians observe such overwhelming consensus, unmoored from a sense of empirical rigor, and find themselves duty bound to poke, prod, and ask taboo, subversive questions.

In the 1960s, one of Warren Buffet’s clients famously quipped, “No one gets fired for going with IBM.”7 Today’s catchphrase would read, “No one gets fired for going with Agile,” or whatever other Agile-type methodology you’d like to throw in there — Scrum 8 and Scaled Agile Framework (SAFe)9 being particularly nefarious candidates.

If you have read this far, you may wonder about the value of spending so much time exploring what amounts to definitions and semantics. They matter greatly if you care about meaning. The grey wizard Gandalf spoke aptly regarding such things in words penned for him by linguistic luminary J.R.R. Tolkien:

“Good Morning!” said Bilbo …

“Do you wish me a good morning, or mean that it is a good morning whether I want it or not; or that you feel good this morning; or that it is a morning to be good on?”10

Consider as well, as Phil Karlton famously cracked, “There are only two hard things in computer science: cache invalidation and naming things.”11 Difficulty in naming things must not prevent us from doing the hard work. So let’s drive the point home further by exploring the meaning of the word itself. Yes, buckle up; we’re in for a bit more definitions and semantics.

What Does “Agile” Mean to You?

According to the Oxford English Dictionary, “agile” may be defined in the following ways:12

(1) Able to move quickly and easily.

(1.1) Able to think and understand quickly.

(2) Relating to or denoting a method of project management, used especially for software development, that is characterized by the division of tasks into short phases of work and frequent reassessment and adaptation of plans.

The first definition describes attributes most software development teams would likely find desirable. Yet typically the necessary efforts for sustaining an ability to move quickly and easily, and to think and understand quickly, remain unconsidered.

Other important questions often remain unexplored as well: How can a team evaluate and measure such attributes in its environment? How exactly does a team achieve such characteristics and maintain them over a significant period of time? True skeptics and free thinkers may even add more to the list of crucial questions: How do team members define and understand the words “quickly,” “easily,” and “understand” in their context? Can we think of times when such characteristics should not take top priority? What risks, cost increases, or additional complexities might arise if these attributes take precedence above all others the majority of the time? An organization or team seeking agility should ask these and other probing questions about what it actually hopes to attain and how it would measure such attainment, or lack thereof.

Now for the second definition. Another irony reveals itself in that one may jump to the second definition while completely neglecting the first! Frequent reassessments and adaptations provide no actual guarantee of agility. In fact, such efforts may utterly fail to increase, or even maintain, agility. No doubt, value and benefit often come from breaking larger tasks into smaller phases. Once again, though, important questions often go unasked. What tools, techniques, or processes provide helpful guidance for dividing tasks into short phases? Are they working as intended? What might go wrong if such a process of decomposition, contrary to stated desires, instead hampers agility? How would the organization or team detect or measure such an outcome?

Of course, words cannot bear the burden for their usage, the responsibility for which lies with the wielders of said words. Yet the second definition leaves the door wide open to closed mindedness, zealotry, and a lack of empirical measurement. Such a description adequately sums up the state of attempts to “do Agile” in the software industry. “Measuring agility” often degenerates into conformity to certain ceremonies and practices. Conversations peppered with frequent references to trainings, frameworks, methodologies, and manifestos substitute for observation, experimentation, adaptation, and critical thinking. For example, ask some random software engineers whether their team’s Agile process serves them, or if, instead, they have ended up serving the process (and, by extension, serving the purposes of managers and “masters” maintaining the ceremony). All this frequently occurs as a substitute for what really matters: the ability of teams to reliably and predictably create value and respond efficiently and effectively to inevitable changes in requirements.

As a project manager or entrepreneur in the software industry, if forced to choose, which would you prefer? “Short phases of work with frequent reassessment and adaptation of plans”? Or the ability to “move quickly and easily” and “think and understand quickly”? It’s a trick question, and, if I were a betting man, I’d wager you fell for it.

Check Your Thinking

Notable theoretical physicist Richard P. Feynman eloquently described the risks inherent in placing excessive trust in our intuitions and formulations:

The first principle is that you must not fool yourself — and you are the easiest person to fool.13

Surely Mr. Feynman is not joking.14 Humans excel at seeking shortcuts and quick solutions. From an evolutionary standpoint, this instinct has served us well. But, from a long-term planning and project management perspective, we follow such instincts at our ongoing and compounding peril. Promises of quick wins, easy training, cheap expertise, and magic processes appeal to our baser instincts. But we can sense what our elders have reminded us of all along: there’s no such thing as a free lunch. Software architect Juval Löwy roots the basis of this wisdom in a fundamental principle of the universe: the first law of thermodynamics. In his book Righting Software, Löwy phrases it this way: “You cannot add value without sweating.”15

Our industry has traveled long down the wrong road. Logical and forward-thinking action beckons us: the time has come to get on a different road.

We stand by and watch, or even participate arduously, as copious amounts of effort and sweat pour into various rituals and ceremonies prescribed by the high priests of Agile. Unfortunately, even monumental efforts expended on the wrong thing cannot provide value. The effort and sweat must flow toward productive ends for value to increase. Our industry has traveled long down the wrong road. Logical and forward-thinking action beckons us: the time has come to get on a different road.

As Thomas suggested, the word “Agile” had already outlived its utility years ago. Rather than disrupting Agile, we should move on, simply ignoring it until the fanfare dissipates. Of course, the snake oil peddlers can always discover new snake oil to foist on the unsuspecting or new ways to twist words and concepts to suit their profiteering purposes. In response, we can tie ourselves to the mast and avoid the siren songs promising cheap expertise and promoting dangerous shortcuts.

A final and exquisite irony exists to be discovered by mining the Internet domain where this morass finds its origin. If you look closely, you will find an understated hyperlink at agilemanifesto.org that reads “About the Manifesto.” You will then discover on this page a 14-paragraph summary of the history behind the “Manifesto for Agile Software Development.” Written by Cutter Consortium Fellow Emeritus Jim Highsmith, one of the original signatories, the written history terminates with an intriguing expression:

We hope that our work together as the Agile Alliance helps others in our profession to think….16

At the end of an obscure page on a highly cited site, we find the only advice you really need. And you never needed permission from anyone for this advice to apply to you.

The Ultimate Disruption

Drop the “stone tablets” written in manifesto form. Forget the alliance, the methodologies, the cottage industry, and the cargo cults. Ultimately, I have one basic and fundamental encouragement for you, dear reader, as you consider whether a need exists for a disruption of Agile.

Don’t disrupt Agile. Drop it and think for yourself.

Why rely on a manifesto?17 Why look to words written down by others based on their intuition and experience, which may or may not apply to your circumstances and situation? Why take the opinions and experiences of others at face value without a critical eye and an inquisitive mind?

I present no new manifesto. I offer no silver bullet methodology. I have no magic formula or perfect set of values, qualities, principles, and certifications to sell you. I could describe in great detail what matters most to me as a software architect and industry veteran: repeatability, reversibility, rigor, and the relentless, even ruthless containment of change whenever and wherever it reveals itself. It would please me greatly to explore such topics with you and your colleagues. But in the end, I repeat my one encouragement and exhortation to you.

Don’t disrupt Agile. Drop it and think for yourself. Don’t seek to uproot, transform, improve, reclaim, redeem, or “do Agile.” Instead, disrupt your own processes in the relentless pursuit of continuous improvement. Think for yourself and invite others to join you in the endeavor. You may surprise yourself at the level of adaptability and value creation you can achieve.

This paper first appeared in The Cutter Business Technology Journal, Vol. 33, no. 4, 2020, “Don’t Disrupt Agile. Drop It.”

Want to discuss these ideas in more detail? Send me a tweet, or find me on any of the social media platforms at the bottom of this page.

Footnotes

1: Beck, Kent, et al. "Manifesto for Agile Software Development." Agilemanifesto.org, 2001.

2: Yes, I checked with Chrome DevTools.

3: "Become an Agile Expert for Just $39." Android Authority, 3 March 2020.

4: Thomas, Dave. "Agile is Dead (Long Live Agility)." The Coding Gnome, 4 March 2014.

5: "Nearer, My God, to Thee." Wikipedia, 2020.

6: "Law of the Instrument." Wikipedia, 2020.

7: The Conservative Income Investor. "5 Investment Tips from the Legendary Peter Lynch." Seeking Alpha, 28 November 2011.

8: "Welcome to the Home of Scrum." Scrum.org, 2020.

9: "SAFe® for Lean Enterprises 5.0." Scaled Agile, Inc., 2020.

10: Tolkien, J.R.R. The Hobbit, or There and Back Again. George Allen & Unwin, 1937.

11: Fowler, Martin. "TwoHardThings." martinFowler.com, 14 July 2009.

12: "Agile." Lexico, 2020.

13: Feynman, Richard P. "Cargo Cult Science." Caltech, 1974.

14: "Surely You’re Joking, Mr. Feynman!" Wikipedia, 2020.

15: Löwy, Juval. Righting Software. Addison-Wesley Professional, 2019.

16: Highsmith, Jim. "History: The Agile Manifesto." Agilemanifesto.org, 2001.

17: I must confess that I myself have previously bought into the value of manifestos, a sin for which I intend to spend the rest of my career paying penance.