5 arguments against kanban

ARGUMENTS

against

@NickOostvogels

KANBAN

Kanban is on the rise

Source : VersionOne - State of Agile Survey 2011

http://www.flickr.com/photos/smannion/3385144016/

When introducing

new ideas…

People compare it

to what they know

http://www.flickr.com/photos/mvjantzen/4815422633/

… and

start to

criticize

http://www.flickr.com/photos/the-g-uk/3913466332/

Kanban is hard to

explain

briefly

http://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

http://www.flickr.com/photos/scania/2869199313/

In Software Development

http://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 soon on

5 tough questions

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

we lose

our

ability

to plan

http://www.flickr.com/photos/40358860@N04/4250860618/

http://www.flickr.com/photos/photojonny/2268845904/

No

estimates?

http://www.flickr.com/photos/daren/241192712/

Customers

Managing people

http://www.flickr.com/photos/lambdachialpha/3795728748/

Release planning

Initial

specs

Translation into

requirements

Estimation

Review

estimations Release

Plan

Issues

• Not a repeatable process

• Never built something alike

• (educated) GUESSING

• Software dev = Creative

process

Kanban : measuring

http://www.flickr.com/photos/jaydedman/2593673396/

Different

sizes ???

Use a scale

compare

Keep features small

Why sizing?

http://www.flickr.com/photos/lawdeda/4094259672/

Planning with

measurements

Reduce variation

1. Reliable planning

2. Fast response

3. Stabilize the process

4. Base for continuous

improvement

Small releases

Kanban != continuous deployment

Small releases

Kanban can lead to continuous

deployment

http://www.flickr.com/photos/photojonny/2268845904/

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

it will

take longer

http://www.flickr.com/photos/40358860@N04/4250860618/

http://www.flickr.com/photos/photojonny/2268845904/

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.”

Management by cost

Healthy balance in

Kanban

Managing by measuring

Healthy balance in

Kanban

Helping to improve

instead of command & control

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

http://www.flickr.com/photos/23945877@N05/2623633694/

Flow

WIP limits create

a pull system

http://www.flickr.com/photos/photojonny/2268845904/

Isn’t this

inefficient?

NO, it reduces risk & waste!

Not pulling = risk of starting something that doesn’t match expectations

No WIP Limits = cost of waiting + risk of getting obsolete

Things will

get stuck,

we can’t

keep WIP limits!

http://www.flickr.com/photos/40358860@N04/4250860618/

“Our testers can never keep

up the pace of our

developers.

Developers would be idle for

half of the time!”

Remember:

Kanban doesn’t focus on

maximizing utilization of

people

End to end flow efficiency

http://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!

http://www.flickr.com/photos/annayanev/3491617954/

Ex. 1 - Requirements

Ex. 2 - Defects

Ex. 3 - Deployment

Ex. 4 - Emergencies

Ex. 4 - Emergencies

Collaboration

Stakeholders

don’t care

about feeding

the flow

http://www.flickr.com/photos/40358860@N04/4250860618/

Prioritization doesn’t have to

be on task level

Clear rules make

prioritization easier

• What is the type of feature? (new,

bug, enhancement, ...)

• 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!

http://www.flickr.com/photos/cayusa/2194119780/

building an MVP

Stakeholders care about Return on Investment

http://www.flickr.com/photos/59937401@N07/5929491095/

Stakeholder collaboration

focus on economic decisions

instead of fighting for capacity

http://www.flickr.com/photos/jpeepz/6236688/

Expectation

management

we will

lose

team cohesion

http://www.flickr.com/photos/40358860@N04/4250860618/

http://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

http://www.flickr.com/photos/atomicshed/161716498/

Vertical organized

companies lead to teams

with conflicting goals

That’s why cross-

departmental functions

were created

in Kanban, everybody

contributes to the

end 2 end process http://www.flickr.com/photos/saamiam/4203685689/

this is a powerful change

management approach

• no theoretical frameworks

• no new job descriptions

• only some basic rules

http://www.flickr.com/photos/photojonny/2268845904/

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

http://www.flickr.com/photos/photojonny/2268845904/

Will it

cause a

death march?

Measurements are used to

understand reality

& have a base for improvement

http://www.flickr.com/photos/usnavy/6083504722/

Not pushing to go faster

but improving end 2 end

http://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

www.SkyCoach.be