Difference between revisions of "Kanban"

From Pearl Language
Jump to navigation Jump to search
m (→‎Games: -- |person=''anonymous'')
Line 78: Line 78:


==Games==
==Games==
*{{web|url=http://www.agile42.com/en/training/kanban-pizza-game/|site=Agile 42|person=''anonymous''|title=Kanban Pizza Game}}
*{{web|url=http://www.agile42.com/en/training/kanban-pizza-game/|site=Agile 42|title=Kanban Pizza Game}}


==Simulations==
==Simulations==

Revision as of 10:00, 17 April 2013

The Principles Of The Kanban Method

David Anderson observed 5 core properties to be present in each successful implementation of Kanban. These have become know as the Principles of Kanban.

First adopt the foundational principles…

  1. Start with what you do now
  2. Agree to pursue incremental, evolutionary change
  3. Respect the current process, roles, responsibilities & titles

Then use the 5 Core Properties…

  1. Visualize the workflow
  2. Limit WIP
  3. Manage Flow
  4. Make Process Policies Explicit
  5. Improve Collaboratively—using models & the scientific method

To get started:

  1. Walk the line—Staple yourself to an item and follow its steps through its life.
  2. Visualize the workflow—Draw the flow of steps that are taken as a sequence of columns. Use common sense to merge columns.
  3. Track all work—For a couple of weeks, put all work as individual items on the board, and track them as they progress.
  4. Limit Work in Progress—After some time, and using common sense, put limits on some columns (and swim lanes, if you have them) to increase flow and throughput. Tighten up the limits over time, until it starts hurting. Use the pain to trigger a conversation on how to get rid of the pain while maintaining the limit. Repeat.

Examples

Kanban for maintenance

Maintenance department (9 fte) has 4 types of work:

  • incidents (errors in production, from small to mayor issues)
  • change requests
  • problems: problems are structural solutions to recurring incidents resulting in a change request, solution is not known beforehand
  • service requests: query requests for certain data, some data error analysis etc.

Some numbers: type of work average amount hours spent per type of work Percentage of total work spent incidents 15 per day 10 min – 30 hours, 1 a 1,5 hour on average 34% change requests 14 per month 40 hours on average 38% problems 3 per month wide range (solution unknown beforehand) 2,5% service requests 3 per day 1 – 8 hours 12% 12% general support

Two service domains, using swimming lanes:

  1. Office applications; and
  2. Logistical applications.

Per swimming lane, they sacrify one person as ‘incident master’ for the day, eliminating interrupts for the rest of the team. Other team member jump in when either or both get overloaded with work. There is no boom buffer agreement.

What types of work would you put up on the Kanban board?

Sources

Slides

Videos

Articles

Games

Simulations

Tools

There is a plethora of agile tools.

Wanted