based on the idea that in a supermarket, customers get what they need at the needed time, and in the needed amount.the supermarket only stocks what it believes it will sell, and customers only take what they need because future supply is assured.This led Toyota to view a process as being a customer of preceding processes, and the preceding processes as a kind of store.The customer process goes to this store to get needed components, and the store restocksKanban uses the rate of demand to control the rate of production, passing demand from the end customer up through the chain of customer-store processesIn 1953, Toyota applied this logic in their main plant machine shop
Kanban in sw development
Our experienceDaniel Céspedes Daza
Agenda1. Kanban in a nutshell2. Kanban in SW development3. Scrum – Kanban similarities4. Scrum – Kanban differences5. How to apply Kanban6. How we applied Kanban in our project7. Conclusions8. Questions9. Sources
1-Kanban in a nutshell • Kan-ban (看板) = Signal-card.
1-Kanban in a nutshell - JIT • In the late 1940s, Toyota started studying store and shelf-stocking techniques from supermarkets
1-Kanban in a nutshell – Queue Mgmnt • Cashier focuses on taking order • Barista focuses on supplying coffee • Separated by queue allowing variable demand to be “absorbed” • Cashier moves to help Barista when no customers waiting to order • Focus is on end to end FLOW = customer- centric
1-Kanban in a nutshell – Process Mgmnt Tool Principles Make work Visible Limit Work In Progress Help the work Flow
2-Kanban in SW development The Kanban method formulated by David J. Anderson. 1st virtual kanban system for SW engineering was implemented at Microsoft en 2004 Kanban method as an approach to change started to grow after Agile 2007 in Washington DC
2-Kanban in SW development • Is an approach to change management. • It isn’t a software development process or project management methodology. • Kanban is an approach to introducing change to an existing software development process or project management methodology.
2-Kanban in SW development • Kanban leverages many of the proven concepts from Lean including: • Defining Value from the Customer’s perspective • Limiting Work in Progress (WIP) • Identifying and Removing Waste • Identifying and Removing barriers to Flow • Culture of Continuous Improvement
2-Kanban in SW development• Kanban encourages incremental evolution of existing processes.• Kanban does not ask for a revolution of how people work, rather it encourages gradual change.
2-Kanban in SW development• Kanban is based on a very simple idea. Work In Progress (WIP) should be limited.• The kanban (or signal card) implies that a visual signal is produced to indicated that new work can be pulled because current work does not equal the agreed limit.
5-How to apply Kanban? • The principle of Kanban is that you start with whatever you are doing now. • You understand your current process by mapping the value stream. • You agree to WIP limits for each stage in that process. • You then start to flow work through the system by pulling it when kanban signals are generated.
5-How to apply Kanban?• Visualize the workflow • Split the work into pieces, Stories we already do that. • Use named columns to illustrate where each item is in the workflow.• Limit Work In Progress (WIP) – assign explicit limits to how many items may be in progress at each workflow state.• Measure the lead time (average time to complete one), optimize the process to make lead time as small and predictable as possible.
5-How to apply Kanban? Lead Time = Customer View Cycle Time = Internal View
6-How we applied Kanban in our project? •Process – we modeled our process •Work – we decided the unit of work •WIP limits – limit WIP to help work flow •Policy – set quality policies •Bottlenecks and flow – move resource to bottlenecks •Class of Service – different work has different policies – done definition for each state •Cadence – Releases, Plannings, Reviews
6-How to apply Kanban in our project? We modeled our process
6-How to apply Kanban in our project?Value Stream
7-ConclusionsHistory: Team: 14 members, 8 at Arg, 6 at US. 2 years doing Scrum with 1-week sprints (3 years Scrum in total) before shifting to Kanban Kanban implemented 6 months ago on TFS (Visual WIP) with some Scrum practices (PO, Scrummaster, standup, review, retrospective)
7-ConclusionsBenefits Simplified “pull” system to the team, visibility on workflow and bottlenecks Stories defined as per valuable product rather than to fit within an iteration, with less and clearer gauges (lead time, WIP limit) with more focus on work product With clearer “Done” criteria for each column (state of a work item) quality became integral part along dev process. Stabilization reduced from 2 months to 2 weeks.
7-ConclusionsTo-do Still difficult to have mid-long term visibility (e.g. done-not done for next release)Results 1st release done March with 15 stories and 160 bugs fixed. Beta released 2- month ago to experts and early adopters (1st time a beta is provided). Lead time 60 days average per story, while with Scrum it was ~90. (lead time ~45 days for next release).