Are Agile Lifecycle Management tools worth it?

There are many well known agile pundits, practitioners and trainers that very specifically believe teams do not need to use any sort of tool to help with the agile process.  I no longer fall into that camp for a variety of reasons.

It is important to recognize successful agile teams are always using some sort of management tool, even if it is Excel or post-it notes on a wall.  Both of those are tools, just not tools specifically created to support an agile process.  Once we understand that all teams are using a tool of some kind, the “no tools are needed for agile” argument really doesn’t make much sense.  Instead the discuss-ment (discussion/argument) should be about whether we want to use caveman era tools or modern tools, and whether the cost of the tool makes sense.

In the past I would recommend teams learn the agile process while using cards on a wall so they focused more on getting the process right than on the specifics of a tool.  However, over the past few years the modern tools have become much more effective and can actually simulate cards on a wall very well.  Now I recommend teams that are considering a tool should do so very early rather than getting “good” with cards on a wall and then changing.  Change always has a cost, even if the change makes you better eventually.  If you fall into one of several categories of teams you should certainly consider using a tool as soon as possible.

There are some situations where a more modern tool is almost a necessity.  For example, if you have a geographically dispersed team it is going to be very difficult to use cards on the wall to track things.  That sort of team could use Excel, but personally I have never found a way to make Excel have all the necessary information stored in a way that made sense and was still shareable.  Perhaps someone has an Excel spreadsheet that works well for this.  If so, send a copy my way!  All the spreadsheets I’ve seen in the past have been too lightweight to do the job (my personal opinion).  In summary, a geographically dispersed team needs to use some sort of shared tool that makes sense.  This usually will imply a modern agile lifecycle management tool of some sort.

When else would a modern tool make a lot of sense?  In my opinion, any enterprise that has more than one product development team would benefit from use of a modern tool.  The ability to run reports, roll-up information, and see status across multiple teams and projects is something that no caveman tool will allow.  I’d rather have an executive get a report with a few mouseclicks than pay someone on each team to generate reports and then pay someone else to roll them together into one final report.  Worse yet, that final report is probably a couple of days out of date by the time the executive sees it.  Modern tools allow real-time reporting or in a worst case the reporting would be from the end of the previous work day.

One final situation I want to mention is the one that affects almost all teams – wanting to do things in a natural way that doesn’t generate waste.  If that is a goal, then a modern tool is what you want.  These tools are built around agile methodologies so the workflow can match the process being used.  They understand iterations and releases.  They understand defects and tracking.  They understand reporting.  In short, they are purpose-built for the job.

Of course money comes into play when making these decisions.  Some questions I like to ask are:

1. How much time will a product champion save by using a modern tool?  What is that worth?
2. How much time will a project manager save by using a modern tool?  What is that worth?
3. How much extraneous paper shuffling and reporting will be done away with?  What is that worth?

By themselves those three items will usually give a decent ROI on a modern tool, but then comes a kicker question – how much time will developers and testers save by working together in a tool that complements their combined workflow?  Modern tools save a LOT of time for developers and testers.  They work together seamlessly.  Delays are avoided.  Mistakes are avoided.  Quality software is created faster.  The cost savings here are substantial.

Since modern tools generally cost less per month than a couple of hours of pay per employee, ask yourself if getting a tool would make the average employee 30 minutes more productive per week.  In most cases the answer is yes, which means the tool is well worth the investment.  Heck, 30 minutes per week could be saved just by not having to walk back and forth to a room containing the cards on the wall (and having the conversations with people that come up while we’re in transit)!  Some tools are less expensive than others and maybe people only need to be 10-15 minutes more productive per week.

Finally, the two tools I generally recommend are VersionOne and Rally.  I believe they are the two most popular tools available today.  There are certainly others like Scrumworks and Target Process, but I am not very familiar with them.  Both VersionOne and Rally do the job and do it well.  Both also have free trial versions or even free permanent versions (with limitations).  I suggest you try both and see which one you prefer.

Even if you don’t fall into one of the categories above it may make sense to look at a modern tool anyway.  The free versions from either VersionOne or Rally may fit your needs, and that price is certainly right!