Guest Post – Adzerk & Kanban

by agilezen on February 14, 2012

This post was originally published by Andy Schrader of Adzerk, an online ad network management tool, on Adzerk’s company blog.

Adzerk Logo We’ve been using Kanban for a couple of months now at Adzerk so I wanted to give you an update on how’s its been going.  spoiler alert: it’s great!

The Way We Were

As mentioned in previous posts, we’ve always used AgileZen to manage our backlog and current development work.  When it was just James, Kacy and I we could operate without too many rules/conventions. Mostly this meant that I snuck a ticket into the queue when James wasn’t looking and it was ignored in favor of shinier objects (don’t tell him I said that).

There were hundreds of tickets in the AgileZen backlog and we would meet regularly to pick which ones to work on next. Often a high priority would come up and get put directly into the working queue alongside existing tickets. It wasn’t uncommon for the queues to get fairly large until we had time to clean them up. Completed items would get moved to the ‘QA’ queue which would backup until we were ready for a deploy and then we would scramble to test everything before releasing into the wild. Unless you wanted to have some sort of roadmap, allow engineers to be laser focused on a small set of tickets and limit a bug’s impact on our customer base then it was all a glorious process that never failed.

A New Age

With the addition of Sarah and Jeffers (not to mention Andrew, Ron, Brian and Steve) we needed a bit more order to ensure we were focusing our resources on the right priorities.  In addition to better organizing our engineering team, we also needed a better way to give timelines to customers and market facing teams.  James gathered us all into a conference room and the Wild Wild West became the Renaissance.

AgileZen makes it easy to add Kanban limits to each step in the development process so we added limits to the number of tickets each queue could have. We moved forward with the following queues (and work-in-progress limits):

  • Ready (7)
  • UX (2)
  • Working (4)
  • Acceptance (4)

Only 7 tickets can be in the Ready queue and we limit the Acceptance queue to 4. The UX and Working queue limits are equal to the number of engineers+1. Somewhat arbitrary limits but there was also some thought put into them.

The key is to obey the Kanban work-in-progress limits and if the Kanban board is clogged you don’t want to continue moving tickets forward, which would be a Kanban violation. The first rule of Kanban is to follow Kanban, so when we catch someone violating the Kanban process by overloading a queue we play this ALERT throughout the office.

Effects of Kanban

Adzerk Screenshot

From a product owner’s perspective this is all great because by instituting Kanban limits on each step the product owner has more control over what engineers focus on (he/she controls what goes into the ready queue). As the product owner I use Excel to manage the backlog of bugs/features and keep it prioritized at all times. When there’s room in the Ready queue I create a ticket and add it to AgileZen. When tickets are put into the Acceptance queue it’s the product owner’s responsibility to give final approval that a ticket is complete and works as intended. I get the last look at making sure it’s ready for customers to use and am responsible for clearing tickets off the board when they are complete.

Kanban encourages a team mentality because if any of the queues reach their limit the whole process gets clogged up which forces everyone to focus on fixing the clog. If there are already four tickets in the acceptance queue then no more tickets can get completed and moved into acceptance until the product owner clears out the queue. If there’s a problem testing a ticket because of the QA environment then it hurts everyone because the Kanban board gets backed up.

We’re constantly discussing the process and tweaking it to work better for us. If a ticket needs more work should we move it back to the working queue? We decided the answer is NO, tickets never move backwards (but I can see it working both ways). Do we need to have a UX queue? I’ll bet at some point we try getting rid of the UX queue and just have a Working queue with 5 or 6 slots. One new piece of the process for us was adding size attributes to each ticket so we can start tracking velocity. I’m excited about the new insights this will give us but I also expect it will also lead to some tweaks with our processes.

These were some big changes to adopt. And there was definitely some concern voiced when the Wild Wild West ended. “Rules!? We don’t need no stinking rules!!” The bottom line though is to not let the process get in the way of being productive. I think we’ve succeeded with that and everyone is much happier since the change.

TEASER

The best part about all of this, and I think everyone’s favorite part, is the use of feature flags. By using feature flags we’re able to continually deploy and keep new code hidden from production accounts. I’ll leave this topic for a future post but it’s a beautiful thing when combined with our Kanban process.

95052431a3c3e4b5ee05c6f696060c5a
Share

Previous post:

Next post: