Agile Project Management Tool Evaluation Guide

Posted on July 13th, 2009 in Agile by siddharta || No Comment

It seems that the only agile project management tool evaluator guides around are written by tool vendors and the “guides” are carefully constructed to highlight the positive features of the tool. Well, we’re tool vendors too, but in this post we’ve tried to take a more neutral path. Of course, the bias cannot be fully eliminated :) We welcome your comments if you have an alternate point of view.

First thing: Decide why you want a tool

What is the purpose and what kind of value do you feel it might add? Do you want a tool so that the team can organise themselves better? Is it for management to get better visibility? Do you need it for reporting? To coordinate with distributed teams?

You need to be absolutely clear about this. Many teams adopt a tool just for the sake of it – and then find that it is more of a hindrance than a help. In such cases you are better off using no tool and sticking with paper, pens and charts.

Once you are clear on why you need a tool, think about the type of tool you want. Tools can be either supportive or disruptive. There is a fine line between the two. Unfortunately, many who are new to agile don’t focus on what is really important.

The Four Primary Factors

Does the tool improve visibility?

Agile requires transparency to succeed. Can everyone who needs to know about the project from the developers to the stakeholders and maybe even the customer be able to use the tool? There is no point using a tool if only a ScrumMaster or a few people can use it and everyone else has to rely on email.

Does the tool improve communication?

For example: Do team members start “reporting” status to the scrummaster so that the tool can be updated with their status. This is a common dysfunction that can occur with a tool and can reduce communication – ultimately leading to project failure.

Tools can be used to open up channels of communication. For example, allowing a developer to comment on a user story and have a remote customer reply back – setting up direct communication between developer and customer and bypassing all the bureaucracy in the middle.

Does the tool reinforce trust?

Example: A team member forgot to update the estimate for friday. He remembers on monday. Can you set the estimate for friday on monday?

In a “high trust” tool like pen & paper: you can just pick up a pen and redraw the burndown. In a “low trust” tool, you cannot do this because it is considered as meddling with the past recorded history of actions.

Does the tool adapt to the way you work?

Each team is going to use the tool differently. Some tools adapt to the way you work, other tools force you to work the way the tool is setup. Because of the self-managed nature of agile, it is important that the tool support the team, and the team should not have to change their working to fit the tool.

For example, a tool may enforce a particular workflow, which may not be the way the team works.

Secondary Factors

Standalone, monolithic or integrated?

Standalone tools do only agile project management. You can create users, stories, iterations and tasks and generate some reports like burndown or velocity. Basic, but useful when you want something simple.

Integrated tools do only project management, but they can integrate with external tools, like other bug tracking tools, source control, wikis and so on. For example, you will be able to synchronize bugs from the bug tracker to the PM tool, or link tasks in the tool with code commits and so on. They can provide an overview across multiple tools in use.

Monolithic tools support the entire lifecycle like document management, bug tracking, artifact management over and above standard PM functionality all within a single tool.

Advantages of monolithic are that all components are tightly integrated. Disadvantage is that you have to discard all your existing tools to move to a monolithic one. Also if the monolithic tool does not support a particular component (like continuous integration or code analysis) you may still have to use multiple tools.

Usability

How usable is the tool? When you have poor usability, people may resent working with the tool and might start working around the tool instead. Tools with poor usability may also call for additional unplanned expenditure in training and support. You also have issues of general resentment by the team at whoever foisted the tool upon them.

Pricing model

Is the tool open source, free or commercial? For commercial tools, it the pricing per-user or per-project? Subscription or one-time payment? What is your risk exposure should the team size or number of projects increase? What is the total cost of ownership, including training, support, customizations etc. How does it fit your budget?

For our take on per-user vs per-project, click here.

Finally: The Feature List

Most who are new to agile tend to look at the feature list first. We think this is the last thing to look at. All the features are no use if you end up reducing communication or trust.

Most agile tools support all the basic features like stories, tasks, iterations, burndown and so on. There are a few variations that may have an impact on your decision. Some tools allow you to create any kind of hierarchy of projects, iterations and features. Some have more reports, some have less. Some allow you to change terminology, some don’t.

These could be important in certain type of projects, and if you think so, you should keep a look for them. On the whole, apart from some features that you may need specifically, they aren’t going to be total deal breakers the way the primary factors are going to be.

Summary

So here then are the questions you need to ask yourself when choosing a tool.

  1. The FIRST question: Why do you need a tool?
  2. The four PRIMARY factors
    1. Does the tool improve visibility?
    2. Does the tool improve communication?
    3. Does the tool reinforce trust?
    4. Does the tool adapt to the way you work?
  3. Secondary factors
    1. Standalone, integrated or monolithic?
    2. Usability
    3. Pricing model
  4. Finally: The feature list

Doing Distributed Agile?

Share and collaborate with distributed teams with our electronic agile board tools. Get all the benefits of electronic tools without sacrificing the benefits of physical boards. Supports Scrum taskboards, Kanban boards and user story maps. Check it out!

Leave a Reply