There is a veritable plethora of agile product management tools on the market and probably more open-source or in-house efforts. All have their various strengths and weaknesses. However, no matter which product happens to be your favourite, there are many times on an agile project when you should remain logged out, and should not be interacting with any other computer-based tool either including MS Excel.

Turn them off in Collaborative Sessions

Personally, I do not think there is anything more irritating during a release or iteration planning session than watching a non-typist editing user stories and tasks in a web-based product. This is especially true of one built by over-zealous Ajax fans where every other click seems to require a trip to the server reducing the whole room to watching that little spinning circle for a few seconds while it does so.

Not only does this suffocate creativity in a blanket of frustration as the poor person struggles to spell 'retrieve' for the umpteenth time or clicks on the wrong menu option yet again, nearly all eye contact is lost during discussion as people focus on the mesmerizing image of the user interface beamed onto the wall. Not to mention, that for those sitting furthest away, the size of the font on detailed screens makes it a strain to read.

Even when the person operating the product is a competent typist and experienced user of the tool, there is often another problem. We have given that person a position of extraordinary power in what is meant to be a highly collaborative session. The person with the keyboard and mouse controls the input into the product. It takes an almighty effort to resist the temptation to not abuse that power and start saying things like, “I'll put xyz down until we decide different”, “I've created a user story in Product X to capture that ; we can break it down later”. If not very, very careful, the person with the keyboard and mouse starts to control the session.

A second downside of the use of agile project management tools is, quite bizarrely, a reduction in visibility. The use of index cards and colored sticky notes on large wall charts or corkboards, in a team room or near the coffee-machine provides almost unavoidable visibility and communication. If the use of a tool means that we replace these with beautifully formatted burndown charts and data displays visible only when running a particular computer program, it becomes too easy to not see them by simply not running that application.

In addition, while the index cards and sticky notes have a limit to the amount of data that they can physically communicate, it is all too easy to add more and more data columns and extra summary information to a software produced screen or print-out. Too much clutter makes it harder to see the wood for the trees. The detail overwhelms and communication is actually reduced.

I am not anti-agile project management tools. In fact, quite the opposite! I think some agile project management tools are great, in exactly the same way as I think some UML modeling tools are great. However, in both cases, I do not want them in collaborative planning or design sessions because the use of the tool inevitably becomes too much of a distraction.

Until we get user interface devices that can truly support collaborative group working in the same way that multiple whiteboards/flipcharts, index cards and colored sticky notes can, I strongly recommend keeping software-based agile project management tools out of such sessions. Indeed, it would be fantastic if we could forget about spreadsheets and web-based tools for managing projects, and rely only on index cards, sticky-notes, white-boards, cork-boards and flip-charts. For a single, small, co-located team we might indeed be able to do just that. However, for distributed teams and managing sets of teams across larger projects, programs and enterprises, it is not realistic.

Where we are using a spreadsheet or purpose built agile management product in a Scrum-style project, I recommend that the product owner always provide the relevant parts of the back log on index cards or equivalent printed media before a planning session. Then record the results in the tool at the end of collaborative sessions. If you are using Scrum, then the Scrum Master or Product Owner can serve the team by entering the results of a planning session into the computer-based tool of choice. Feature-Driven Development already has a points defined in its five processes for recording information from collaborative work. People may complain about the amount of time spent entering the data but I would much rather 'waste' one person's time entering the data after a meeting than have seven, eight or more people watching that person 'waste' time entering and updating that data throughout the duration of a planning meeting.

Choosing an Agile Management Tool

When choosing an agile management product, it is important to keep firmly in mind why the team needs the tool; what prevents the team from simply sticking with whiteboards/flipcharts, index cards and colored sticky notes, etc. One team that worked with identified and ranked the main reasons for needing something more than a low-tech solution:

1. The product manager had multiple sources asking for features, each with their own sets of priorities. He was struggling to manage the growing product backlog. He wanted something to help him group, sort, and filter the backlog contents so he could view it in different ways as he worked on setting business value and relative priorities.
   
   
2. Two members of the team worked remotely for significant periods. They needed to view and update the tasks in the current sprint/iteration. They could not do this if the only place the tasks were found was stuck on a wall in the project team's work area. E-mailing and phoning the team's scrum master two or three times a day to do this for them was becoming tedious and far from ideal.
   
   
3. The scrum master was looking for something that would automatically produce sprint, release and project burndown charts because while he was having to work with a growing number of teams.
   
   
4. The programme manager was also looking for something that could roll-up information across the growing number of project teams into a higher-level product backlog or project plan.
   
   
5. The team still had to work within a more traditional administrative framework where they were required to book their time against project codes in one of those typically obnoxious timecard systems. The hope was that they could automate this somehow by cross-referencing sprint/iteration tasks with these larger grain project codes, and have most if not all of the traditional timecard filled in for them from the hours they were marking against each sprint/iteration task.

Having enumerated these requirements the team was able to wade through the end-less feature-lists and different emphasis of the various products within their budget-range and select an appropriate one.

Other Thoughts on Selecting a Tool

1. Agility is about being flexible, frequently inspecting what is working and what is not and adapting to improve the ways the team work together. Forcing an agile team to use a tool that rigidly supports a particular agile approach like Scrum or FDD might work well for a few months but the team is likely to out-grow it after a few sprints/iterations if it cannot adapt with along with them.
   
2. Most purpose-built agile management tools are built around a traditional relational database backend. Few of these can answer general retrospective questions such as what did the project look like on such and such date in the past? Agile project management tools built instead on a versioning backend can do this.
   
3. Most agile management products are multi-user. Single-user products like MS-Excel can be almost as usable if the appropriate discipline and process is established around their use. However, this becomes harder and harder as the number and sizes of teams increase. Most organisations hoping to benefit across the enterprise from agile approaches are eventually going to need a true multi-user product.
   

Ironically, of the few products that I have used, one of the best has been the old Borland StarTeam CM product (now owned by MicroFocus). It needs appropriate configuration but the ideas built into it by the original StarBase company in the late 1990's were light-years ahead of some of the more recent purpose-built web-based products. It is a shame that the Borland team were unable to develop StarTeam to its true agile potential.

Microsoft's Team Foundation Server has a number of the same sort of ideas built into it but unfortunately many of these still seem very immature compared to StarTeam's and many seem to suffer from being implemented as a facade across a loose set of Microsoft backend systems instead of a truly integrated repository. Nevertheless, if Microsoft do manage to improve the quality, functionality, and ease of use of TFS, they will have a compelling product agile teams, especially those working with the .Net platform.