Yesterday, Elizabeth Hendrickson posted her Agile Acid Test in which she asks three questions to determine whether or not a team is truly "agile". There is also the Agile Manifesto which describes the values that an agile team should adhere to. While there is nothing that I disagree with in either Elizabeth's post or the Agile Manifesto, there are two simpler questions you can ask that get to the heart of whether or not your team is agile: Can you react immediately and without panic when external constraints on your project are changed, and does your team regularly and frequently review its processes to ensure the answer to the previous question is always "yes"?

If you can answer yes to both questions, then your team is agile. Whether you use XP, Scrum, Lean, Waterfall or any other process or mix of processes doesn't matter at all for the purpose of determining agility; these processes may help you deliver software that meets stakeholder needs in a timely fashion (or they may not), but no single one of them is "the right way".

Note that I don't ask about delivered value or sustainable pace. It's not my intent to discount the importance of either of these things in general; I do not, however see them as a strict requirement of agility, per se. Granted, if a team isn't able to do both of these things, that team probably will not be successful in the long run, but if the team asks itself the two questions I propose, then the other things are likely to fall into place naturally. (When I say team, I am talking about the whole organization—it is critical that the team is empowered to make changes that can affect its answers to these questions, so the management needs to be part of the process.) Both the Agile Manifesto and Elizabeth's questions address qualities that are typically evident in truly agile teams, but the essence is that a team is able to react quickly to whatever is thrown at it and is able to react differently to changing situations.

Most software development methodologies start out as experiments that worked for one team, got introduced to others and managed to gain successes and proponents. Then somebody puts a label on it and writes down the definition of what it means to do, say, Scrum. Now we have a neat list of things that a consultant can point to and say "yes, you are doing Scrum" or "no, that's not Scrum". This recipe for Scrum is now ready to ship off to other development organizations, and if only they perform the recipe just the way it's written down, everything will be fine.

Right...

A tangent: My wife and I both love to cook. One of my favorite celebrity chefs is Alton Brown—he is, in fact, singularly responsible for my move from viewing cooking as "something you had to do occasionally if you wanted to eat" to being something I actually enjoy doing. The reason for this is simple: he doesn't just give you a recipe, he gives you the tools you need to reflect on what you've done and understand why a dish did or did not turn out the way you expected. That way you know what to do differently next time as opposed to assuming you can't make that particular recipe work and giving up on it.

The promotion of various "agile" methodologies as connect-the-dots exercises is the biggest failing of the agile software development movement. A methodology gains enough popularity that an organization's management (or often the developers themselves) decide to adopt that methodology in order to take advantage of the benefits of "agile". They follow the process to the letter for one or two releases, but they don't meet the goals of the organization, write off "agile" as something that won't work for them and go back to old patterns that are perceived to work at least a little bit better for them. Meanwhile, the consultants and trainers have moved on to greener pastures with the occasional tweet about "#notscrum".

I much prefer the approach of those like Diana Larsen of FutureWorks Consulting and co-author of the excellent book Agile Retrospectives who—while promoting agile methodologies—stresses the importance of an organization reflecting on what it has achieved, what it has failed at, and in both cases how and why it has done so. She will then challenge that organization to find the next steps it can take to get closer to meeting it's goals.

With such an approach, a team that is new to agile software development may start out with a by-the-book Scrum implementation, but after several iterations of delivery, retrospective and process modification, that team may or may not have a process that still resembles Scrum. As long as that team is able to answer yes to my two questions, they may be "#notscrum", but they can hardly be called "#notagile".