I fall into an interesting category of software developers. Most of my experience as a professional software developer (thus far) has been working with agile teams using agile processes.

Most developers who follow agile methods seem to come from the “been there, done that” camp. They have experienced all the non-agile strategies and people. They learned through years of experience why agile was important. I, on the other hand, only worked for a couple of years doing business software before adopting eXtreme Programming around the 1999-2000 timeframe. Ever since that time, I have worked for places that more-or-less accepted agile practices as law.

So, it’s a real eye-opener for me to work with people who just downright don’t know, care, or accept the concepts of TDD, collaborative code ownership, pair programming, project rooms, not checking in broken code, following a process, etc. I see many of their pains, but I can’t just downright tell them that they are doing everything wrong (even though they are).

Convincing people of agile is a delicate process. You have to approach it in the same manner as a strong salesman: by listening for their pain. Offer a business or technical solution to their biggest problems. You just have to make sure that you are really listening to make sure that you really understand the core of their problem. The solution is usually a fundamental practice. You start becoming nag if you are making suggestions for improving things that they don’t really feel like they’re suffering in (even if they are).