The road to potential shippable increments

1,229 views
1,075 views

Published on

One of the most common struggles of Scrum teams is finishing a sprint 100%. In their retrospectives, teams work out improvement actions to address this issue. These actions are often targeting better planning, better estimating or better preparation of user stories. However, as time proceeds, the next sprints are not completed 100% neither. Even when the Scrum master encourages the team to commit to less story points. They always seems to deliver 80% to 90% of the sprint backlog. Not only is this very demotivating, it also compromises shipping the next increment. In this session I will explain with a case study, why this struggle is not related to poor planning, estimating or preparation. I will share how this specific team used the improvement kata and Theory of Constraints to optimize their flow of work and ended up finishing their sprints successfully.

Published in: Business, Technology, Sports
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,229
On SlideShare
0
From Embeds
0
Number of Embeds
13
Actions
Shares
0
Downloads
7
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

The road to potential shippable increments

  1. 1. the ROAD to potential SHIPPABLEincrements April 25, 26 - Lyon hp://www.flickr.com/photos/gravitywave/483395506/  
  2. 2. Who am I? •  Nick Oostvogels •  Independent consultant •  PM, agile Kanban coach •  Freelance blogger •  Conference organizer •  Father of 3
  3. 3. The story hp://www.flickr.com/photos/expressmonorail/3121252611/  
  4. 4. The story •  A typical Scrum team •  Dedicated team of 5 devs, 2 qa, 1 PO, 1 SM,1 analyst
  5. 5. The story •  Switched from waterfall 6 months ago •  Getting better •  Being coached
  6. 6. The story •  Developing a web application •  Highly visible project •  Have to start delivering
  7. 7. Retrospectives •  Taken seriously •  Improving continuously •  Open minded, willing to try new things
  8. 8. PROJECT POST-MORTEM LESSONS LEARNED MORE FREQUENT withITERATIVE developmentAgile RETROSPECTIVESImage  by  code_mar.al  at  h2p://www.flickr.com/photos/code_mar.al/4145914957/  
  9. 9. Retrospectives SET the STAGEGATHERINFORMATIONINSIGHTSDEFINE ACTIONSCLOSE
  10. 10. But still… Finishing a sprint 100% seemed impossible
  11. 11. Introducing… The 6 step program… … towards potential shippable increments hp://www.flickr.com/photos/theklan/1276710183/  
  12. 12. 1st step Change focus by learning the improvement kata Goal: get more value out of the retrospectives
  13. 13. Kata : a pattern you practice to learn a skill andmindset. Improvement kata : a pattern for improving,adapting and innovating. It helps to improve continuously towardsa goal instead of random hunting forimprovements. hp://www.flickr.com/photos/kaibara/1449448184/  
  14. 14. Current condition Vision Target Condition PDCAPDCAPDCAImprovement kata
  15. 15. Customized for retrospectives 1.  Formalize the vision “What is important for us? How do we want todeliver software?
  16. 16. Current condition Vision Target Condition PDCAPDCAPDCA
  17. 17. Customized for retrospectives 2. Use the vision to agree on the targetcondition “What is the next step we can take to get closerto the vision?”
  18. 18. Customized for retrospectives 3. Use the vision as a cross-check Does this improvement suggestion help us toget closer to the vision?
  19. 19. Result •  Better focus •  Long term thinking •  Systems thinking •  The vision is used as a referee during discussions •  It may take several sprints to get to the next target condition hp://www.flickr.com/photos/louish/5626178350/  
  20. 20. 2nd step Focus on quality Goal:‘REALLY’ delivering features
  21. 21. What is quality? Zero bug policy! hp://www.flickr.com/photos/felixjacksonjr/2280660104/  
  22. 22. How? •  In sprint testing •  In sprint validation Definition of done: + no open bugs related to user stories of thesprint backlog Fix regression bugs before starting new work
  23. 23. Results •  Happier end users •  Easier demo’s •  Higher confidence towards deployment •  More accurate planning
  24. 24. 3rd step Focus on improving flow Goal: identify and understand bottlenecks
  25. 25. http://www.flickr.com/photos/96dpi/3371440496/Theory of constraints
  26. 26. Boyscouts example http://www.flickr.com/photos/22326055@N06/4257346829/
  27. 27. •  Step 1 – Find bottlenecks through symptoms •  Step 2 - Plan actions to reduce or eliminatebottlenecks •  Step 3 – Subordonate everything else to theabove decision •  Step 4 – Evaluate the bottleneck •  Step 5 – go back to step1
  28. 28. Investigate act Walk through the lifecycle of the user stories
  29. 29. h2p://www.flickr.com/photos/usnavy/6083504722/  Investigate act Use measurements
  30. 30. Investigate act Discuss possible bottlenecks h2p://www.flickr.com/photos/smannion/3385144016/  
  31. 31. Investigate act Plan actions to reduce or eliminate the bottleneck
  32. 32. Result •  Awareness •  Get used to hunt for bottlenecks
  33. 33. 4th step Make bottlenecks visible
  34. 34. Limit Work in Progress Active In Development (5) In Test (3) Resolved (2) Closed
  35. 35. Kanban board
  36. 36. Kanban rules Never break the WIP limits!
  37. 37. Being idle due to uneven flow distributiondrives people crazy! hp://www.flickr.com/photos/annayanev/3491617954/  
  38. 38. Kanban rules 1.  Check if the bug list is empty 2.  Check if you can help the next stage to pull afeature 3.  Check if you can help somebody with a featurein your stage 4.  Investigate the root cause 5.  Improve the application or your way of working 6.  Learn something new, related to the job What to do when the flow is stuck?
  39. 39. Remember:Kanban doesn’t focus onmaximizing utilization ofpeople
  40. 40. Result •  Focus on the entire chain •  WIP limits to manage flow and tacklebottlenecks
  41. 41. 5th step Anticipate bottlenecks early on
  42. 42. Understanding measurements
  43. 43. Distribution
  44. 44. SLA’s
  45. 45. Result •  Visualisation •  Better decision making •  No more tasks that disappear in the process
  46. 46. 6th step Use SLA’s for good sprint backlog composition
  47. 47. Sprint backlog Big user stories need to go first We can only do a few big ones Small user stories near the end Dependent user stories may not fit thesprint S  (0-­‐2  sp)  :  4  days    -­‐  7  days  M  (3-­‐5  sp)  :  4  days  -­‐  7  days  L  (8-­‐13  sp)  :  10  days  -­‐  14  days  
  48. 48. The Role of PO and SM http://www.flickr.com/photos/joshuacraig/5410326211/Product Owner Explain priorities Actively participate Trust the team Put quality and flow first Scrum Master Guard the rules Give the team amandate Trust the team
  49. 49. Compare with 1 year earlier
  50. 50. Compare with 1 year earlier Planning is much more accurate despiteless upfront preparation •  Bugfree software •  Consistent delivery •  Definition of done •  Up to date product backlog
  51. 51. Compare with 1 year earlier Easier end-user testing and demos Better feedback http://www.flickr.com/photos/cblue98/7635645124/
  52. 52. Compare with 1 year earlier Team spirit increased http://www.flickr.com/photos/wwworks/1384952210/
  53. 53. Not pushing to go fasterbut improving end 2 end h2p://www.flickr.com/photos/rwp-­‐roger/3854246685/  
  54. 54. Compare with 1 year earlier Focus on finishing instead of starting http://www.flickr.com/photos/tharrin/3555828959/
  55. 55. Compare with 1 year earlier Ownership “Everybody cares” http://www.flickr.com/photos/saamiam/4203685689/
  56. 56. Summary 1 Improvement Kata 6 Use SLA’s during planning 2 Focus on Quality 3 Improving flow 4 Make bottlenecks visible (WIP limits) 5 Anticipate bottlenecks (SLA’s)
  57. 57. Available on
  58. 58. Related books
  59. 59. www.dare2013.be
  60. 60. Thanks! @NickOostvogelshttp://www.skycoach.be

×