• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Kanban = Violet Pill
 

Kanban = Violet Pill

on

  • 3,830 views

Kanban talk presented at Italian Agile Day 2011 #iad11

Kanban talk presented at Italian Agile Day 2011 #iad11

Statistics

Views

Total Views
3,830
Views on SlideShare
3,659
Embed Views
171

Actions

Likes
14
Downloads
113
Comments
0

13 Embeds 171

http://presentz.org 112
http://lanyrd.com 22
http://iad11.presentz.org 16
http://www.linkedin.com 5
http://dev.presentz.org 3
http://local.host 3
https://twitter.com 2
http://a0.twimg.com 2
http://paper.li 2
http://iad.presentz.org 1
http://localhost 1
http://feeds.feedburner.com 1
http://www.feedspot.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Kanban = Violet Pill Kanban = Violet Pill Presentation Transcript

    • Kanbanviolet pill Gaetano Mazzanti @mgaewsj Gama-Tech
    • disruptiveno change change
    • révolution?
    • inspired by Joakim Sunden
    • changes often end up being local:big impact on a few people,small/no impacton the whole org
    • a storm in a glass?company technical dept SW teams change impacts just here
    • (scared) orgs, prefer smallimprovements, no change inroles and responsibilities(and they don’t like to be told thatmanagers should be kept out of the loop)
    • no cross functional team?
    • no product owner?
    • firefighting?
    • people working onmultiple projects?
    • scared to change?
    • sometimes you cannottransform first observe, visualize work, apply continuous improvement,then transform
    • Purpose > Observe, Measure > Method method should come last!
    • a complex journey, unknown destinationsame pattern:Code un  ProductProcess (BTW you need a Vision…)
    • Kanban 101make work visiblelimit Work In Process(WIP)help work to flow
    • kanban vs Kanban 1950 2004
    • kanban & JIT in manufacturingonly what is neededonly in the amounts neededonly when it is needed pull
    • simple kanbanhome milk delivery
    • muri, mura, muda
    • if you can’t see ityou can’t manage it
    • Limit WIP
    • let work flowlet work flow
    • context matters
    • principles of the Kanban methodstart with what you do nowpursue incremental, evolutionarychangerespect the current process,roles, responsibilities & titles David J Anderson
    • five core propertiesvisualize the workflowlimit WIPmanage flowmake process policies explicitimprove collaboratively(let people design their own process)
    • yes, and…two rules for improv…isation:1. agree2. add Tina Fey EMENT  
    • “the aim of kanban is to maketroubles come to the surface andlink them to kaizen activity” Taichi Ohno, 1984
    • map the mess empower the team to fix it workflow bottlenecks queuesmake visible teamwork time type of work
    • expose dysfunctionsdo you keep stinky food in the fridge?
    • visualize your actual work(flow)backlog   to do   in progress   test   done   A   B   C   D   E   F  
    • visualize your actual work(flow)backlog   to do   in progress   test   done   A   B   C   D   E   F  
    • visualize your actual work(flow)backlog   to do   in progress   test   done   B   A   C   D   E   F  
    • visualize your actual work(flow)backlog   to do   in progress   test   done   A   C   B   D   E   F  
    • visualize your actual work(flow)backlog   to do   in progress   test   done   C   A   B   D   E   F  
    • limit WIPbacklog   to do   in progress   test   done   F   C   A   E   G   D   B   H   I   J  
    • limit WIP measure flowbacklog   to do   in progress   test   done   F   C   A   E   G   D   B   H   I   J   cycle time   lead time  
    • why should we limit WIP? Little’s Law cycle time = WIP / throughput(throughput = average completion rate)
    • why should we limit WIP? Little’s Law length of queue =arrival rate * average wait time
    • why should we limit WIP?too much WIP increases cycle timetoo much WIP leads to queuesqueues lead to delaysqueues lead to multitaskingqueues lead to … many additionaldysfunctions (variability, lowerquality, demotivation, higher risks, etc.)
    • Cost of Delay source David J Anderson
    • causes of delay
    • multitasking sucks ABC  ABC  ABC   AAA  BBB  CCC  
    • multitasking sucks multitaskers optimize for capacity, not for throughput 100   80  percent   60   ABC  ABC  ABC   AAA  BBB  CCC   40   20   0   context  switching  4me   1   2   working  4me   3   4   5   number  of  simultaneous  projects   working  4me   context  switching  4me   source Jerry Weinberg
    • let work flow backlog   to do   in progress   test   done   H   F   C   E   A   I   G   J   D   B  can’t push anything here  
    • let work flowbacklog   to do   in progress   test   done   H   F   C   E   A   I   G   J   D   B  
    • let work flowbacklog   to do   in progress   test   done   H   F   C   A   I   E   G   J   D   B  
    • let work flowbacklog   to do   in progress   test   done   H   F   C   A   I   E   G   J   D   B  
    • who’s working on what?backlog   to do   in progress   test   done   F   C   A   E   G   D   B   H   I   J  
    • total WIPbacklog   to do   in progress   test   done   F   C   A   E   G   D   B   H   I   J   total WIP = 4  
    • buffersbacklog   [ to do   in progress   test   done   [ G   H   C   A   I   F   J   E   D   B  
    • buffers with no WIP limitbacklog   to do   in progress   test   done   I   G   C   A   J   D   B   K   E   L   F   H  
    • no WIP limits => queuebacklog   to do   in progress   test   done   C   O   N   K   A   D   M   P   L   E   B   F   Q   G   H   I   J  
    • no WIP limits => queuebacklog   to do   in progress   test   done   O   N   K   A   M   P   L   B   Q  
    • flow = speed * density
    • flow = speed x density density flow vehiclesvehicles per Kmper hour Km per hour speed Km per hour
    • queues cumulative flow diagram cycle timecumulative WIP quantity time
    • cumulative flow diagram large batches => long queuescumulative quantity time
    • cumulative flow diagram small batches => short queuescumulative quantity time
    • what to do next (help)backlog   to do   in progress   test   done   G   F   C   A   H   B   I   E   D   J  
    • what to do next (pull)backlog   to do   in progress   test   done   G   F   C   A   H   D   B   I   E   J  
    • stuck (cannot break WIP limit)backlog   to do   in progress   test   done   H   G   D   A   F   I   J   E   B   C  
    • stuck (nothing to pull)backlog   to do   in progress   test   done   G   E   D   A   H   I   F   B   C  
    • slack (%) absorb variations 25   20   15  queue size 10   queue size 5   grows exponentially 0   0   10   20   30   40   50   60   70   80   90   100   at high capacity % capacity utilization
    • no testers
    • non-instant availability
    • non instant availability external parking
    • what’s on a stickie?ID 326 As a user I want to So that blocked due date 12 Nov 2011 this is just an example
    • type of work
    • types of workstandard due dateexpedite bug
    • classes of service and WIP standard work = 60% expedite = 10% due date = 20% bug = 10%
    • classes of service, WIP, expedite lane backlog   to do   in progress   test   done   G   H   E   A   C   J   F   D   B   I  6   M   L   K  2   O   N   EXPEDITE LANE  1   Q   P  1  
    • cost of delay & classes of servicecost     6me   cost     6me  cost     6me  
    • explicit policies -­‐  standups  at  11.45  am   -­‐  2  hours  pairing  3  days/week   -­‐  retrospec6ve  every  Friday  at  2pm  backlog   to do   in progress   test   done   =>  In  Progress:   =>  Done:   -­‐  Acceptance  Test  defined   -­‐  Acceptance  Tests  verified   on  test  server   -­‐  Signed  Off  by  Marke6ng   -­‐  Test  coverage  >  80%    
    • multiple projects project A project B project C
    • multiple projectsbacklog   to do   in progress   test   done   G   E   A   C   J   F   B   M   L   K   D   O   N   H  
    • peopleworking on multiple parallel projects
    • portfolio Kanban ouch!
    • portfolio Kanban one month later
    • world is not linear…backlog   to do   in progress   test   done  
    • multiple routes DEVELOPERS   design   code   test   H   E   BACKLOG   DONE  backlog   to do   D   deploy   done   N   M   C   A   L   SUPPORT   B   script   test   I   F   G  
    • networked Kanban source Jurgen Appelo
    • Kanban is not a processKanban is something that isoverlaid over an existing processKanban is a catalyst for change
    • a drug for all seasons Agile Teams running out of steamprocess maturity traditional chaotic
    • gateway drug theory softer drugs (Kanban) can lead to harder drugs (Scrum, XP, whatever…) Michael Sahota
    • a trojan horse?
    • dogma? no, thanks
    • don’t stop improving
    • don’t stop improving Z Z Z Z Z  process time
    • overburden task switching command & controlKan’t Ban?YESB UT Kan…but?
    • it’s a never ending journey K anban enjoy the ride learn from the peopleGaetano Mazzanti plan with the people@mgaewsj begin with what they haveGama-Tech build on what they know Lao-Tzu
    • it’s a never ending journey K anban enjoy the rideGaetano Mazzanti@mgaewsjGama-Tech