Agile planning tools.. paper or ‘plastic’?

Ivan Moscoso, Wednesday, February 13, 2008 @ 6:00 am

How often have you heard, "Yeah it's not great, but it's the best thing out there", or maybe "We spent two months investigating this tools and there's no turning back. End of discussion. We're not going to switch again!" Does anyone ever hear anything like that when your only tools are whiteboards, paper, pencil and a wiki? What's there to change? The color of paper? Illegible handwriting? How long the walk is from the kitchen to your story wall? These are cheap to fix, and anyone can affect such change more easily when the materials you have to work with don't require logins, passwords, user permissions, mouse clicks, overhead projectors, VGA cables, and a fully charged laptop in a meeting room.

I have used many kinds of planning/tracking tools throughout the years. A recurring belief that crops up all the time is one that suggests that the biggest factor preventing a team from being more agile is the absence of a "proper" agile planning or tracking tool that will satisfy everybody's desire to (you guessed it) be more agile. I find this strange to say the least.

Ron Jeffries said it very well here:

When you're working with a tool, someone
owns the keyboard, and everyone else is an observer. It's easy to
develop the habit of "check the database" instead of "talk with each
other". It's easy for a manager to think that he's managing the group
when he's really looking at his screen.

Might a team need a tool like these? Well, yes, they might. But to a
team just learning XP or Agile, I'm very concerned that the tool will
get in a way.

And now, a few words of advice...

I believe these tools hinder just as easily as they can help, hiding what is wrong in your process to the detriment of both the team and the customer. More to the point, while they all have their own specific faults and shortcomings, seeing these types of shortcomings in a software tool is much worse than seeing them outside a tool. When a team decides to change the process between people ('people over process', anyone?), it's changed; no relics of the old way remain.

Contrast this with almost any software tool, which does not empower others to own the process the same way. It's easier for others to just go on autopilot than point out what they don't like about a tool, or tune out knowing that change can be difficult if it means giving up that specific tool for a new one with a different set of shortcomings. Or maybe they decide to ignore some parts of the tool's stated functionality, but reminders of that functionality still linger, hanging around like a bad dream. Eventually someone will ask "what's that column for?" and someone else will shrug and answer, "I don't know, I don't think we use it. I guess you can just ignore it." (Yay team...)

I think people can benefit from realizing a few things:

1. If you can't do it without specialized software, you need to cut the cord for a while and try to live without it first.
2. The tool that worked very well for your last project may not work well at all for the next project. The same applies for the team-- don't expect every team to take to the same tool the same exact way as the last team (realizing this is part of being agile in the first place).
3. Never let a time tracking tool be your only guide for measuring progress or velocity. You will end up with good looking, possibly meaningless data.
4. Weigh the increase in productivity for '1' user of the tool (e.g. a product owner generating weekly reports or harvesting burn down charts), against the slight loss in productivity of 'x' developers using it constantly to perform data entry. Understand that the latter cost (in time, money, effort, focus or morale) is never "zero".

Yes I know it's nice to have a single authoritative source for planning and tracking (so much the better for distributed development). Yes I know it's nice to have things like history and versioning available throughout an iteration. Yes I know it's nice to see burn down charts generated for you on a dashboard. But really, honestly-- how often do you actually benefit from history and versioning (is it a problem of trust? are you not capturing what you need to capture somewhere else?) And how much more time does it really take to talk to a few people before updating the burn down chart by other means? And (to the point concerning distributed teams)-- are you picking a tool that reflects how people on both sides of the wire would already work in its absence, or are you effectively punting-- instituting a process around a tool at a point in time when you don't yet know how else to improve communication?

Once you feel confident answering those questions, the move to the right tool should feel natural, never forced. If it does, then you need to hold back and figure out the right way for your team first.

agile ajax

Comments: 1 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. 

   I think it works best to think of the online ‘tool’ as an extension of internal practices. If your team doesn’t communicate and collaborate well offline, it won’t help to throw them into an online environment. At my company, we rely heavily on whiteboards, post it notes, quick review meetings to get everyone aligned, and lots of paper and ticonderogas for sketching out design ideas.

   We never did find a tool that felt ‘natural’ (this was many years ago when there were fewer options), so we rolled our own to meet the workflow needs of a busy web development shop. Check out Intervals, as you might find your needs similar to our own.

   http://www.myintervals.com

   Comment by John, Thursday, February 14, 2008 @ 11:10 am

Leave a comment