Kelly Waters posted an article recently asking what Agile project management tool folks recommend.  Interesting results so far, but from other discussions I’ve been involved with on Linked In and general conversations with other crazy Agile people most of us recommend no software tool to start with.

It’s MUCH more important for teams to understand how to work in an Agile process BEFORE they adopt a tool.  Agile teams that are co-located use sticky notes, spreadsheets and whiteboards to manage their work and it is extremely effective.

What this poll isn’t saying providing is context around who is voting and what their environment is.   A decision maker who knows nothing about about Agile is probably more inclined to pick the tool first and base that decision on the most well known or “enterprise” version of the software that they hear other people use.

Remember, we value individuals and interactions OVER processes and tools so figure out what Agile is and learn the process BEFORE you worry about the tool.

What tool would I recommend?  Well, first I would recommend sticky notes, whiteboards and spreadsheets/wiki until the team learns and really gets what Agile is.  Once they know what being Agile is all about and management “gets” what it means, I would recommend either JIRA, Rally or Scrumworks.  Rally is GREAT for enterprises, JIRA is great if you want a tool that can do it all and Scrumworks is really lightweight and simple.

Here’s the poll is you’d like to see the results.

Recommended Agile Project Management Software | Agile Software Development Made Easy!.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

When using Scrum, your iterations are fixed time (1 week, 2 weeks, 30 days etc) and therefore your cost is fixed so the only thing that can vary is scope.  Time-boxing is critical to success when implementing Scrum since you don’t really want to waste a lot of time in useless or long discussions.  Yesterday I posted about an estimation session that went off the rails pretty quickly and it was due to the fact we (well, “I”) dropped the ball on enforcing the time-box rule.  We started strong and finished weak.  A stop-watch, wall clock, phone/pda or whatever is fine to use.  I like to use this online tool.  You can set the timer for whatever interval you want and it’ll beep when your time is up.  I typically give warnings at 5 minutes to go and 2 minutes to wrap it up.

Our iterations are 1 week (we’re re-implementing Scrum, so the shorter the better to allow the problems to surface quickly) so we use these guidelines for time-boxing:

• sprint backlog: 1.5 hours – this is where the team commits to their work and break stories into tasks.
• development activities:  1 hour -  If you’re stuck after an hour, ask a team member
• ’stop the line’ discussions:  15 minutes -if a team members runs into a roadblock, the whole team stops and a quick 15 minute brainstorm session happens.  All potential solutions are written on the whiteboard and then the line resumes work.

The biggest question the team always has around time-boxing is “what happens if the meeting is over and we haven’t finished our task breakout?”  The answer is simple:  The meeting is over.  If you didn’t meet your goal, schedule another discussion or in this case, when it comes time to work on that story, time-box the task breakout to 15 minutes.

The lesson is, by time-boxing your efforts you force yourself into focusing on the issue or discussion at hand.  It’s tempting to allow a couple more minutes here and a couple more minutes there, but avoid the temptation.  The team will get into a rhythm pretty quickly and be much more efficient at time-boxing.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

One of the Scrum values is the idea of Individuals and Interactions over Processes and Tools and that doesn’t mean processes and tools have no value, it simply means that Scrum values individuals and interactions more than processes and tools.

The key meaning I picked up from that is your tools and processes should be valuable enough to support your Scrum process and not hinder it by introducing more overhead than necessary.

JIRA: We’ve been using JIRA for just over a month now for all customer projects, internal projects and customer support. We’re using a ‘virtual agile wall’ plug-in that makes it easy to see what’s in progress, not started or done in a sprint. We’re also using a pretty cool plug-in from Green Pepper software that allows for easy manipulation of backlog items as well as creation of burndown charts.

One of my favourite features is being able to easily print out story cards for our real agile wall so we get the benefit of tracking and the visuals in our work area. We’re also using Atlassian’s wiki (Confluence) which will be the topic of a future post.

It also can integrate with various IDE’s as well as SVN so you can associate defects (which there should be none, right?) and backlog items with your code.

Card Meeting: It’s not ready for prime-time yet, but this is a wicked electronic version of the Agile wall.

Scrumworks: I have limited experience with this one, but it’s a really quick and easy tool to manage your product backlog. If you just need a simple tool to manage your software development projects, this is a great one. It also integrates with JIRA and Bugzilla but the biggest benefit over JIRA is that it has out-of-the-box metrics like ROI and business value calculations.

I’ll be posting more information with details around our JIRA implementation in the future.

Related posts:

1. Recommended Agile Project Management Software Kelly Waters posted an article recently asking what Agile...

Related posts brought to you by Yet Another Related Posts Plugin.