How to Get JIRA and Agile to Play Nice

JIRA is an incredibly versatile tool. Agile is a proven philosophy with frameworks such as Scrum and Kanban helping teams manage their deliverables in an agile manner.

And yet, often when an organisation that is trying to be agile installs JIRA, it continues to have organisational challenges even months later. We hear statements such as “JIRA is useless” or “We used JIRA at our last place and it didn’t work.”

It’s not JIRA that’s at fault, however.

JIRA is just a tool. Try to put up a set of shelves with a kettle and you’re going to have problems.

Imagine you wanted to build a house. Some would say all you need are the tools. But without people, and people knowing the process of building the house, the house won’t get built.

People, Process, Tools

JIRA is just a tool; it’s how you use it that counts. Agile teams around the world are very successfully implementing Scrum or Kanban using physical cards on glass walls, or Post-It notes on whiteboards.

So what goes wrong when JIRA comes on the scene?

JIRA has two very effective use cases:

JIRA is a tool with a great UI and UX and can be a very effective digital Post-It note-type system JIRA is an incredibly powerful and customisable workflow engine that can be extended with lots of plugins.

And it goes wrong when these two use cases are mixed. 

Just as Scrum teams that use physical boards don’t have a person standing at the side, slapping people on the wrists when they move a sticky note from one column to the next, you also shouldn’t programme JIRA to do the same.

I’ve personally lead many agile programmes across a global organisation with out-of-the-box JIRA. Simply by teaching agile mindsets and Scrum, and leaning JIRA down, JIRA becomes an incredibly effective agile tool.

In Summary

Agile teaches us that it's about the people more than the tools. Agile Principle No. 5: “... trust [the people] to get the job done.” Agile Principle No. 10: “Simplicity - the art of maximizing work not done - is essential.”

JIRA is an incredibly powerful tool that can be used very effectively within agile teams; just because you can do it in JIRA, doesn't mean you should.

Keep the tool simple, keep the agile and lean values, principles and practices in mind, and JIRA can help you succeed with agile.

And that is how to get JIRA and agile to play nicely together.

The Coffee of Destiny

A few years ago, I pulled into one of the many local Starbucks, like I did everyday. But on this day, the world changed for me. 

We had been applying Scrum successfully on our games for a while, but we had a problem with applying it during production. 

Often, games go through at least two phases before they launch. One is pre-production, where the core gameplay features and engine are developed. 

The second is production, where the hours of gameplay content (levels, characters, story) are developed using those features and technology. 

As much as we tried to be agile, we couldn’t eliminate that separation of phases. 

The problems were that during production there is more of a flow of handoffs from one discipline to the other, and large assets, such as levels, took far longer than a single sprint to complete. 

This led to a lot of unfinished work at the end of every sprint and bottlenecks between the handoffs. 

Now, if you are a straight-coffee drinker who frequents Starbucks, like me, you probably appreciate that you don't have to wait for all the lattes, cappuccinos, etc. ordered ahead of your cup of coffee to be made first. 

The barista works on those exclusively and the cashier can directly pour your coffee for you.   

That day at Starbucks, the light bulb turned on.

I thought, maybe we can learn something from this. A bit of Googling showed that Starbucks was applying a practice called Kanban.

Kanban roughly translates to “signal card” in Japanese. It’s a set of practices that focuses on the flow of work and uses the state of the work in progress to signal to the people doing the work what they should do. 

At Starbucks, the empty coffee cups, marked with your misspelled name and order details are the Kanban. Based on how many there are between the cashier and barista, this informs them of what they should do next. 

Looking at the Kanban board above, my coffee goes from the "order" column to the "leave" column directly. 

Based on the size of the line, the barista and cashier might help one another out. If the line is long and the barista has nothing to do, they’ll ask people in line what drink they want and start making that before the cashier takes their order. 

Conversely if the line empties, but there is a backlog of unfinished drinks, the cashier will join the barista in making drinks. 

This benefits everyone. A key metric for Starbucks is the customer cycle time: the amount of time it takes between walking in the door and when you walk out with your drink.   

The critical path for coffee drinkers and latte drinkers isn't the same, but it isn't entirely separate; much as I personally would enjoy it, there is no separate cashier line for coffee drinkers. 

Starbucks has chosen not to optimize specifically for us straight-coffee drinkers for good reason. 

This is similar to the approach you might use for asset types. Although every asset will have a large variation of effort needed (like that between coffee and a latte) and partially separate paths, measuring every asset's cycle time will still give us valuable information.   

The goal isn't to achieve a uniform cycle time for all assets, just as people who order lattes should expect to wait longer at Starbucks than us super-efficient coffee drinkers. 

Let's look at the Kanban board that shows various assets going through a game asset production pipeline:

This board includes assets that might need particle FX or animation applied to them, or neither. The important principles apply. 

We're going to measure the throughput and limit the work-in-progress (WiP) regardless of which steps are taken. Some assets will skip some steps like me skipping the barista. 

Doing this can improve the entire system. As a coffee drinker, I don't care how quickly the barista can make a latte, but I greatly appreciate when the under-tasked barista helps fill coffee orders. 

This can happen in an asset production pipeline as well. As we measure throughput, we can create such policies in a production pipeline: Starbucks has far shorter coffee cycle times than barista-drink cycle times and that is fine for everyone.   

The key is to measure throughput for different asset classes and explore where and when improvements for classes can improve their cycle time without impacting the other classes. 

Most production pipelines are far more complex than this, but the same principles apply. Start by simply modeling what you're doing now. Then measure throughput and reduce WiP.