Tuesday, March 13, 2012

Kanban for Social & Mobile Game Teams, Part 1

Many social game teams (or MMO or mobile game teams) deploy new features once or twice a week.  For them, Scrum is more challenging to adopt because 2-5 day sprints are too short and there are often frequent interruptions to their work.  These impede the team's ability to commit to a valuable sprint goal.

For these teams, kanban is a more suitable approach.  I've used kanban for years (see links below) and have worked with many teams adopting it.  With the growing popularity of social and mobile games and their platforms, kanban has become more established.

Kanban has the following advantages:

  • It's easy to deploy.  You start by visualizing your current workflow.  No new roles are needed.
  • Deployment of features is continuous, which matches the needs of many live games.
  • It helps lead you to many continuous changes through daily inspection.
Here is an example kanban board:

If you've used a Scrum task board, you can quickly understand a kanban board.  The immediate difference you'll notice is that the kanban board has more columns.  This is because it's capturing a more predictable flow of smaller features that live games typically deploy.   For example, let's say we want to add a button which tweets a player's status in the middle of a game (by the way, I'm not a big fan of such features).  The designer specs out the button and it's behavior, it's then implemented, tested and deployed.   While this is happening, a card which represents the "Tweet Status" feature moves from left to right through the workflow.  Kanban doesn't "say" that's the best way of developing such a feature or not; we're just visualizing it. 

The other thing you'll notice is a couple of columns called "done" and the numbers at the top of most columns.  The columns labelled done are little holding buffers that we use to handle the variable amount of time for each step (e.g. some buttons take longer than others to create, so we let a little bit of backup occur so the next developer down the line isn't waiting around).  The numbers, called work-in-progress (WIP) limits, will prevent too many things from piling up.  When too many things get into the flow, there's a point at which development really bogs down (think of a Southern California freeway at rush hour).  WIP limits and a few judiciously placed buffers help things move smoothly and quickly through the flow.

The next article in this series will describe kanban's use, the blending of kanban and Scrum practices and where it makes sense.  We'll look at how to use lean practices to improve flow and handle emergencies.

Some links to previous videos, chapters or articles about kanban. (chapter 7)

No comments: