Nick Oostvogels: 5 Arguments Against Kanban

ARGUMENTS against

@NickOostvogels

KANBAN 5

Kanban is on the rise

Source : VersionOne -‐ State of Agile Survey 2011

h"p://www.flickr.com/photos/smannion/3385144016/

When introducing new ideas…

People compare it to what they know

h"p://www.flickr.com/photos/mvjantzen/4815422633/

… and start to criticize

h"p://www.flickr.com/photos/the-‐g-‐uk/3913466332/

Kanban is hard to explain briefly

h;p://www.flickr.com/photos/digitalmums/6310508350/

That’s normal

•  Kanban is a change management approach, ��not a process

•  Less prescriptive •  It’s roots go all the way back to

lean thinking

What is Kanban? In Industry

h"p://www.flickr.com/photos/scania/2869199313/

In Software Development

h"p://www.flickr.com/photos/adelcambre/2768856149/

Change Management approach that employs a WIP limited pull system

1.  Start with what you now

2.  Agree to pursue incremental,

evolutionary change

3.  Initially, respect current roles, responsibilities & job titles

Source : limitedwipsociety.org

1.  Visualize

2.  Limit Work In Progress

3.  Manage Flow

4.  Make Process Policies Explicit

5.  Improve Collaboratively

Source : limitedwipsociety.org

then adopt the core practices

For me …

Kanban is a way

to change your process into one

that focuses on end to end value

and getting stuff delivered.

And that’s hard to sell !

Available on

Leanpub.com/kanbanforskeptics

h"p://www.flickr.com/photos/40358860@N04/4250860618/

5 tough questions

1. ��we lose our ability to plan


h"p://www.flickr.com/photos/photojonny/2268845904/

No estimates?

h"p://www.flickr.com/photos/daren/241192712/

Customers want estimates

estimates are used to decide

h"p://www.flickr.com/photos/ol1/4605912815/

we manage people by estimates

h"p://www.flickr.com/photos/lambdachialpha/3795728748/

Typical Release planning

Initial specs

Translation into requirements

Estimation

Review estimations Release

Plan

Issues of software development

•  Not a repeatable process

•  Never built something alike

•  (educated) GUESSING

Kanban : measuring

h"p://www.flickr.com/photos/jaydedman/2593673396/

Different sizes ???

Use a scale

compare

Standard size

Why sizing?

h"p://www.flickr.com/photos/lawdeda/4094259672/

Planning with measurements

Reduce variation 1.  Working with averages

must be reliable 2.  Fast response

3.  Base for continuous improvement

Small releases Kanban != continuous deployment

Small releases Kanban can lead to continuous

deployment


Won’t this annoy our users?

Small releases NO, because… •  Updates will be smaller •  Risk for bugs is lower + Releasing early creates a sense of urgency

options for Re-planning 1.  Reprioritize the input queue 2.  Cadence 3.  Pull a planning meeting

2. ��it will take longer



No deadlines?

Parkinson’s law

“The amount of time which one has to perform a task …

… is the amount of time it will take to complete the task.”

From a cost perspective

From a value perspective

From an HR perspective

Healthy balance in Kanban

Managing by measuring

http://www.flickr.com/photos/wok_design/2499217405/

Healthy balance in Kanban

Helping to improve instead of command & control

http://www.flickr.com/photos/wok_design/2499217405/

http://www.flickr.com/photos/96dpi/3371440496/

Theory of Constraints

for process improvement

the weakest chain determines the rate of the entire system

the WIP Limits will let you feel the TOC and ��do something about it

•  Only work on customer orders •  Reduce guessing to avoid waste •  Limit WIP to reduce inventory,

cost & risk


Flow

WIP limits create ��a pull system


Isn’t this inefficient?

NO, it reduces risk & waste!

•  The risk of starting something that doesn’t match expectations

•  The risk of declining value

3. ��Things will ��get stuck, ��we can’t keep WIP limits!


“Our testers can never keep up the pace of our developers. ��Developers would be idle for half of the time!”

h"p://www.flickr.com/photos/wheaKields/4774087006/

Remember: �� Kanban doesn’t focus on maximizing utilization of people��

End to end flow efficiency

h"p://www.flickr.com/photos/serdar/125457544/

WIP limits will always cause bottlenecks

That’s a good thing!

It drives continuous improvement towards end to end efficiency

Being idle due to uneven flow distribution drives people crazy!

h;p://www.flickr.com/photos/annayanev/3491617954/

Ex. 1 - Requirements

Ex. 2 - Defects

Ex. 3 - Deployment

Ex. 4 - Emergencies

Ex. 4 - Emergencies

Collaboration is a cure for bottlenecks

4. ��Stakeholders don’t care ��about feeding the flow


Prioritization doesn’t have to be on a task level

Clear rules make prioritization easier •  What is the type of feature? (new, bug,

enhance- ment, ...) •  What is the business value? •  What is the cost of delay and which

type? •  Any dependencies on other

features? •  …

it forces stakeholders to do their homework!

h"p://www.flickr.com/photos/cayusa/2194119780/

Encourages building an MVP

Stakeholders care about ��Return on Investment


Stakeholder collaboration

Stop relying on status reports Visual progress instead

focus on economic decisions �� instead of fighting for capacity

h"p://www.flickr.com/photos/jpeepz/6236688/

5. ��we will ��lose ��team cohesion


h"p://www.flickr.com/photos/psit/5207166416/

Won’t the team turn into factory workers?

WIP limits lead to ��cross-boundary communication

Good teams have a common goal

h"p://www.flickr.com/photos/atomicshed/161716498/

h"p://www.flickr.com/photos/atomicshed/161716498/

Vertically organized companies lead to teams with conflicting goals

Good teams have a common goal

in Kanban, everybody contributes to the ��end 2 end process

h"p://www.flickr.com/photos/saamiam/4203685689/

this is a powerful change management approach

•  no theoretical frameworks •  no new job descriptions •  only some basic rules


What about creative thinking?

The focus on improving flow stimulates creativity

•  Team will start to investigate •  Limit back-cycles •  Lead & Cycle time measuring

stimulates close collaboration


Won’t it cause a

death march?

Measurements are used to understand reality��& have a base for improvement

h"p://www.flickr.com/photos/usnavy/6083504722/

Not pushing to go faster��but improving end 2 end

h"p://www.flickr.com/photos/rwp-‐roger/3854246685/

Now you have a response!

1.  We lose our ability to plan

2.  It will take longer

3.  Things will get stuck

4.  Stakeholders don’t care about feeding the flow

5.  We will lose team cohesion

Thanks!

@NickOostvogels

http://leanpub.com/kanbanforskeptics


6. ��Software��development is ��not manufacturing!

Kanban has it’s roots in the Toyota Production System

That’s why it feels so right for support teams.

It feels different in product development

not all lean manufacturing principles are valid for product development

h"p://www.flickr.com/photos/chrism70/104302940/

Instead fast feedback loops are

more interesting Removing waste by truncating a

bad path quickly

Product development characteristics: •  creative thinking •  continuous testing of new ideas •  seeking as much feedback as possible •  intense discussions

Lean product development: •  Strong leadership •  Cross-functional teams •  Set-Based Concurrent Engineering •  Short feedback loops •  Focus on the customer and supplier •  Cadence, Pull, and Flow

The application differs in Lean •  Product development •  Manufacturing

The same way it differs in Kanban for •  Software development •  Support & operations

Nevertheless they are built on the same principles!

Thanks!

@NickOostvogels

http://leanpub.com/kanbanforskeptics

Documents

Nick Oostvogels: 5 Arguments Against Kanban