If the Agile Manifesto needs an update, why not ask its original authors? Or why not ask the Agile community at large, and conduct an open process? These are valid questions, and we considered these over a long period of time. Let’s take these one at a time:

Why Not Ask the Original Authors?

The Agile Manifesto does not define Agile. Agile began before the Manifesto. The Manifesto was written in response to Extreme Programming (XP) and other methodologies that were disrupting software development. So while the Agile Manifesto was a thoughtful statement, it is not all-encompassing. In fact, one could argue that the Agile Manifesto, with its emphasis on balance, was quite opposed to the spirit of XP, which is – as its name says – about extremes, and a one-size-fits-all approach. (Even though XP said that one could tailor it, the XP community became very dogmatic about insisting on the use of its practices, such as pair programming and Test-Driven Development.)

Another consideration is that while the Agile Manifesto’s authors all contributed to its four values, it is not clear who wrote the twelve principles. Those were created through some email exchanges in the weeks following the Snowbird meeting. Did all seventeen people contribute to those emails? We don’t know. Anecdotal reports indicate no.

Finally, how would we reach the remaining sixteen authors? The Agile Alliance was established by some of them some time after Snowbird, but today the governance of the Agile Alliance is a different set of people. So the original authors are not driving it anymore.

We actually did reach out to a few, and were unable to generate interest in changing the Manifesto. The Manifesto is a revered document, and it seems that at least some of them want to keep it that way, or perhaps they just do not have the energy. So while we thank them for helping to bring about change, we cannot expect them to take the lead in an Agile pivot.

Why Not Create a Community Process?

The Agile community is part of the problem. The Agile community developed some severe dysfunctions very early in the movement. One was that it shifted firmly away from technical issues, focusing almost entirely on workflow and facilitation processes.

In the consciousness of organizations, Scrum essentially became synonymous with Agile for a time, to the dismay of those who do not feel that Agile is the same as Scrum. A large cohort of Scrum-certified non-technical coaches and Scrum Masters developed, entrenching the community in a particular set of viewpoints. That cohort identified with those viewpoints, and so it was resistant to change or challenge. The situation was so bad that in the British Computer Society’s ten year Agile retrospective, they identified “Scrumdamentalism” as a core problem. [See this slide deck from the event, specifically slide 11.]

The community also was about extremes – even though the Manifesto expressed a need for balance. The tone had been set by XP: pick extreme practices and insist that everyone follow them. No matter that some of those do not work for some people. [See the debates between Kent Beck and David Heinemeier Hanson, about Test Driven Development.]

The community was also highly resistant to reintroducing a focus on technical practices. Jez Humble spoke often about continuous delivery at Agile gatherings, and his talks were standing room only, but his ideas spread mostly through the developer community rather than the Agile community. There remained little awareness of continuous delivery methods within the larger Agile community, and so DevOps became its own movement. It was not until Gene Kim’s 2013 book The Phoenix Project that DevOps finally became something that the Agile community could not ignore.

Today many Agilists say that DevOps is just XP – it is not. Or they say that DevOps evolved as part of Agile – but it did not, as we just explained. And today, it is almost impossible to find an Agile coach who knows DevOps methods, or a DevOps engineer who knows Agile methods well, because the two communities are so divided. That is the reality.

The sad fact is that the Agile community has a great deal of dysfunction, and so it is itself part of the problem. Generally speaking, it does not even know that it has a problem: if one posts the question “How is Agile doing?” to an Agile group, one generally receives positive responses: “Agile is great!” But if one posts the same question to a programming group, one gets a very different profile of responses, because programmers – the people who are most affected by today’s Agile – are far less enthusiastic; and what is worse, they are afraid of speaking up about it. [See this Reddit thread, “I hate Scrum.”]

That is why we did not appeal to the Agile community. If we had, we would have gotten more of the same, pushing things farther and farther in the current direction, when what is needed is a hard pivot.

The Agile Industrial Complex

Every Agilist knows that change is hard. Organizations have inertia. People are invested in the status quo, and they have agendas.

The Agile community is no different. Most people do not realize that Agile is a territory, and it has been carved up into fiefdoms. These fiefdoms are an enormous source of revenue. Those who control those fiefdoms will look at Agile 2 and evaluate, asking, “Does it advance my interests?” Some will decide that it does, because it loosens the grip of a controlling fiefdom. Others will decide that Agile 2 threatens their control of the Agile territory.

One cannot avoid the monetization of Agile: this is how the global economic system works. However, it means that to bring about change, one has to appeal to those who stand to benefit. Luckily, the situation is such that those who stand to gain from Agile 2 are mostly the ones who have had a healthier attitude that is more open and inclusive with regard to the Agile idea space.

That is not entirely accidental: monopolists usually become exclusionary, while those on the outside promote inclusiveness – because it would benefit them. Microsoft was highly aggressive and exclusionary when it ruled computing, but today, now that they are an underdog, they have been described as “the adult in the room.”

Let us share some misbehavior that most people do not know about. Instead of making our own statements, we invite you to follow these links:

1. Ken Schwaber’s blog post: “Greed and Control Can Ruin an Industry and Movement.”
2. Civil action record (legal.com): “SCRUM ALLIANCE, INC. v. SCRUM, INC.”: Lawsuit of Scrum Alliance against Scrum Inc.
3. Blog post, “Why I am NOT Going to Renew My PMI, Agile & Scrum Certifications (2020)”

In addition, the contract that a Certified Scrum Trainer (CST) must sign with the Scrum Alliance (at least in 2016) stipulates that the person “may not be a trainer for, or participate in teaching classes for, any Scrum certification body other than Scrum Alliance,” and that the trainer “may not teach, promote, market, advertise or support any certification course that (i) is primarily devoted to the field of Scrum or Agile, and (ii) directly competes with a current Scrum Alliance offering.”

Basically, this demands that Scrum Alliance trainers be evangelists for the Scrum Alliance’s methods, exclusive of all other Agile methods. This supports the contention that former Scrum Alliance board member Tobias Mayer made in a blog post, that Scrum Alliance is only concerned with making money. We feel that this indicates a “zero sum” approach – a territorial approach – to Agile ideas.

Are the above things the behavior of an organization that has the best interests of the community in mind? Draw your own conclusions.

Unfortunately, the Scrum Alliance has created a large army of these evangelists, bound by contract – mercenaries in the war for Agile territory. And this is why we cannot put Agile 2 in the hands of the “community,” because there are already too many special interests controlling that community.

The good news is that there are elements of the Agile community that are open. Thought initiatives such as Agnostic Agile and training organizations such as ICAgile explicitly embrace open sharing of ideas. We believe that Agile 2 will be well received by those who are open and not deeply invested in the status quo.

Conclusion

This is why we created a new group to define Agile 2. The two primary criteria for being selected for the group were:

1. You must not have a vested interest in the status quo.
2. You must have demonstrated, through writing or postings, independent thought.

We knew that we needed to pivot Agile – not merely nudge it. In fact, it needs a hard shove. The community does not want change: it wants more of the same, just in more ways. Left to itself, it will not change in the way that it needs to. We need to call out what the current problems are, using the perspectives of independent thinkers, who have deep and broad experience among the community, but who have remained independent of it.