• Save
Introduction to Kanban
Upcoming SlideShare
Loading in...5

Like this? Share it with your network


Introduction to Kanban



In this presentation, Roni explains the basics of Kanban and the principles governing the application of Kanban for process improvement. We also look at a comparison between Scrum and Kanban and visit ...

In this presentation, Roni explains the basics of Kanban and the principles governing the application of Kanban for process improvement. We also look at a comparison between Scrum and Kanban and visit the basic differences between them.



Total Views
Views on SlideShare
Embed Views



5 Embeds 269

http://mestreacasa.gva.es 251 7
http://www.onlydoo.com 7
https://twitter.com 3
http://presentationdocs.playableitems.demobo.com 1



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

Introduction to Kanban Presentation Transcript

  • 1. Introduction to KanbanRoni C. Thomas@ronicthomashttp://in.linkedin.com/in/ronicthomas/roni@intelligrape.com
  • 2. Agenda− What’s wrong with the current system?− History of Kanban− What is Kanban?− Why Kanban?− Kanban Practices− Creating your first board− Kanban Principles− How is Scrum different from Kanban?
  • 3. What’s wrong with the current system?− Burnout− Frequent bugs on production− Complaints about productivity− Low throughput− Leads to vague sprint planning− Too much work stuffed into one sprint− Unidentified bottlenecks
  • 4. KAN BAN署名する ボード++=“signboard”
  • 5. History of Kanban− Developed by Taichi Ohno at Toyota in 1940s− Designed after the shelf-stocking techniques used by supermarkets− Demand controlled system where replenishment happened based onmarket conditions− Based on a pull based system rather than a push based one− Use of visual signals was essential to the system
  • 6. What is Kanban?− Scheduling system used in manufacturing to help companies improvetheir production process− Adopted by software cos for JIT delivery without burdeningdevelopers− “The Kanban Method” for software dev pioneered by David J.Anderson− WIP limited pull system which exposes system problems throughvisualization
  • 7. What is Kanban? (contd.)− In its simplest form, a kanban system consists of a big board withstory cards− Board represents the state of the project at any point− Different from other visualizations – implements WIP limits− Tries to limit the amount of work at any stage− Easy identification of bottlenecks in system through visual boards− Aims at minimizing waste states
  • 8. Fig. One typical Kanban board
  • 9. But why Kanban?… because …− it helps in visualising the system and expose problems− it allows us to evaluate the impacts of process changes− it allows us to identify bottlenecks and alleviate them− it allows us to establish trust in the process− it helps us to maintain a sustainable pace with a sustainablethroughput− you need to relax and Kanban advocates just that!
  • 10. The KanbanPractices
  • 11. Visualize− Workflow is inherently invisible− Visualization is core to Kanban− Enables people to take a quick look at the state of the workflow− Use of story cards can be used− Development process is divided into columns− Each task is specified on a story card− Essentially cards move along the board to show workflow.
  • 12. Limit WIP− Apply limits on WIP in each phase of development− Is the basis for implementing a pull based system− Work is pulled into the next phase once capacity is available− Improves quality by giving greater focus to fewer tasks− Also reduces lead time for work by reducing the number of concernsfor the developer
  • 13. Limit WIP (contd.)− Because maximum utilization of resources is not desirable contraryto popular belief− Brings in slack into the system – creates a more conducive workprocess− Get the most important things done, one by one, with a clear focus− Things get done faster, better than before, leading to lesser rework
  • 14. Manage flow− Workflow should be closely monitored− Measurements must be made to identify problems in the system− Leads to better understanding of the system and helps in makingeducated improvements− Helps identify the positive and negative impact of changesintroduced in the system
  • 15. Make policies explicit− All policies related to workflow management should be explicit− For eg. WIP limits, basic workflow, rejection/acceptance flow,definition of doneness etc.− Helps in providing a basis for process improvement based onstatistics− Allows for a more rational approach to process improvement bylogical reasoning
  • 16. Improve Collaboratively− Through the use of scientific models− Popular models: Theory of Constraints (TOC)− Use of models allows a team to make predictions about a change− The expected and actual result can then be used effectively toimprove the process− This approach leads to learning both at individual and organizationallevel
  • 17. Getting StartedThings you need:− A board− Lots of Post-it notes (preferably of different colors)− And lots of commitment (very important)− The next slides!
  • 18. And some terms...Important terms:− Lead Time – time taken from request of feature to its completion− Cycle Time – time taken to finish the task− Throughput – essentially refers to productivity. Defined as the amountof work delivered in a time frame− WIP Limit Value Stream – this refers essentially to your developmentprocess− Swarm(ing) – collaboration on a problem
  • 19. Fig. The Kanban BoardThe Board− Allows easy visualization of thedevelopment process− Each column represents onephase in your existing development process− Numbers on top represent WIP limits− The number of tasks in each phase is limited by the WIP limitsspecified
  • 20. − Keeps track of features/tasks− Is more of an XP related feature− Includes information regardingtransition of features on board− Post-it notes can be used− Different colored post-it notes can be used for different issue typessuch as bugs, features, tasks, improvement etc− TIP – Token, Inscription, PlacementFig. Story CardStory Card
  • 21. Charts− Measurement tools to measure the effectiveness of the system− Every time card is pushed/pulled on/off the board, charts startchanging− Can be used to interpret various important metrics like average timetaken for a task to be completed.− Can be used to identify the flow of work− Also useful to identify the state of tasks in each phase of development− Control Charts & Cumulative Flow Diagrams
  • 22. Control Chart
  • 23. Control Chart− Are used to measure the average time taken for a task to beprocessed− Lead time and cycle time is represented on a control chart− Simplest charts that can be drawn− The aim is to keep lead time and cycle time as low as possible
  • 24. Cumulative Flow Diagrams
  • 25. Cumulative Flow Diagrams− Show relative amount of work for each stage− Use of colored areas for each phase for easy identification ofbottlenecks− Vertical distance of the chart shows how many tasks are on the boardand helps you set right WIP limits− Horizontal distance allows you to monitor Cycle Time− CFD should run smoothly− Large steps or horizontal lines indicate problems in flow− Variations in gap/band indicate bottlenecks− When the band gets too wide, it indicates problems in work finishing ordevelopers unable to handle amount of work.
  • 26. Let’s get started− Identify your dev process− How are features decided?− What are the various steps involved in materializing it?− Define start and end points for the board− Identify your boundaries− Identify when a task enters the board− Identify the end of its life cycle on the board
  • 27. Let’s get started (contd.)− Agree− Initial WIP limits and policies – can change later− Prioritization and selection policies− Policies for different classes of service (expedite, standard, fixeddelivery date, intangible)− Process review cycle time
  • 28. …but before going on…CostTimeLinearClasses of service vs. Cost of DelayExpediteTimeCostFixedTimeCostIntangibleTime Cost
  • 29. Let’s get started
  • 30. The KanbanPrinciples
  • 31. Start with what you do now!− Do not prescribe any new roles or responsibilities to implementthe new system− No such thing as “Kanban Software Development Process”− Implement Kanban with existing system- David Anderson
  • 32. Agree to pursue incremental, evolutionary change− Optimize what already exists− Agree to continuous, incremental and evolutionary change to improvethe system− Keep experimenting to understand the effects of changes on thesystem− Make small changes rather than huge process changes- David Anderson
  • 33. Respect the current process, roles, responsibilities− Do not remove existing roles and titles− This will eliminate fears in introducing the new system in theorganization− Will help you get broader support in introducing the new system− Kanban was designed to reduce resistance to change- David Anderson
  • 34. Leadership at all levels− Empower the workforce to bring about change− Swarm on a bottleneck for faster resolution− Hold frequent discussions and process improvements− Include everyone in these discussions and do not disregardanyone’s viewpoint- David Anderson
  • 35. Scrum in a nutshell
  • 36. Split your productSplit your organizationLarge team spending a long time building a huge thingSmall team spending a little time building a small thing… but integrating regularly to see the wholeOptimize your processOrder the backlogSplit time
  • 37. Scrum vs Kanban
  • 38. Scrum prescribes roles, Kanban doesn’t!
  • 39. Scrum prescribes time-boxed iterations
  • 40. Scrum backlog items must fit in a sprintScrumKanban
  • 41. Both limit WIP in different waysScrum Board Kanban BoardWIP limited per unit of time(iteration)WIP limited per workflowstate
  • 42. Does it matter?− Emphasis should be on the goal and not the tool. Becoming/agilelean is not the goal− Don’t be dogmatic about your process− There is no good or bad tool. Only good or bad decisions− Keep experimenting for understanding and not judgment− Process is not important, improving the process is important
  • 43. Feedbackroni@intelligrape.com@ronicthomashttp://in.linkedin.com/in/ronicthomas/
  • 44. References− David J Anderson, Kanban - Successful Evolutionary Change foryour Technology Business, 1st ed, Blue Hole Press, 2010− Henrik Kniberg, 2009, “Kanban and Scrum – Making the Most ofBoth”, Online, Available: http://goo.gl/oiqPG− Images from www.kanbantool.com/kanban-analytics-and-metrics
  • 45. LicenseThis work is licensed under the Creative Commons Attribution-Noncommercial-ShareAlike 3.0 License