My favorite agile software development topic of them all — tools. More specifically, agile project management tools. If you’re old school, you bust out some index cards, some butcher paper, some writing utensils, and you get to work. If you’re trying to use one of the simplest of agile project management software tools (that most are introduced to as part of their Scrum training), then you open up an Excel template. If you’re looking for something a bit more comprehensive or even just a little more automated, then you do a search on Google for “agile project management software”. You click around, see quite a few options, look at some screenshots, screencasts, and likely research mailing lists and blogs to see what people think of these tools.
At some point you’re likely tempted by some vendors making amazing promises. These vendors aren’t simply selling software project management tools; they’re selling you the keys to enterprise enlightenment. They show screen after screen packed full of nondescript icons, drop down menus, and incredibly detailed forms that make you wonder how you got by in the past without tracking all that information. They integrate with version control systems, integrated development environments, issue trackers, testing tools, portfolio management systems; some will even have integration with customer relation management systems. What more could you want? A lot more. Actually, a lot less. But, as the saying goes, “less is more.”
The problem I see with a number of the agile project management software offerings available today is that they have lost sight of what it is to be agile, at least when it comes to managing their own products. It seems like these solutions are trying to be all things to all people. Featuritis has hit these products in the worst way. I think the UI designers of these products were forced to get their daily dose of inspiration through slide shows of Enterprise Resource Planning (ERP) software screen shots and other “enterprisey” offerings that cause many of their users to go home each night wondering why they can’t master the art of using the software to get their jobs done more efficiently.
Beyond the usability issues I see with this new breed of agile project management tools and the attempt to “be all things to all people”, I think these tools are missing the mark in an even bigger way. If you want to provide the ultimate agile project management software, then you might as well leap frog the old project management tools by looking at what the open source community is doing and using. The offerings by sites like java.net, Sourceforge, and many other open source project hosting sites are where these agile project management vendors likely need to turn their attention to. There is a reason tools like Trac, Redmine, and others are utilized by more and more open source projects to manage development of the software. These tools acknowledge the need to manage the software development process in a distributed environment where there can be many contributors and many users. 
The focus of these tools does not start with a project manager view of the world, but rather with a project contributor and user focus. This means that an issue tracker becomes the central nervous system. Version control is a first class citizen, not something you leave for third party integrations. Mailing lists, forums, and RSS/ATOM feeds are often key features in these open source software project management tools.
I will admit to being biased in this post. I am not a fan (in general) of most software that is aimed at the “enterprise.” I believe that many of the best practices in open source software development should be adopted by agile tool vendors looking to address the problems faced by those involved with software development projects. I’ve held off writing a post about agile project management tools for over a year now, but after recently re-evaluating the options out there I felt it was time to give my thoughts on the topic. It’s a way more popular topic than it should be in my opinion. It’s much easier to talk about the merits of one tool over another than it is to address the more difficult (and more critical) challenges involving changes required in human behaviours.