At PagerDuty, we’ve been doing Kanban for a while now, and as an Engineering Manager who has managed several teams over my tenure, I wanted to share some tips I’ve learned from the experience as well as some improvements we made to the process to best suit our teams.

“We have so much time and so little to do. Wait a minute. Strike that. Reverse it.”

What Kanban Looked Like at PagerDuty

First, let’s take a look at the PagerDuty Engineering workflow. Most teams have a Kanban board with five states for tickets:

1. To Do
2. In Progress
3. Blocked
4. Code Review
5. Done

We have work-in-progress (WIP) limits on each state that are based on team size. These limits make sure we don’t have too many tickets in flight at once.

When you’re doing Kanban, you work on one ticket at a time. When that ticket is completed, you move it to Code Review or Done and then select your next ticket. For those who use Kanban, this is nothing surprising.

Here’s where it gets interesting. When we started using Kanban, the selection of the next ticket was pretty constrained. If there was a ticket waiting for Code Review that you could pick up, that ticket would be your next task; otherwise, you were required to select the top ticket from the To Do column and work on that instead. If the To Do column was empty, you would grab another team member and refill the column from the backlog.

The intention behind this restriction was to distribute knowledge across the team. Requiring the team to select the top ticket from To Do meant everyone would—eventually—end up working on everything, including code they might not have worked on before.

Our Kanban Gap

This process was very successful in ensuring everyone on the team had a wide base of knowledge; however, in one of the team’s kaizen meetings, the developers identified a few unanticipated side effects that they found frustrating. After some discussion, the side effects were narrowed down to two main issues:

The first issue arose because the process required the top ticket in To Do be chosen every time, meaning you may be forced to context switch between projects or areas of work every time you completed a ticket. This constant context switching was frustrating for the team, as it would always slow them down. Conversely, you may end up working on the same project for many tickets in a row, even if you would instead benefit from a break so you could come back later with fresh eyes.

The second problem was due to the nature of Kanban itself. In Scrum, there is often a gap provided by periodic sprint planning sessions. However, in Kanban, the constant flow of new tickets into To Do with each replenishment resulted in a sort of monotony and didn’t leave time for any experimental or creative work.

After discussing these challenges, the team put their heads together and came up with a pair of changes that we then implemented. Both of these changes (like the problems they were meant to solve) came from discussions between team members.

“If you want to view paradise, simply look around and view it. Anything you want to, do it; want to change the world… there’s nothing to it.”

How We Changed Our Kanban Process

The first change was a simple one—instead of being forced to choose only the top To Do ticket, developers now have a choice:

1. 1. Choose the top ticket, or
   2. Choose the top ticket that is in the same epic as the last ticket you worked on.

As a special case, if the tickets in options 1 and 2 are the same ticket (because the top ticket is in the same epic as the developer’s last ticket), the options would change and instead become:

1. 1. Choose the top ticket, or
   2. Choose the top ticket that is not in any epic.

These two choices combined to effectively allow each developer to choose between staying on their current project or getting something different to work on.

Our hypothesis was that this change would help us better manage our productivity by allowing developers to decide which sort of ticket is best for themselves, given each person’s current energy level, mood, and interest.

We could have chosen to remove all restrictions on what ticket to choose next, but wanted to preserve the idea of spreading knowledge around by occasionally pushing ourselves to work in unfamiliar areas. This change was intended to balance that desire with the reality of how people work.

“However small the chance might be of striking lucky, the chance was there.”

The second change addressed the issue of monotony and experimentation. We decided to introduce a way for us to create our own tickets as an official part of our workflow by creating a new issue type in JIRA: the Golden Ticket. Golden Tickets are special tickets that are created every time To Do is refilled—one new Golden Ticket is randomly inserted into the refilled To Do column, and it contains this text:

Greetings to you, the lucky finder of this Golden Ticket! I shake you warmly by the hand! Tremendous things are in store for you! Many wonderful surprises await you!

I do invite you to use this ticket in one of two exciting ways:

1. 1. Select any other existing ticket (not in an epic) from the team’s backlog, drag it onto the Kanban board in place of this ticket, mention the replacement ticket in a comment on this ticket, and move this ticket to Done.
   2. Replace the summary and description of this ticket with ones describing a technical spike timeboxed to one day and proceed to work on that. You must include a DoD in this ticket, and should present your results to the team.

As you can see, there is again a choice presented: either select any issue (that’s not in an epic) from the team’s backlog (or icebox, if you have one) and work on that issue, or do a bit of experimentation (limited to one day or so), document it, and (usually) present it to the rest of the team when you’re done.

Initially, Golden Tickets seemed like a risk: we’d be allocating a whole day to something that might not be that useful, might fail, etc. But for a team the size of ours at the time (four developers), at the rate that we refilled our To Do column (roughly every two weeks), Golden Tickets would only make up around 2.5% of our development time. In other words, each person on the team would get to do around one golden ticket every two months. Given the small time commitment involved, we decided to give this idea a shot.

“Invention, my dear friends, is 93% perspiration, 6% electricity, 4% evaporation, and 2% butterscotch ripple.”

The Impact Our Changes Made

So what was the result of these two changes? They both worked extremely well. In subsequent kaizen meetings, both changes were consistently identified as having a positive impact, and we didn’t make any further adjustments to either of them. The team also decided that the cadence we had originally set for the introduction of new Golden Tickets worked well.

In fact, the Golden Tickets, in particular, have been a resounding success. Within four months eight Golden Tickets were completed: four were used to do technical spikes, and four to pull in tickets from the backlog. All of them have had an impact.

In particular, two Golden Tickets have been used to create a helpful service skeleton that other teams were able to use to bootstrap new services quickly, another was used to open-source a system we’d written (db2kafka). Some ended up fixing an annoying bug, doing experiments for future work, and improving the development environment for ourselves.

“Don’t forget what happened to the man who suddenly got everything he wanted.”
“What happened?”
“He lived happily ever after.”

Making Kanban Work for You

If you’re thinking of adopting some of these ideas for your own team, I’ll leave some parting thoughts. And if you try it out, we’d love to hear how it works for you!

• • “Golden Ticket” is a real issue type I created in JIRA. You should do the same as it makes them easier to track. If you do create this issue type, I suggest adjusting the colors of the issues in your boards so that Golden Tickets are a proper golden yellow. And, to avoid confusion, you might also want to change the color of Epics to a darker yellow or another color entirely, since they seem to default to a golden yellow otherwise.
  • It’s important that the Golden Ticket get either a link to the replacement issue or a proper definition of Done, and, in the latter case, that they are presented to the team when completed. Golden Tickets are not a license to waste time!
  • Developers also can’t just pluck the Golden Ticket from To Do whenever they want—they’re still constrained by the ticket selection process.
  • Golden Tickets can easily be applied to Scrum teams—just insert them into each sprint during sprint planning!
  • A larger team might want to introduce more than one Golden Ticket at a time, so that everyone gets a fair chance at one.