Jira, Greenhopper, Lighthouse: tools vs practice in Scrum

31 July 2009 by Rod McLaren

We switched from Lighthouse to Altassian’s Jira for our ticket-tracking/sprint planning shortly after starting to adopt scrum seriously. We used Greenpepper’s Greenhopper extension, which makes Jira a bit more scrum-like. We tried it for about 3 months in a team about 5-6 strong. Here’s what happened.

The good:

• JIRA is an powerful project management/ticket-tracking tool, and can be configured and customised significantly.
• the Greenhopper extension hides some of Jira’s complexity
• Greenhopper offers useful views for product planners and scrum masters: a planning board with draggable priority; a task board with draggable story status (we had ours set to todo, in progress, in testing, complete); chart views including velocity
• tasks/stories and sub-tasks/stories can be useful
• It’s definitely a good, powerful tool for some teams, but…

The bad:

• our biggest problem with Jira/Greenhopper was that it isn’t as well-aligned to our developing practice of scrum as we needed it to be. The tool got in the way of our learning the practice, and started behaviourally skewing our view of scrum (‘The chosen tool becomes a factor of the first order in determining not “only” how Agile (or any other software method) will be practiced, but what mindset will evolve in the course of the rollout’). We were trying to fit scrum to the tool we had, and were talking more about how to use the tool well than we were about whether the sprint was going well.
• you can see that Altassian and Greenpepper had very good reasons for making every design decision they did, but the end result is a tool that’s massively complex and feels really unforgiving, even with the Greenhopper extension. Because you can do so much with it, it makes you set up huge amounts of stuff. You feel like you need an expert to set it up; you feel like you have to be an expert to use it well.
• many of the good features in Jira/Greenhopper required a high degree of ritual – we felt like these were activities that should have been secondary to the primary activities of estimating tasks, committing to a sprint plan, and delivering the sprint.
• the development team didn’t use Jira’s hooks to source control and release management (they just preferred to use Subversion directly)
• Greenhopper has some truly horrible user experience. My particular bugbear was that double-clicking in a text input field toggled the field back to a read-only view instead of selecting the word – a small thing, but incredibly interruptive because it’s at variance with the every other software/website I use.
• Greenhopper is pretty slow to use, which can be annoying – probably because it has massive amounts of javascript
• we found it hard to identify our success criteria and we were constantly putting off making a decision to commit to Jira/Greenhopper for the long-term. (Which was one of the signs that we should have been focussing on the practice rather than on the tools.)
• it’s also a bit expensive against the competition.

Many of these downsides aren’t fundamental problems in the product itself, but gaps between it and how we behave as a development team. For your team it might be different.

For now, we have gone back to the simplicity of Lighthouse for the detail in stories and tasks, and to the speed and visibility of a large whiteboard with post-it notes for the bigger picture. That’s working better for us. In future we make look at using or making a scrum extension for Lighthouse, but for now we’re staying focused on trying to improve our practice of scrum rather than on optimising tool use.

Job opening: Mobbu is hiring a great QA/tester Support as a metric for technical debt in scrum sprints