Contents

  1. Kanban for Launchpad
    1. Overview
    2. Organization
    3. Development Workflow
      1. Analysis & Design
      2. Development
      3. QA
      4. Deployment
      5. WIP & Ready Lanes
      6. Backlog
      7. Archive
    4. Work Item Types
    5. Priority Mapping
    6. Prioritisation
    7. Stall & blockage
    8. What if the WIP are reached?
    9. Standup
    10. Launchpad Integration
    11. Experiment Evaluation

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 activities.

Public read-only access is available by login in using 'guest@launchpad.net' with 'launchpad' as password.

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

lane-analysis-design.png

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.

    lane-development.png 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.

    The initial WIP on the Coding and Review lane is usually around 2* the number of delevopers working on the feature. The Tasks lane doen't have any WIP limit, it's the backlog of tasks to complete the main card.

  2. A 'Bugs' lane

    lane-bugs.png 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 twice the number of developers.

QA

lane-qa.png

In this station, the development work is validated on production data. The first Landed lanes is used for cards that were merged into devel or db-devel and are awaiting validation against our test suite buy buildbot. Once their integration is blessed and they are available for testing on staging or qastaging, the card should be moved to the Ready lane.

Its WIP limit is around twice the number of developers.

Deployment

lane-deployment.png

The Ready lane is used to hold items that have pass QA and that are ready to deploy. Once the item has been deployed, either through a nodowntime deployment or the monthly roll-out, they can be moved to the Done-done 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

lane-backlog.png

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

lane-archive.png

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.

  • card-feature.png

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.

  • card-defect.png

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

  • card-improvement.png

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

card-feature-task.png

Priority Mapping

We use only two priority icons for cards.

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.

card-blocked.png

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:

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:

Kanban (last edited 2011-02-17 20:23:34 by flacoste)