KANBAN @CTCT

Scrum works well to well when there is a distinct backlog of prioritized work and distinct time-boxed release cycles. Scrum scales well with a Scrum-of-Scrums group where scrum masters scrum across teams, provided you introduce program management to oversee the progress across teams. As an organization grows in agile product teams that align with a single delivery cycle, agile service teams emerge (e.g. Engineering Services, Database, Application Operations, automation infrastructure, etc.). Many of these teams have both planned backlog work and on-demand unplanned work (work request tickets).

Scrum is a push model where work is pushed into the team in prioritized order. Many times work on an item may be blocked by a dependency on another team, so the team picks another work item to work on, and so on. This leads to many things started without being completed and accepted in an consistent flow throughout the length of the sprint. The result is a lot of task switching and inefficiencies near the end of the sprint to get the work done in the sprint, and technical debt (deferred defects, refactoring for reuse, etc.). This is especially difficult when you have many interdependencies between scrum teams.

There are three key challenges that emerge as you scale these needs:

• minimizing work in process (WIP) with smaller work items
• balance the planned and unplanned work and their priorities
• minimize bottlenecks in the flow of work

Kanban is another agile concept borrowed from the lean principles of the manufacturing industry in Japan. Kanban (or kamban in Hepburn romanization–kanji 看板, katakana カンバン, meaning “signboard” or “billboard”) is a concept related to lean and just-in-time (JIT) production. According to Taiichi Ohno, the man credited with developing JIT, kanban is a means through which JIT is achieved (en.wikipedia.org/wiki/Kanban). Kanban is a pull model, rather than the push model of Scrum. It uses the same idea of a user story broken into work items with tasks attached. It uses the card (sticky note) concept as in Scrum, but it uses the idea of clarifying distinct process steps (columns) and swim lanes (rows), where each step has a distinct WIP limit. You still have a prioritized backlog to pull work from. Each swim lane has a purpose for processing work, and each step can only pull work from the previous step once a work item or task is pulled from the downstream step. If the downstream step does not have capacity you can’t push the work to them. This leads to tuning the efficiencies and capacities in each step to accommodate a cadence of pulling work through the swim lanes.

Constant Contact (CTCT) is moving from Scrum to Kanban to address these needs. Mike Fitterman (Development Manager) and Rick Simmons (Agile Coach) illustrate the learning of the pilot team (website) at Constant Contact, as presented at the Agile2010 conference: AgileConference2010-Upstream_Kanban_at_CTCT. At Constant Contact, we have nearly all (both product delivery and service) agile teams using this approach at the time of this writing. You can see Kanban boards in many of our conference room and work area walls as you walk through the engineering space. The Scrum-of-Scrums still occurs daily, however it is more focused on larger project progress, interdependencies, and organizational impediments. We are still working out our inefficiencies with this new process, but it seems to be working well for us so far.

Constant Contact Website Team Kanban Board

Kanban addresses the need to minimize the WIP by constraining each step in each swim lane. It allows for an express lane for high priority on-demand unplanned work (defects and footprint tickets). It makes inefficiencies and bottlenecks apparent to the team to self-correct and tune how the work is done at each step (colored sticky notes and visible policies). Overall it smooths out the cadence of work to keep work flowing through the team with visible status of all work items to the whole team.

Visit agilemanagement.net to explore more about Kanban agile practices, references, training with David Anderson, founder of Kanban as a software development practice.