April 18, 2008

Stop Making your Own Agile!

I heard many times people talking about the fact that they are agile because they don’t strictly follow “the practices”. Good, I think. Then they describe that their TDD approach is like: first they write down some code, then they test and because testing make them think about possible corner cases, then they expand the first core with additional logic. Here’s another example about pairing: since I am in a room with 3 other people, when I’m stuck I ask one of them to help me understand what’s going wrong with my code. Another style of pairing is instead the situation where a team try to pair up when the pressure on the project is not too tight: a degenerated collective ownership.

I think that Beck’s 2nd book has been largely misunderstood. There is a reason to introduce flexibility applying a process and the possibility for a team to change practices or introduce new ones. But those changes are the product of an hard work of the team made of metrics and continuous retrospective. You start from the practices and when you realize that something is wrong in a deterministic way (i.e. numbers), then you change the practices.

Being agile doesn’t mean that you’re so smart that in front of a set of rules you are empowered to skip or change those rules. Being agile means that after you followed the rules or best practices and collected a feedback (or you contextualized to a specific environment), you have the power to change those rules and adapt the process for the team. I know that what I said before sounds naive (with all that good literature around about craftsmanship, journeyman to master and pragmatism) but it looks like that the temptation to skip the hard work and jump to the master status became equivalent to agility these days.