Over a million developers have joined DZone.

Martin Fowler on Rigorous Agile

· Agile Zone

Learn more about how DevOps teams must adopt a more agile development process, working in parallel instead of waiting on other teams to finish their components or for resources to become available, brought to you in partnership with CA Technologies.

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.

Discover the warning signs of DevOps Dysfunction and learn how to get back on the right track, brought to you in partnership with CA Technologies.


Published at DZone with permission of Martin Fowler, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}