Any "Agile" tool which isn't subscription based isn't trustworthy. But that's probably just my Web 2.0-Cluetrain-Conversation bias coming out.

The problem is that "Agile" has been formulated and structured at this point, and many "Agile" teams don't really have the kind of meta-process thinking that the whole thing was originally based on. To many teams (including a fair percentage of the ones I've been on), "Agile" means story cards, planning sessions, iterations, retrospectives, and burndown charts. There's never a conversation about whether that's really the right way to go, and throwing out that structure in favor of trying something which might (but might not!) work better looks like a failure to the Agile consultants brought in.

So, if you're locked into a process, you might as well have a tool which helps you work that process.

Further, there's a major awkwardness with Agile and long-term planning. Managers and executives used to asking "When is this going to be released?" and then structuring their business around the answer have a lot of problems. So there's suddenly a lot of demand for software oracles which can divine these facts. In all honesty, I don't blame the executives and managers for wanting those numbers: it's hard to tell the marketing or sales department what to do when the technical reality of the project is ambiguous. And the "old ambiguity" of projects running late to deliver is familiar -- but the "new ambiguity" of Agile brings with it control, responsibility, and decisions which require more knowledge and work.

I am a QA engineer for one of those evil tool vendors. In fact, I spent 18 months or so on the team that developed Borland's new agile management tool (I won't name it or link to it since I don't want to appear to be a spam/marketing droid), and I worked the booth at the Agile 2008 confernece last week, where we debuted this tool (yes, we do have cool drag and drop, Ajax-y stuff in our UI).

When I started on the project, I struggled with some of the same issues you mention. My thinking at the time was: we're developing a tool to manage a process that's so lightweight that it shouldn't need a tool.

And as far as the teams themselves are concerned, I still think that's pretty much the case. But that's where 'enterprise' comes into the equation. Borland has something like 13 agile dev teams in at least three locations worldwide. If we're using cards only, management would have no direct visibility into the teams' progress. However, if the teams have their relevant data in a tool, then management can see our sprint progress and other info directly. Management find direct data from the teams much more trustworthy than someone who manually prepares a PowerPoint summary of progress each month, which would be the alternative without an agile management tool.

(My assumption is that that is management's job and responsibility; I'd like to leave that assumption out of the discussion for now.)

At Borland, we're very fortunate that management fully embraces and, in my opinion, 'gets' agile. The types of data that they want to see, for example, is team's average velocity, the number of sprints remaining until release and the rough estimates of the next prioritized stories in the backlog.

Based on that info, they can monitor how many more stories the team is likely to complete for the release and make plans accordingly (change the release date to get all desired functionality in, or plan for more or less functionality than originally planned, for instance).

As far as the team's tool itself goes, our goal is to make it flexible and easy enough to use that it doesn't add any significant burden for the team to use it over cards. We don't claim that it's better than cards, just that its use fulfills the 'enterprise' needs outlined above.