Article

2020: The Year That Agile Gets Found Out

Posted February 13, 2020 in Business Agility & Software Engineering Excellence, Business Technology & Digital Transformation Strategies Cutter Business Technology Journal
cracksinsurface

CUTTER BUSINESS TECHNOLOGY JOURNAL  VOL. 33, NO. 1
  

Barry M. O’Reilly questions the validity of Agile practices. According to him, “The Agile movement’s focus on process as the solution to uncertainty has allowed technical quality to fall by the wayside, bringing even more doubt as to the ability of Agile to actually deliver.” O’Reilly contends that “only the people working directly with a problem can decide on tools and process in the evolving picture of their project, and their individual talents — not adherence to or avoidance of certain ideas — guide whether they achieve success or not.” What is your opinion on Agile versus talent, or is it Agile and talent?

The bed of Procrustes1 is a Greek legend that describes a giant — Procustes — who had a bed of a certain size. When entertaining guests, the giant would either stretch them or break off their limbs to make them fit the bed.

As the original creators of the Agile Manifesto recoil in horror at the giant they have created, it is easy to see why the procrustean bed is an apt metaphor.2, 3 As Agile becomes ever more vapid (and meaningless), it becomes possible to break the limbs of any practice to make it fit the Agile bed, until the behaviors and the practices described as Agile begin to resemble the very practices the original movement sought to be rid of. “Four legs good, two legs better,” says the Agile industrial com­plex, as it totters around unconvincingly selling two-day certification courses.4

For those who previously had no problem in asking why the Agile emperor was not only naked but also deranged, 2020 will bring some satisfaction and a changing of the guard. The communist argument — that communism absolutely will work if only it is done right — will no longer hold for Agile as many become acutely aware that the meaningless, certification-driven Agile industrial complex is made up of an increasing percentage of “dark” or ‘”faux” Agile, or Agile “in name only,” practices. “True” Agile unfortunately remains a Procrustean idea, only appearing where things have gone well, with dark Agile suspiciously seeming to occur only in failing projects.5 And there are many failing projects, if we are to believe the few sources of empirical evidence, such as Chris Porter’s “An Agile Agenda6 and the Standish Group’s CHAOS reports.7

As Agile makes its way to the boardroom, it will be harder and harder to hide behind procrustean decla­rations of what is and isn’t Agile, as the key to understanding success or failure will cease to be anecdotal and start to focus on cold, hard results. Cynicism will grow, as with all trends, and answers will need to be forthcoming.

What will change in 2020, however, is our perception of the problem. Developers have long seen change as the enemy, the reason for requirements churn, and something to be either fought, predicted, or embraced. The last few years have seen some digging deeper than the Agile Manifesto’s aphorisms, trying to understand change instead of mastering it via process or prediction. In truth, change represents how developers are forced to view the world because this is traditionally how problems are presented to them. Yet, most of what is presented as change to developers is a result of uncertainty in the business world, and the Agile sticky plaster of process, Post-it Notes, and certifica­tions pretends to solve the problem of change without ever tackling the much more difficult question of uncer­tainty. Uncertainty is left up to the business, which bizarrely now looks to Agile methods to solve the problem it should have been solving all along.

The reason for change is because businesses present problems as requirements, requirements that are half-truths elaborated in the shadows of uncertainty, and as the truth reveals itself, changing requirements become a second-order effect. Agile therefore fixates on stemming the bleeding without ever stitching the wound, eventually allowing the patient to bleed to death, albeit with working software every two weeks. The truth is that the only true way to cope in modern business environments is to embrace not change, but the uncertain. Agile is, and has been, a response to uncertainty, but the current practices around Agile at scale involve selling certainty to executives. Selling certainty in an uncertain environment is an attractive pitch, but it can be done only so many times. The Agile movement’s focus on process as the solution to uncertainty has allowed technical quality to fall by the wayside, bringing even more doubt as to the ability of Agile to actually deliver. As Agile practices crash and burn, proponents gather to complain about the reasons it’s not working, usually focused on the new favorite target of hierarchical management practices. Such excuses will not be endured for long. The Agile move­ment has served its purpose as a vehicle for driving the needs of developers frustrated by working in complex contexts that neither they nor their task givers understood, but it will soon be time to take stock, to look back at 20 years of hype and ultimately underachievement.

Standish CHAOS reports show that the number of successful projects has barely shifted since the publishing of the Agile Manifesto.8 Although it shows much higher rates of success in Agile than in waterfall projects, the overall numbers have not shifted enough to suggest that anything has changed significantly, which suggests that the choice of methodology is not the driver of results or that successful teams had already figured things out before the Agile Manifesto. This leads to the conclusion that agility and quality are products of the team, not of the process. The same teams that have had success with Agile would probably have had success if constrained to waterfall processes — but these ideas are dangerous, since they suggest that developer talent is what survives uncertainty and drives results, and no one can sell developer talent with the same margins as certification programs based on simplistic processes and truisms.

In 2020, Agile will reach fever pitch, as it moves on from software development to penetrate the nightmares of naive executives. There will be more hype, more noise, and more religion. But the dam has already sprung a leak. Indeed, the IT industry is starting to embrace the Cynefin framework,9 which leads to the obvious conclusion that while the Agile Manifesto had the diagnosis right in reacting to the changes caused by underlying uncertainty, it only ever guessed at a potential cure. It will become increasingly obvious that few Agile methodologies stand any form of empirical test, and the dam will eventually break.

Agile will never officially die, of course. Its procrustean bed will always fit everyone; complexity approaches will be absorbed and older methodologies will be quietly swept under the rug, as Agile changes to become something else entirely, something where technical quality, developer talent, and understanding of complexity become paramount to success.

This is a hard argument to make. So convinced are the followers of today’s version of Agile that their arguments seem to them obvious truths, anecdotes pass for data, and the loose relationship between cause and effect is always interpreted in favor of a set of fluid principles in a manifesto that no one really seems able to make concrete.

In a world where uncertainty is the rule, there cannot be a process, a set time for meetings, or an exact way to design, break down work, put Post-it Notes on the wall, or handle requirements and change. Only the people working directly with a problem can decide on tools and process in the evolving picture of their project, and their individual talents — not adherence to or avoidance of certain ideas — guide whether they achieve success or not. In 2020, the role of uncertainty and talent will become clear. The proponents of Agile will claim that they always meant to emphasize uncertainty and talent, and some of them truly did, but the Industrial Agile that has evolved beyond their control needs to be put to bed — in whatever size bed we need.

References

1Procrustes.” Wikipedia, 2020.

2Fowler, Martin. ”The State of Agile Software in 2018.” martinFowler.com, 25 August 2019.

3Jeffries, Ron. “Developers Should Abandon Agile.” RonJeffries.com, 10 May 2018.

4Important Quotations Explained: Animal Farm — George Orwell.” SparkNotes, 2020.

5Agile is a Procrustean concept, in that it is made to fit the narrative of success; those Agile projects that fail and don’t help the narrative are rejected as not being true Agile.

6Porter, Chris. “An Agile Agenda: How CIOs Can Navigate the Post-Agile Era.” 6Point6 Technology Services, April 2017.

7Sample Research.” The Standish Group International, Inc., 2020.

8The Standish Group International (see 7).

9Snowden, David J., and Mary E. Boone. “A Leader’s Framework for Decision Making.” Harvard Business Review, November 2007.


2020 Trends and Predictions

Explore the technologies, strategies, and business models that will have the most relevance this year and beyond, according to eight Cutter thought leaders. You might be modifying your strategic game-plan after reading this thought-provoking issue!

Download the complete issue of 2020 Trends and Predictions here: Cutter Members and Subscribers access here

About The Author
Barry M. O'Reilly
Barry M. O’Reilly is the founder of Black Tulip Technology and creator of Antifragile System Design. Previously, he held positions as Chief Architect for Microsoft's Western Europe practice and IDesign, IOT TAP Lead for Microsoft’s Western Europe practice, Worldwide Lead for Microsoft’s Solution Architecture Community, and startup CTO. He can be reached at barry@blacktulip.se.