Differences between revisions 4 and 5

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.

-  ⇤ ← Revision 4 as of 2010-02-12 22:50:09 → 
  Size: 4516
  Editor: flacoste
  Comment: Lanes description
+   ← Revision 5 as of 2010-02-15 22:49:48 → ⇥
  Size: 6390
  Editor: flacoste
  Comment:
-Deletions are marked like this.
+Additions are marked like this.
 Line 46:
-. Analysis & Design
-Line 48:
+Line 47:
-    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:
+=== Analysis & Design ===
-Line 52:
+Line 49:
-    The WIP limit on this station has been initially set as the number of
    Feature lane available to the team.
+{{attachment:lane-analysis-design.png}}
-Line 55:
+Line 51:
-. LaunchpadEnhancementProposalProcess
+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:
-Line 57:
+Line 55:
-. UserInterfaceDesign
+. LaunchpadEnhancementProposalProcess
-Line 59:
+Line 57:
-. Development
+. UserInterfaceDesign
-Line 61:
+Line 59:
-    That's the station where the coding and development activities occur.
    It is subdivided into a number of sublanes.
+The WIP limit on this station has been initially set as the number of
Feature lane available to the team.
-Line 64:
+Line 62:
-    The number of feature lanes has been determined based on team size / 2.
+=== Development ===
-Line 66:
+Line 64:
-. 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.
+That's the station where the coding and development activities occur.
It is subdivided into a number of sublanes.
-Line 118:
+Line 68:
-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.
+. 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 124:
+Line 159:
+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.

launchpad development

Kanban for Launchpad

Overview

Organization