I’ve talked about this with people for some time now, and I think it’s time that I try to solidify my thoughts on the matter by writing a post about it.
My theory is that what hurts agile introduction in new enviromnents most are well-meaning but badly-informed agile promoters. I mean people who like the buzz and some ideas of the agile life, have read a few blogs, and are eager to try it out.
A colleague told me about a client that had an architect that misunderstood TDD. Their development process was something like this:
1. Architect writes interface declaration
2. Developer writes unit tests for the interface
3. Architect signs of on the unit tests
4. Another developer implements the actual class the implements the interface and turns the tests green
Anyone working in this manner will wind up frustrated. If they have no prior experience with TDD, naturally they’ll blame their frustation on this stupid thing called TDD. What test driven design is about is rhythm. Taking small steps, and letting the code guide you to a good solution. Calling this system TDD is like having all your code in one big static method and claiming you are coding object oriented, just because you write in C#.
I’m aware that I might come across like an elitist know-it-all, but that is not what I aim at. What I think you should do before starting with agile development is to spread the knowledge in the group. Again and again, I find that I can’t explain things as well as Kent Beck. Or as Martin Fowler. Or as James Shore. Make people read their work. In any group that plans on working with XP, everyone in the team should at least read Extreme Programming Explained. Developers should also read Refactoring and TDD by Example. Customers should read User Stories Applied. I promise, this will save you a lot of headache, misunderstanding and frustration.