scrum sucks! kanban rules!

Scrum sucks! Kanban Scrum sucks! Kanban Rules!Rules!Mark GibaudMark Gibaud

#londonagile#londonagile

Kanban basic conceptsKanban basic concepts

““Kanban” = Visual CardKanban” = Visual Card

Developed by Taiichi Ohno in the TPSDeveloped by Taiichi Ohno in the TPS

Kanban in the real worldKanban in the real world

StarbucksStarbucks

Why care about Why care about kanban?kanban?

Improved quality of featuresImproved quality of features

Faster turnaround of featuresFaster turnaround of features

Reduces waste (context switching, delays, etc)Reduces waste (context switching, delays, etc)

2 Basic Rules2 Basic Rules

Visualize your workVisualize your work

Limit your work-in-progress - encourages flowLimit your work-in-progress - encourages flow

Little’s LawLittle’s Law

Little’s Law (queuing theory):Little’s Law (queuing theory):

L = λW.L = λW.

Length of a queue = arrival rate * average wait Length of a queue = arrival rate * average wait timetime

OR Wait time = length of queue / arrival rateOR Wait time = length of queue / arrival rate

OR Cycle time = WIP / ThroughputOR Cycle time = WIP / Throughput

Capacity utilizationCapacity utilization

Example Kanban BoardExample Kanban Board

[REDACTED]

Engineering practicesEngineering practices

Branch-by-featureBranch-by-feature

Subversion vs DVCSSubversion vs DVCS

Continuous Deployment / DevOps / Frequent Continuous Deployment / DevOps / Frequent ReleasesReleases

One-click deployOne-click deploy

Scrum metricsScrum metrics

Points - nobody outside dev understandsPoints - nobody outside dev understands

Velocity - unwieldy and subject to ambiguous Velocity - unwieldy and subject to ambiguous fluctuationfluctuation

Project-level estimation mechanism?Project-level estimation mechanism?

Kanban metricsKanban metrics

Cycle timeCycle time

Duration an item of work gets through the Duration an item of work gets through the systemsystem

ThroughputThroughput

How many items get done in x weeksHow many items get done in x weeks

Scenario 1: ScrumScenario 1: Scrum

Developer raises that feature will not be done Developer raises that feature will not be done by Friday, but by Mondayby Friday, but by Monday

Pressure to get it done => loss of qualityPressure to get it done => loss of quality

Pressure to delay release => difficult Pressure to delay release => difficult conversationsconversations

Pressure not to disappoint customersPressure not to disappoint customers

Scenario 1: KanbanScenario 1: Kanban

Developer raises that feature will not be done Developer raises that feature will not be done by Friday, but by Monday by Friday, but by Monday

Fine, I’ll let customers know it’ll be Fine, I’ll let customers know it’ll be released Monday and not Fridayreleased Monday and not Friday

No quality loss, developer pressure, No quality loss, developer pressure, customer hatecustomer hate

Scenario 2: ScrumScenario 2: Scrum

‘‘Critical’ bug reported after a releaseCritical’ bug reported after a release

Argument: Is it REALLY critical?Argument: Is it REALLY critical?

Patching: ceremony!!Patching: ceremony!!

Reputational loss with patchingReputational loss with patching

Interrupts ‘normal’ workflowInterrupts ‘normal’ workflow

If normal bug, gets prioritized against all other If normal bug, gets prioritized against all other backlog items, loses, stays in the product.backlog items, loses, stays in the product.

Scenario 2: KanbanScenario 2: Kanban

‘‘Critical’ bug reported after a releaseCritical’ bug reported after a release

Fix it. Ship it. Usually in less than a day.Fix it. Ship it. Usually in less than a day.

Who cares how critical it is?Who cares how critical it is?

Who cares what opportunity cost there is?Who cares what opportunity cost there is?

Doesn’t interrupt ‘normal’ workflowDoesn’t interrupt ‘normal’ workflow

Customers impressed by response time?Customers impressed by response time?

Advantages of KanbanAdvantages of Kanban

Simple, understandable metricsSimple, understandable metrics

ScalesScales

Non-intrusive, evolutionaryNon-intrusive, evolutionary

Focus on quality, not deadlinesFocus on quality, not deadlines

Metrics that a PMO (and customer) Metrics that a PMO (and customer) understandsunderstands

Includes all functionsIncludes all functions

Kanban scalesKanban scales

Kanban PMOKanban PMO

[REDACTED]

DisadvantagesDisadvantages

Counter-intuitive practices/foundations? eg. Counter-intuitive practices/foundations? eg. Little’s LawLittle’s Law

Fully enabled only by advanced engineering Fully enabled only by advanced engineering practicespractices

Doesn’t encourage collaboration as well as Doesn’t encourage collaboration as well as ScrumScrum

Rely on maturity of team for collaborationRely on maturity of team for collaboration

More informationMore information

@markgibaud@markgibaud

Google!Google!

VersionOne WhitepaperVersionOne Whitepaper

NetObjectives WhitepaperNetObjectives Whitepaper

““Demystifying Kanban”Demystifying Kanban”

Consider thisConsider this

A lot of the people using Kanban today, were A lot of the people using Kanban today, were the people using Scrum 5/10 years agothe people using Scrum 5/10 years ago

Dan North: “Scrum is training wheels”Dan North: “Scrum is training wheels”

Songkick, 7DigitalSongkick, 7Digital

Questions?Questions?