Agile Practices as a gateway drug...

The agile community needs to recognize that not everyone can jump in with both feet.

We seem to be going through an identity crisis where we are declaring what is agile and what isn't. This is very important because the agile label is getting slapped on many presentations when companies think it makes them look good when they are in fact, not agile. In doing so, they are also diluting the global understanding that agile is a cultural change as much as a process change. Not standing up for this means allowing agile to become the same thing as RUP, PMI, CMM, or any other silver bullet labels that have been mis-used to the point where they don't contain the strong value they did when they first arrived.

Having said this, we can't keep believing that everyone should either be full agile or no agile. I get the sense that many people post about what it means to be agile, and at the same time (reading between the lines) they are creating a "you aren't really one of us unless..." cultures.

Agile started as an inclusive community. We are all going down a path of growth and learning. We have to make sure that when we provide clarity on the true side of agile, we don't give the impression that there is no value in the separate pieces.

We WANT people to get ALL of it. But sometimes people have to get there in their own way. Is it okay for someone to add retrospectives and nothing else? Is it okay to implement sprints and nothing else? Yes, I believe it is. I believe that if people are reading about agile and like the ideals, but can't afford the whole cost (and immediately gain the whole value)... then they will continue to learn and read. Many of the agile practices are a gateway drug to wanting to achieve the whole thing.

Maybe that's an Agile 2009 presentation I'll consider giving: Using agile practices as a gateway drug to becoming agile.

Anyway... this thread was triggered by a blog post about incremental, iterative, and agile development by Mike Cottmeyer. He also makes some good points such as:

"... You can still get some mileage from delivering software in two or four week cycles, daily interactions between project members, and frequent project reviews. You can make use of loosely coupled requirements, prioritized backlogs, and rolling wave planning. There is value in understanding the definition of done and making sure that once you've delivered, you have really delivered. Managers can do product planning, release planning, and iteration planning without being particularly agile... "