Some time back, I whined about not having a good agile project tool.  Times have changed:  four years and two jobs later I’m happily doing Scrum development using Rally.

It didn’t happen overnight.  Red Hat is a big consumer of Bugzilla and in the beginning of our project, we agreed that rather than adopt the existing tool-du-jour (XPlanner) in addition to Bugzilla, we’d stick with what we knew well and build a process around that.

It worked, sorta, but we quickly became hindered by Bugzilla’s lack of anything resembling a workflow. We’d file user stories as bugs but since the tool is so cumbersome to use, we’d rarely task them out properly.  Some things would slip and other things would take scrum team members by surprise.  I’m no fan of Bugzilla, but in Mozilla’s defense, they aren’t really trying to do agile.

We decided as a team to adopt Rally since we already had some seats set aside for it.  I’m happy to report that thus far (half a sprint in), we’re pretty pleased.  It steps up in all the places Bugzilla falls over:

• Dead simple creation of tasks per story
• Resource management
• Implicit grouping of tasks under a story such that hours/progress are aggregated meaningfully
• Quick in-place editing (BZ languishes in web 1.0)
• Built-in workflow & reporting designed for agile development
• Useful dashboard that displays rich information about the current sprint (tasks, defects, blockers, burndown)

We’re still deciding what to do with our large Bugzilla backlog, but it turns out there may be a plugin we can use.  If we go that route, I hope to have time to blog about it in a future posting.