TITLE: Agile Themes: Defining Agile AUTHOR: Eugene Wallingford DATE: July 24, 2007 3:42 PM DESC: ----- BODY: Every so often the XP discussion list takes off in a frenzy of activity. The last few weeks have seen such a frenzy, which makes it difficult for readers like me to keep up. Fortunately, I am often able to find some nuggets of value with a two-pronged heuristic approach to reading: I usually home in on messages from a few folks whose posts I have found valuable in the past and scan the sub-threads that follow, and I occasionally select messages pseudo-randomly based on subject lines that tickle my fancy. I'm sure that I miss out on some valuable conversations along the way, but I do find enough to keep my wheels moving. One long-running recent thread has focused on "defining agile" -- that is, being able to tell when an organization is using agile methods or not. If the list were made up solely of academics, this thread would be a natural. Academics love to put things into categories and name them. But this list is made up mostly of practitioners, and there interest in defining agile comes from many different directions, not the least of which is dispelling hype and distinguishing practices that help folks succeed. I used to be much more dogmatic about naming things and separating methods and approaches and people into categories. A prime example was "real" object-oriented programming from the charade that some people display in a language that supports objects. Over time, I have soured of the battles and am more likely to espouse the point of view expressed by Andy Hunt somewhere back in the thread:
Instead of a test for agile, how about a test for "was your project a success or was it horked?" If it was a success, call it anything you want. If not, don't dare call it agile. :-)
This sort of pragmatism is reminiscent of Alan Turing's sidestepping of the question "what is intelligence?" in his seminal Computing Machinery and Intelligence. Such a definition makes it hard for agilists to defend their turf, but it lets folks who want to build systems get down to busy, rather than argue. That said, I think that George Dinwiddie has done a nice job of capturing the essence of defining agile methods in a blog entry responding to the thread: using feedback that is frequent, timely, aligned with our desired goals, and pervasive. If you have read much of this blog, especially back in the first couple of years, you know that I have written frequently of the value of using feedback in many different circumstances, from developing software to teaching a class to training for and running a marathon. My appreciation of Dinwiddie's characterization is unsurprising. Tim Haughton created a branch off this thread with a post that defines the Three Colours of Agile. Haughton reminds us that we need to tell different stories when we are dealing with the different parties involved in software projects. In particular, the customer who will use our software and the manager who oversees the development team have much different views on software development than the developers themselves have. Most of our discussion about agile methods focuses on the practices of developers and only peripherally with our interface to the rest of the world, if at all. Telling the right story at the right time can make a huge difference in whether another person buys into a new method proposed by developers. When we communicate the value of agile methods to the customer and manager from their perspective, the approach looks so much more palatable than a laundry list of developer practices they don't understand. Again, frequent readers of this blog will recognize a recurring theme of story telling. -----