Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Kanban - a quick intro.

A *very* small introduction to Kanban.
Covers the basic rules and some peculiar aspects of the methodology.

  • Identifiez-vous pour voir les commentaires

Kanban - a quick intro.

  1. 1. Kanban a quick intro by Matteo ‘Peach’ Pescarin (@ilPeach)
  2. 2. Kanban (かんばん) literally means “signal cards”. Was developed as a process management system by Taiichi Ohno during the ‘40s at Toyota, in order to improve and maintain a high level of production. Its aim was to reduce problematic areas by reducing the number of signal cards in circulation. The Kanban method used in software development was introduced by David J. Anderson as an approach to incremental, evolutionary process and systems change for organizations. History (sort-of)
  3. 3. Leanest of the Agile methodologies Kanban is part of Agile more prescriptive more adaptive RUP (120+) XP (13) Scrum (9) Kanban (3) Do Whatever Kanban is the most adaptive methodology available with only 3 basic rules: ● Visualise your workflow ● Limit your WIP ● Measure the lead time (average time to complete one item, or cycle time)
  4. 4. Kanban underlying philosophy ● start with what you do now ● agree to pursue incremental, evolutionary change ● respect the current process, roles, responsibilities and titles. These are also the base for a Lean pull system and the building of a continuous improvement (Kaizen) culture.
  5. 5. Some myths and notes Kanban is adaptive, meaning that nothing else apart from the basic rules, is mandatory. The team commits to improve the process by analysing it. Kanban, being so agile, can be made up of different practices and tools (e.g. paired programming, typical of XP, can be used, as well as sprint retrospectives or stand-ups, typical of Scrum, or anything/nothing else). Same goes for roles, timeboxed iterations, etc...
  6. 6. Visualise the workflow As in SCRUM, Kanban uses a board (either physical or digital) to visualise the workflow. The main difference between the two is that some columns are limited. Also, the Kanban board is not reset at the end of each iteration.
  7. 7. In SCRUM the WIP is limited per unit of time. In Kanban the WIP is limited per workflow state. The general idea is to limit all the workflow states. The board is persistent and changes can happen at any time (which is disruptive in Scrum). Limit the WIP
  8. 8. Notes on WIP limits The only thing needed is to agree who is able to modify what. Cross-functional teams are perfectly counted in the process and can work along in a Kanban workflow. Same goes for multi-projects.
  9. 9. Measure the lead time Once we have WIP limits in place we can start measuring and predicting lead time, i.e. the average time for an item to move all the way across the board. Having predictable lead times allows us to commit to SLAs (service-level agreements) and make realistic release plans.
  10. 10. Notes of lead time As in Scrum, lead time measurement can’t be always correct. Although its impact is not directly related to the estimation of each ticket. There are no precise rules on how many columns you should have in the board, what is you WIP limit, or what roles you need. The commitment to an evolutionary change should drive the adaptation based on facts.
  11. 11. Further reading http://www.infoq.com/minibooks/kanban-scrum- minibook (from which I’ve taken the images :P) http://www.infoq.com/minibooks/priming- kanban-jesper-boeg