Kanban In Software Development

Ingvald Skaug

img: http://availagility.co.uk/2008/10/28/kanban-flow-and-cadence/

What Is Kanban?Lightweight framework for evolutionary change, step-by-step improvement

Encourages continuous flow

Not a process

Intro

What Is KanbanWhy FlowWhy Kanban

Some background: David Anderson: The Principles of the Kanban Method

ill.: Henrik Kniberg, Kanban and Scrum - making the most of both (with Mattias Skarin)http://www.infoq.com/minibooks/kanban-scrum-minibook

What Is Kanban?

Kanban: Most adaptive tool

(Number = artifacts)

Why Flow?Inestimable workUnplanned workUnclear workBlocked work

- need input from unavailable stakeholderParking

- unfinished work, - waiting b/c of interruptions, multi-tasking

Changed work/ requirementsLegacy codeNormative estimates

=> tech debtSpecialists

=> uncertain access

Intro

What Is KanbanWhy FlowWhy Kanban

Jørn Ola Birkeland, Bekk, at XP2010, Experience report: From a timebox tangle to a more flexible flowhttp://xp2010.org/program?sid=11&o=1

Why Kanban?You can:Start where you areManage change, improve step by step

Expose problems on quality and processEnable higher qualityMore predictable delivery, due date performance

Sustainable developmentBalance demand against capacityIncrease trust with customersImprove productivityMore agile organization...

Seems like a tall order...

Intro

What Is KanbanWhy FlowWhy Kanban

Everything Is Connected

Why Kanban

Start: Visualize + WIP Limit

Why KanbanEverything Is Connected

Simple Kanban

1. Visualize!

2. Limit WIP!

"Kanban 101" / How-to

WIP = work in progressSimple = not easy

img: http://blog.crisp.se/henrikkniberg/2009/09/15/1253019240000.htmlSome background: http://agilemanagement.net/index.php/Blog/back_to_basics_with_kanban/

Visualize!

Use a Kanban boardReflect real workflowDashboard visible for everyoneTransparent policies

WIP limitsSpecific column names- don't use "Done"...

Kanban 101

VisualizeLimit WIP

Why Visualize?

=> Shared mental model

=> More engaged stakeholders

=> More effective thinking, collaboration

Ex.: Kanban board, permanently visible to dev.team, management, sales...

Agile Basics

VisualizeLimit WIP

http://skaug.no/ingvald/2010/12/agile-basics-visualize-more.htmlimg from Tom Wujec's TED talk

Limit WIP!

Start with generous limits

Better with big limits than no limits- no limits, no improvement- big limits: minimize resistance

Keep WIP limits visible on Kanban board

Kanban 101

VisualizeLimit WIP

WIP = work in progress

Why Limit WIP?

Work in progress expires- e.g., requirements change over time

Agile Basics

VisualizeLimit WIP

WIP = work in progress

ill.: Aslak Hellesøy, Smidig 2009: Kanban for nybegynnerehttp://tcs.java.no/tcs/?id=20B8314B-4EE8-4C87-A418-2AA08F4AB3E6

Why Limit WIP?

Reduce multi-tasking

Agile Basics

VisualizeLimit WIP

Some background, ill.: Karl Scotland: Kanban, Flow and Cadencehttp://availagility.co.uk/2008/10/28/kanban-flow-and-cadence/

Why Limit WIP?

Expose quality and process problems- like bottlenecks

Agile Basics

VisualizeLimit WIP

WIP = work in progress

http://ingvald.posterous.com/kanban-reduce-wip-limits-to-discover-bottlene

Q?

Simple Kanban

1. Visualize!2. Limit WIP!

Keep It SimpleBe PragmaticFlow

Kanban vs ScrumKanban Scrum

Batching of work, feedback-loop

Works with anythingNatural fit: continuous flow

Iteration (+/- 30d),sprint backlog to demo

Tolerance for variations, distractions

Yes (with flow) - swimlanes, classes of service

No, process needs hacking (e.g., extra buffer)

Control mechanism WIP limit Commitment - stand-up (personal)- sprint: dates, features (team)

Initial change Small - low threshold Revolution - prescribed process

Eventual changes in process

Evolution - step by step improvements in "process under Kanban"

No, Scrum is a fixed process regarding its artifacts

What can improve If you keep visualizing, limiting WIP: pretty much everything

XP practices etc

Estimating/ Predictability

Works with anything.Best: use lead time after the fact as predictor, not detailed estimates

Estimating needed for burn-down

Specialists No problem Should be cross-functional teams

Some background: http://agilemanagement.net/index.php/Blog/thoughts_on_how_kanban_differs_from_scrum/http://availagility.co.uk/2009/06/15/how-is-kanban-different-from-other-approaches/http://availagility.co.uk/2010/07/27/a-pattern-for-using-scrum-and-kanban/http://blog.crisp.se/henrikkniberg/2009/12/21/1261410240000.html (Kanban and Scrum - making the most of both)

Forward

David J Anderson: 5 core properties of a Kanban implementation1. Visualize Workflow2. Limit work-in-progress3. Measure & Manage Flow4. Make Process Policies Explicit5. Use Models to Recognize Improvement

Opportunities

"Kanban 201"

Background: David Anderson: Five Core Properties of a Kanban Implementation

Forward

QualityTech DebtFlowClasses of ServiceSlackCadence - separate development, deliveryMetrics

"Kanban 201"

a small selection

Some more: Aspects of Kanban, by Karl Scotland, including cadence, slackDennis Stevens on SLAs in Kanban, including cost of delayClasses of Service and Policies, by David JoyceKanban and Systems Thinking, by Karl Scotland

Become More Agile

More or less

Not either/ or

img: http://www.flickr.com/photos/42429527@N03/5063150948/

ill.: Jørn Ola Birkeland, XP2010: From a timebox tangle to a more flexible flowhttp://xp2010.org/program?sid=11&o=1

Tech Debt vs Quality

LegacyMaintenanceUnpredictability

Improve Quality Kanban 201

ill.: Jørn Ola Birkeland, XP2010: From a timebox tangle to a more flexible flowhttp://xp2010.org/program?sid=11&o=1

Enable and Use Swarming, Slack

1. Can you help progress an existing kanban? Work on that.

2. Don’t have the right skills? Find bottleneck and work to release it. (SWARMING)

3. Don’t have the right skills? Do work which - won’t create any work downstream, - will improve future throughput and - can be paused as soon as existing kanban related work is available. (SLACK)

Kanban 201

http://ingvald.posterous.com/kanban-slack-creates-opportunities-for-improv

Metrics Cumulative Flow Diagram

Sources of Error

Some work off the board

Work items vary too much in size

ill.: Henrik Kniberg & Mattias Skarin: Kanban and Scrum - making the most of bothhttp://blog.crisp.se/henrikkniberg/2009/12/21/1261410240000.html

Resources

David Anderson: Kanbanhttp://agilemanagement.net

Henrik Kniberghttp://blog.crisp.se/henrikkniberg/Especially One day in Kanban land

Links in slides, particularly:Karl Scotland (articles)Jørn Ola Birkeland (video)

http://skaug.no/ingvald/kanban/http://twitter.com/ingvald