Within the Agile/Scrum/XP community there is a love/hate relationship with tools that support the development process. I used to call these Computer Aided Software Engineering (CASE) tools but that term has fallen out of favor. CASE is more associated with the waterfall wold the the Agile Manefesto revolted against. There is one camp of Agilistas that will only use 3x5 index cards posted on a board in a war room. And even when considering tooling, the complexity of the tool is a major discussion point.
Last night, I attended an agile tools shootout hosted by the aRTP group. We looked at the following tools:
Microsoft Team System
IBM Rational Team Concert
Actually, the demos were given in two separate rooms and I was only able to personally see the Zen, PivotalTracker, ScrumWorks Pro, and Rational demos. From the demos and what I could see from their web sites I would broadly seperate the Microsoft and IBM tools from the rest and put them into the more complex category. However, this is because with both of these tools the vendors are attempting to cover the full development cycle and making sure at detailed design and coding they have things covered. For example, Team Concert was demoed as an Eclipse plugin with source code control, build management, real time notifications, project management features all enabled
Other tools, such as Zen and PivotalTracker tended to be more like electronic 3x5 cards with electronic boards. They did offer the advantage over a manual system of being able to automatically calculate burn down and other statistics.
In the middle of the complexity spectrum were Rally and ScrumWorks Pro because they added more project management features and the ability to integrate with other tools.
So which would I pick? Like any good consultant the answer is "Depends".
It depends on the size and complexity of the organization using the tool.
It depends on the target architecture and technologies used (e.g. one tool I did not classify above is JIRA/Grasshopper which is specifically used for Ruby development)
It depends on the level of contol over tool content needed (e.g. several tools were SaaS with concerns over security)
It depends on the sophistication of the developers.
It depends on the level of formality required of the process (e.g. if federal certification of the software is required then more traceability and reporting will be needed)
It depends on the risk accommodation of the users (Want to go with a small flexible rapidly changing tool/company OR stick with a slowly moving but more stable large vendor)
I did enjoy the exposure to the tools and we will be holding another shootout in the future.