• Name: Kanban for Launchpad

• Owner: Francis Lacoste

• Effective: 2010-02-10.

• Experiment: Will replace PolicyAndProcess/GeneralDevelopmentProcess

• Reviewed: 2010-04-05

Kanban for Launchpad

Overview

We are trying Kanban to coordinate our development process. The goals of switching to Kanban for Launchpad development are:

1. Provide slack by balancing demand against throughput

   • By slack we mean non-fully utilized resources allowing opportunities for continuous process improvements and also give the room to react without overload to unplanned events.

2. Deliver a predictable cycle time by controlling the quantity of work-in-progress.
3. Provide a simple prioritization mechanism enabling self-direction.
4. Make it possible to reserve capacity for technical debt reduction and general polish.

The two most important characteristics of a Kanban system are:

1. Vizualize the development workflow
2. Limit work-in-progress.

Organization

Each Launchpad team has a http://leankitkanban.com board set-up for them. This will be the control center of the development activies.

• Bugs

• Code

• Foundations

• Registry

• Soyuz

• Translations

Background information on Kanban can be found on the Canonical Lean CoP resources page.

Development Workflow

The board shows all the work-in-progress and its state. All boards are similar but have different work-in-progress limits based on the team size and capacity.

Analysis & Design

This station is used to track and limit the number of work at the pre-coding stage. The end goal of that station is to get the feature to a ready-to-code stage. It has two subprocesses:

1. LaunchpadEnhancementProposalProcess

2. UI/Design

The WIP limit on this station has been initially set as the number of Feature lane available to the team.

Development

That's the station where the coding and development activities occur. It is subdivided into a number of sublanes.

1. One or more feature lane.

   The number of feature lanes has been determined based on team size / 2. These lanes are used for longer term work that will take more than one branch to complete. Here are its subdivisions:

   Task

   This column contains the bug or feature that is used for the lane. It also acts as the backlog of the tasks (branches) that are needed to complete that feature.

   Coding

   Used for representing when a developer is working on a branch.

   Review

   Used for when a branch is in review.

   Completed

   Used to hold the merged branches. All branches related to the master feature should be in this holding area, until it is completed, at which point the branch cards should be moved to

   the Archive and the feature or bug should be moved to the QA Ready lane.

   The initial WIP on the Coding and Review lane has been set to 2. The Tasks and Completed lanes don't have any WIP limit.

2. A 'Bugs' lane

   This lane is use for defects (OOPS), technical debt cleanup and other general minor enhancement (bugs). Items in this lane should be able to

   be completed using one branch. It has the same Coding / Review subdivisions than the feature lane. Its initial WIP limit is equal to the number of developers.

QA

In this station, the development work is validated on production data. Remember that QA is done on bugs or features, not branches.

Its initial WIP limit is equal to the number of developers.

Release

That's the station to hold stuff that is completed (available to users on edge - or ready to be part of the next release on staging) If the changes need to be cherry-picked (CP), the 'Ready for CP' lane can be used. Once the item has been deployed, it can then be moved to 'Done'. An arbitrary WIP of 2 has been set on the Ready for CP lane.

WIP & Ready Lanes

Most of the lanes are further subdivided in a WIP and a Ready column. The WIP column holds the card when the developer is working on the task. Once the work related to column is complete, it's moved to the Ready column. So that it can be pulled in the next one when things start. The Ready columns are used as hands-off buffer when the item will switch owners across functional boundaries (for example, if the engineer doing the UI mock-ups isn't the one who will implement the feature). It's also used to compute the effectiveness of our process (that's the ratio between when things are actually being worked on vs the time things spend waiting for some-one to be available to work on them).

Backlog

The backlog is structured into different areas and also has limits on it. Usually there is a lane to hold upcoming feature work and another for defects, tech-debt and general enhancements. New work should be pulled from these when capacity is available.

It is the responsibility of the team leads in conjunction with the product strategist to fill the backlog.

Archive

The lane in this pane holds the completed items. There is a special lane called Trash or Rubbish that is used to collect items which were started but then got cancelled.

Work Item Types

There are three main type of work items.

Feature work

These are the green cards and represent high-impact user visible work.

• 

Defects

These are the red cards. They are used for OOPSes and other major bug that prevent users from accomplishing their intended task. Don't use it for minor usability improvement or other of the many "improvement bug" that we have.

• 

Improvement

These are the blue cards. They are used for tech-debt items or other general improvement category.

• 

The yellow cards are used when one of the items in the Feature lanes need to be subdivided.

Priority Mapping

We use only two priority icons for cards.

• Critical -- Critical defects should have the Critical marker set. It's ok to override WIP limits when a critical item passes through.

  High -- Items that have a due date (because of a serious cost of delay) should have the High priority. That's only to make it obvious that the item has a due date, because leankitkanban does't make it obvious otherwise. All due date needs a justification. Good reasons for having a due date are that there is a contractual obligation or other externally imposed deadlines (for example, it needs to be done to a particular date because of a Ubuntu release.)

All other items should have the Normal priority.

Prioritisation

The overall aim of the game is for developers to move things as fast as possible to the right-hand side of the board, without violating the WIP limits.

When selecting the next task to work on, the prioritisation criteria:

1. Critical items should be worked on first. It is ok to override WIP limits for these items.
2. Priority should then be given to Due-date items that are coming up. Due-date items that are late should be considered as 'Critical' priority work items.
3. Priority should then be given to making progress on the oldest items on the board.
4. When ready to start new work, priority should be given to Defects, then Feature work, then Improvements. Since the number of in-progress Features on the board is limited, this should allow the possibility to start - and thus finish - lower-priority Improvements. It is suggested to keep the backlog sorted. Since items goes on the board from left to right, you should pull the rightmost card you can start.

Stall & blockage

When no progress can be made on an item that is in a WIP column (not sitting in a Ready column where it means that work could start on it), the card should be marked as blocked and the reason for it should be entered.

Since that blockage will hamper progress of other cards through the system, the team priority should be to remove that blockage.

What if the WIP are reached?

When a WIP is reached and moving one of your card or starting new would exceed one of the WIP limit, what should you do?

The thing to not do is ignore the WIP limit! Obvious thing to do are to look at what items are blocked downstream. Is there someone's else branch that needs a review? Are there branches that needs QA that you could help.

If there is nothing you can do to help remove the blockage, then do some non-code related:

• Try out this new technology you heard about.
• Work on that process improvement idea you had.
• Research new development techniques.
• Improve the documentation on dev.launchpad.net or help.launchpad.net

• You get the idea

If this situation happens too often, it means that there is a systemic reason for it. You should discuss it with your team lead and team mates, maybe even the whole Launchpad team. It's possible that the WIP limits are too low, then they should be raised, but that shouldn't be the first obvious response. Flow problems points at systemic problems in our process and opportunities for improvements.

Standup

It is suggested that teams use the Kanban board to drive their stand-up. Instead of taking turns and each person reporting what they have done, what they are up to and their blockers, it's easier and faster to walk the board. Looking at all the in-progress items and discussing their status. With experience, you can focus the discussion only on blocked items and slow-progressing items.

Obviously, teams should make sure that the boards are up to date before starting the stand-up.

Launchpad Integration

At the start of this experiment, there is no Launchpad integration. Which means that the status of bugs will have to be maintained in two places. It is more important that the kanban boards are up to date, than the Launchpad counterparts. So if people find it a bother to update two things, only update the kanban for now. The fact that the stand-up is driven from the kanban should make it obvious the rationale for this.

Following the initial experiment, we are now looking at synchronising Launchpad and Kanban status using their somewhat RESTful API. They recently added the ability to link each card on the Kanban board to an external link which makes it easier to link both ways.

The https://edge.launchpad.net/lp-kanban project will host the integration effort.

Experiment Evaluation

The evaluation of the initial experiment was very positive.

Success criteria for the experiment were:

• Overall satisfaction of developers and team leads with it: 90% of developers thought we should continue with it.
• Improved predictability into the development process: ability to get offer an SLA to external party based on request type (feature/defects/improvement).
  • We have the data now and will start using it with our stakeholders.
• Number of process improvements that were brought up by the increased visibility into the development process.
  • This is relatively disappointing, in that in the initial two months period we cannot say that we got any.