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.

• Bugs

• Code

• Foundations

• Registry

• Soyuz

• Translations

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