Kanban Basics for Beginners kaizen WIP kaikaku flow value stream mapping visualize work flow cycle time lead time throughput TPS build failed CFDcreated byZsolt Fabók (email@example.com) June 22, 2011 @
Our goal for today ● Have an idea where Kanban comes from ● Understand the core principles of Kanban ● Going down the Rabbits hole ● Discuss open questions ● The coin game
Before saying anything:"I promise not to exclude from consideration any idea based on its source,but to consider ideas across schools and heritages in order to find theones that best suit the current situation." This means the end of statements like “That’s no good – it’s notagile / object-oriented / pure / etc…”, but rather a discussionabout whether idea (agile or plan-driven or impure or whatever)works well in the conditions of the moment.
A dream business model: ...make an idea possible with the lowest amount of work
Unfortunately, reality is a little bit different... + + ...you have to invest some money, but - and I dont want to ruin your day - , but youll have to do some work as well Building software is very expensive, so we need a methodology which makes it less expensive
Between 1940 and 1950, Japan and Toyotawerent in the best economical conditionBut Toyota had a plan to survive (TPS, ): ● Maximize customer value while minimizing waste ● Improve the production process continuously ● Bring out the best from the people
This is the 8th slide and no Kanban so far... WHERE IS IT?
By definition, Kanban is a pull-based inventorycontrol system ()Why did Toyota need an inventory controlsystem? Because inventory is waste, and as such, it needs to be eliminated(warning: according to Wikipedia, Kanban isnt an inventory control system, but thatarticle hasnt been verified yet )
Still nothing usable on Kanban, you are talkingabout waste... All right, Ill play along... WHERE IS IT, AND WHAT IS IT?
As you wish... It is here + +There are three kinds of waste: ● Muda: damage, wastage, loss, unnecessary expenditure, unnecessary effort ● Muri: overload, overburden, congestion, perversity ● Mura: Unevenness, imbalance, fluctuation, irregularity, deviation
Lean thinking and Kanban helps Toyota deliverquality products with lower investmentMaybe it could work for software development aswell, maybe...It is working for the chef...Lets see how it works in software development...
First principle: visualize the flow This is the flow, your actual process! There is no such thing as a standalone Kanban system It is always applied on a software development process like Waterfall, Scrum, XP, DSDM or a company-specific one
I visualize my flow in a more transparent way ...because "arrows" and non-visible process states wont help you find waste and improvement areas
What do you see on this picture? I see a huge inventory (11 items), and no customer value
Block your flow so that items will push each otherout... regular approach single piece flow
Second Principle: Limit the actual work in progress(WIP) Exercise: what needs to be done if the customer wants item F delivered in three days?
What shall I do when I become available? ● start something new ● or help finish something(preferred) priority
So far so good, when will I see any income? In this case, lets say that item A has been finished in 6 days... ...in 6 days? ...thats the lead time lead time Is this enough? According to Lean, of course... The answer is: no. You should improve it continuously (Kaizen) or drastically (Kaikaku)
Third Principle: continuous improvement forfaster delivery and faster feedback queued time working time cycle time lead time
The flow is continuous, it is always changing, likea river. There is no other choice than adaptation = [re] visit, [re] prioritize, improve everywhere
For faster delivery: ■ Use MMF (Minimal Marketable Function) it is small, travels fast through the system, but still holds customer value ■ Apply Littles Law small batches also travel fast through the system, and its better to have a fresh apple every day, than a bucket of rotten apples at the end of the week ■ Limit the amount of avatars people will do less context switching, which increases the speed of the items they are working on 
Prioritise by: ■ business value ■ cost of delay ■ service level agreement (SLA) ■ actual resource availability ■ current throughput and load
Closing words ● Dont work on a feature that nobody wants ● Dont write a document that nobody will read ● Dont write code that nobody can/will test ● Dont test a feature that cannot be deployed And there is a huge difference between being efficient and effective 
Thank you very much for your attention!For more Kanban-related topics, check out my website: http://zsoltfabok.com/