2. The Kanban Method, as formulated by David J. Anderson, is an
approach to incremental, evolutionary process and systems change
for organizations.
A layman’s way of describing Kanban is:
• a way to organize the chaos that surrounds so many delivery
teams by making the need for prioritization and focus clear.
• a way to uncover workflow and process problems so you may
solve them in order to deliver more consistently to your
client/customer/etc.
Kanban accomplishes these things by introducing constraints into the
system to optimize the flow of value.
Flow is king but focus on the flow of VALUE!
4. Common Misconceptions of Kanban
• Start with Scrum, move to Kanban
Scrum and Kanban are two very different methods,
Neither one can be identified as a truly advisable start to absolutely
any project.
• Kanban only works for Support kind of work
However, Kanban is capable of reflecting every process or flow– it depends on
the way you’re working.
• There is no planning and estimation in Kanban
Some does Kanban without some sort of planning but people do Kanban with
planning and estimations as well
• You just need to follow the method.
Copying others Solution will not solve your Problem
5. • New stories/ Work Unit are constantly added to the Scope of work
• Constant task-switching and reduced productivity
• Unclear “Definition of Done” for many backlog items
• Team roles & responsibilities overlap – causing extra work for everyone
impacting Team motivation
• Work is often started but not always finished or Implemented
• Too many stakeholders for source of work
• Indecisions about work priorities, roles, responsibilities and job titles
• Poor quality leading to high defect rates – lots of rework
Are These Disrupting Your Development Process?
5
If “YES” -- Kanban Like System Is Right For You
6. Flow Systems – Example of Kanban Board
Discovery Kanban Delivery Kanban
8. 1. Does your workflow match your team’s actual process?
• Are you transitioning to Kanban from a prescribed process (like Scrum).
• Maybe your team knows its process but other teams don’t.
• You’ve never mapped your process and don’t know where to start.
2. Do you have process policies in place?
• If you run into an impediment. Who needs to know?
• How are you going to seek resolution?
• While you’re waiting, do you start new work or not?
• Process policies help answer those and other questions so everyone understands
the “rules of the road” for how work gets done.
• This helps to reduce confusion and leads to greater process consistency.
3. Are your standups and retrospectives effective?
• Does Regular rich targeted discussion take place between management and team members
about how the work flows:
• What’s moving?
• What’s not moving and why?
• What needs to happen so work will start moving again?
9. 4. Have you implemented WIP limits?
• Practicing (WIP) to make your Kanban board a pull system, rather than a visual to-do list.?
• Using WIP limits, to improve the flow of work and increase Team’s focus and collaboration.
• Creating shorter feedback loops through WIP within the process?
• Learning from work flowing and allowing you to make adjustments on the fly.
5. Have you adopted a culture of continuous improvement?
• Are you analyzing your workflow -- measuring things like total WIP, blockers, throughput, or lead time
• Do you begin to see ways you can evolve and streamline
• Do you have a Kanban change team to start and support a culture of continuous improvement.
6. Is there a need for a more structured introduction to Kanban?
• The previous the first five questions on this checklist would test Teams basic understanding of
Kanban and tell if they need additional Kanban education.
7. Do you have a plan for continuing education?
• Are you ready to invest for various Education for Different stages of your Kanban initiative.
• Adding new team members or re-form teams
• Revisit your arsenal of initial Kanban education
• Regular departmental trainings around webinars or book clubs
• Certified Kanban coaches and trainers to resolve recurring issues.
22. Coordinating At Scale
Program Stand-up twice per week
- Management
- Solution Team
- Dev Teams
- QA Teams
- OPS Teams
Team Stand-ups
- Dev Teams, Daily
- QA Teams X times per week
- Ops Team X times per week
Improvement Meetings
- Each Kanban Team 2 weekly to 4 weekly Cadence
- Program Retro Monthly or Bi-weekly – as needed
- Cross Team Retro as Needed
23. Kanban daily standup meetings can be very large
In this example more than 40 people attend a standup for a large project with 5 concurrent development
teams. The meeting is usually completed in under 15 minutes
24. Manage WIP at Scale
Projects/Features
with high attention
Cross-Product
Features/Task Forces
Shared Resources
Class of Service
Fixed Date / Cost / etc.
25. Kanban Metrics Recommended Basic Metrics for Kanban team:
Lead time
Cycle time
Throughput
No. of work items at each state (CFD)
Statistic based in time elapsed
• Horizontal line from a given point to the edge of the
“done” lane – gives lead time from that point on
your board
• Connect those vertical and horizontal lines to form a
triangle, (the slope of the line on the edge of the
“done” lane”) == average throughput, i.e., the rate at
which you are getting things into “done.”
• The Control Chart can show the cycle
time (or lead time) for your product, version or
sprint. It takes the time spent by each issue in a
particular status (or statuses), and maps it over
a specified period of time. The average, rolling
average and standard deviation for this data is
shown.
26. 26
Kanban Metrics
Cycle time should start being measured, when the item task enters
the "working" column, not earlier.
Between the commitment Points:
• WIP = 100 work items in progress
• Throughput = 10 work items per week
• A variation of Little’s Law is often used to calculate cycle time.
• Cycle Time = WIP/Avg completion Rate
= 100/10= 10 weeks
This means the cycle time to complete all the WIP is 10 weeks.
The Lead time is the time from the moment when the request was
made by a client and placed on a board to when all work on this
item is completed and the request was delivered to the client. So
it's the the total time the client is waiting for an item to be
delivered.
• Lead Time = Cycle Time * WIP
Or
Lead Time = WIP/Throughput
Cycle Time Lead Time
A customer requests their product on November 6. The company receives the order instantly, and delivers the product on November 10.
He actually starts working on the product only from the 8. Therefore, the Lead Time here is 4 days, while the Cycle Time is 2 days
27. BenefitsOfScalingKanban All teams coordinated their work in order to reach a common goal:
“The success of the program”
All parties starts to focus on flow and not on utilization.
No new work gets started once we reach a WIP limit and focus on
improving the system instead.
Lead times of Epics gets reduced.
Throughput goes up
A lot of pressure was taking off the teams.
Deliver more stuff in a shorter period of time with happier people.
30. Resources/ References
• Scaling Kanban by Klaus Leopold
• Cross-Department Kanban Systems - Andy Carmichael and Simon Wood
• Various Blogs and Slide Share content