As Bryce posted this morning on our developer blog, the Atlassian Build Engineering team adopted GreenHopper’s Rapid Board to make some big changes and solve a number of operational problems. GreenHopper 5.8 is here, and marks the Rapid Board moving out of ‘Labs’ – so operational teams at Atlassian have been exploring ways to use agile methods & tools to solve their common problems.

Communication Breakdown

Operational teams often have a number of ‘customers’ – ranging from development and engineering to support, sales, and marketing. Each customer wants accurate information about the relative priority of his or her issue, and a rough idea of how soon the operations team will address it. The Rapid Board solves these problems by:

  • Showing issues according to relative priority
  • Visualizing the operations process – from creation to resolution
  • Replacing a physical wallboard for remote communication

Keeping issues up to date will always be an individual responsibility, but the Rapid Board provides users outside the team with an understanding of how much work the team has as a whole, what high priority issues are already in flight, and which issues are at the top of the backlog.

buildeng-triage.jpg

What to work on Next?

build-engineering-working-board.pngThe board above shows an awesome amount of information, but it can be quite distracting during day-to-day work. So, the team created a second Rapid Board, showing just the three columns on the right. The larger, complex board above is a place for the person on triage to visit a few times a day. Everyone else uses the slimmed down ‘working’ Rapid View, thus ignoring untriaged issues, adding up to less distraction and more focus on getting work done.

Optimizing operational processes to reduce cycle time

Triage is difficult whether you’re the reception nurse in the emergency room, sorting your inbox after a long vacation, or an operational team with a large backlog. The first step for any goal is to measure what’s happening now, so the Build Engineering team used the new Control Chart to measure issue cycle time – and discovered their average was 1.9 days. They then set a goal of moving any issue out of the Untriaged column within 12 hours.

devops-control-chart.jpg

The Control Chart lets them discover outlier issues and spot trends. Using that chart, along with the Rapid Board’s handy new issue card display – with number of days in current status indicated by dots across the bottom of an issue – helps them get to the root of the ‘long time in status’ problem, and track progress toward their triage goal.

rapid-board-dot-status.jpg
A third feature aimed squarely at handling backlog and triage is the work in progress (WIP) limits. WIP limits are a standard Kanban practice: min and/or max limits can be set on each Rapid Board column to indicate when a backlog is getting low, or when the number of issues in flight is too much. This, however, has sparked a lively discussion between two of our operational teams about blockers and dependencies.

Handling Blockers & Dependencies

Operational teams – by nature – do lots of things for other people. The issues In Progress can pile up quickly when waiting on someone else to answer a question or perform a necessary task. Our Internal Systems team and Build Engineering team have had some great discussion on how to handle WIP limits in relation to these blockers and dependencies. Here’s a snippet:

Build Eng: You’ve got 9 issues In Queue and 43 issues In Progress? You might want to introduce some WIP limits 🙂

Internal Systems: Ah!
Such is the life of Business Analysis! A BA can be working on stuff
but only ‘do things’ on it once a week, since we’re waiting on other
people. Actually, we stuck in a column for Waiting on Customer.

No two teams do things quite the same. Working with remote locations and opposing time zones complicates this further: waiting on ‘someone else’ can add a day or two to even a simple task.

  • Complicate your workflow by adding a ‘waiting’ step?
  • Keep things simple by setting generous WIP limits, knowing these issues will be clogging the columns? (like Atlassian Internal Systems)
  • Meet somewhere in the middle, using a label or other unstructured indication? (like Atlassian Build Engineering)

GreenHopper and the Rapid Board are flexible enough to do any or all of these, which keeps both operational teams happy.

Get the Rapid Board Today

GreenHopper 5.8 is available, but you’ll need to upgrade Jira to version 4.4.3 to get it. Upgrade today!

download-jira-443.png

GreenHopper 5.8 deep dive – DevOps & IT Operations with the Rapid Board