In my last post, I included a recent article from Andrew Binstock, who is the Editor in Chief of Dr. Dobbs Journal. Mr. Binstock expressed his concerns about how we are corrupting Agile.
Today, I am continuing with Part 2 of my The Corruption of Agile series by highlighting thoughts from one of the founding authors of the Agile Manifesto, Dave Thomas. Dave (photo, right) is a coauthor of the legendary Pragmatic Programmer book, one of the authors of the Agile Manifesto, a publisher, speaker, and the man who brought Ruby to the masses.
In a recent interview with Mr. Binstock, Dave discussed what he feels is wrong with Agile. But, before we get started, let’s review what the Agile Manifesto really said. This is verbatim from the Agile Manifesto website.
Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more. 
The Corruption of Agile – Andrew Binstock’s Interview with Dave Thomas 
AB: Let me move to the Agile Manifesto. You were one of the original signatories…
DT: Yes, yes. There were 17 of us that met in Snowbird in Utah in February 2001; and we came up with the four values and the common ground and practices. The way we came up with it was not something I’d ever experienced before. There were 17 people and everyone had their own ax to grind and their own particular viewpoint on what was best. And within a couple of hours, we’d come up with a way of working that let us discuss the principles behind what we were doing without going into the details.So the framework itself, the actual four values, came out in half a day. It just kind of came. I think everyone kind of knew what they wanted to say. I think it was actually Martin Fowler and I — everyone else was having lunch — we were kind of sitting at a whiteboard just chatting through things and we came up with the “we value A over B” formulation, which as it turns out, has worked out really well.
AB: I think that perhaps a limitation is that a lot of people have interpreted it as “no B whatsoever.”DT: Indeed! And, in fact, we recognized that might happen at the time, and we put in the little phrase at the bottom: “whereas we value B, we value A more.” So, we thought that would happen and we tried to stop it, but, of course, we…AB: …can never control…
DT: Yes, that was the depressing thing for me. I came away from Snowbird feeling really happy. And within a month, I realize it wasn’t going to work. And I have not been involved in anything even called “Agile” until last month.
AB: Last month?
DT: That’s right, last month. I have not gone to any Agile conferences. I have not joined the Agile Alliance.
AB: Why is that?
DT: Because it got immediately productized in many different ways. The whole point, to my mind, of the Agile Manifesto is that it’s a set of personal practices that may scale to team level. You do not need a consultant to show you how to do that. It may help to have someone facilitate, but you do not need a consultant. And yet immediately what happened was that everyone and their dog hung out an Agile shingle and the whole thing turned into a branding exercise.
DT: And so now in the software world, if you’re selling something and it doesn’t have the word “Agile” somewhere in the title, it’s not good. And I hate that because we had something that was…it was my best attempt at the time to present a set of free-standing, self-contained values that could be applied by all. And now it’s just become mush. It’s become devalued to the point where it doesn’t mean anything.
DT: I also have a pure English-language abhorrence to the people who use Agile as a noun. As in “I do Agile.” No you don’t. It’s like saying “I do orange.”
AB: When you were meeting at Snowbird, was there a feeling there that you were doing something important that was going to change software?DT: Good question.AB: The fact that you chose the term “manifesto” suggests that you were planting a flag.DT: There was a lot of discussion at the time about what it should be called. And, to be honest, I can’t remember to what extent we were thinking of posterity when we came up with the word “manifesto.” Even the word Agile was debated a lot.
AB: That’s what I’ve heard.
DT: I think we discussed “lightweight.” There was some sense that this was going to be bigger than the 17 of us because we agreed on the last day that Ward [Cunningham] was to go create a site that would allow people to sign up. Ward is someone who is always building community. And I think we all went along thinking that would be a really good way to spread the word. But the reality was that I don’t think any of us were particularly marketing people. The fact that it took off as quickly as it did was that we just happened to say the right thing at the right time. We didn’t actively push it particularly, it just kind of pushed itself or actually pulled itself.
Next: Allen Holub and The Agile Holocracy
Bonus Section: The 12 Principles behind the Agile Manifesto
For you folks that have never read the actual Agile Manifesto, I have provided a copy of its guiding principles here for your review.
We follow these principles:
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
Business people and developers must work
together daily throughout the project.
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
Continuous attention to technical excellence
and good design enhances agility.
Simplicity–the art of maximizing the amount
of work not done–is essential.
The best architectures, requirements, and designs
emerge from self-organizing teams.
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly. 
 Andrew Binstock, Dave Thomas Interview: The Corruption of Agile; Ruby and Elixir; Katas and More, Dr. Dobbs Journal, March 18, 2014, http://www.drdobbs.com/architecture-and-design/dave-thomas-interview-the-corruption-of/240166688?pgno=3.
 Kent Beck et al, Manifesto for Agile Software Development, The Lodge at Snowbird Ski Resort, Utah, February 11-13, 2001, http://agilemanifesto.org/.