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
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
'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:
- 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.
- 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.
- 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.
- 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.
- 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
Other Thoughts on Selecting a Tool
- 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.
- Most purpose-built agile management tools are built around a
traditional relational database backend. Few of these can answer
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.
- 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.