Martin Fowler on Rigorous Agile

Retreaded in 2012, originally posted in 2005.

I often run into a complaint that agile methods don't have a rigorous definition. The complainer may talk about how this means that you can't tell if a particular team is using an agile method or not. They may also say that this makes it hard to teach people how to do agile methods - what's the curriculum?

To some degree I do feel the pain of this complaint - but I accept there is no cure. This lack of rigorousness is part of the defining nature of agile methods, part of its core philosophy.

One of the fundamental problems of thought processes in general - and of software development in particular - is the very varied nature of the settings. Different kinds of systems have different kinds of pressures and forces, which makes it very difficult to come up with a rigorous statement of what to do that's sufficient to cover them. This effect is compounded by the fact that software development is such a people-oriented activity, and people are naturally inconsistent and highly variable. The conclusion that agilists made from this is that's its not effective to try and bind software development to a rigorous process, because that's ignoring the essential nature of the primary (human) components that will execute that process.

(It's probably because our profession is to work with computers is what leads us to want to program human systems the same way that we program computers - despite the fact that they are so different.)

The upshot of all this is that agile methods fundamentally expect teams to decide what process to follow and furthermore expect teams to actively and regularly change their process. Any attempt to define a rigorous process that can be tested for conformance runs contrary to this philosophy.

I can't deny that this is frustrating. How can you do a survey on whether agile methods are more effective that alternatives, or whether Extreme Programming is more effective than Scrum, when you can't get a clear definition of what Scrum is in the first place? If a client wants a system built using Extreme Programming how can they tell if it's really being done?. There is a sense of "I know it when I see it", but it requires an experienced practitioner to have that sense and even then there's lots of room for such practitioners to disagree.

I don't have an answer to this conundrum. Indeed I don't think there is an answer. It's a an unfortunate consequence of the activity itself, just as getting wet is an unavoidable consequence of swimming.