launchpad development|
Size: 8330
Comment:
|
Size: 12295
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| ||<tablestyle="float:right; font-size: 0.9em; width:40%; background:#F1F1ED; margin: 0 0 1em 1em;" style="padding:0.5em;"><<BR>><<TableOfContents>>|| * '''Name:''' Kanban for Launchpad * '''Owner:''' Francis Lacoste * '''Effective:''' Under experiment as of 2010-02-10. * '''Experiment:''' Will replace [[PolicyAndProcess/GeneralDevelopmentProcess]] * '''Review:''' 2010-04-05 |
|
| Line 221: | Line 229: |
| 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. |
Feature work, than Improvements. Since the number of in-progress Features on the board is limited, this should allow the possibility to start - and thus finish - lower-priority Improvements. It is suggested to keep the backlog sorted. Since items goes on the board from left to right, you should pull the rightmost card you can start. == Stall & blockage == When no progress can be made on an item that is in a WIP column (not sitting in a Ready column where it means that work could start on it), the card should be marked as blocked and the reason for it should be entered. {{attachment:card-blocked.png}} Since that blockage will hamper progress of other cards through the system, the team priority should be to remove that blockage. |
| Line 228: | Line 249: |
| When a WIP is reached and moving one of your card or starting new would exceed one of the WIP limit, what should you do? The thing to not do is ignore the WIP limit! Obvious thing to do are to look at what items are blocked downstream. Is there someone's else branch that needs a review? Are there branches that needs QA that you could help. If there is nothing you can do to help remove the blockage, then do some non-code related: * Try out this new technology you heard about. * Work on that process improvement idea you had. * Research new development techniques. * You get the idea :-) If this situation happens too often, it means that there is a systemic reason for it. You should discuss it with your team lead and team mates, maybe even the whole Launchpad team. It's possible that the WIP limits are too low, then they should be raised, but that shouldn't be the first obvious response. Flow problems points at systemic problems in our process and opportunities for improvements. |
|
| Line 229: | Line 273: |
It is suggested that teams use the Kanban board to drive their stand-up. Instead of taking turns and each person reporting what they have done, what they are up to and their blockers, it's easier and faster to walk the board. Looking at all the in-progress items and discussing their status. With experience, you can focus the discussion only on blocked items and slow-progressing items. Obviously, teams should make sure that the boards are up to date before starting the stand-up. == Launchpad Integration == At the start of this experiment, there is no Launchpad integration. Which means that the status of bugs will have to be maintained in two places. '''It is more important that the kanban boards are up to date, than the Launchpad counterparts.''' So if people find it a bother to update two things, only update the kanban for now. The fact that the stand-up is driven from the kanban should make it obvious the rationale for this. The Lean``Kit``Kanban developers are looking into adding more features to make that integration easier. (For one, they'll add the possibility to have an external link on each card that will be clickable from the UI.) They tool offers offer a somewhat [[http://wiki.leankitkanban.com/KanbanAPI.ashx|RESTful API]]. The [[https://edge.launchpad/lp-kanban||lp-kanban]] project hosts the integration effort. == Experiment Evaluation == We'll be running using this Kanban process until April 5th 2010, collecting feedback on how things are going through then. We'll evaluate our use of Kanban at this point. Success criteria for the experiment: * Overall satisfaction of developpers and team leads with it. * Improved predictability into the development process: ability to get offer an SLA to external party based on request type (feature/defects/improvement). * Number of process improvements that were brought up by the increased visbility into the development process. |
|
Name: Kanban for Launchpad
Owner: Francis Lacoste
Effective: Under experiment as of 2010-02-10.
Experiment: Will replace PolicyAndProcess/GeneralDevelopmentProcess
Review: 2010-04-05
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.
Archive
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
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 Features on the board is limited, this should allow the possibility to start - and thus finish - lower-priority Improvements. It is suggested to keep the backlog sorted. Since items goes on the board from left to right, you should pull the rightmost card you can start.
Stall & blockage
When no progress can be made on an item that is in a WIP column (not sitting in a Ready column where it means that work could start on it), the card should be marked as blocked and the reason for it should be entered.
Since that blockage will hamper progress of other cards through the system, the team priority should be to remove that blockage.
What if the WIP are reached?
When a WIP is reached and moving one of your card or starting new would exceed one of the WIP limit, what should you do?
The thing to not do is ignore the WIP limit! Obvious thing to do are to look at what items are blocked downstream. Is there someone's else branch that needs a review? Are there branches that needs QA that you could help.
If there is nothing you can do to help remove the blockage, then do some non-code related:
- Try out this new technology you heard about.
- Work on that process improvement idea you had.
- Research new development techniques.
You get the idea
If this situation happens too often, it means that there is a systemic reason for it. You should discuss it with your team lead and team mates, maybe even the whole Launchpad team. It's possible that the WIP limits are too low, then they should be raised, but that shouldn't be the first obvious response. Flow problems points at systemic problems in our process and opportunities for improvements.
Standup
It is suggested that teams use the Kanban board to drive their stand-up. Instead of taking turns and each person reporting what they have done, what they are up to and their blockers, it's easier and faster to walk the board. Looking at all the in-progress items and discussing their status. With experience, you can focus the discussion only on blocked items and slow-progressing items.
Obviously, teams should make sure that the boards are up to date before starting the stand-up.
Launchpad Integration
At the start of this experiment, there is no Launchpad integration. Which means that the status of bugs will have to be maintained in two places. It is more important that the kanban boards are up to date, than the Launchpad counterparts. So if people find it a bother to update two things, only update the kanban for now. The fact that the stand-up is driven from the kanban should make it obvious the rationale for this.
The LeanKitKanban developers are looking into adding more features to make that integration easier. (For one, they'll add the possibility to have an external link on each card that will be clickable from the UI.)
They tool offers offer a somewhat RESTful API. The https://edge.launchpad/lp-kanban project hosts the integration effort.
Experiment Evaluation
We'll be running using this Kanban process until April 5th 2010, collecting feedback on how things are going through then. We'll evaluate our use of Kanban at this point.
Success criteria for the experiment:
- Overall satisfaction of developpers and team leads with it.
- Improved predictability into the development process: ability to get offer an SLA to external party based on request type (feature/defects/improvement).
- Number of process improvements that were brought up by the increased visbility into the development process.
