Professional Documents
Culture Documents
Kanban Scrum
Kanban Scrum
2. Scrum
vs. Scrumban
vs. Kanban
Evaluator
3. Feedback Loops
in Kanban
4. Kanban Metrics
• In kanban, the process workflow, from definition of work to its delivery to the
customer, is displayed for participants to see and team members pull work
from each queue.
F
G
GY
DE
I
Getting Beyond Proto-Kanban
Getting beyond visual board:
Hedge risk by allocating capacity, by defining WIP limits to shape demand (total WIP) for queues/swimlanes.
Explicit policies &
Engineering
WIP Limits Ready Development Testing Deployment Done
Ready
based on classes of
3 3
service & work type! 2 Ongoing Done Verification Acceptance ∞
Defect&
Tech 1
Debt
(30%) 2 Expedite Lead time “clock” Lead time ends at
P1
starts at input queue! AB 1st infinite
infinite queue!
queue!
NPD In my kanban coaching experience, kanban "flow
i.e. 2
Fixed D E & pull" aspect orientation forces you to "stop
New MN starting, start finishing", better than scrum
Prod Date PB "inspect & adapt" orientation. Kanban being
workflow management tool, requires solid
Dev
3 engineering practices for teams to succeed in
Rallying with
virtual kanban
board & syncing
physical card wall
with it! That’s
one way to do
scrumban!
Scrum
vs.
Scrumban Scrumban Level 1
- Scrum but no commitment to the content
- Teams get most value out of daily standups,
retrospectives, grooming and to a lesser degree
Planning mechanism
• This is another area where contrasting scrumban with scrum and kanban makes a lot of sense, based on Corey Ladas's
blog about scrumban. In scrumban (& kanban), planning is done to fill the available (not all) slots: just in time & slack.
Timeboxing
• Scrumban does not distinguish between sprints/releases. It’s better to call it "timebox".
– That way folks will know that in scrumban, burndown is less important than Lead Time and Cycle Time. Here are quotes from the
scrumban creator Corey Ladas whose blog exemplifies this. Read on these 3 excerpts:
Burndown is
less important than
Lead Time and Cycle Time
"With the pull system in place, our flow will become smoother as our process capability
improves. We can use our inter-process buffers and flow diagrams to show us our process
weaknesses and opportunities for kaizen. As we get closer to level production, we will start to
become less concerned with burndown and more concerned with cycle time, as one is the
effect and the other is the cause. Average lead time and cycle time will become the primary
focus of performance. If cycle time is under control and the team capacity is balanced against
demand, then lead time will also be under control. If cycle time is under control, then
burndowns are predictable and uninteresting. If burndowns are uninteresting, then goal-setting
and risky heroic efforts are unnecessary. If burndowns are uninteresting, then iteration backlogs
are just inventory for the purpose of planning regularity and feeding the pull system. As such,
they should be the smallest inventories possible that optimize planning cost."
Sprint backlog-
Smallest Inventory
to Optimize Planning Cost
"A simple mechanism that fits the bill is a size limit for the iteration backlog. Rather than go
through the trouble of estimating a scope of work for every iteration, just make the backlog a
fixed size that will occasionally run to zero before the planning interval ends. That’s a simple
calculation. It’s just the average number of things released per iteration, which in turn is just a
multiple of average cycle time. So if you have 5 things in process, on average, and it takes 5 days
to complete something, on average, then you’ll finish 1 thing per day, on average. If your
iteration interval is two work weeks, or 10 work days, then the iteration backlog should be 10.
You can add one or two for padding if you worry about running out. This might be a point that’s
been lost on the Scrum community: it’s never necessary to estimate the particular sizes of
things in the backlog. It’s only necessary to estimate the average size of things in the backlog.
Most of the effort spent estimating in Scrum is waste."
Why estimate
the average size of
things in the backlog?
"In our final incarnation of Scrumban, iteration planning still happens at a regular
interval, synchronized with review and retrospective, but the goal of planning is to fill
the slots available, not fill all of the slots, and certainly not determine the number of
slots. This greatly reduces the overhead and ceremony of iteration planning. Time
spent batch processing for iteration planning estimation can be replaced with a
quality control inspection at the time that work is promoted to the ready queue. If a
work item is ill-formed, then it gets bounced and repeat offenders get a root cause
analysis."
Process Framework Evaluator – Source: Steve Sanoff
An Example Questionnaire
Questions Explanation
Planning: Scrum: Scrum works best when requirements are stable for the duration of the Sprint so that the team can commit to their
delivery.
Despite the PO trying to do so, is it impossible to lock down the scope for your chosen timebox?
Do you have more than 25% scope churn during the chosen timebox? Kanban: Some scope change can be accommodated. By dropping the fixed timebox, Kanban can allow teams to adapt more easily
to quickly changing priorities.
Scrumban: Iteration planning is done at a regular interval, with the goal of planning is to fill the slots available - not fill all of the
slots, and certainly not to determine the number of slots.
Decomposition: Both Scrum and Kanban work best when you break your work down into small incremental pieces. The Scrum Sprint timebox can
help new teams recognize deficiencies (work not completed at the end of the sprint) and adapt (retrospective).
Even after trying your best, is it impossible to break features into incremental pieces of value to
be delivered within the chosen timebox? Scrumban: Can you decompose work to lock scope for the timboxed duration?
Estimation: Kanban: Kanban removes the overhead of estimation in favor of measuring cycle time for like sized items. Work should be
comprised of similarly sized activities for Kanban.
Is it hard or impossible for the team to size the work in the chosen timebox?
Does estimation take more than 3 hours? Scrum: Scrum absolutely requires that all work be estimated so that the team can commit to the sprint.
Responsiveness: Kanban has a strong focus on cycle time, where Scrum has a stronger focus on Velocity.
Both can be tuned to provide very similar output, but Kanban has the flexibility to lower batch size to reduce cycle time at the
Is your top priority to optimize responsiveness to customer needs? potential cost of productivity.
Must work begin in the current timebox (cannot wait until the next one)?
Predictability & Productivity: You can achieve predictability and a high level of productivity using any agile framework.
Scrum provides more guidance on how to handle release planning and progress tracking so is preferable for new teams.
Is your top priority predictability and productivity for larger projects?
Process Oriented Culture: Although Scrum has fewer ceremonies and artifacts than many other methodologies, it has more than Kanban and can more
easily be integrated into a culture requiring them.
Does your team culture demand a higher degree of process ceremonies?
Shared Team Members: Scrum: Scrum teams work best when they do not have dependencies on people outside of the team
.
Do you share engineers with other teams? Does your team lack all the required skills to complete Kanban: With Kanban, others can see when there is work for them to do and pick it up at that time.
the work?
Variety in work (complexity & size): Both Scrum and Kanban work very well with similar sized work items.
However, in Kanban the variability between different sized items makes it difficult to adhere to SLAs.
Are your work items of approximately similar size & complexity?
Primary Feedback Loops in Kanban
• Ops Review
– Third level of feedback - operations review – is where organizational process improvements occur beyond a
localized team level, to realize full benefits of Kanban.
Source: PayPal
Kanban Metrics
* Lead Time Distribution indicates Predictability
* Average Lead Time impacts SLA Adherence
* High Productivity means better “Flow Efficiency”
* Monte-Carlo forecasting for planning fixed bid projects
160
140
120
100 Throughput
(# of resolved tickets / week)
80
Average Lead Time / week
60
Frequencies
input queue for “planning” work intake.
6
– Team can try to reduce the average lead time
by doing scrum-style decomposition. 4
– Example stats:
2
Lead Time Stats
33.80435 (Average) 0
26.5 (Median)
0 10 20 30 40 50 60
0 (Mode)
Lead Times
• Analyzing Lead Time Distribution Curve
– Have you ever wondered how we measure lead time
in Kanban and how we make use of them?
– Alexei Zheglov has posted a couple of insightful articles
on how to analyze, measure and understand lead time.
Click to read more -
• Analyzing the Lead Time Distribution Chart
• Inside a Lead Time Distribution
• Introducing Lead Time Forecasting Cards
• Scrum Commitments, Little’s Law, and Variability
• Lead Time and Iterative Software Development
10/3/2013
-50 0 50 100 150 200 250 300 350
SLA Adherence
– According to Russell Healy, creator of getkanban board game: +ve and -ve values should not be treated equally. The cost of
delay for a fixed delivery date item is a "Heaviside step function" (http://en.wikipedia.org/wiki/Heaviside_step_function)
modified for the opportunity cost incurred for -ve values of x. Go figure!
High Productivity means better “Flow Efficiency”
Flow Efficiency metric
• What percentage of lead time does a work item actually take end-to-end, on an average?
By comparing lead time against the touch time (aka assigned time), we get “waste indicator”.
• waste can be due to high WIP
• waste can be due to wait/blocked times
40
• How to compute Flow Efficiency? Flow Efficiency (Ratio) higher % is better! It
means there is not much
35
• It should be possible to create waste!
histogram based this formula: 30
Flow Efficiency =
Flow Efficiency %
“touch time” 25 Flow Efficiency
/ “lead time”
20
• Although very difficult to measure 15
flow efficiency for knowledge work,
histograms are useful 10
How do you use this metric to inspire teams to be even more productive?
In order to improve flow efficiency , teams should try to reduce the WIP, so that less cards will have delays due to wait times and/or blocked times.
Source: Dimitar Bakardzhiev
120.00%
100.00%
80.00%
Probability
60.00%
40.00%
20.00%
0.00%
200
Control Chart for Lead Time Variability
Lead Time
Smoother control band is better!
150
100
Lead Times
50
0
10/3/2013 11/22/2013 1/11/2014 3/2/2014 4/21/2014 6/10/2014 7/30/2014
-50
Acceptance Dates
• Time In Process
– This metric is specific to Rally Insights tool, and sounds very complementary to lead time, cycle time, and time to market.
– Time in Process is the number of business days a typical user story is in the "In-progress" or "Completed" column. (i.e. not accepted yet).
– Why is this Important? According to renouned metrics guru Larry Maccherone, Accurate planning & budgeting need accurate estimates.
– Time in Process charting in Rally shows how long the median of Stories are in process.
Kanban Depth Framework-
A Model for Kanban Team Assessment
Practitioners in smaller organizations have tended to adopt
a relative assessment model
Improvements Visualize
Outer edge
defines
specific local
goals
Limit WIP
Feedback Loops
Activity Not present
at
Where we would Proto-Kanban level
like to be
Explicit Policies Manage Flow
Source: Christophe Achouiantz – @ChrisAch
Assessing the Depth of
a Kanban Implementation
• Improve continuously in a • See & Understand
sustainable way
Effects (12) (WIP, Blocks, Queues)
Improve (10) Visualize (13)
10
7 12
• Generate actionable 10 • Improve Predictability
6
feedback (information) • Reduced Task Switching
from stakeholders to Lean 4 7 • Reduced Lead times
improve N4 esssa
Necessary
Necess saary
ryy fo
for
or
o • Reduced Overburdening
2 ssustainable
u
ussstaainaabble
b (quality, sustainability)
improvements
Feedback 6 3 2
Limit WIP (4)
1 2 3
Loops
2
(7) 5
IImproving
m g Sustainably • Increase Liquidity
8 6 • Measure Flow / capability
Excellence (WIP, throughput, Queues,
10
• Set Standards to improve upon lead time)
10 • Defer Commitment
Explicit Policies (12) Manage Flow (11)
Visualize Limit Work in Progress Manage Flow Source: Christophe Achouiantz – @ChrisAch
1. Work (all, according to current policies) 1. No WIP limit, but commitment to finishing work over 1. Daily planning meetings (as “daily” as agreed by policies)
2. Work Types starting new (eventually reaching a WIP level that “feels 2. Blocks out of team control are escalated for resolution
3. Workflow (“process”, way-of-working, value stream) OK” for the team) 3. Next is re-prioritized continuously (no commitment in Next)-
4. ‘Next’ & ‘Done’ 2. Some explicit WIP limits, at lower level than workflow Deferred Pull decisions (dynamic prioritization)
5. Current Team Focus (avatars) (a.k.a Proto-Kanban): personal Kanban, WIP limit per 4. CFDs (updated at least once a week)
6. Blocks person, WIP limits for some columns or swim-lanes, 5. Control Charts (updated at least once a week)
7. Current Policies (DoD, DoR, capacity allocations, etc.) workflow with infinite limits on “done” queues, etc. 6. Size of ongoing work items is limited (large work is broken
8. Ready for Pull (“done” within the workflow/in columns) 3. Explicit WIP limit at workflow level - Single workflow full down)
9. Metrics (lead-times, local cycle times, SLA targets, etc.) pull 7. Flexible staff allocation (swarming)
10. WIP limits 4. Multiple interdependent workflows with pull system 8. Cadence is established (planning, delivering, retrospective)
Make
11. Policiesdependencies
Inter-work Explicit - All(hierarchical, parent-child,
Policies must be CURRENT etc.)
(known & actually used) Implement Feedback Loops Improve
9. Flow metrics (number of days blocked, lead-time efficiency)
12. Inter-workflow
1. dependencies
Definition of Work Types and Work Item (template) 1. Daily Team standups 10. SLA
1. The expectations
group knowsand whyforecasts (lead-time
it exists and targets)
its criteria for success
13. Risk
2. Howdimensions
to pull work(cost-of-delay,
(selection from technical risk, market risk)
‘Next’/prioritization of WIP) 2. Key stakeholders (mngt, customers, other groups) are 11. Capacity
2. Allocations
Regular Retrospectives / Kaizen events
3. Who and when manages the ‘Next’ and ‘Done’ queues regularly updated on the current situation 3. The team knows its current condition (may require metrics)
4. Staff allocation / work assignment (individual focus) 3. Managers go and see (walk the ‘gemba’) regularly 4. True North exists, is communicated and shared by the team
5. Definition of Ready for ‘Next’ 4. Regular discussions with upstream and downstream 5. The team knows the current target condition (the challenge)
6. Who, when and how to estimate work size partners 6. There is a validation criteria (test) for the current target condition to
7. Limit size of work items (work breakdown) 5. Regular presentations and discussions about Financial know when the target condition is reached
8. How to select & prepare work for the ‘Next’ queue performance 7. The team knows what obstacles are preventing them from reaching
9. Definition of Done at all steps (seen as a Target Condition) 6. Regular presentations and discussions about Quality KPI the target condition
10. Knowledge spreading/sharing strategy (defect rate, customer satisfaction, etc.) 8. The team knows what obstacle is being currently addressed
11. Class-of-Service 7. “Regularly” means once per month or more often 9. The team knows what is the next step in resolving the current obstacle
Effects (seeing
12. Capacity Evidence of…)
allocation (PDCA)
1. Team members are seeing and understanding the Big Picture 10. The team go and see what they have learned from taking that step
(team-level vs. local situations) Improve (10) Effects (12)
2. Better “team spirit” (helping each-others to complete work, Visualize
respect)
3. Focus on removing blocks
4. Focusing on finishing work rather than starting new work
5. Team is working on the “right” thing (“right” prioritization) Lean
6
4
10
7
4 7
10
12
(13)
00
Current
6. Limiting work to team’s capacity (limited stress, optimal lead- 2
times) Necessary ”Score”
Feedback 6 3 2
Limit WIP
7. Team has motivation to drive improvements 1 2 3
8. Local process evolution (visualization, workflow, policies, WIP Loops 2 (4)
limits) 5 Baseline
9. Increase depth of Kanban implementation (7) 8 Excellence
Ex ll 6 Team:
10. Process evolution was model-driven 10 Trend
11. Process or management policy evolution as a result of mentor- 10 ________
mentee Explicit Policies (12) Manage Flow (11) Date:
12. Inter-workflow or management policy evolution due to
operations review
__/__/__
References & External Links
There is more continuous improvement happening in Lean Kanban community with contributors like Arne Roock (known for “Stop Starting Start Finishing!”),
Russell Healy (getkanban.com game creator), Christophe Achouizntz (known for Kanban team assessment survey) or Hakan Forss (creator of flow efficiency
metric as the primary Kanban metric).
References
• Pre-requisite #1: “STOP Starting, START finishing” by Arne Roock
• Pre-requisite #2: Anderson, David (April 2010). Kanban - Successful Evolutionary Change for your Technology Business. Blue Hole Press.
• Pre-requisite #3: Anderson, David (April 2012). Lessons in Agile Management- On the road to Kanban. Blue Hole Press.
• Pre-requisite #4: Scrumban - Essays on Kanban Systems for Lean Software Development by Corey Ladas
• External links
– David Anderson’s blog posts & Henrik Kniberg’s blog posts
– InfoQ eBooks by Henrik Kniberg & others [e.g. Jasper Boeg (2012-02). "Priming Kanban" (in English). InfoQ]
– The difference between Cycle Time and Lead Time... and why not to use Cycle Time in Kanban
– Scrumban - Essays on Kanban Systems for Lean Software Development by Corey Ladas
– What is Kanban? by Joseph Hurtado
– Aspects of Kanban by Karl Scotland
– De-mystifying Kanban by Al Shalloway of Net Objectives
– Kanban Applied to Software Development: from Agile to Lean
– What is Best, Scrum or Kanban?
– Kanban for Teams by Al Shalloway
– Open Kanban Presentation
– Open Kanban Documentation
– LKNA conferences & related links
• https://plus.google.com/113439681622341364754/videos
• http://leankanban.com/case-studies
• http://blackswanfarming.com/cost-of-delay/