According to the current board of the Agile Alliance, agile
methods have
"crossed the chasm" , which I think means they are becoming more
widespread. While this has its advantages, it also brings
problems. As a methodology or design approach becomes fashionable,
then we see a lot people using it, or teaching it, who are focusing on
the fashion rather than the real details. This can lead to
reports of things done in agile's name which are a polar opposite to
the principles of movement's founders.

Drifting around the web I've heard a few comments about agile
methods being imposed on a development team by upper
management. Imposing a process on a team is completely opposed to the
principles of agile software, and has been since its inception.

For me, one of the key features of agile methods is that they are
PeopleOriented. They
recognize that people and how they work together is the primary
factor in software development, and that processes are a secondary
factor. This is reflected in the first value of the agile manifesto "Individuals and interactions over processes and tools" and is
reinforced by two principles of the manifesto:

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The best architectures, requirements, and designs
emerge from self-organizing teams.

An important consequence of these values and principles is that a
team should choose its own process - one that suits the people and
context in which they work. Imposing an agile process from the
outside strips the team of the self-determination which is at the
heart of agile thinking.

This notion goes further with another principle from the
manifesto: "At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly." Not just should a team choose their own
process, the team should be control of how that process evolves.

This notion of a process made to fit the team (and not the other
way around) is a necessary condition for agile methods, but clearly
isn't sufficient. A team may choose a totally waterfall, un-agile
process. In that case, clearly the process is no more agile than
apples taste of strawberries. But agile methods aren't the best for
all situations, and personally I'd rather have a team work in a
non-agile manner they chose themselves than have my favorite agile
practices imposed upon them.

So I hope I've made clear that imposing agile methods is a very
red flag. When I hear about it, however, I'm usually not getting the
whole story. There are situations that may look similar from the
outside, but aren't really the same.

One case is that of learning. Introducing agile methods often
involves learning a whole bunch of new things at once, many of which
are counter-intuitive. This is particularly true of Extreme
Programming. In this situation it's very difficult to tailor a
process until you've used it for a while (I wrote about this with
respect to XP several years ago). At this point a team is in the Shu
stage of ShuHaRi and thus needs to follow the practices
pretty slavishly until they get the hang of how they work. In this
situation dogmatism and inflexibility are a (temporary) learning tool.

Another situation that we are usually in at ThoughtWorks is where
we are on a co-sourced project with a client team. In most of these
situations we are responsible for the delivery of the software but
we need to work with client staff in order to provide a good
handover and so that the client people can learn about how we
work. In this situation we are being paid to be as effective as we
can be, so we'll use a process that works for us. This doesn't mean
we don't tailor the process to the client's environment, that's
always necessary, but there is a tricky line between sensible
tailoring and abandoning the practices that make us successful.

Those kinds of situations show than imposition isn't as clear cut
as it can sound, but the fundamental point remains - imposing agile
methods introduces a conflict with the values and
principles that underlie agile methods.

This kind of problem was inevitable. I distinctly remember a
period when it was fashionable to be object-oriented and all sorts of
odd things were done in the name of objects. It's all part of the
normal adoption process. There's nothing that can be done to prevent
the agile name being applied to very un-agile behaviors - there's no agile
police enforcing RigorousAgile. All we can do is for those of us who care to
keep trying to explain what agile is really about. And I prefer to
explain than convince.