Difference between revisions of "Kanban"

From Pearl Language
Jump to navigation Jump to search
(→‎Articles: Dropbox » Christophe Achouiantz » The Kanban Kick-start Field Guide)
(→‎Sources: ==Pearls==)
Line 57: Line 57:
   
   
What types of work would you put up on the Kanban board?
What types of work would you put up on the Kanban board?
==Pearls==
{{#ask: [[Category:Kanban]]
| mainlabel=Kanban
| ?Wish in a single line=Goal:
| ?Therefore in a single line=Therefore:
}}


==Sources==
==Sources==

Revision as of 14:42, 10 May 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?

Pearls

KanbanGoal:Therefore:
Ask for the moon
Blocker waiting room
Capacity planning
Flow master
Goldilocks sizer
Honest time
Ka-ching a day makes product owner hurray
Kanban
Life is a broccoli
Metric drives behavior
Obeya
Only move forward
Physical information radiators
Retrospective meeting
Slack speeds up
Spice girls question
Story splitter
Unique specific tasks
Visual workflow
Work in progress limit

Sources

Slides

Videos

Articles

Games

Simulations

Tools

There is a plethora of agile tools.

Wanted

Processable

  • InfoQ » Arne Roock » Implementing Kanban in Practice
    • There is just one prerequisite for change, there needs to be what leadership authority John Kotter calls in his book by the same title "a sense of urgency".
    • before you start introducing Kanban, you need to agree on the major goals. That means we need to have management support.
    • We cannot see our work, and that means it is very hard to improve things. create visibility for the end-to-end flow
    • What will work is if you achieve better results and make them transparent, people will become curious, and curiosity is a very powerful tool.
    • distributed kanban can use a remote buddy
      • it sounds like a lot of overhead and it is. But you need to have this communication. But you will observe that now the buddies will start communicating, not just about moving tickets but about things like “I am out next week on vacation, so please remind the other team members to do this and that.”
      • people are communicating across the team boundaries and that is really valuable.
    • When people are only communicating via the tool, you’re nailed!
    • There is a rule called "three by three; if you're standing 3 meters from the Kanban board, then in 3 seconds you want to know what is going on. You can't read every card but you can see where things are piling up, and where people have nothing to do. But if you have too many columns or too many swim lanes then you start to get lost.
    • The other thing you referred to is an item that is blocked but is not an expedite. I am waiting for another team because I need information or something from them. I can start another item and break the WIP limit, or I can use this “slack capacity” slack speeds up—slow down to speed up
Retrieved from "http://pearllanguage.org/index.php?title=Kanban&oldid=778"