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.