Differences between revisions 4 and 7 (spanning 3 versions)

Kanban for Launchpad

Overview

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

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.
Deliver a predictable cycle time by controlling the quantity of work-in-progress.
Provide a simple prioritization mechanism enabling self-direction.
Make it possible to reserve capacity for technical debt reduction and general polish.

The two most important characteristics of a Kanban system are:

Vizualize the development workflow
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.

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:

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.

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 it's 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.
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 feature, 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, needs to be cherry-picked, 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 structure into different areas and also has limits on it. Usually 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.

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 obgligation 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 developpers to move things as fast as possible to the righ-hand side of the board, without violating the WIP limits.

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

Critical items should be worked on first. It is ok to override WIP limits for these items.
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.
Priority should then be given to making progress on the oldest items on the board.
When ready to start new work, priority should be given to Defects, than Feature work, than Improvements. Since the number of in-progress Feature on the board is limited, this should allow the possibility to start - and thus finish - lower-priority Improvements.

-  ⇤ ← Revision 4 as of 2010-02-12 22:50:09 → 
  Size: 4516
  Editor: flacoste
  Comment: Lanes description
+   ← Revision 7 as of 2010-02-17 19:43:11 → ⇥
  Size: 8330
  Editor: flacoste
  Comment:
-Deletions are marked like this.
+Additions are marked like this.
 Line 46:
-. 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:

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

    1. LaunchpadEnhancementProposalProcess 

    1. UserInterfaceDesign

  1. Development

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

    The number of feature lanes has been determined based on team size / 2.

    1. One or more feature lane.

        These lanes are used for longer term work that will take more than
        one branch to complete. Here are it's subdivisions:

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

        1. Coding

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

        1. Review

            Used for when a branch is in review.

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

    1. A 'Bugs'

        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
        subdivision than the feature lane.

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

  1. QA

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

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

  1. 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,
    needs to be cherry-picked, 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 'CP' lane.


Most of the above 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.
+=== Analysis & Design ===

{{attachment: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

  1. UserInterfaceDesign

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.

  {{attachment:lane-feature.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 it's 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.

  1. A 'Bugs' lane

  {{attachment: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 the number of developers.

=== QA ===

{{attachment:lane-qa.png}}

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

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

=== Release ===

{{attachment:lane-release.png}}

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, needs to
be cherry-picked, 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 ===

{{attachment:lane-backlog.png}}

The backlog is structure into different areas and also has limits on it.
Usually 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 ===

{{attachment: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.
-Line 125:
+Line 160:
+There are three main type of work items.

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

    {{attachment: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.

    {{attachment:card-defect.png}}

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

    {{attachment:card-improvement.png}}

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

{{attachment:card-feature-task.png}}
-Line 127:
+Line 186:
+We use only two priority icons for cards.

    {{attachment:priority-critical.png}} Critical -- Critical defects should
    have the '''Critical''' marker set. It's ok to override WIP limits when a
    critical item passes through.

    {{attachment:priority-due-date.png}}  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 obgligation 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 developpers to move things as fast as
possible to the righ-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.

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

  1. Priority should then be given to making progress on the oldest items on
  the board.

  1. When ready to start new work, priority should be given to Defects, than
  Feature work, than Improvements.  Since the number of in-progress Feature 
  on the board is limited, this should allow the possibility to start - 
  and thus finish - lower-priority Improvements.


== What if the WIP are reached? ==

launchpad development

Kanban for Launchpad

Overview

Organization