Kanban VS Scrum

Kanban VS Scrum Alimenkou Mikalai 31.10.2009

Agenda
Introduction to Kanban
Kanban main principles
Example from Kanban-land
When apply/not apply Kanban?
Comparison of Scrum and Kanban

What is a Kanban? A Kanban is a physical card used in Toyota Production System (TPS) to support non-centralized "pull" production control. It has spread to the manufacturing industry all over the world as a tool of Lean Manufacturing . " Kan " means visual, and " ban " means card or board .

Kanban Practices
Map the Value Stream
Visualize the Work
Limit Work in Progress
Establish a Cadence
Enable continuous improvement

Kanban Board Source: Crisp ( http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf )

Limiting Work in Progress
Reduce multi-tasking
Prevent context switching
Performing tasks sequentially yields results sooner
Maximize throughput
Enhance teamwork
Working together to make things done
Increase cross-functionality

Pull, Don’t Push

WIP Limit Strategy
Start with some initial value
Small constant (1-3)
Number of developers
Number of testers
Measure the cycle time
Average time of one piece full cycle flow
Change limit to decrease cycle time

Idle Team Members Guide
Can you help progress and existing kanban? – Work on that.
Don’t have the right skills? – Find the bottleneck and work to release it.
Don’t have the right skills? – Pull in work from the queue.
Can’t start anything in the queue? – Check if there any lower priority to start investigating.
There is nothing lower priority? – Find other interesting work (refactoring, tool automation, innovation).

What is Cadence? “ A regular cadence, or heartbeat, establishes the capability of a team to reliably deliver working software at a dependable velocity. An organization that delivers at a regular cadence has established its process capability and can easily measure its capacity. ”

Kanban Metrics
Stories in progress ( SIP )
When story enters stories queue set entry date ( ED )
When story enters first process step set start processing date ( SPD )
When story is done set finish date ( FD )
Cycle time ( CT ) = FD – SPD
Waiting time ( WT ) = SPD – ED
Throughput ( T ) = SIP / CT

Workflow Diagram

5 Wrong Reasons to Apply Kanban
User stories diversity
User stories vary in size a lot, large stories don’t feet into an iteration
Failed iterations
Many stories are not completed in a single iteration
Failed retrospective meetings
Retrospective meetings are waste
Shared people
We have a single pool of developers for some projects
Simplicity
Kanban is so simple, no planning, no retrospectives, no estimations

5 Right Reasons to Apply Kanban
Ability to release anytime
When user story is ready you may release it
Ability to change priorities on the fly
Not started stories queue is always changeable
No need in iterations
Iterate first then flow
No need to estimate
Release when it is ready, do most important story
Perfect flow visualization
Clear view of current work in progress

When no Need in Iterations?
Support project
Bug fixing stage
All valuable stories are too large and can’t be divided
Testing can’t be finished in iteration so quality suffers
Team is self-organizing and trusted enough to work without iterations
No backlog ready for iteration planning

When no Need to Estimate?
You are new to the project
Estimations don’t change plans
Velocity is not taken into account
Team is very experienced in breaking tasks
Average cycle time is enough for the customer

Example from Kanban-land 1 2 Source: Crisp ( http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf )

Kanban for Product Owners
New
Prioritized buffer
Unlimited size
Preparing
Work in Progress
Limited to PO capacity
Cycle time
Promotion model
Ready
Prioritized buffer
1-2 Team Velocity
In Progress
Work in Progress
Limited to Team WIP limit

Kanban Best Practices
Bugs get top priority
Set so minimal WIP as possible
Stories should be ”minimal marketable features”
Create separate column with goals
Add Scrum practices (daily scrum, retrospectives, demos)
Add XP engineering practices

User Stories Mapping

Kanban Issues
Lack of goal and focus
Less predictability
Less commitment level
More discipline required

Scrum Overview

Kanban is Less Prescriptive Source: Crisp ( http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf )

Task Flow Scrum Kanban Source: Crisp ( http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf )

Project Cadence Scrum Kanban Source: Crisp ( http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf )

Scrum VS Kanban (Similarities)
Both are Lean and Agile
Both use pull scheduling
Both limit WIP
Both use transparency to drive process improvement
Both focus on delivery releasable software early and often
Both are based on self-organizing teams
Both require breaking work into pieces
Both optimize release plan based on empirical data (velocity/cycle time)

Scrum VS Kanban (Differences)

Don’t Forget That … ANY process or methodology (that is not actively destructive), applied to a skilled, disciplined, high-functioning, motivated team, will succeed, regardless of the process. Likewise, any process applied to a low-functioning team will likely fail.

Resources
http://availagility.wordpress.com/kanban - largest collection of Kanban related resources
http://www.agileproductdesign.com/blog/2009/kanban_over_simplified.html - Kanban detailed description
http ://www.lostechies.com/blogs/derickbailey/archive/2009/08/05/how-to-get-started-with-kanban-in-software-development.aspx - simple guide to start with Kanban
http://lizkeogh.com/2009/09/16/scrum-vs-kanban-fight - funny Scrum and Kanban dialog
http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf - great book from Henrik Kniberg

Any questions? Email me: [email_address] Read my blog: http://javadevelopmenttips.blogspot.com Visit my website: http://agilecoaching.com.ua

http://www.slideshare.net	37
http://www.lmodules.com	2
http://clickwatchlearn.blogspot.com	1

Kanban VS Scrum

by Mikalai Alimenkou on Dec 15, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

3 Embeds 40

Statistics

Kanban VS Scrum — Presentation Transcript