Managing Projects with JIRA and Greenhopper

For the last few months I’ve been overseeing a project that comprises between 2 to 4 developers at any one time. I’m not a project manager. We have project and program managers here in DSI who oversee larger teams of 7-20 people each, and they are by necessity abstracted away from the code. I’m an architect and a developer, so I’m most at ease at the centre of a triangle with a phone (or Skype), a coffee machine and an IDE at each apex.

For a project of this size – and arguably bigger ones – a Gantt chart is an unnecessary burden. It’s no coincidence that [tag]Gantt charts[/tag] looks like waterfalls. They are describing dependencies between steps: “You have to do X before you can do Y.” But most software projects don’t need that kind of detail – you can break them down into work items that can be more or less independently allocated. If you are doing [tag]Unit Testing[/tag] and using [tag]Continuous Integration[/tag] then you know that most test and integration activities are performed as part of coding. You can put most of your tasks into a big hopper and as long as you have enough skilled engineers available to take tasks from the hopper, you can work to any reasonable schedule.

Modelling the Project
We usually don’t need the dependency information that Gannt charts provide. (If you are assembling a pharmaceutical plant, or even retooling one of its production lines, then you will needs Gantt charts coming out of your ears – aren’t you glad you work in software!!) The kind of activities that tend to block software projects are those related to getting information from the client: clarification on requirements, agreements on platforms, feedback from iterative deliveries and so on. It’s one of the project manager’s jobs to anticipate these blockages, and if he’s too busy trying to update his Gantt chart (which also typically involves distracting the developers from their coding) then he’s less likely to be able to do that job effectively.

Enough about Gantt charts. What information do you need to oversee a software project?

  1. How the project is broken down into tasks.
  2. How long each of these tasks should take.
  3. How these tasks are to be organized into iterations.
  4. Who is working on each of these tasks.

This, in UML terms, is the core static model of your project. And there are a number of tools out there that will help you to persist and share this information. [tag]JIRA[/tag] is one such product – and it’s what I’m using right now on my current project.

So do you make all these measurements at the start of the project, stick them in JIRA, and then just sit back and watch it run like clockwork? Sure you do. And you spend all that spare time you now have taking pictures of the fairies at the bottom of your garden, and turning base metals into gold. Fun and profit!

Of course not. It’s not the plan that matters, it’s the planning. The numbers will start to change from day 1, so you need a dynamic model to go along with your static one – something to describe the process by which your project plan gets updated and with which you track actual versus planned project details.

knock! knock!

Oh – did you hear that? There’s someone at the door. Excuse me for a moment…

Pad pad pad. Creeeeaak.

“Yes? Can I help you? Oh it’s one of you.
No – I’m not interested, thank you.
Yes – I realise I’m going straight to hell.
No – I don’t mind. The weather’s got to be better than here.


I’m back. Sorry about that. Damn evangelists. You even mention the word ‘[tag]process[/tag]’, and they come knocking trying to sell you something. This time it was Scrum, but it varies. Where was I? Oh right – there’s no point in getting religious about what brand of project management you’re going to use. I think some simple self-evident logic should be applied:

  1. Ask the developers to update their time spent, and task estimates, daily.
  2. Ask them if they have enough information to keep them working for the next few days.
  3. Go talk to the customer and get whatever information is missing, if absolutely necessary, including the developer in the meeting.

If you want to see how the project is doing, run a report. If you like, print out a few dozen and use them to block the door when the evangelists next come calling.

Putting a Better Face On It
While JIRA models the project info very well, and has excellent reporting features (which you can extend very easily, by the way), it’s not a very attractive environment to work in. The interface is geared towards searching and listing issues (JIRA started life as a bug tracker) but the editing pages are clunky and unfriendly. Enter [tag]Greenhopper[/tag]. Now if you’ve stayed with me to this point, and been forgiving of my stupid door-knocking interlude, then you’re about to be rewarded. This plugin for JIRA is a jewel. Very simply, it puts a useable interface on JIRA for both developer and project manager. Using a whiteboard and index card metaphor, it gives an instantly recognizable and very editable front end. This is no small thing. If you want to discourage the use of an excellently engineered system, put a crappy front end on it. People will find another way. If you like how JIRA models your project and you want developers to want to use it, install Greenhopper. The guys in Montréal who have built this tool (and are continuing to add improvements at a cracking pace) are as responsive to questions and open to suggestions as any team I have ever come across.

To sum up, the best way to make a smaller project economically viable is by reducing administrative overhead as much as possible. As I’ve said in a recent blog entry, the relationship with the customer is crucial is deciding how low that overhead can go. We’ve used a combination of our normal code-centric process, alongside some new requirements, estimation and metrics techniques. The end effect is that the coding activity is the motor that drives the project management – not the other way round.

In fact, [tag]project management[/tag] might better be described as project channeling or project direction. What’s required is

  1. an understanding of the scope of the work, and for relevant sections, an understanding of its depth
  2. a willingness to document shared understandings as part of clarifying requirements as the project goes along (once upon a time, the very word ‘committee’, or ‘meeting minutes’ would send a shiver down my spine. But suffering as I do from a dreadful memory, I now consider writing certain things down to be as vital as defending ground gained in a battle).
  3. keeping the hopper loaded with the right work and
  4. generally getting the hell out of the way otherwise.

– brendan

  1. #1 by Beth Brock on December 11, 2008 - 2:26 pm

    Any advice as how to chart or see how different projects are affecting each other by robbing resources. I keep getting requests to have a larger burndown chart that entails all the developers that are working on multiple projects, but I can’t see how that info could be digested.

  2. #2 by Brendan Lawlor on December 18, 2008 - 10:33 am

    Hi Beth,
    I’m afraid I can’t offer any wisdom there. Have you spoken with Jean-Christophe Huet and the Greenhopper team? They’re always looking for new ideas.

  3. #3 by Ashley on November 4, 2009 - 5:28 am

    Explained in a quite wonderful way and I do like the point using developers to update frequently. Yes, it is the main reason where most of the people struggle.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: