A Holiday with Kanban

Introduction

Over the course of many agile projects using Scrum or Scrum-like methodologies, invariably one comes up against that dreaded speedbump: the winter holidays. Generally, the span of time beginning roughly during the week of American Thanksgiving and ending a few days after New Year's day. This time period is littered with several federal holidays and a large expendeture of team members' vacation time; unfortunately, usually resulting in large portions of the team missing pivotal ceremonies such as sprint planning. These absences can cause significant degredation on a teams' total velocity, generally more than one would expect from the time off alone. The reason for the larger than expected velocity differential stems from the required synchronization of product team and technical team during sprint ceremonies. If half of the either side of the agile coin is missing during a sprint review, it is largely wasted time; and scheduling a bi-weekly or weekly meeting during the holidays is often quite the ordeal. When resolving this issue on our own project, it was obvious we needed to shift to a methodology that was more asynchronous. We decided to experiment with using Kanban for our holiday season.

Holiday Kanban

The time period for our experiment was from November 15th (the end of a Scrum sprint) to January 3rd (3 of our 2-week sprints). We preserved our daily stand-up, but replaced the sprint review, retrospective, and planning meetings with demo and retrospective meetings on December 6th and January 3rd. We increased the number of backlog grooming meetings from once a week to every Tuesday and Thursday. These backlog meetings lasted roughly thirty minutes, and due to their high frequency, a few absent members did not affect the usefulness of the meetings as a whole. By shifting to Kanban, we were able to allow the technical team to maintain a constant workflow and the product team could continually refine and update the backlog without requiring the alignment of both teams' schedules.

Results

Empirical

On average, one Scrum sprint's velocity is typically 80 story points for our project. Over the course of our entire Kanban expriment, the technical team completed 283 story points - roughly 94 points every two weeks. While our team is small and the span of time relatively small, it appears that regardless of vacation days our technical team kept pace with other standard sprints. This is likely attributable to the removal of what would have been a sprint review, before which a code review of all the changes takes place.

Anecdotal

Both the product team and technical team seemed pleased with the outcome of our time with Kanban. It allowed developers to tackle smaller, technical debt tasks when they were short on time and larger tasks when they had an abundance. While our design team had to adopt an aggressive time table to keep up with the number of new stories in our backlog.