Differences between revisions 1 and 5 (spanning 4 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.

-  ⇤ ← Revision 1 as of 2010-01-26 22:19:36 → 
  Size: 1432
  Editor: brianfromme
  Comment:
+   ← 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 1:
-= Kanban Lives Here =
+= Kanban for Launchpad =
 Line 3:
-As we develop our thinking on use of Kanban in Launchpad development, we will place that thinking here.
+== Overview ==
 Line 5:
-== Kanban Web-Based Tools ==
+We are trying Kanban to coordinate our development process. The goals of
switching to Kanban for Launchpad development are:
-Line 7:
+Line 8:
-Here are a list of Kanban web-based tools.
+. Provide slack by balancing demand against throughput
-Line 9:
+Line 10:
- * Agile Zen
  * http://www.agilezen.com
+    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.
-Line 12:
+Line 14:
- * Digaboard
  * http://www.digaboard.net/
+. Deliver a predictable cycle time by controlling the quantity of 
 work-in-progress.
-Line 15:
+Line 17:
- * flow.io
  * http://flow.io/
+. Provide a simple prioritization mechanism enabling self-direction.
-Line 18:
+Line 19:
- * Jira 4.0 plus Greenhopper plugin
  * http://blogs.atlassian.com/jira/2009/11/add-kanban-support-to-jira-with-greenhopper-40.html
+. Make it possible to reserve capacity for technical debt reduction and 
 general polish.
-Line 21:
+Line 22:
- * Kanbanery
  * http://kanbanery.com/
+The two most important characteristics of a Kanban system are:
 Line 24:
- * LeanKit Kanban
  * http://LeanKitKanban.com
+. Vizualize the development workflow
-Line 27:
+Line 26:
- * Qanban
  * http://code.qbranch.se/post/listTag?selectedTag=qanban
+. Limit work-in-progress.
-Line 30:
+Line 28:
- * RadTrack
  * http://radtrack.com
+== Organization ==
-Line 33:
+Line 30:
- * Rally 2009.5 plus Kanban Mashup (video)
  * https://cc.readytalk.com/cc/playback/Playback.do?id=3jr0mg
+Each Launchpad team has a http://leankitkanban.com board set-up for them.
This will be the control center of the development activies.
-Line 36:
+Line 33:
- * Silver Catalyst
  * http://www.toolsforagile.com
+  * [[http://launchpad.leankitkanban.com/Boards/Show/12753884|Bugs]]
  * [[http://launchpad.leankitkanban.com/Boards/Show/12749742|Code]]
  * [[http://launchpad.leankitkanban.com/Boards/Show/12749740|Foundations]]
  * [[http://launchpad.leankitkanban.com/Boards/Show/12749744|Registry]]
  * [[http://launchpad.leankitkanban.com/Boards/Show/12749743|Soyuz]]
  * [[http://launchpad.leankitkanban.com/Boards/Show/12749741|Translations]]
-Line 39:
+Line 40:
- * Target Process
  * http://www.targetprocess.com
+== Development Workflow ==
 Line 42:
- * Trichord
  * http://trichord.change-vision.com/en/index.html
+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.
-Line 45:
+Line 46:
- * Version One
  * http://community.versionone.com/GettingStarted/Guide/Kanban.aspx
-Line 48:
+Line 47:
-== Tools Under Evaluation ==
+=== Analysis & Design ===
-Line 50:
+Line 49:
-The Launchpad team is currently evaluating the use of Kanban whiteboard tools for process visualization.  The current findings on that work can be read from our [[/Evaluation|evaluation]] page.
+{{attachment:lane-analysis-design.png}}
-Line 52:
+Line 51:
-== More Reading ==
+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 54:
+Line 55:
-You can read more about Kanban all over the web.
+. LaunchpadEnhancementProposalProcess
-Line 56:
+Line 57:
-If you just want a quick introduction, try: http://www.kanban101.com
+. 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.

== 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 ==

== Standup ==

launchpad development

Diff for "Kanban"