Customizing Agile

When I'm running on the trails down at Town Lake or I'm in the gym working out, it is natural to take a look at those around me and see what they're doing. Are they running as fast? Are they doing as much weight?

But you really can't compare because you don't know what they've been through. Maybe they're running slower because they've run (or are planning to run) twice as far. Or they're doing less weight because they're doing twice as many reps. Or maybe they have an injury that they're recovering from. Or maybe their body just responds differently to various training techniques and they're doing something that works better for them.

So what is the parallel in agile? Well, when you look at other teams and you observe their practices, you have to take into account that the other team is different. What works for them might not work for you (and vice versa).

You have to understand the principles and then modify the practices to what will work for you (this might take some experimentation). For example, in one project I worked on, pair programming wasn't a good cultural fit. What are the principles behind it? Catching bugs early through peer review, cross training, etc.

So we put into place a process where every check in required an informal peer review. Someone would look over what you did (code, unit tests, etc.) and give feedback. We caught a lot of issues, improved the code quality, ensured that at least two people were familiar with every line of code and started to standardize practices / approaches.

There's not a clear definition of what is agile and what isn't. It is a set of principles and common practices. Teams are expected to tailor it for their use. I believe that this customization has really helped with the success of agile.

Retrospectives are a wonderful thing. They force you to look at how the process is going, to identify the biggest issues and to resolve those issues. This results in a process customized to the needs of the team.