In the 1940s, Toyota developed a scheduling system to improve their manufacturing production. Aligning the supply of materials with the demand of the production line reduced the amount of inventory in the system, and enabled a flexibility never before seen in the automobile industry.
Over the years, teams dealing with knowledge work (e.g. software development) adapted many of these ‘lean’ ideas, such as limiting the amount of work in progress, to improve the flow of work through their system.
Ideal for product owners, business analysts, developers, testers, and any users of Agile/Scrum, this presentation explains the basics of this system, called Kanban, and how it can be used to improve workflow and delivery rate.
2. If you only remember 2 things
Kanban is about flow Kanban is not
prescriptive
3. No ‘Big Bang’ changes
Three foundational principles:
1. Start with what you do now
2. Agree to pursue evolutionary change
3. Respect the current process, roles,
responsibilities & titles
!
4. What is Kanban?
!
IS a set of ideas/practices
IS a ‘lean’ system
IS about evolutionary change
IS focused on knowledge work
IS a pull system
!
IS NOT a prescribed process
IS NOT an agile framework
IS NOT about revolution
IS NOT kanban in manufacturing
IS NOT a push system
Kanban …
5. What is Kanban?
• What is a pull system?
– Agree capacity of the system
– Use tokens (e.g. cards) to denote capacity
– Attach a token to each piece of work
– When run out of tokens, stop taking on new work
– Only take on new work when a token becomes
available
• Means the system cannot become overloaded
6. 1. Visualise your work
2. Limit WIP
3. Manage flow
4. Make policies explicit
5. Implement feedback loops
6. Evolutionary improvement
Kanban has 6 core properties
8. • Visualising your work enables you to
understand how work flows through your
system
• Helps you spot areas that need change
• Most common approach is to use cards on
a board – with different columns for each
step of your process
Visualise Workflow
9. • Start by drawing out your current process
• It is NOT about roles
• It IS the steps your work goes through
• Don’t worry if some items skip some steps
Visualise Workflow
10.
11. • Translate your process to your board
• How can you best visualise your workflow?
– Different types of work
– Different priorities
– Different customers
– Who is working on what?
– What is blocked?
Visualise Workflow
13. • Assumes stable flow (i.e. one in, one out,
similar sized stories) and pull system
• Allowing too much work to happen at the
same time can have negative effects; so
can having too little.
• Aim is to get WIP limits to the “sweet
spot” where you have the optimum/
optimal flow
Limit Work-In-Progress
14. I have produced a video to explain:
– WIP limits
– Cycle Time/Lead Time
– Throughput Rate (now ‘Delivery Rate’)
!
!
You can find the video (“WIP: why limiting work in
progress makes sense”) on YouTube
Limit Work-In-Progress
15. • Encourage swarming
• Encourage small work items
• Encourage flow of work
• Encourage finishing work items
!
“Focus on finishing things, not working on things”
Why WIP Limits Help
16. • Start with what you have now …
• Can you:
– Limit WIP of tasks in progress per story?
– Limit WIP per column on the board?
– Limit WIP per section of the board?
– Limit WIP across the whole board?
– Limit WIP across the whole organisation?
How to start using WIP limits
18. • Measuring the flow of work through your
system helps you identify problems
• Every process has at least one bottleneck
• Your system can only work as fast as your
slowest point
• So make changes to your process in an
attempt to improve flow
Measuring Flow
19. • Scrum has a Burndown Chart
!
• Kanban has a variety of reports:
– Cumulative Flow Diagram
– Control Chart
– Histogram
Kanban Reports
20. The CFD shows us:
– Flow of items coming in
and out of process
– Current level of WIP
– Lead/Cycle Time
– Warnings about
bottlenecks
Cumulative Flow Diagram (CFD)
21. • The Control Chart shows us:
– Our average (‘mean’) Lead
Time/Cycle Time
– Upper & Lower Control Limits
(based on a 1-sigma
variation)
– Outliers
!
!
Investigate performance to
attack sources of variability
Control Chart
22. • The Histogram shows us:
– Frequency of each Lead/
Cycle Time
– A guide for the time that
future stories will take
!
This information gives us
much greater understanding
than a burndown chart!
Histogram
24. • If you don’t know the rules, it is difficult
to improve a situation (responses will be
emotional and subjective)
!
• Acknowledge any policies in your process
by stating them explicitly.
Make Policies Explicit
25. • Entry criteria
• Definition of ‘Done’
• Classes of Service
– Standard
– Expedite
– Fixed
– Intangible
Make Policies Explicit
27. • Review data and experiences regularly.
• Encourage feedback from inside and
outside the team:
– Retrospectives / Operations reviews
– Daily stand-ups
– User feedback
– Stats & reports
– Feedback from stakeholders / the business …
Feedback Loops
29. • “Kaizen” = continuous improvement
(rather than revolutionary change)
• All the other Kanban ideas lead to this
and should provide data to help improve
• Start where you are now and seek to
“attack the sources of variability” in your
processes
Evolutionary Improvements
30. • Differing sizes of work items
• Differing work types (e.g. bugs, features,
debt)
• Differing classes of service
• Having to rework items
• Accepting unknown work
• Problems with platforms/environments
Sources of Variability
31. Thank you
If you would like to know more, check out
scrumandkanban.co.uk