Compromise will be the key in a situation like that, unless all team members are already versed in aspects of Agile. After the urgent need is met and the dust settles, there might be a wonderful opportunity for the team to look at Agile more deeply and see if its practices would make sense moving forward.

To your second point regarding a “mutant version of agile”: I would have to concur, especially if folks rush in without taking the time learn the concepts, then to make a plan and work that plan. However, one of the neat things about Agile I have experienced is that you learn by doing. Don’t tackle all of Agile all at once. Maybe take a concept, such as Continuous Integration, read up on it then start working it. Once that is understood well and in place, start on the next. There are a lot of free or low-cost resources out there on the internet to help.

The approach I have taken on my latest team is to introduce concepts slowly: first demonstrate and begin mentoring on TDD. Next, Continuous Integration. While this is going on we are discussing things like S.O.L.I.D. and Clean Code (ie., the “craftsmanship side” of Agile, if I could draw a fuzzy line).

We are also discussing Paired Programming and the concept of Stories – when it would make sense to begin slowly integrating those in. And how. Once those are tackled, we’ll look at the next Agile/XP principle that speaks to us.

From my perspective, I continue telling the team we’ll only implement a practice if it makes sense. I do that because I don’t believe dogma is healthy. Each team member’s experience, point of view and opinion are important. For Agile to work, it needs to make sense to a large majority of the team, at least. I can do this because I firmly believe that Agile, when really understood, stands up to scrutiny and, therefore, we can throw hard questions and skepticism at it. It can take it.

So, I first ask myself, then I ask the team: does this make sense for us and why? The challenge is demonstrating that. Nicely, though, all these things typically make alot of sense to an open-minded developer, especially one who has been in the trenches a while. Once they see this stuff for what it really is and then experience it in action, it just makes sense.

For example, once the team saw TDD and CI in action, they were drawn to it. When those processes are in place we will have a solid foundation upon which to build other practices in. And their faith in Agile will have grown some because not only will they understand it intellectually but they will have experienced the practice in real-world situations and seen how it addresses a pain point they’ve most likely had all their professional life.

This incremental approach seems to be working well in the situations I’m in. I’d rather do it this way then run in and try to implement all of Agile all at once. That would be a mistake. Slow, steady steps seem to be working best in my case. Maybe it’s not ideal, but I think in the long run I will see a solid Agile team.

As well, this incremental approach mitigates the cost of implementing Agile. If it’s not in the budget to hire a mentor or go to some training, a team can build their understanding by tackling one or two concepts at a time.

Just some thoughts. Anybody have any disagreement? I’d love to hear it!

I think that Agile teams can (or cannot in some cases) be very effective but the initialization and training cost of switching to agile is immense. And I don’t think that is highlighted enough.

Most of the time a group of people at a company read a book or something and try to create what turns out to be a mutant version of agile, with a disjointed collection of practices that sound interesting. This in turn, has little effect on their actual development process.

It really takes an agile pro, mentoring other initiates to set the whole thing up quickly and effectively. And we all don’t have situations where this is possible.