This post originated from an RSS feed registered with Agile Buzz
by Martin Fowler.
Original Post: Retreaded: RigorousAgile
Feed Title: Martin Fowler's Bliki
Feed URL: http://martinfowler.com/feed.atom
Feed Description: A cross between a blog and wiki of my partly-formed ideas on software development
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.
Previous Topic
