Agile Project Management Tools – The Missing Key. Part I

It’s obvious for me that almost all existing Agile Project Management Tools (including TargetProcess on it’s current stage) do not bring many benefits to software developers. Yes, they might help to resolve some problems with remote teams, customers and project stats, but they just don’t as effective as they could be. The key point is automatization. I am not sure that most agile teams like the automatization provided by agile pm tools.

Many agile teams like simple tools (me too). Big whiteboards and walls with big charts, cards, and all the other staff like that. Why did they want to use any Agile Project Management Tool? To move user stories description from cards into database? To have a possibility to check project status online? To assign tasks via fancy web interface? I don’t think so. This will not speed up the team, so they’ll likely decide to not use Agile Project Planning Tool unless they’ll have to. For example, project stakeholders want more formal reports about project state. Or maybe two of six developers far far away from the rest of the team. Yes, these circumstances will FORCE team to use a tool like VersionOne or TargetProcess, but the team likely will not WANT to use the tool.

So I think that planning and tracking features resolve just several secondary problems, but, in general, do not help to plan and track project. Yes, people are different, and some of them like using web-based application instead pencil and paper, so agile pm tools have they place. But I still think that these tools provide a little of benefits having the following disadvantages:

  • they might reduce voice communication in the team (but may not, this depends)
  • they usage may take additional time (how about bugs? learning curve?)
  • they always have limited functionality thus restricting team creativity about planning and tracking. For example, team invented very cool report format for project progress state, but they couldn’t create it in the current tool.
  • sometimes they cost pretty much. Maybe it is better to upgrade all workstations? At least this will boost performance for sure.

Let’s take a look at possible advantages (we’ll suggest that team is co-located and it don’t forced by customer or top management to use any planning tool).

  • all requirements are in a single place. PM and customer might feel safer in this case.
  • team have a possibility to easily track time spent on each user story and create a better estimate (however, I don’t think that time tracking is always a good idea, but sometime it is).
  • a little automatization (velocity calculation, user stories sorting by business value, release date estimation).
  • project history tracking. It’s useful to analyze previous projects to identify issues, but more better solution is just ask someone from the team that worked on that project.

Maybe there are some other benefits, but I doubt that they are very important. It seems that disadvantages have greater weight… So agile teams likely do not stick to web-based tool.

Ok. For now we’ve found two cases when agile project management tools are useful, but really helpful tool should simplify and automatize some routine processes. Let’s imagine what could it be. For example, tool may shipped with very cheap printer of A2 format and allows to easily print BVC (well, I guess how much you’ll spend on paper :). Or it can be shipped with pretty cool device that will automatically print out user stories’ cards (card format must be changeable). Any other ideas? Yes, good scanner with hand-written text recognition app, so you’ll just put all cards into special device and within 5 minutes you’ll have all the cards in the database (Wow! I’m already loving this device). Well, enough for now.

I see that all the ideas above are pretty similar. They all help to convert electronic data (database) into physical format (paper) or vise versa. It is required to say that there are two viable possibilities for agile project planning:

  1. Use almost only paper and big boards
  2. Use almost only software application

The third approach is to use both, but in ANY case this WILL take additional time to convert data from one format to another. And these formats VERY different, so there is no easy way for automatic convertion.

In fact, software agile project management tools force teams to not use simple original tools. And this is the main problem. It can’t be resolved easily and quickly. All possible solutions are expensive and a little bit crazy I think.

But why quite many agile project management tools have been appeared during the last several months? I don’t know. Maybe their creators have clear vision and could answer this question better. Could agile project management tools bring more benefits? Yes, they could. Some thoughts about possible ways will be discussed in the next article.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s