Henrik Kniberg: Lean from the Trenches keynote @ AgileEE

2,909 views

Published on

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,909
On SlideShare
0
From Embeds
0
Number of Embeds
566
Actions
Shares
0
Downloads
69
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Henrik Kniberg: Lean from the Trenches keynote @ AgileEE

  1. 1. Lean from the Trenches Oct 6, 2012 Agile Eastern Europe, Kiev Henrik Kniberg Agile/Lean coach www.crisp.se
  2. 2. Henrik Kniberg 2
  3. 3. 3Henrik Kniberg
  4. 4. 4Henrik Kniberg
  5. 5. Lean principles Kanban XP ScrumHenrik Kniberg 5
  6. 6. <dislaimer> No solutions. Only examples.</disclaimer>Henrik Kniberg 6
  7. 7. Once upon atime… 7 7
  8. 8. PUST – Polisens Utrednings STöd 2011 2010Henrik Kniberg 8
  9. 9. Timeline First pilot Nationwide Project launch 1.0 1.1 1.2 1.3 1.4 1.5 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 2009 2010 2011 10 people 30 people 60+ peopleHenrik Kniberg 9
  10. 10. Slicing the elephant Region Östergötland, Uppsala, etc 1.0 Crime types 1.1 1.3 1.4 (weapon, drunk driving, 1.2 shoplifting, etc) 1.5 PUSTIntegrations Henrik Kniberg 10
  11. 11. User involvement Acceptance test Pilot users user group ”Customer” Onsite PUST Project userHenrik Kniberg 11
  12. 12. Team structure &”Daily cocktailparty” 12 12
  13. 13. Team structure - before Requirements 3 Test analyst Development team team teams ! ! #% #% !? !?Henrik Kniberg 13
  14. 14. Improved team structure Requirements 3 System test analyst Feature team team teamsHenrik Kniberg 14
  15. 15. ”Daily cocktail party” 9:15 – 10:15 Henrik Kniberg 15
  16. 16. 10:00 – 10:15 Project sync 9:45 – 10:00 9:45 – 10:00 Requirements Dev sync Test sync sync 9:30 – 9:45 9:30 – 9:45 9:15 – 9:30 Feature team 1 Feature team 2 Feature team 3 16Henrik Kniberg
  17. 17. The project board 17 17
  18. 18. Next 10 UserIdeas Features Development System features acceptance Production test test FLOW Henrik Kniberg 18
  19. 19. Henrik Kniberg 19
  20. 20. Cadences week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8 Retrospectives (2w) Planning (2w) Demo & systest (continuous) Release (2m) 20
  21. 21. 21
  22. 22. Henrik Kniberg 22
  23. 23. Impediments & escalation Feature General blocked impediments Can’t 2011-03-01! Police car = As police!t!! asdfasdfasdf tes r! ing fo der! I need tocode rea Wait scan! urgent (patch) bar So that JMmr! ch 12! !i aHenrik Kniberg 23
  24. 24. Scaling the boards 24 24
  25. 25. Feature swimlanes Next 10 Dev Ready for Sys test features in progress sys test progress Henrik Kniberg 25
  26. 26. Next 10 Dev Ready for features in progress sys testDev Team 1 Dev Team 2 Dev Team 3 26 Henrik Kniberg 26
  27. 27. Definition of ”ready for development” Definition of ”ready for system test”Henrik Kniberg 27
  28. 28. Henrik Henrik Kniberg Kniberg 28 28
  29. 29. How we handletech stories 29 29
  30. 30. Tech stories Next 10 features Ready forDevelopment Next 5 tech stories Henrik Kniberg 30
  31. 31. Example: the 7 meter classHenrik Kniberg 31
  32. 32. ”Oh no, bottleneck in System Test! FLOWHenrik Kniberg 32
  33. 33. Question of the week: How can we best contribute to system test today? Bottleneck ”Let’s stop building new features” ”... and focus ontest automation!” Henrik Kniberg 33
  34. 34. Everyone doing tech storiesHenrik Kniberg 34
  35. 35. How we handlebugs 35 35
  36. 36. ReleaseBefore:Test at end Test Fix %&@#! Week 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8Now: ReleaseTest continuously Week 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8 Test Fix Test at end: %&@#! Test continuously: Test Fix Time saved! Henrik Kniberg 36
  37. 37. Bug fixing process Bug found! Yes Write sticky-note, Blocker? find developer, fix now! No More important Yes Replace one of than any of the the other current top 30? top 30 bugs with this one No Ignore it Don’t log it. Fix it NOW!Henrik Kniberg 37
  38. 38. Three input queues Next 10 features Next 5 tech stories Next 5 lower priority bugsHenrik Kniberg 38
  39. 39. Recurring bugsHenrik Kniberg 39
  40. 40. How wecontinuouslyimprove theprocess 40 40
  41. 41. Retrospectives every1-2 weeks Henrik Kniberg 41
  42. 42. Too much, too fast!Henrik Kniberg 42
  43. 43. Limiting the rate of change ”A4” improvement proposal ”A4” improvement proposal ”A4” improvement proposal ”A4” improvement proposalHenrik Kniberg 43
  44. 44. Proposal:  More  Customer-­‐Valued  Stories  Why?  What  Problem  Are  We  Trying  to  Solve?   DescripAon  /  FAQ   A  story  that  goes  into  development  must:  •  Hard  to  get  an  overview  of  the  project  board   1.  Be  size  S  or  M   from  customer  perspec7ve,  many  stories  are   2.  Be  as  customer  valuable  as  possible,  as  long  as  we  don’t   break  the  size  rule.   so  small  that  they  can’t  be  delivered.   The  requirements  team  ensures  that  each  card  under  ”Ready  for  Who  Is  Affected  By  The  Change?   Development”  is  a  customer-­‐valued  story  (regardless  of  size).  •  Requirements,  development,  and  test  teams.   However,  before  it  enters  development  it  must  be  S  or  M.     Ques7on:  What  happens  if  the  story  is  L,  and  must  be  delivered  as  What  Are  the  Change  ImplementaAon  Steps?   a  whole  before  it  is  valuable  to  the  customer?  •  Update  Defini7on  of  Done  for  ”Ready  for   •  Break  it  down  to  smaller  stories  (new  cards)  which  are  size  M,   but  with  highest  possible  customer  value  per  story.   Development”,  add  ”the  story  is  valuable  to   •  Visually  group  these  stories  by  wri7ng  the  name  of  the  higher   the  customer”.   level  feature  in  big  blue  leSers  at  the  top  of  each  card.  •  Go  through  the  board  &  iden7fy  stories  that   are  too  small  to  be  valuable.  Combine  these   into  bigger  stories  (as  long  as  they  don’t   exceed  Medium).   Example:   CONFISCATION Register Confiscation M Confiscation CONFISCATION L Remove Confiscation Henrik Kniberg S 44
  45. 45. Limiting the rate of change ”A4” improvement proposal ”A4” improvement proposal ”A4” improvement proposal ”A4” improvement proposalHenrik Kniberg 45
  46. 46. How we captureand use processmetrics 46 46
  47. 47. Process metrics"   Velocity = feature per week"   Throughput time = weeks per feature 47
  48. 48. Velocity – stories per week Ready for acceptance test (this week so far) Ready for acceptance test (previous weeks) Velocity per week Henrik Kniberg 48
  49. 49. Velocity-based release planning All of these will be done# offeatures Weekdelivered to Some of theseacceptance will be done,test but not all None of these will be done 49 Henrik Kniberg 49
  50. 50. Henrik Kniberg 50
  51. 51. BedTotal time!work Play time! Timeline Henrik Kniberg (5 minute 51 intervals)
  52. 52. Henrik Kniberg 52
  53. 53. Velocity improvement Q2 6.5 features per Q1 week# of 3 featuresfeatures per weekdelivered toacceptancetest WeekHenrik Kniberg 53
  54. 54. Throughput time – weeks per feature Ready for Next 10 acceptance Throughput time (elapsed days) features testHenrik Kniberg 54
  55. 55. Elapsed days FeatureHenrik Kniberg 55
  56. 56. Throughput time improvement Q1 6-14 weeks per feature Q2 3-6 weeks per featureElapseddays Henrik Kniberg 56
  57. 57. Surprising insight Average throughput time Small:  31  days   Medium:  37  days  Elapsed ”Small” & ”Medium” Large:  59  days  days features take roughly same amount of time Feature Henrik Kniberg 57
  58. 58. How we track thehigh level goal 58 58
  59. 59. High level goal MilestoneHenrik Kniberg 59
  60. 60. Death March Detectionusing gut feel Do you believe the current goal is achievable? 5 = certainly 4 = probably 3 = barely 2 = probably not 1 = forget itHenrik Kniberg 60
  61. 61. Henrik Kniberg 61
  62. 62. Wrapup 62 62
  63. 63. Setting the project up Incremental deliveryfor successCo-location Customer involvement 63
  64. 64. Creating a culture ofcontinuous improvement Clarity CommunicationData Henrik Kniberg 64
  65. 65. Perfection is a direction, not a place The important thing is not how you work. The important thing is how you improve the way you work!Henrik Kniberg 65

×