Agile is one of those super buzzwords that everyone knows. The problem starts when you ask people what it means. It seems that the more people I ask, the more answers I get. One of my standard interview questions is, what development process do you use where you are today? I am always frustrated when they say, we “do” agile. My canned response is “What does that mean?” Very few developers can answer that question. I get the standard, “we have daily meetings and we don’t do requirements.” That hardly sounds like a development process. It sounds more like chaos. And unfortunately, many shops that “do” agile are nothing more than cowboy shops that use agile as an excuse to not plan. They are missing the whole point of what agile is.
In February 2001, Kent Beck and Bob Martin pulled a group of “lightweight” method leaders into one room at the Snowbird ski resort in Utah. Their purpose was to come to a consensus on lightweight methodologies and what the core principles are. What resulted from those discussions was called “The Agile Manifesto.” They concluded that the agile movement can be boiled down to four core principles. Individuals and interactions over processes and tools, Working software over comprehensive documentation, Customer collaboration over contract negotiation, and Responding to change over following a plan. This is the very essence of agile. It is very important that developers understand the core principles of agile before embracing one of the many agile methodologies out there.
These tenants basically come to this, if you have the right people, they will do the right thing. Processes should be in place to equip developers to get their jobs done, not hold them back. Documentation is useful but only if people are going to read it and respond to it. Agile is not about swapping one rigid mindless process for another. Can I run waterfall in an agile fashion? Yes, as long as I understand change is coming and include change procedures in my process I am well within the spirit of agile. As long as I understand developers can’t work in a vacuum and encourage them to ask questions and have interaction with the business partner, I am being agile. If I am running Scrum and throw a fit when something interrupts my well laid out sprint, I have missed the point.
The bottom line here is this, Agile is not a process, it is not something you do. Agile is a philosophy. You bring the agile tenants to whatever process you have in place today. In my last post I talked about the agile approach to doing agile. The idea there is, over time, insert these core concepts into your process. Agile is not a process change, it’s a mentality change.
I will leave it to Jim Highsmith to summarize,
The Agile movement is not anti-methodology, in fact, many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment.We hope that our work together as the Agile Alliance helps others in our profession to think about software development, methodologies, and organizations, in new, more agile, ways. If so, we’ve accomplished our goals.