From Scrum to ScrumBan or Kanban- Process Evaluator Workshop using Excel.pptx

From Scrum to Scrumban/Kanban:
Process Evaluator Workshop using Excel
Ravi Tadwalkar
Lean/Agile/DevOps Coach
Co-founder, “Cisco Internal Coaches Network” (2011-13)
Event Co-organizer, KIN20xx conferences (2017-current)
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.

Context for the workshop:
Process Evaluator Workshop using Excel
• Assume that we are a team struggling to do iterative development with Scrum, but the
needle is not really moving, customers are not happy, and everything is just like before
Scrum, or even worse at times.
• How do we come out of this status quo situation and move the needle?
• Let's talk about what can work for our team.
• We will go thru' series of questions in a spreadsheet format to understand how to
evaluate what process framework can work for our team.
• Create 2-3 teams among the audience to compare and contrast process outcome,
perhaps group by company/industry, and I will fire up Excel spreadsheet to go thru’ each “team”.
– We will use common sense (not culture models) when forming and storming during this workshop 

Process Framework Evaluator –
An Example Questionnaire
Questions Explanation
Planning:
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?
Scrum: Scrum works best when requirements are stable for the duration of the Sprint so that the team can commit to their
delivery.
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:
Even after trying your best, is it impossible to break features into incremental pieces of value to
be delivered within the chosen timebox?
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).
Scrumban: Can you decompose work to lock scope for the timboxed duration?
Estimation:
Is it hard or impossible for the team to size the work in the chosen timebox?
Does estimation take more than 3 hours?
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.
Scrum: Scrum absolutely requires that all work be estimated so that the team can commit to the sprint.
Scrumban: Scrumban does not require estimation.
Responsiveness:
Is your top priority to optimize responsiveness to customer needs?
Must work begin in the current timebox (cannot wait until the next one)?
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
potential cost of productivity.
Predictability & Productivity:
Is your top priority predictability and productivity for larger projects?
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.
Process Oriented Culture:
Does your team culture demand a higher degree of process ceremonies?
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.
Shared Team Members:
Do you share engineers with other teams? Does your team lack all the required skills to complete
the work?
Scrum: Scrum teams work best when they do not have dependencies on people outside of the team
.
Kanban: With Kanban, others can see when there is work for them to do and pick it up at that time.
Variety in work (complexity & size):
Are your work items of approximately similar size & complexity?
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.

Compare & Contrast Scrum, Scrumban & Kanban:
Do Planning to fill available (not all) slots
Card Template
• Scrumban/Kanban process is about moving cards as fast as you can across the value stream to have shortest lead time.
This requires slightly different way to look at requirements than following Scrum-style user story templates.
– While it does help when you use a user story template with tasks associated for teams that prefer that kind of card on their board,
it can very well be at a granular task level if all other cards on the board are of similar sizes, more like activities rather than stories.
Unlike Scrum framework, in Kanban (and Scrumban), there is no need to take a particular stance on this.
– Stories hover around typical size for Kanban/Scrumban teams (e.g., 3,5,8 if average size is a 5-point story).
• Kanban manifesto could very well begin with this one liner: We prefer having typical sizes over following user story template!
• Kanban does not put emphasis on estimation of work, as long as all work items have similar levels of effort, complexity & risk.
– Decomposition- using patterns for splitting (i.e., slicing) work- remains same; Scrumban adds timeboxing on top of Kanban board.
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 team 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. Please refer to slides in appendix for 3 excerpts from his blog post.

From Scrum to Scrumban/Kanban: Practitioner’s Way to improve Flow Efficiency
A team improves its average lead time and flow efficiency by applying explicit policies, WIP limits for queues/swim-lanes, at regular cadence!
Mature Kanban teams calculate lead time when accepting cards flowing on the physical/virtual card wall, with Scrumban-style regular cadence.
After participating in release planning, such Kanban teams commit to iterative development/support on a cadence to finish work in 1-2 weeks.
Sautéing with Jira
Kanban board -
perhaps using a
physical card wall
with it! That’s one
way to acclimatize
with transition to
Scrumban/Kanban!
Scrumban Level 1
- Scrum but no commitment to the content
- Team gets most value out of daily standups,
retrospectives, grooming and to a lesser degree
planning (at least some planned work is done)
- Aim to empty the queue in each timebox
- Don't split stories
Scrumban Level 2
- Essentially Kanban but timeboxed
- It forces stories to be broken down so work is
completed (versus open ended Epics)
- Aim to empty the queue in each timebox
- Don't split stories

It all began with what the west calls “Lean”

And who started the “Lean” moment?

Kanban for knowledge work
• David J Anderson created “K”anban, now known as Kanban Method. Kanban
for knowledge work is a management method of just-in-time delivery based on
capacity to do work. As such, here the focus is not to overload the team
members.
• 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.
• Kanban for software development means a visual process management system
that tells what to produce, when to produce it, and how much to produce-
inspired by the Toyota Production System and Lean Manufacturing.
Source: : David J Anderson (2010)

Done
F
E
I
Engineering
Ready
Deployment
Ready
G
D
GY
PB
MN
2 ∞
P1
AB
Ongoing
Development Testing
Done Verification Acceptance
3 3
DE
Proto-Kanban
You may have used or seen a Kanban board for running events like conference or even hackathon.
Whenever a team starts visualizing work with a Kanban board, that team is doing proto-Kanban!
Explicit policies &
WIP Limits based on
queues (aka lanes or
columns)
Lead time ends at
1st infinite queue!
There could be
additional queues
with no WIP limit.
Lead time
“clock” starts
at the 1st
queue aka
input queue!

Done
F
E
I
Engineering
Ready
Deployment
Ready
G
D
GY
PB
MN
2 ∞
P1
AB
Ongoing
Development Testing
Done Verification Acceptance
3 3
Expedite
1
3
Fixed
Date
Standard
Intangible
2
2 DE
Lead time ends at
1st infinite queue!
Lead time “clock”
starts at input queue!
NPD
i.e.
New
Prod
Dev
(60%)
Defect&
Tech
Debt
(30%)
Innov
ation
(10%)
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 &
WIP Limits
based on classes of
service & work type!
5
2
1
In my Kanban coaching experience, Kanban "flow
& pull" aspect orientation forces you to "stop
starting, start finishing", better than scrum
"inspect & adapt" orientation. Kanban being
workflow management tool, requires solid
engineering practices for teams to succeed in
lean software development. However, it's non-
prescriptiveness can let newbies fall back on
practices & controls that worked in waterfall
world. For those, I have always found Scrumban
to be a practical middle-ground since it brings
best from both scrum and Kanban.

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."

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/

From Scrum to ScrumBan or Kanban- Process Evaluator Workshop using Excel.pptx

More Related Content

Similar to From Scrum to ScrumBan or Kanban- Process Evaluator Workshop using Excel.pptx (20)

More from Ravi Tadwalkar (20)

Recently uploaded (20)

From Scrum to ScrumBan or Kanban- Process Evaluator Workshop using Excel.pptx

Editor's Notes