Agile Tooling: Being Agile in how we Choose, Adopt and Abandon our team tools
Many teams are stuck using tools that don't serve them well because of inertia
and the percieved cost of analysing all the alternatives to find the "best one".
We don't need to find the "best" tool; we only need to find one that is "good
enough" and "better" than the one we are currently using.
The tools that could solve the problem today are changing so fast that a
different one will be "the best" 6 months from now.
Many tools have free cloud-based (Software-as-a-Service) trials that can be used
within minutes of signing up.
Tools should be adopted because they solve an existing problem, not because they
might solve a future problem.
Rather than conducting an exhaustive analysis of all tools doing detailed
comparison of feature lists, why not have a short list of acceptance criteria
and pick a tool that satisfies all of them and try it out.
In enterprise environments, rather than bitching about the enterprise sanctioned
tools, teams should pilot different tools and compare experiences. If the
corporate data hounds require usage of enterprise tools for data-collection
reasons, have one person from the team synchronize the data once per reporting
interval rather than have the whole team suffer with using the enterprise tools
Author of the Jolt Productivity Award winning book "xUnit Test Patterns –
Refactoring Test Code" and winner of the "Programming with the Stars"
competition at Agile 2009. Learn more at http://xunitpatterns.com/index.html