Adrian Lander - Agile 2

Industry groups sprang up: the Agile Alliance, the Scrum Alliance, Scrum.org, ICAgile, SAFe, LeSS, Kanban, and many others. The large consulting companies had a hard time learning about Agile, because Agile's central message of being lean and efficient and not having big contracted “phases” was antithetical to their model. Eventually they figured out how to incorporate it into their offerings, and today they all have substantial Agile practices, claiming to be the experts in Agile.

Thus, there is a lot of money today in the Agile industry, and the Agile community is arguably driven by moneyed interests, with a continuing tide of people seeking certifications in the various frameworks and becoming indoctrinated into them. The phrase Agile industrial complex , which might have been coined by Martin Fowler (one of the authors of the Agile Manifesto), has come to be used to refer to the industry as a commentary on the degree to which it is driven by financial interests rather than by ideas and efficacy.

Today Agile is big business, and it is highly competitive.

Large consulting companies have traditionally used their partners to fly around and build relationships with their clients' executives, convincing the executives that the partners and consulting firms have strategic insight. That was the case before COVID-19 and will probably resume being the case after COVID-19. Through those relationships, the partners are able to place large numbers of Agile-certified staff on-site, generating a lot of revenue.

Placing staff is their goal—as many as possible. These staff members do not usually have the industry experience that the partners have, but they have a certificate, perhaps a Certified Scrum Master certificate, perhaps a SAFe certificate, or perhaps others. In other words, they sat in a classroom for a few days or weeks, and they probably participated in at least one project that was said to be Agile. Most are not what one would normally expect from a consultant who is advising teams and programs: decades of practical experience at multiple levels of responsibility, great acumen, demonstrated industry thought leadership, and a history of P&L accountability.

Certainly there are many people in large consulting companies who are very qualified, but we have seen many who are not. The point is that one should not treat a large consulting company as if it is inherently more trustworthy than any other with regard to Agile expertise. Have their people achieved business results? The partners will tell you they have and will provide proof, but you know how data can be misused.

Many of the various industry groups do not like each other either. One of the largest Scrum training organizations—one that claims to speak for the Scrum community at large—actually writes into its contract with its trainers that one cannot train for a “competing” training framework such as the Scaled Agile Framework. Thus, the organization does not want its customers to have a choice or to be able to consider other ideas. Limiting what one’s trainers know does not seem to us like a good way to serve one’s customers.

Meanwhile, the organization preaches Agile's value of “customer collaboration over contract negotiation” and professes to being open to all ideas and to being cooperative and collaborative—core Agile attributes. You should not miss the hypocrisy in this.

An Agile training organization's armies are its certified coaches. When the CSM certification was introduced, it had an unintended effect (at least, there is no evidence that it was intentional). Large numbers of people who had no software development experience took the training and became certified. Almost overnight they had a new career: their CSM certification could get them a job as a Scrum Master or an Agile coach.

We then saw the rise of these two new professions (Scrum Master and Agile coach), and they quickly came to be dominated by nontechnical people from every manner of prior profession. Since their background was nontechnical, they emphasized the human side of software teams: team trust, team happiness, and so on, as well as the set of Scrum practices: the sprint planning, the daily scrum (aka daily standup), the sprint review, and the retrospective. The technical focus that XP had was almost entirely lost, and by 2011, 52% of Agile teams reported using Scrum (which defines no technical practices), compared to only 2% using the highly technical XP. 13

This is a big problem. In a talk at Agile Australia in 2018, Martin Fowler, one of the authors of the Agile Manifesto, asked the audience, “How many people here are software developers?” Then he said, “A smattering, but actually very much a minority … and that's actually quite tragic.” 14

Agile coaches and Scrum Masters focused on the nontechnical practices as if they were the be-all and end-all of software development, ignoring critical things such as test coverage, code branching, integration testing, issue management, and all the critical things that every programmer knows are essential. The retrospective, in which a team is supposed to talk about how to improve their work, was facilitated by the Scrum Master, who was usually nontechnical, and so the discussion tended to steer toward the Scrum practices, because team members did not want to bring up issues that the Scrum Master would not understand. Teams then went back to their desks, anxious to get back to work after all of the Scrum-related ceremonies (what the Scrum practices are called), and so important technical issues went undiscussed.

The Agile conversation was essentially taken away from software developers—the people for whom Agile was created. After all, the Manifesto begins with (italics added), “ We are uncovering better ways of developing software … .”

Agile thought leadership was increasingly controlled by those who wanted to advance an increasingly extreme behavioral agenda. Programmers speak up from time to time, but with trepidation. For example, a poster on Reddit wrote this:

“I hate Scrum. There. I said it. Who else is joining me? Scum seems to take away all the joy of being an engineer. working on tasks decided by someone else, under a cadence that never stops. counting story points and ‘velocity’. ‘control’ and priority set by the business - chop/change tasks. lack of career growth—snr/jnr engineers working on similar tasks.”15

The Scrum Master and Agile coach roles became so entrenched that organizations now assume that they need those roles. No one questions it. More important, no one questions the skills and knowledge that are needed for those roles to actually be effective.

The career of a Scrum Master or Agile coach relies on the perceived value that they provide. Since the experience of most was not in the technical realm, the natural evolution was to inflate the value of the nontechnical dimension of things. We saw a rise in Agile dogma, in which Agile or Scrum advocates—usually Agile coaches or Scrum Masters—would deride anyone who challenged Scrum or Agile practices. We have mentioned the term Agile doubter . These dogmatic people were such a problem that in a 10-year retrospective on the state of Agile, the British Computer Society referred to Scrumdamentalism—a play on the words Scrum and fundamentalism —as one of the main problems with the state of Agile. 16

The Agile community suffered from groupthink: the community mostly spoke to itself. One of our editors described the community as insular. During the first decade of Agile, Agilists mostly read books that said “Agile” on the cover, but important ideas from other communities, such as those that study organization change or organizational psychology, did not permeate the Agile community. In the words of Norwegian Wood 's author Haruki Murakami, “If you only read the books that everyone else is reading, you can only think what everyone else is thinking.”