At the time the term “agile software development” was coined, it filled a need. Different people had come up with different responses to the endemic problems in IT. Most of these innovations were ad hoc, localized, and not widely shared. A few had been published in book form and were better known than others. But there was no single flag around which people interested in improving the state of the art of software development could rally.
After the Snowbird meeting, we had such a flag. “Agile” was loosely enough defined, and yet clearly enough focused, to serve as a basis for people to innovate in the areas of process, practices, and human factors to achieve better results than were seen with traditional methods, as indicated by the many industry studies and surveys carried out in the 1990s and early 2000s. The loose definition of “agile” was, in the early years of the movement, its main strength. The very looseness of the definition enabled innovation. But every strength is also a weakness, when it is taken beyond the point of diminishing returns.
Now, more than ten years later, the word “agile” has suffered from the inherent downside of its loose definition. The word has been co-opted by every pundit, author, consultant, trainer, and coach in the IT field. For them, “agile” means “whatever we sell.” For people in IT organizations, the perception is that they had better embrace “agile” or they will be marginalized and their careers will stall. For them, “agile” means whatever it has to mean to qualify them to sit with the cool kids in the school lunchroom. They are more concerned with achieving a high score on the latest “agile” assessment than they are with software quality, consistent delivery, and sustainable performance. Form trumps substance.
Today, people fall into two main camps when it comes to “agile.” In the first camp are those who seem to think “agile” is a magic potion that cures all ills. They ask for “agile” this and “agile” that without having first carried out any sort of root-cause analysis to identify their problems, or any sort of strategic planning to identify their goals. When you ask them how they think “agile” will help in their situation, they have no answer. “Agile,” whatever it means, will just magically fix everything. They tend to overlook or misunderstand two of the most fundamental tenets of “agile” thinking: People over process, and continuous improvement. They are looking for a canned “agile” model they can implement once and repeat forever by rote. Yet, by definition, such a thing cannot exist.
In the second camp are those who go out of their way to look for “agile failures,” which they use as a convenient excuse to maintain the status quo. These are the people who constantly demand studies that prove “agile” works, and consistently dismiss any studies that don’t say what they want to hear. At the same time, they cannot provide any studies that prove their own preferred methods work. They don’t understand how “agile” might help for the same reason they don’t understand how traditional methods cause problems: They don’t really understand how or why any approach works or doesn’t work in a given context. They’ve memorized one way of getting their work done, and anything different is simply a threat to them. They talk about “waterfall” as if it were a proven effective way to build software, and “agile” as if it were some sort of heresy.
In both cases, the danger is that people tend to overlook the substance of things. The faithful assume that if they can just manage to label whatever they do in “agile” terms, then somehow things will turn out well. The nay-sayers are quick to discard anything that appears to be associated with the “agile” movement, including methods and practices that were well-proven many years before Snowbird, and that are relevant to software development and delivery whether one uses an “agile” approach or not.
There’s an unhealthy focus on the word “agile,” to the detriment of critical thinking, goal-setting, and problem analysis. “Agile” is not an end in itself, but only a means to an end. People have lost sight of the end, and look only at the means.
It’s time now to parse out the substance of the lessons learned in the “agile” movement, add those lessons to our overall IT toolkit, and move on.