A lot of the time the first question a lot of people ask about agile and distributed agile in particular is:
“Which tool or product should I buy for me and my team?”
This isn’t a bad question provided everyone involved understands that tools aren’t the primary driver of project execution, or even software development.
Imagine your brother is a bit of a klutz when it comes to home improvement projects. He’s the guy who puts up shelves which turn out to not be level and “fixes” the kitchen electrics so that the garbage disposal unit fires up every time someone turns on the lights.
Do you buy him a nail gun, a power saw and one of those fancy tools for crimping wires? Will that make him a better carpenter or electrician? I’d say not.
Assuming the person isn’t at fault here—he’s your brother after all—the thing to focus on is the process. In this case how to hang shelves or fix wiring. Having a nail gun might eventually make sense and will significantly improve his productivity but that comes after everyone understands the process and maybe even learns how to do it with less capable tools.
Of course maybe your brother is a completely lost cause and no matter how much you try and teach him he just doesn’t get it. This is unlikely because that would make him the person who built my house. But if this does turn out to be the case then it’s probably time for him to leave the contracting business and start a career where he can do less damage. Middle management at a large software development company for instance.
I’m not saying tools aren’t important. Writing code in Visual Studio is a whole lot better than using Notepad (I work for Microsoft’s Developer Tools Division after all). But if you have a team of disorganized people who aren’t being given any clear direction (process) then no tool on Earth is going to save them!
Interestingly Distributed teams are one area where tools and process become very entwined. Tools may become a key part of implementing your process. Availability of tooling and possibly bandwidth to support them may constrain how your team can work. Regardless the process should drive the tools not the other way around.
Thanks to Dan Massey for pointing out that tools are a third not second order effect, as I’d originally postulated, when I lumped people and process together.