An Introduction to Kanban


Published on

Kanban is an Lean practice that focuses on completing work. Used alone Kanban provides an evolutionary approach to agile development and better fits many SW development teams (like maintenance or sysadmin) that don't have an iterative cadence. Used in combination with agile processes like Scrum or Extreme Programming, Kanban practices like WIP limits and Service Level swim lanes solve issues real teams and companies encounter every day. Project managers should pay special attention to Kanban Lead Time metric.

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

An Introduction to Kanban

  1. 1. An  Introduc+on  to  Kanban   Camille  Bell   Agile  Coach   Twi+er  @agilecamille  
  2. 2. Background   •  Agile  ≠  Scrum   –  Agile  is  a  philosophy   •  Individuals  and  interac+ons  over  processes  and  tools   •  Working  soAware  over  comprehensive  documenta+on   •  Customer  collabora+on  over  contract  nego+a+on   •  Responding  to  change  over  following  a  plan   –  There  are  many  ways  to  do  Agile   •  Scrum   •  Kanban  /  Lean   •  XP   •  Etc   •  Kanban  is  a  change  management  method,  not  a   soAware  development  lifecycle  or  project   management  method  or  process              2  
  3. 3. Why  Kanban?   •  Stop  rewarding  star%ng  work  and  start   focusing  on  finishing  work   – Work  in  progress  (WIP)  should  be  limited   – Only  start  work  on  something  new  when  there  is   capacity  to  do  the  work              3  
  4. 4. Way  Too  Many  User  Stories  in  Flight   (Scrum  without  WIP  Limits  can  be  dysfunc+onal)              4  
  5. 5. 5  Key  Principles  to  Kanban   •  U+lize  Visual  Controls   •  Limit  WIP  (Work-­‐In-­‐Progress)   •  Manage  Flow   •  Con+nuous  Improvement   •  Explicit  Policies   Manage  the   work   Not  the  people!              5  
  6. 6. Visual  Controls   •  Work  is  transparent  and  always  present   •  Easy  to  iden+fy  boZlenecks   •  Kanban  literally  means  “visual  card/board”   TITLE Owner  Date  Ready   Date  Started   ID#   Project  name  Due  Date              6  
  7. 7. To  Do   In  Progress   Done   What  Happens  to  an  “In  Progress”  Story?   Where  is  each  story  in  that  process?              7  
  8. 8. “In  Process”  Steps  May  Differ  by  Team   •  Team  A  “In  Process”  steps   –  UI  Design   –  TDD  (Automated  Test/Code/Refactor  Cycle)   –  Manual  Acceptance  Tes+ng   •  Team  B  “In  Process”  steps   –  Analysis   –  SW  Design   –  Review   –  Code   –  Automated  Unit  Test              8  
  9. 9. Model  Steps  That  Exist   (not  what  you  wish  they  were)   When  the  steps  change,  then  change  your  board,  not  before              9   In   Process   In   Process   In   Process  Queue   Queue   Queue   User   Stories   Step  1   Step  2   Step  n   Done   .  .  .   .  .  .   8   7   6   5   4   3   2   1  
  10. 10. KANBAN  BOARD  –  VISUALIZE  WORK  STEPS   Work Type - Doing Work Type - Done Model  All  the  Steps  That  Exists  –  there  could  be  dozens.  Steps  will  vary  by  team.  Some  teams  do  UI   design,  some  code  reviews,  etc.  Create  a  column  for  each  step.     If  you  can  totally  eliminate  a  step  later  (do  you  really  need  that  Control  Board?),  do  so,  but  start  with   what  is,  not  what  you  wish  there  was.  Update  whole  en+re  structure  regularly  as  you  find  ways  to   eliminate  handoffs  and  waste.              10  
  11. 11. Input   Queue   UI  Design   Development   Acceptance  Test   Release   Ready   Visualize  “In  Process”  by  breaking     down  into  separate  steps   Your  defini+ons  of  “Done”  can  iden+fy  steps   FLOW              11  
  12. 12. Limit  WIP   •  We  make  a  commitment  to  limit  the  Work-­‐In-­‐ Progress  (WIP)   – Prevents  context  switching   – Performing  tasks  sequen+ally  yields  results  sooner   •  Focusing  more  on  finishing  work  we’ve  already   taken  on,  versus  just  star+ng  new  work   •  Enhance  teamwork   – Increase  cross-­‐func+onality              12  
  13. 13. To  Do   UI   Design   Done   Why  is  so  liZle  gepng  done?   Work  in  Progress  BoZlenecks  !  !  !   Jim   Sue   Mark   Paul   Jim   Ken   Sue   Sue   Sue   Sue   Ken   Ken   Paul   Mark   Sue   Mark   Sue   Development   Manual   Test   Scrum doesn’t have WIP Limits. Without WIP Limits Scrum can be dysfunctional. Consider adding WIP Limits to Scrum. FLOW              13  
  14. 14. Queue  Limits  &  WIP  Limits  Avoid   Premature  Work  and  Mul+-­‐Tasking   WIP  Limit  prevents  Queue  Limit  prevents              14   In   Process   In   Process   In   Process  Queue   Queue   Queue   User   Stories   Step  1   Step  2   Step  n   Done   .  .  .   .  .  .  
  15. 15. Manage  Flow   •  The  flow  of  work  through  each  state  in  the   workflow  should  be  monitored,  measured  and   reported   •  Work  is  pulled  not  pushed  through  the  system   •  Allows  you  to  quickly  iden+fy  boZlenecks  in   produc+on/work   – Toyota  produc+on  line  example              15  
  16. 16. Input   Queue   UI  Design   Development  Dev   Ready   Test   Ready   Test   Release   Ready   In  Prog                Done   In  Prog                Done   In  Prog   5   3   3  5  4   2   WIP    Limits   BLOCKED!  Can’t  move  ahead   FLOW   Queue    Limit              16  
  17. 17. Con+nuous  Improvement   •  Start  with  what  you  do  now   •  Respect  the  current  process,  roles,   responsibili+es  &  +tles   •  Agree  to  pursue  incremental,  evolu+onary   change   – Team  empowered  to  suggest  changes   “Nothing else in their world should have changed. Jobs, activities, handoffs, and artifacts are the same. Their process hasn’t changed, other than you asking them to accept a WIP limit and to pull work….” - David Anderson              17  
  18. 18. Input   Queue   UI  Design   Development  Dev   Ready   Test  Ready   Test   Release   Ready   In  Prog                Done   In  Prog                Done   In  Prog   5   3   3  5  4   2   WIP    Limits   BLOCKED!  Can’t  move  ahead   FLOW   Queue    Limit              18  
  19. 19. But…..   •  But  what  about  unexpected  cri+cal  work?   – Expedite  lane   •  But  some  of  my  tasks  are  more  important  than   others!   – Class  of  Service  (CoS)   •  But  what  about  tasks  that  are  blocked?   – There  are  ways  to  handle  this  and,  more   importantly,  to  measure  the  impact  of  these   blocked  tasks.              19  
  20. 20. A  Kanban  Board  at     WIP  Limits   Metrics   FLOW              20  
  21. 21.                      Kanban  Board  with  Swim  Lanes   (2  feature  sets,  1  bug  fix)   Features     Maintenance  &   Improvement              21  
  22. 22. Possible  Metrics   •  Day  finished  –  Day  entered  queue  =  Wait  Time   •  Day  finished  –  Day  started  =  Time  to  Complete   •  Average  wait  +me   •  Average  +me  to  complete   •  Averages  per  CoS   •  Standard  devia+on   •  Metrics  for  unusual  events  (e.g.  field  crisis,   special  event,  emergencies)              22  
  23. 23. Metrics  Example   Many  tool   companies  now   have  tools  that   support  Kanban.   Alterna+vely   white  boards,   s+cky  notes  and   Excel  spread   sheets  provide   the  ul+mate  in   flexibility  and   they  are  cheep.              23  
  24. 24. Where  Kanban  Is  Especially  Needed   •  Large  organiza+ons  with  mul+ple  teams  (also  to   organize  2nd  4er  Scrum  teams)   •  Teams  that  aren’t  fully  cross  func+onal  (e.g.  missing   full  +me  DBA,  Tester,  Deployment  Specialist,  etc.)   •  Teams  that  don’t  have  a  standard  itera+on/sprint   cadence  (e.g.  maintenance  bug  fix  teams,  system   engineering  teams,  etc.)   •  Teams  that  receive  unplanned  emergency  work   •  Teams  that  support  mul+ple  customers  or  Classes  of   Service   •  Teams  or  organiza+on  that  need  beZer  metrics              24  
  25. 25. Bibliography   •  ”Kanban  101”  -­‐  Jessie  Link,  November  2011     •  “Kanban”  by  David  J.  Anderson  ISBN        9780984521401   •  “Scrumban”  by  Corey  Ladas  ISBN      9780578002149   •  “Lean  from  the  Trenches”  by  Henrik  Kniberg  ISBN  139781934356852              25  
  26. 26. Webliography   •  Limited  WIP  Society/KanbanDev:  User  group  discussing  development  using  Kanban  for   technology  business  hZp://   •  DZone  Refcard  109  “Gepng  Started  with  Kanban  for  SoAware  Development”  by  David   J.  Anderson  and  Janice  Linden-­‐Reed  hZp://   •  BTI360  Blog  “Kanbanima+on”  by  Clinton  Wivell   hZp://   •  Agile  Agility  “Kanban,  Flow  and  Cadence”  by  Karl  Scotland     hZp://­‐flow-­‐and-­‐cadence/   •  LeanKit  Kanban  “Simplifying  Project  Management”  hZp:// landing/smpl/?gclid=CPPtrJOHlK4CFRIDQAodsRWn9w   •  Lean  SoAware  Engineering  “PaZerns  of  SoAware  Engineering  Workflow”  by  Corey   Ladas  hZp://­‐paZerns/              26  
  27. 27. Camille  Bell   Agile  Coaching  &  Consul+ng   Retrospec+ves   Agile  Boot  Camps     Agile  Training   Updated  Slides   or  just  to  chat  about  things  agile