Agile Tool Selection
The question of which agile tool a team should use comes up again and again. For some reason this always seems to generate a fair amount of debate, research, analysis and hand wringing that most projects could simply do without. Perhaps any debate about tools on an agile project is a little suspect, given that the first agile value on the agile manifesto (http://agilemanifesto.org/) is: Individuals and interactions over processes and tools. But there is the practical need to having some system in place to ‘manage’ the work – particularly with a distributed team – that good tool can support and be of great value to the team.
My preference for an agile project is to start out as simple as possible – hand written story cards pinned to a cork board with yellow post it notes for the task break down. To calculate metrics (velocity is really the only one that I care about early on) and generating the Release Burndown (or Burn Up) charts and the sprint burndown chart can easily be done with some daily data entered into a spreadsheet. (It may take 5 minutes a day to enter this data after the standup meeting – at most.) This keeps it simple, easy, and focuses the team on getting stuff done – not creating metrics for the project.
The only drawback to a physical taskboard is that it really works best with a co-located team. I always suggest that you start with a dedicated, co-located team when starting an agile project, but it is not always possible to do so. (You can, of course, “do agile” with a distributed team – it just requires different support.)
When working with a distributed team – it can be very helpful to add some web-based tool support to the project to make it easier to manage the backlog, view who is doing what, and capture daily status data needed to create the sprint burn-down chart(s). So, what tool do we select for this support?
Selecting a Tool
The short answer: Find something that works for the team, but don’t spend a lot of time doing it.
What works well for one team, may not for another – but in my experience, there are a few things that teams typically want from an agile tool. I have listed these in the table below and indicated their relative importance:
Using these as the key features for selecting a tool, I have compared some of the market leading tools in the matrix below:
Looking at the feature set and the products in the market, you can see that many of the products are competitive with one another on a feature by feature basis. It really comes down to deciding how much you want to spend and which UI (UX) you find the most comfortable.
I usually suggest making things simple and going with a Market leader like RallyDev or VersionOne and be done with it.
Again – find what works for your team, but don’t spend a lot of time on it. Focus on getting the work started and getting something done!
Enough Already!
I found this site with a list of current agile tools: http://agilescout.com/best-agile-scrum-tools/. This goes well beyond the subset that I put my comparison matrix above. There are just too many tools out there all doing pretty much the same thing. I get back to my original point – for most teams I am not sure it matters which tool you select. If the tool supports your team in a low-friction way – and it works for you and your stake holders – buy it, and get started on doing the work.
Recent Comments