Diff for "Kanban"

Not logged in - Log In / Register
Differences between revisions 1 and 4 (spanning 3 versions)
⇤ ← Revision 1 as of 2010-01-26 22:19:36 →
Size: 1432
Editor: brianfromme
Comment:
← Revision 4 as of 2010-02-12 22:50:09 → ⇥
Size: 4516
Editor: flacoste
Comment: Lanes description
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
= Kanban Lives Here = = Kanban for Launchpad =
Line 3: Line 3:
As we develop our thinking on use of Kanban in Launchpad development, we will place that thinking here. == Overview ==
Line 5: 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.  1. 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/		  2. Deliver a predictable cycle time by controlling the quantity of
 work-in-progress.
Line 15: Line 17:
 * flow.io
  * http://flow.io/		  3. 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		  4. 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: Line 24:
 * LeanKit Kanban
  * http://LeanKitKanban.com		  1. Vizualize the development workflow
Line 27: Line 26:
 * Qanban
  * http://code.qbranch.se/post/listTag?selectedTag=qanban		  2. 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: 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		   1. Analysis & Design
Line 48: Line 48:
== Tools Under Evaluation ==     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 50: Line 52:
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.     The WIP limit on this station has been initially set as the number of
    Feature lane available to the team.
Line 52: Line 55:
== More Reading ==     1. LaunchpadEnhancementProposalProcess
Line 54: Line 57:
You can read more about Kanban all over the web.     1. UserInterfaceDesign
Line 56: Line 59:
If you just want a quick introduction, try: http://www.kanban101.com   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.

== Work Item Types ==

== Priority Mapping ==

== Standup ==

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.

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.

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

    • LaunchpadEnhancementProposalProcess

    • UserInterfaceDesign

  2. 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.
    • 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:
      • 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.
    • 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.
  3. 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.
  4. 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.

Work Item Types

Priority Mapping

Standup

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