One of the many hats I’m wearing at work these days¹ is project manager for an OEM deal we’ve done with a company that’s going to be bundling our core product with their own. As part of this I’ve had to produce several project plans and I’ve found myself reaching for Microsoft Project to draw up Gantt charts showing milestones, delivery dates etc.

I’m not as comfortable with this as I used to be. About three years ago when we began what was a ground-up redevelopment of our core product we decided to adopt agile practices, specifically XP, within the development team. Apart from a few initial hiccups, mainly caused by misconceptions on the part of those of us who had no prior experience of XP and some management buy-in problems, it’s been a good experience and quite successful. One side-effect of the experience though has been to make me wary of more traditional planning and PM techniques including using Project and the venerable Gantt chart.

However this particular project is a bit hard to run using the full agile toolbox. That may just be because in the last year we’ve switched from core development to substantially more customer engineering work and we haven’t yet adapted our agile experiences to this new situation. There are some specific factors in play on this project though. For starters there’s only one developer working on the section of code that needs to be customised. Obviously this isn’t an ideal situation² but we’re currently seriously under-resourced and there are only so many different hats people can wear at the same time. Despite there being probably enough work for four 2-week iterations the customer isn’t particularily interested in scheduling that work, they’re only interested in getting the final set of deliverables by a fixed deadline. Indicating project progress in this case could be done in terms of units of work completed, units remaining and current velocity but how do we give them an overall plan for delivery from the start in a format that they’ll understand (i.e. with dates)?

I have to admit that I really like Gantt charts. I know that there’s quite a bit of opposition to using them as part of the agile process but I think that has more to do with how they are used in traditional waterfall-style planning as opposed to what they are themsevles. They way they tend to be used means that they inevitably become little more than the World’s Greatest Studyplan³, going out of date as soon as they are produced. I’m also a beliver of big visible charts however and I think they can be very useful in conveying a lot of information. There are a few problems with them though in the agile context.

1. How do you show stories that haven’t yet been assigned to an iteration?
2. Stories/tasks need to be represented in in arbitrary units of work (we use gummy bears) rather than a number of hours. Project doesn’t currently allow you to do this.
3. Having estimated stories in gummy bears, you need to be able to apply the current velocity to this to show how much work is expected to be completed in each coming iteration, with the effect that has on milestones/completion dates etc.

The ideal tool for me would be a Gantt chart generator that tracks project velocity over time and applies the latest velocity to outstanding stories. At the end of each iteration you could get a management-friendly graph of current progress (the completed stories) and expected future progress (incomplete/unassigned stories) based on the current velocity. Sure, this would be an estimate but it would probably be more accurate than the way most people use Gantt charts anyway. It would certainly be more up-to-date. Another benefit, I feel, would be to give the Customer a very clear idea of the impact of prioritising or dropping stories on a project end-date. If they wanted a release by a certain date, the Gantt chart would show them what they could get by that date by moving stories around.

It won’t help us on this particular project but I’ve started a review of some of the currently available agile project management tools out there to see what they provide. I remember looking at what was out there some time back when I was in the Tracker role on our core product development and not being too overwhelmed. In the end I drafted a spreadsheet that worked for me but was too unwieldy for the rest of the team to use. The graphs that were produced were informative though, showing team velocity over the course of the project, traction (the % of time in an iteration that the team was able to spend working on gummy bears) and the burn-rate on stories but I just never got past the feeling that they were more historical than predictive – which is what you really want.

XP zealots will tell you that all you should have are some index cards and a whiteboard. Fine if that works for you but I like pretty pictures and we have computers to do the work for us these days. I’ll keep you posted.

– Fintan [listening to Arctic Monkeys]