(I originally posted this on my MSDN blog.)
A frequent question on the internal email groups around here is, “My team is going to start using Scrum and we need to find a good Scrum tool to use for tracking everything. What tool should we use?” Usually these questions come from teams who have a tradition of metrics-heavy, documentation-heavy process with lots of artifacts. The assumption behind the question is that Scrum is also a metrics-heavy, documentation-heavy process, just with different artifacts.
My answer is that Scrum is a philosophical and cultural shift. Scrum is highly ceremonial in some respects, but the ceremony is all oriented around face-to-face, real-time communication, not artifacts. If your team is geographically distributed then yes, you’ll probably need some artifacts to compensate for your lack of face-to-face communication, but remember that Scrum is not about artifacts. Unfortunately, most software-based Scrum tools are about artifacts to a greater or lesser extent, which makes them less useful than you might think at first.
Low-tech Scrum tools like sticky notes and whiteboards are not glamorous and of course it seems somewhat heretical that software developers might eschew software tools in favor of old-fashioned paper, but there are lots of advantages to be had. You can make pieces of paper behave precisely the way you want them to with very little effort, and physical objects offer visual and tactile feedback that’s hard to beat.
I usually track my product backlog electronically in a spreadsheet because it can get large and I want to do a lot of sorting and filtering on it, but I prefer to track my sprint backlog on a whiteboard because its size is fairly bounded and I don’t do a lot of arbitrary manipulation on it, and half the value of the sprint backlog is in seeing physical objects up on a wall and moving them from place to place. It gives you a sense of flow and progress like nothing else can.
However, if your team isn’t ready to make the cultural shift to low-tech Scrum all at once (it takes time!), or if you have a distributed team, then yeah, there are some tools out there that can work decently well. But beware: any tool you adopt will come with some built-in assumptions and ways of doing things. When you adopt the tool, you adopt the entire philosophical mindset behind the tool (or you spend a lot of time wrestling with the tool for control of your philosophy). If your needs and views are compatible with theirs then all’s well, but if you differ then it’s going to be painful. There are several nice things about sticky notes and whiteboards but one of the biggest advantages is that you can customize your process to your precise needs. Agile processes should exist to serve the team, not the other way around.
One excellent description of a low-tech approach to Scrum can be found in a free eBook titled Scrum And XP From The Trenches. It’s a couple of years old now (which at the rate agile thinking evolves these days is positively ancient) but it’s still an excellent guide and source of ideas. And because it’s low-tech it’s easy to tune it to your needs.
SaintGimp 