In February 2001, 17 middle-aged white guys came together at a Utah resort and hammered out the Manifesto for Agile Software Development. And lo, Agile was born.

In the intervening 19 years, organizations of all sizes, from the largest enterprises to the nimblest of startups have attempted to follow the principles of Agile. Agile – spelled with the deific capital A – has informed methodologies, framed transformational business strategies and, in some quarters, achieved the highfalutin status of religious dogma.

Yet even with all this attention on the value Agile is supposed to provide, people still struggle to put it into practice. Achieving the goals of Agile has remained so elusive, in fact, that “Agile” has lost all meaning in some quarters, having become nothing but an empty marketing buzzword.

One fact that everyone can agree on, however: It has been 19 years now since the white-guy crew wrote the Manifesto – and little if anything in the technology world lasts that long. It’s no surprise, therefore, that Agile has outgrown its usefulness.

Counting Agile’s flaws

A lot has changed in those 19 years. Tools have improved, providing better automation and collaboration. The cloud has changed the landscape. And diversity is now a priority.

Indeed, Agile has evolved to take into account these changes. Proponents are also quick to point out that Agile is often misunderstood or implemented improperly. True enough. But after 19 years, you’d think we’d be past such misunderstandings.

There’s no question that Agile has become long in the tooth. “While the smart concepts made a lot of sense and resonated widely, unfortunately, their detailed Manifesto for Agile Software Development is now as crusty as the 2001 website it still lives on, yet people still quote it like the Bible,” opines Kelly Wondracek, digital content strategy manager at Anthem. “I’ve seen creative lights dimmed and inspired spirits dampen because people are forced to work within the confines of their organization’s Agile standards.”

Although agility was clearly an implied benefit of Agile, the opposite has often become the reality in practice, especially with Scrum, the most popular software methodology that follows Agile principles. “Scrum seems to have caused severe damage to some companies,” warns Ulla Sebestyén, owner of Agile consulting firm Parmatur HB. “Perhaps even the understanding of what product development really is has been lost. Over time, a rigid organizational structure has been created by introducing Scrum teams.”

Fundamentally, Agile has provided an approach for small, relatively uniform teams to crank out working software quickly, in spite of the fact that modern software teams are rarely small nor relatively uniform. Also questionable: whether cranking out working software quickly is really the top priority for the effort.

In fact, people are wondering whether Agile was misguided from the start. “The Agile Manifesto had it wrong from the beginning,” says Kurt Cagle, chief technology officer at Semantic Data Group. “It was not so much that small teams worked better because they could follow a lean and mean methodology to accomplish a project. Rather, small teams on small projects made it possible to follow a lean and mean methodology and have any luck at success.

But he noted that Agile does not always scale well. “Integration dependencies are often not tracked (or are subsumed into hierarchical stories), yet it tends to be one of the most variable aspects of any software development,” he said. “There are whole classes of projects where traditional Agile is counterproductive. Enterprise data projects, in particular, do not fit the criteria for being good Agile candidates.”

Problems scaling Agile

The sweet spot for Agile has always been small, “two-pizza” teams – but there are only so many tasks that small teams can practically accomplish. “The biggest limitation of agile methodologies is how they handle larger teams,” explains Atahan Ceylan, back-end developer at Radio Free Europe/Radio Liberty. “Agile methodologies rely heavily on communication, so large teams make it difficult to use Agile methods.”

Rising to the challenge of scaling Agile in enterprise contexts is the Scaled Agile Framework, or SAFe. Now at version 5.0, SAFe touts dozens of enterprise deployments – and yet, its detractors abound.

“[SAFe] proclaims values that seem sensible and then turns around and imposes processes and structure that stifle real agility,” opines Sean Dexter, senior user experience/product designer at Cigna. “The high-level thinkers come up with ideas, and the low-level doers execute on those ideas. Ignored is the possibility that those closest to the work might be best equipped to make decisions about it. Escaping from this misguided mindset is a core goal of Agile thinking that SAFe fails to remotely accomplish.”

Dexter is by no means a lone voice in his negative opinion of SAFe. Sebestyén weighs in as well. “What SAFe does is reinvent the line organization based on the permanent Scrum teams, introducing more middle managers in new roles and on top of that adding on a lot of bureaucracy,” Sebestyén says. “Then we are back where we started, with communication problems between the engineers and very slow-moving product development.”

Sebestyén doesn’t think the core problem is with SAFe, however. “SAFe is a solution to a symptom,” he points out. “The problem is found in Scrum.”

Getting to the heart of the problem

The way that people generally react to a discussion of Agile’s flaws is to launch into ways to address them and thus improve or update Agile for the modern world. To be sure, such efforts do move the Agile ball forward somewhat, but they’re all missing the elephant in the room.

That elephant is diversity.

Remember that 17 middle-aged white guys put together the Agile Manifesto? Although each of them was assuredly a consummate professional in his own right, the fact of the matter is that when you have a homogeneous group come up with a plan, that plan will invariably emphasize the benefits of homogeneity.

The fundamental Agile construct of the two-pizza team working together heads-down to pound out quality software fundamentally lacks the necessary context for diversity.

“Real-life doesn’t exist in neat little sprints in which tasks can be allocated in perfectly measured doses,” Anthem’s Wondracek explains. “You don’t just pause the sprint cycle for a month because it’s flu season or because Todd suddenly quit or because Shelly is taking maternity leave.… Because, according to Agile: ‘The sponsors, developers, and users should be able to maintain a constant pace indefinitely.’”

Parmatur’s Sebestyén expresses his own diversity-related concerns. “There may also be strong peer pressure on people who are deviant,” he says. “The conformational pressure also causes the group over time to lose their ability to think creatively outside the box. They will then no longer be able to work with anything else than incremental development.”

This “groupthink” problem is especially pernicious to women, who typically make up a minority of most Agile teams. “[Agile] is still extremely male-dominated,” says Laura Powers, U.S. chief executive officer at RADTAC and principal of Powered by Teams. “There are places where it’s a challenge to have your voice heard because the way we’ve done things in the past tends to be a predictor of how we’re going to do things in the future.”

Over the past 19 years, many different organizations and individuals have pushed for more diversity within Agile efforts, in spite of the fact that Agile is inherently antithetical to diversity.

“Teams who can handle complex problems and adapt rapidly to changing circumstances are in fact inclusive,” explains Anita Kirpal, global head of diversity and inclusive leadership at YSC. “These teams tend to be made up of people who are different from each other; and different not only in terms of age, gender and ethnicity, but also in terms of personality and thinking styles. Their blended viewpoints and skills work together toward a common outcome, one that adds significantly more business value.”

Nothing about such team dynamics appears in the Agile Manifesto, however – and in reality, such diversity principles have largely supplanted the original vision for how teams should work and think that the Manifesto’s creators envisioned.

When we look at today’s modern approaches to software development, including DevOps and continuous integration/continuous delivery or CI/CD, we see the heritage of Agile, to be sure. But the more that a particular organization seeks to adhere to the fundamental tenets of Agile, the more challenges they have around scalability, diversity and, in the end, business value.

Contrariwise, organizations that leave Agile behind and move onto better, more modern philosophies of how teams can best create software are where we find the greatest success overall. The obvious conclusion, therefore, is to realize that Agile has run its course and it’s time to relegate it to the dustbin of history.

Jason Bloomberg is founder and president of the digital transformation analyst firm Intellyx, which advises companies on their digital transformation initiatives and helps suppliers communicate their agility stories. None of the organizations mentioned in this article is an Intellyx customer.

Image: Skitterphoto/Pixabay