Jira for agile projects? Get GreenHopper

I previously blogged about trying to use Atlassian Jira as an agile project management tool. My current client already uses Jira across multiple projects and they are reluctant to change tools or spend for new tools. We use Jira "versions" to define iterations. Jira items without a "Fix for version" are part of the product backlog. We installed the free Jira plug-in Custom Issue Order which lets you set the absolute order (rank) of items in a list. Here's a screen shot of it in action, with the "Rank" column added.


We also installed the free Agile Velocity Tracking plug-in.

So far, I must say I'm not particularly happy with the results. It works, but I find myself yearning for a tool that was truly designed to accomodate agile development. Some specific things I don't like:

• I can't drag and drop items to change list order. As a product manager, I'm frequently re-ordering the backlog and it needs to be fast and painless. With the Custome Issue Order plug-in, you have to move an item one position up or down, or type in it's new rank, but either way the page refreshes each time. With a Jira server on the opposite side of the planet, the latency is killing me.
• If the backlog is too long, each user must customize the page size to be able to view all items in the list. When it's split between pages, you can't move an item from one page to another.
• Suppose the team is starting iteration 3.0.2 (2nd iteration toward release of V3), and a defect is reported on V2.1 that must be fixed in a V2.2 release. You can't include this defect in the 3.0.2 iteration backlog because it's based on Jira's "fix for version" 3.0.2, and this item will be fixed in Jira version 2.2. So you have to manage these items separately.
  
• You can't "collapse" a single story to show/hide it's subtasks in the list. This is a feature of ScrumWorks that I really like.
  
• The agile velocity tracking plug-in isn't very intuitive. It might be more useful after our project has more iterations completed, but for now the data isn't very helpful.
• No burndown chart. We tried a free plug-in from Laughing Panda but couldn't get it to work. The closest things Jira has is the progress bar: go to Reports -- Versions -- (a specific version) and you get a graphic like this:
  

The burndown chart is far more useful since it clearly communicates the estimated work remaining (in hours) and the trend line for completing it by the end of the iteration.

My recommendation for co-located teams is still to use a physical task board. If you have a distributed team, or you've tried the task board and have specific reasons for moving to an electronic tool, then I'd recommend Jira + GreenHopper, ScrumWorks, XPlanner, or the free editions of Rally or VersionOne. When I first wrote this post, I hadn't yet tried GreenHopper, but now I have, and it's a great tool. Read about it here.

Kanban in action

Kanban is a Japanese term common in the lean literature meaning a signaling device: downstream activities signal to an upstream activity when they have capacity to do more work, enabling value to be pulled through to a customer in continuous flow. In software, it starts with a ranked backlog of stories/features to be done, just like in agile. But instead of fixed iterations or sprints, the team pulls items the highest priority items from the backlog as soon as it has capacity. Software may still be released on a regular cadence, and the release includes whatever backlog items have been completed on the release date.

This blog post is a great primer describing how kanban was applied at Corbis.

I have always thought that the schedule pressure of short iterations can have a positive motivating effect on team member and keep them focused on the goal, but I realize now that it can also have negative consequences, invoking feat and causing developers to feel pressured to make short cuts and bury quality problems under the rug in order to give the appearance of completing tasks on time. David Anderson addresses this issue eloquently in this post on the kanbandev discussion group. In a nutshell, David describes how the objective in a kanban system is to reduce cycle time while maintaining quality. With those measurements in place, the team is motivated to continually improve but the system is tolerant of missteps and underestimation on individual features. Done properly, a kanban system should eliminate the potential negative motivations that can be caused by iterations.

New generation of collaboration tools

One of my session proposals for Agile 2009 is titled Collaboration Tools 2.0 - Which is Best? I plan to have an interactive workshop comparing the merits of tools like Basecamp, Huddle, Zoho Projects, Sosius, and Google Docs. If you have experience with these tools or others in the same genre, please let me know.

Agile 2009 session proposals

I've submitted proposals to present 3 different sessions at the Agile 2009 conference in Chicago in August:

• Agile Outsourcing in China: A Happy Family
  
• Collaboration Tools 2.0: Which is Best?
• Strategies for highly effective distributed teams

I'd love to get some feedback - positive or negative! You can find my proposals here.