This document introduces Scrumban, which is a combination of Scrum and Kanban principles for software development. It describes some of the weaknesses of Scrum for large enterprises, and how Kanban addresses those weaknesses by focusing on continuous flow, limiting work-in-progress, and making processes more flexible. Scrumban blends elements of Scrum like cross-functional teams with Lean/Kanban elements like cadences instead of sprints and visualizing work to improve flow. The document argues that Scrumban can help organizations focus on continuous delivery while maintaining quality.

1. “SCRUMBAN” –
A LEAN-AGILE FUSION
Michael O’Rourke
Product Manager. Agile & Lean Enthusiast.
LinkedIn

2. WHAT’S THE INTENT HERE?
 Expose complaints about your products to determine
where improvements must be made
 Review your current product development processes
 Justify the necessity of injecting new “Lean” philosophies
into your work
 Compare the finer points of Scrum & Kanban
 Define what Scrumban is
 Show opportunities where improvements can be made to
better quality, performance & meet user/buyer
expectations
2

3. WHAT ARE YOUR OPEN WOUNDS?
 Is your software quality poor?
 Are your releases continuously late?
 Has the amount of hotfixes (or patches) increased?
 Are you an enterprise disguised as a small business?
 Are you a flat organization catering to an imperial
organization?
 Do you serve many masters in different groups – groups
rarely agreeing or communicating with one another?
 The problem is not you personally
 The problem is not agile, either
3

4. PROCESSES YOU USE TODAY ARE NOT
SCALABLE & ADAPTABLE TO DEAL WITH
YOUR BUSINESS DYNAMICS

5. WHAT’S DISRUPTING YOUR DEVELOPMENT PROCESS?
 Don’t have what’s needed to start work, but
forced to commit to it anyways
 New stories constantly injected (force-
added) after committing to a Sprint
 Constant task-switching that reduces
productivity
 Unclear “Definition of Done” for many
backlog items
 Team roles & responsibilities overlap –
causing extra work for everyone
 Too many stakeholders with all the power
& none with their skin in the game
 Impossible to schedule recurring demos
with all the stakeholders’ meeting conflicts
 Indecisions about priorities encourage Dev
Teams to find work on their own
5

6. DEVELOPMENT PROCESSES YOU USE TODAY
 Today, you use Scrum – a framework that derives from
the Agile software development methodology
- Scrum is more than just a process – it’s a value system
- It’s core component is the double-feedback loop – without it
you’re not Agile
kind of
 Scrum works for you
- Early, constructive feedback to make early adjustments
- Frequent knowledge sharing & internal communication
improves our performance
- Teams inspect each iteration thoroughly & adapt quickly
- Continuous involvement of QA
- Able to mitigate risks & resolve issues easily & quickly
- Nearly instant patch releases for critical issues
- Heavy, up-front requirements were rarely necessary
6

7. WEAKNESSES OF SCRUM IN AN ENTERPRISE
 Limited visibility of where the Team is in their
development cycle
 Nearly impossible to scale-up with enterprises going
through organizational changes
 Being in constant crunch modes encourages cutting
corners – leaving you with piles of technical debt
 Scrum Master & Product Owner roles sometimes conflict
& overlap, making excessive work for both of them
 Lacks flexibility for Teams during transitions – Scrum
demands for normalized Teams before starting work
 “Pig & Chicken” lore encourages Dev Team’s to push out &
diminish Product Owners authority
 Any slack in a Sprint can be filled with unauthorized work
 You need processes that are flexible, predictable
& practical
7

8. SO, WHY NOT CHANGE HOW SCRUM WORKS?
 That should be your exact Kanban-
Lean
intentions processes
 You don’t need to scrap Scrum
 Rather, you need to layer new Scrumban
Kanban philosophies on top of
your Scrum framework
 This approach is called Scrum
SCRUMBAN Framework
8

9. WHAT’S KANBAN?
 Pronounced kahn-bahn
 Derives from Lean – a software development methodology
 Unlike Lean, Kanban is not a framework or methodology – it’s
a process model similar to Scrum
 Starts with 3 basic principles
1. Start with what we do now
2. Agree to pursue incremental, evolutionary change
3. Respect the current process, roles, responsibilities & titles
 Draws on 5 core properties
1. Visualize your Work
2. Limit WIP (Work-in-Progress) We’re not pioneers. Pro-Lean
subcultures started to emerge within
3. Make Process Policies Explicit
product development communities back in
4. Manage Flow 2008. Since then, companies like Dell,
5. Improve Collaboratively FedEx, eBay, Telerik & SAP have
welcomed Lean thinking into their
software endeavors.
9

10. WHY SCRUMBAN IS A GOOD FIT FOR YOU?
 Instills Lean principles
 Reduces time devoted of planning & estimating
 Promotes constant flow of work
 Spawns a “continuous improvement” culture
 Emphasizes on continual delivery while not
overburdening the development team
 Encourages a “Think big, act small, fail fast, learn rapidly”
philosophy
Rally claims customers get to market 50% faster and are 25% more
productive when they employ Lean and Agile hybrid methods
10

11. DIFFERENCES BETWEEN SCRUM & KANBAN
Scrum Kanban
Time-boxed Iterations Cadences (Time-boxing is optional)
Commit to chunks of work each Iteration Commitment is optional
Velocity is the default metric for planning Lead Time is the metric for planning
Cross-Functional Teams Specialists (Cross-Functional Teams are optional)
Decompose work to fit in a sprint No sizing requirements
Burndown Charts Cumulative Flow Charts
WIP limited by Sprint WIP limited by State
Estimation prescribed Estimation optional
Can’t change Sprint in process Add whenever there is capacity
Sprint backlog owned by Team Kanban board shared by Multiple Teams
Scrum board reset between Sprints Kanban board is persistent
Prioritize backlog Prioritization is optional
Requires WFT (Well-Formed Teams) before starting a
Focuses on Flow rather than Team forming & norming
project
No tactic for enforcing explicit policies Allows explicit policies
Visibility of development input & output only – work is
Visibility of development input, work & output
black-boxed
Management is kept at bay Management is inclusive
11

12. BLENDS THE BEST OF BOTH WORLDS…
Scrum Kanban Scrumban
Time-boxed Iterations Cadences (Time-boxing is optional) Cadences (Time-boxing is optional)
Commit to chunks of work each Iteration Commitment is optional Commitment is optional
Velocity is the default metric for planning Lead Time is the metric for planning Lead Time is the metric for planning
Cross-Functional Teams Specialists (CFT’s are optional) Cross-Functional Teams
Decompose work to fit in a sprint No sizing requirements No sizing requirements
Burndown Charts Cumulative Flow Charts Cumulative Flow Charts
WIP limited by Sprint WIP limited by State WIP limited by State
Estimation prescribed Estimation optional Estimation prescribed
Can’t change Sprint in process Add whenever there is capacity Add whenever there is capacity
Sprint backlog owned by Team Kanban board shared by Multiple Teams Kanban board shared by Multiple Teams
Scrum board reset between Sprints Kanban board is persistent Kanban board is persistent
Prioritize backlog Prioritization is optional Prioritization is optional
Requires WFT (Well-Formed Teams) Focuses on Flow rather than Team Focuses on Flow rather than Team
before starting a project forming & norming forming & norming
No tactic for enforcing explicit policies Allows explicit policies Allows explicit policies
Visibility of development input & output Visibility of development input, work & Visibility of development input, work &
only – work is black-boxed output output
Management is kept at bay Management is inclusive Management is inclusive
12

13. WHAT CHANGES NEED TO BE MADE?
This goes… …and gets replaced with this
 Time-boxed Iterations  Cadences (Release)
 Sprint Planning  Dynamic Planning
 Fine-grained Stories  Coarse-grained Stories
 Estimating Tasks  Estimating Stories only
 Velocity is replaced by  Cycle Time
cycle time
13
13

14. SCRUMBAN: IN LAYMAN’S TERM…
 Eliminates a constant iterative
cycle
 Also eliminates need for a Sprint
backlog
 Encourages a pull by demand
system, rather than a “push by
force” system
 Promotes constant flow of work
MUST SEE!
Click here to watch a short, informative
video about applying Kanban to Scrum –
compliments of bti360
14

15. WITH A “LEAN” APPROACH, YOU WILL
FOCUS ON CONTINUOUS FLOW &
QUALITY, RATHER THAN TIME-BOXED
ITERATIONS