I’m proud to be working for an Engineering organization that feels safe. Safe for its engineers to bring their authentic selves to work and discuss...by Derek Ralston
October 3, 2018
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.”
First, let’s take a look at the PagerDuty Engineering workflow. Most teams have a Kanban board with five states for tickets:
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.
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.”
The first change was a simple one—instead of being forced to choose only the top To Do ticket, developers now have a choice:
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:
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:
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.”
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.”
“He lived happily ever after.”
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!