Update February, 2012: I’m currently seeking my next engagement as a Scrum Coach or ScrumMaster, so please contact me (You can use the “About” tab above) if you know of an opportunity.

I often get asked to evaluate a particular Scrum tool or to compare the relatively value of one to another. To be honest, tool evaluation is not something I spend significant time on. Most teams I coach have little choice about which tool to use, so I usually just a) try to encourage them to use more manual techniques and b) help the team adapt the tool usage to their optimum performance/usage, which sometimes means no usage.

Reason 1: Tools often hurt more than they help. (Decreases Productivity)

The vast majority of the time I have seen Scrum teams extensively using a tool, it is wasteful or aids in creating poor habits. It’s pretty hard to justify spending money on a tool that decreases overall productivity. I’m amazed at how many companies do this. I also believe that most of these tools have a huge amount of bloat in them, and thus the bloated features either a) obscure the needed features or b) waste a lot of time with very little ROI in terms of value.

Bad Habit # 1: The worst habit they encourage is that they often obscure transparency by hiding data inside the tool that has to be …started up, logged into, and menu driven to the point of wanted info. Transparency in Scrum is VERY important, which is why I favor more manual techniques. This obscurity is extremely widespread as it affects the product backlog and/or stories, sprint backlog tasking, teamwork, optimizing with a burndown chart or other sprint progress monitor, etc. Transparency aids in inspection and adaptation, so the converse is also true: obscurity detracts from inspection and adaptation and thus, detracts from the empirical nature of Scrum.

Bad Habit # 2: They discourage mis-use of good techniques. For instance, in many tools, there is no direct support for story tests/acceptance tests directly with the User Stories themselves. One tool at least allows some basic html formatting and tables so that you could put in some concrete examples like those that are encouraged by the “Specification By Example” technique. However, that tool’s HTML formatting is very clunky and far inferior to any decent wiki.

Bad Habit #3: Having a tool encourages double entry. I’ve seen teams where, because they were forced to use a tool but also wanted a good Scrum Board, had to do double entry of the same information. Giant waste of time.

Bad Habit #4: A tool encourages mis-use of metrics created by Scrum related data such as velocity. Many managers and executive types will try to do draw incorrect conclusions from data tracked in such a tool. Yet another giant waste of time. The managers and executive types should instead be focusing on whether the users of the system are getting value out of the features that are being provided. While some management has a responsibility to focus on productivity in software development, micro-analyzing the Scrum data is not a good way to do this.

Reason 3: The development team usually has the tool forced upon them, or usually has no choice but to use a particular tool. (Decreases Self Organization)

Besides the normal effects of top down mandates (poor adoption, minimal ROI, etc), the elephant in the room created by mandating tools is that it greatly harms self organization on a Scrum team. Mandating particular tools or tool usage is just another form of command and control management. To achieve Scrum’s benefits, self organization is absolutely vital, which means, when it comes to tools, the team should be able to make their own choices. I want the team as a whole (and preferably not the ScrumMaster at all) to create, maintain, own, love, and care for their own artifacts. Having said all of this, it’s perfectly acceptable for management types to try and organize company strategy around goals and timelines — I just don’t believe that Scrum software tools are a good way to do that.

In Conclusion…

There, I said it… I’m generally anti-tool for Scrum artifacts and data.

In a future blog post, I intend to talk a little about some special contexts in which I think tool usage is ok, and about my general views as to the kinds of tools that I like. Teams where multiple members are working mostly remote is one exception to my generally anti-tool stance. I’ll talk more about that in the future post.

> distributed teams
Generally agreed, though it still depends on just how distributed the team is, who is distributed, etc. Sometimes you can get away without a tool if the team only has a small amount of “remoteness.”

As for tracking stories in a product backlog and tasks on a Scrum board, the best strategy I’ve seen is to only put stories in the tool, and then all tasks are managed on the physical board. If needed, one can put story acceptance tests/criteria in the tool, or linked out from the tool to a wiki(what I generally prefer, since most tools don’t allow tables and other good formatting).