Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Kicking ScrumBut

7,726 views

Published on

A series of ScrumBut anti-patterns observed in multiple Scrum projects along with guidance on how to avoid them.

As presented at the European Scrum Gathering (Munich, Germany) on October 19, 2009.

Published in: Business, Technology
  • Jeb Andrews, PhD, CEO of Clinical Trials of America, sent me this touching handwritten letter after he won over $5,000 betting conservatively using my "Demolisher" Baseball Betting System: ▲▲▲ http://t.cn/A6zP2wH9
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • John Buffi is a retired police offer who lost his home to Superstorm Sandy. He now uses the "Demolisher" system to help take care of his 91-year-old father and children. John says: "My only statement is "WOW"...I thought your other systems were special but this is going to turn out to be the " Holy Grail" of all MLB systems, no doubt! ◆◆◆ http://t.cn/A6zP2wH9
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • My only statement is "WOW"...I thought your other systems were special but this is going to turn out to be the "Holy Grail" of all MLB systems, no doubt! ▲▲▲ http://t.cn/A6zP2GDT
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Dating direct: ❤❤❤ http://bit.ly/39mQKz3 ❤❤❤
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Sex in your area is here: ❶❶❶ http://bit.ly/39mQKz3 ❶❶❶
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Kicking ScrumBut

  1. 1. ic k me K Kicking ScrumBut Rowan Bunning Certified Scrum Trainer Software WithStyle
  2. 2. There are pitfalls on the journey
  3. 3. There are pitfalls on the journey How can we help each other to avoid them?
  4. 4. ScrumBut • ScrumButs are reasons why you can’t take full advantage of Scrum to solve the problems and realise the benefits. • Format: (ScrumBut) (Reason)(Workaround) • Example: “We use Scrum, but Daily Scrum meetings are too much overhead so we only have them once a week.” Source: Ken Schwaber.
  5. 5. ScrumBut • ScrumButs are reasons why you can’t take full advantage of Scrum to solve the problems and realise the benefits. • Format: (ScrumBut) (Reason)(Workaround) • Example: “We use Scrum, but Daily Scrum meetings are too much overhead so we only have them once a week.” Source: Ken Schwaber. What ‘ScrumButs’ have you seen?
  6. 6. Some ScrumButs to avoid...
  7. 7. Some ScrumButs to avoid... ✖ Goalless, soulless Scrum ✖ Cherry-picking practices and premature process optimisation ✖ Shooting the Scrum messenger ✖ Planning paralysis ✖ Mis-aligned stories ✖ Command and control-style micro-management ✖ Individual heroics ✖ Smoke and mirror demos ✖ Lack of risk management ✖ The vicious cycle of overcommitment ✖ Stalled improvement
  8. 8. Avoid: Goalless Scrum “We use Scrum but... only because [insert latest fad].” Is your Scrum implementation goalless?
  9. 9. Avoid: Goalless Scrum “We use Scrum but... only because [insert latest fad].” Is your Scrum implementation goalless?
  10. 10. Avoid: Goalless Scrum “We use Scrum but... only because [insert latest fad].” Is your Scrum implementation goalless? • Why are you using Scrum?
  11. 11. Avoid: Goalless Scrum “We use Scrum but... only because [insert latest fad].” Is your Scrum implementation goalless? • Why are you using Scrum? • What are your pain points?
  12. 12. Avoid: Goalless Scrum “We use Scrum but... only because [insert latest fad].” Is your Scrum implementation goalless? • Why are you using Scrum? • What are your pain points? • What can the business expect to get out of this?
  13. 13. Try: Targeting process improvement goals
  14. 14. Try: Targeting process improvement goals
  15. 15. Try: Targeting process improvement goals • Consider using Scrum to govern the introduction of Scrum
  16. 16. Avoid: Soulless Scrum Is your Scrum implementation soulless?
  17. 17. Avoid: Soulless Scrum Is your Scrum implementation soulless? • Are you just practicing Scrum by rote?
  18. 18. Avoid: Soulless Scrum Is your Scrum implementation soulless? • Are you just practicing Scrum by rote? • Do you have a shared vision of the future?
  19. 19. Avoid: Soulless Scrum Is your Scrum implementation soulless? • Are you just practicing Scrum by rote? • Do you have a shared vision of the future? • Does your team regularly discuss Scrum values and principles?
  20. 20. Avoid: Soulless Scrum Is your Scrum implementation soulless? • Are you just practicing Scrum by rote? • Do you have a shared vision of the future? • Does your team regularly discuss Scrum values and principles? Try: Discussing Scrum values, principles and what these mean for you
  21. 21. Avoid: Cherry-picking practices “We use Scrum but... only the practices that are most appealing”
  22. 22. Agile methods as systems
  23. 23. Agile methods as systems “No single practice works well by itself, each needs the other practices to keep them in balance.”
  24. 24. Agile methods as systems “No single practice works well by itself, each needs the other practices to keep them in balance.” “If you follow 80% of the process you get 20% of the benefits.”
  25. 25. Agile methods as systems “No single practice works well by itself, each needs the other practices to keep them in balance.” “If you follow 80% of the process you get 20% of the benefits.” - Kent Beck
  26. 26. Agile methods as systems “No single practice works well by itself, each needs the other practices to keep them in balance.” “If you follow 80% of the process you get 20% of the benefits.” - Kent Beck
  27. 27. Agile methods as systems “No single practice works well by itself, each needs the other practices to keep them in balance.” “If you follow 80% of the process you get 20% of the benefits.” - Kent Beck Source: Kent Beck.
  28. 28. Agile methods as systems “No single practice works well by itself, each needs the other practices to keep them in balance.” “If you follow 80% of the process you get 20% of the benefits.” - Kent Beck Source: Kent Beck. Avoid: Premature process optimisation
  29. 29. Try: applying before inspecting and adapting
  30. 30. Try: applying before inspecting and adapting “[Apply] Scrum as proposed... for at least 3 Sprints.” - Christian Schmidkonz, SAP.
  31. 31. Try: applying before inspecting and adapting “[Apply] Scrum as proposed... for at least 3 Sprints.” - Christian Schmidkonz, SAP. “ ‘Doing Scrum’ is as meaningless (and impossible) as creating an instance of an abstract class.” - Tobias Mayer
  32. 32. Shooting the Scrum messenger “We use Scrum but… we don’t like it because it makes life more difficult.” m S cru
  33. 33. Shooting the Scrum messenger “We use Scrum but… we don’t like it because it makes life more difficult.” • Is Scrum surfacing existing issues? m S cru
  34. 34. Shooting the Scrum messenger “We use Scrum but… we don’t like it because it makes life more difficult.” • Is Scrum surfacing existing issues? • Are people speaking out early? m S cru
  35. 35. Shooting the Scrum messenger “We use Scrum but… we don’t like it because it makes life more difficult.” • Is Scrum surfacing existing issues? • Are people speaking out early? m S cru “Bad news doesn’t get any better with age!”
  36. 36. “Scrum is a mirror.” - Alistair Cockburn
  37. 37. “Scrum is a mirror.” - Alistair Cockburn Try: Looking into the Scrum mirror
  38. 38. “Scrum is a mirror.” - Alistair Cockburn Try: Looking into the Scrum mirror
  39. 39. “We use Scrum but… we're still not confident about our plan after two days of Sprint planning!
  40. 40. Avoid: Planning Paralysis “We use Scrum but… we're still not confident about our plan after two days of Sprint planning!
  41. 41. Avoid: Planning Paralysis “We use Scrum but… we're still not confident about our plan after two days of Sprint planning! Try: Doing your homework on the backlog
  42. 42. Avoid: Planning Paralysis “We use Scrum but… we're still not confident about our plan after two days of Sprint planning! Try: Doing your homework on the backlog • Grooming the Product Backlog • Regular estimation sessions • Getting Stories to a state of ‘Ready’ • 5-10% of effort preparing future work
  43. 43. Avoid: Mis-aligned Stories
  44. 44. Avoid: Mis-aligned Stories e.g. Building screens rather than workflows
  45. 45. Try: Sashimi slicing by value
  46. 46. Try: Sashimi slicing by value Try: • Slicing by business value • Being user task-centric • Going end-to-end through technology stack
  47. 47. Avoid: Command and control- style micro-management “We use Scrum but… a manager keeps telling team members which tasks to do when!”
  48. 48. Avoid: Command and control- style micro-management “We use Scrum but… a manager keeps telling team members which tasks to do when!” Q: Does Scrum involve micro-management?
  49. 49. Avoid: Command and control- style micro-management “We use Scrum but… a manager keeps telling team members which tasks to do when!” Q: Does Scrum involve micro-management? A: Yes!
  50. 50. Avoid: Command and control- style micro-management “We use Scrum but… a manager keeps telling team members which tasks to do when!” Q: Does Scrum involve micro-management? A: Yes! Q: Who is doing the micro-management?
  51. 51. Avoid: Command and control- style micro-management “We use Scrum but… a manager keeps telling team members which tasks to do when!” Q: Does Scrum involve micro-management? A: Yes! Q: Who is doing the micro-management? Thanks to: Mike Cohn
  52. 52. Avoid: Command and control- style micro-management “We use Scrum but… a manager keeps telling team members which tasks to do when!” Q: Does Scrum involve micro-management? A: Yes! Q: Who is doing the micro-management? Thanks to: Mike Cohn Is your team empowered?
  53. 53. Try: Allowing the team to self-manage within a time-box
  54. 54. Try: Allowing the team to self-manage within a time-box Do: • Let go! • Emphasise goals • Offer to help • Facilitate learning
  55. 55. Try: Allowing the team to self-manage within a time-box Do: • Let go! • Emphasise goals • Offer to help • Facilitate learning “Never tell people how to do things. Tell them what to do, and they will surprise you with their ingenuity.” - General George S. Patton, Jr.
  56. 56. Individual Heroics Individual heroics
  57. 57. Individual Heroics Individual heroics “We use Scrum but… individuals hoard work and boast about it!”
  58. 58. Try: Team-centric reviews and incentives
  59. 59. Try: Team-centric reviews and incentives
  60. 60. Try: Team-centric reviews and incentives
  61. 61. Try: Team-centric reviews and incentives Try: • Emphasising team achievement • Dampening individual heroics • Teamwork-biased incentives
  62. 62. Smoke and mirror demos “Transparency ensures that aspects of the process that affect the outcome must be visible to those managing the outcomes. ...when someone inspecting a process believes that something is done; it must be equivalent to their definition of done.” - Ken Schwaber, The Scrum Guide you see isn’t quite done.
  63. 63. Smoke and mirror demos “Transparency ensures that aspects of the process that affect the outcome must be visible to those managing the outcomes. ...when someone inspecting a process believes that something is done; it must be equivalent to their definition of done.” - Ken Schwaber, The Scrum Guide We use Scrum but... what you see isn’t quite done.
  64. 64. What you can’t see...
  65. 65. What you can’t see...
  66. 66. What you can’t see... Try: Not demoing features that aren’t truly “done”
  67. 67. Avoid: Lack of risk management
  68. 68. Avoid: Lack of risk management Requirements Integrate & Design Code Analysis System Test First build and deliver Potential Impact of Highest risk activities such as Risks being integration, system testing, tackled load testing are tackled late Time
  69. 69. Avoid: Lack of risk management Requirements Integrate & Design Code Analysis System Test First build and deliver Potential Impact of Highest risk activities such as Risks being integration, system testing, tackled load testing are tackled late Time First build and deliver Iterations All activities are tackled early Potential Integrate & Integrate & Integrate & Integrate & Integrate & Impact of System Test System Test System Test System Test System Test Risks being Code Code Code Code Code tackled Design Design Design Design Design Analysis Analysis Analysis Analysis Analysis Time Source: Craig Larman, Agile & Iterative Development, 2004.
  70. 70. Scrum risk reduction strategies Source: Schwaber, K., Beedle, M., Agile Software Development with Scrum, Prentice Hall, 2001.
  71. 71. Scrum risk reduction strategies Risk of... Scrum Strategy Not pleasing the customer Customer sees product constantly. Customer on-site. Not completing all functionality Develop in priority order. Poor estimating and planning Small estimates tracked daily. Review and adjustment every iteration. Not resolving issues properly Active daily management. Bi-directional reporting. Not being able to complete Delivery of working software every the development cycle iteration. Team forced to confront issues early. Taking too much work and Clear goal and scope each iteration. changing expectations No change within iterations. Source: Schwaber, K., Beedle, M., Agile Software Development with Scrum, Prentice Hall, 2001.
  72. 72. Scrum risk reduction strategies Risk of... Scrum Strategy Not pleasing the customer Customer sees product constantly. Customer on-site. Not completing all functionality Develop in priority order. Poor estimating and planning Small estimates tracked daily. Review and adjustment every iteration. Not resolving issues properly Active daily management. Bi-directional reporting. Not being able to complete Delivery of working software every the development cycle iteration. Team forced to confront issues early. Taking too much work and Clear goal and scope each iteration. changing expectations No change within iterations. Source: Schwaber, K., Beedle, M., Agile Software Development with Scrum, Prentice Hall, 2001.
  73. 73. Scrum risk reduction strategies Risk of... Scrum Strategy Not pleasing the customer Customer sees product constantly. Customer on-site. Not completing all functionality Develop in priority order. Poor estimating and planning Small estimates tracked daily. Review and adjustment every iteration. Not resolving issues properly Active daily management. Bi-directional reporting. Not being able to complete Delivery of working software every the development cycle iteration. Team forced to confront issues early. Taking too much work and Clear goal and scope each iteration. changing expectations No change within iterations. Source: Schwaber, K., Beedle, M., Agile Software Development with Scrum, Prentice Hall, 2001.
  74. 74. Scrum risk reduction strategies Risk of... Scrum Strategy Not pleasing the customer Customer sees product constantly. Customer on-site. Not completing all functionality Develop in priority order. Poor estimating and planning Small estimates tracked daily. Review and adjustment every iteration. Not resolving issues properly Active daily management. Bi-directional reporting. Not being able to complete Delivery of working software every the development cycle iteration. Team forced to confront issues early. Taking too much work and Clear goal and scope each iteration. changing expectations No change within iterations. Source: Schwaber, K., Beedle, M., Agile Software Development with Scrum, Prentice Hall, 2001.
  75. 75. Scrum risk reduction strategies Risk of... Scrum Strategy Not pleasing the customer Customer sees product constantly. Customer on-site. Not completing all functionality Develop in priority order. Poor estimating and planning Small estimates tracked daily. Review and adjustment every iteration. Not resolving issues properly Active daily management. Bi-directional reporting. Not being able to complete Delivery of working software every the development cycle iteration. Team forced to confront issues early. Taking too much work and Clear goal and scope each iteration. changing expectations No change within iterations. Source: Schwaber, K., Beedle, M., Agile Software Development with Scrum, Prentice Hall, 2001.
  76. 76. Scrum risk reduction strategies Risk of... Scrum Strategy Not pleasing the customer Customer sees product constantly. Customer on-site. Not completing all functionality Develop in priority order. Poor estimating and planning Small estimates tracked daily. Review and adjustment every iteration. Not resolving issues properly Active daily management. Bi-directional reporting. Not being able to complete Delivery of working software every the development cycle iteration. Team forced to confront issues early. Taking too much work and Clear goal and scope each iteration. changing expectations No change within iterations. Source: Schwaber, K., Beedle, M., Agile Software Development with Scrum, Prentice Hall, 2001.
  77. 77. Scrum risk reduction strategies Risk of... Scrum Strategy Not pleasing the customer Customer sees product constantly. Customer on-site. Not completing all functionality Develop in priority order. Poor estimating and planning Small estimates tracked daily. Review and adjustment every iteration. Not resolving issues properly Active daily management. Bi-directional reporting. Not being able to complete Delivery of working software every the development cycle iteration. Team forced to confront issues early. Taking too much work and Clear goal and scope each iteration. changing expectations No change within iterations. Source: Schwaber, K., Beedle, M., Agile Software Development with Scrum, Prentice Hall, 2001.
  78. 78. Scrum risk reduction strategies Risk of... Scrum Strategy Not pleasing the customer Customer sees product constantly. Customer on-site. Not completing all functionality Develop in priority order. Poor estimating and planning Small estimates tracked daily. Review and adjustment every iteration. Not resolving issues properly Active daily management. Bi-directional reporting. Not being able to complete Delivery of working software every the development cycle iteration. Team forced to confront issues early. Taking too much work and Clear goal and scope each iteration. changing expectations No change within iterations. Source: Schwaber, K., Beedle, M., Agile Software Development with Scrum, Prentice Hall, 2001. Is it sufficient to rely solely on these built-in strategies?
  79. 79. Try: Creating a safe-fail environment
  80. 80. Try: Creating a safe-fail environment • Time-boxing
  81. 81. Try: Creating a safe-fail environment • Time-boxing • Areas of risk/ uncertainty early in release cycles
  82. 82. Try: Creating a safe-fail environment • Time-boxing • Areas of risk/ uncertainty early in release cycles • Prioritisation bias towards areas of risk
  83. 83. Try: Creating a safe-fail environment • Time-boxing • Areas of risk/ uncertainty early in release cycles • Prioritisation bias towards areas of risk • Spikes to reduce uncertainty
  84. 84. Try: Creating a safe-fail environment • Time-boxing • Areas of risk/ uncertainty early in release cycles • Prioritisation bias towards areas of risk • Spikes to reduce uncertainty • Last Responsible Moment planning
  85. 85. Try: Creating a safe-fail environment • Time-boxing • Areas of risk/ uncertainty early in release cycles • Prioritisation bias towards areas of risk • Spikes to reduce uncertainty • Last Responsible Moment planning • Learn quickly
  86. 86. Try: Collaborative risk management Risks Strategy Mitigating Containing Evading Avoiding Thanks to: Slinger, M., Broderick, S., The Software Project Manager’s Bridge to Agility, Addison Wesley, 2008.
  87. 87. Try: Collaborative risk management Risks Strategy Mitigating Containing Evading Avoiding take steps before the risk materialises to reduce the containment costs e.g. move feature to an earlier sprint Thanks to: Slinger, M., Broderick, S., The Software Project Manager’s Bridge to Agility, Addison Wesley, 2008.
  88. 88. Try: Collaborative risk management set aside time and money to pay for the risk should it materialise Risks Strategy e.g. plan for training on new tools Mitigating Containing Evading Avoiding take steps before the risk materialises to reduce the containment costs e.g. move feature to an earlier sprint Thanks to: Slinger, M., Broderick, S., The Software Project Manager’s Bridge to Agility, Addison Wesley, 2008.
  89. 89. Try: Collaborative risk management set aside time and money to pay for the risk should it materialise Risks Strategy e.g. plan for training on new tools Mitigating Containing bet on the risk not Evading materialising e.g. accepting not having a dedicated team Avoiding take steps before the risk materialises to reduce the containment costs e.g. move feature to an earlier sprint Thanks to: Slinger, M., Broderick, S., The Software Project Manager’s Bridge to Agility, Addison Wesley, 2008.
  90. 90. Try: Collaborative risk management set aside time and money to pay for the risk should it materialise Risks Strategy e.g. plan for training on new tools Mitigating Containing bet on the risk not Evading materialising e.g. accepting not having a dedicated team Avoiding take steps before the risk materialises don’t do part of the to reduce the containment costs e.g. project that entails the risk move feature to an earlier sprint e.g. avoid platform upgrade Thanks to: Slinger, M., Broderick, S., The Software Project Manager’s Bridge to Agility, Addison Wesley, 2008.
  91. 91. Avoid: The vicious cycle of overcommitment “We use Scrum but… we don't have time for bug fixing or process improvement because we have too many new features to
  92. 92. Try: Snapping out of overcommitment! Raise visibility, get buy-in, create a sense of urgency, action!
  93. 93. Stalled improvement “We use Scrum but… we've still got the same issues that we had a few sprints ago! ”
  94. 94. Stalled improvement “We use Scrum but… we've still got the same issues that we had a few sprints ago! ” Are you suffering from the ‘three meeting syndrome’?
  95. 95. Stalled improvement “We use Scrum but… we've still got the same issues that we had a few sprints ago! ” Are you suffering from the ‘three meeting syndrome’? Avoid: Superficial 15min retrospectives only
  96. 96. Try: Deep reflection & correction
  97. 97. Try: Deep reflection & correction
  98. 98. Try: Deep reflection & correction Keep Problem Try Puzzles
  99. 99. Try: Deep reflection & correction Keep Problem Try Puzzles 1. Set the stage 2. Gather data 3. Generate insights 4. Decide what to do 5. Close the retrospective Reference: Derby E., Larsen D., Agile Retrospectives: Making Good Teams Great, Pragmatic Bookshelf, 2006.
  100. 100. In Summary... let’s not dilute Scrum
  101. 101. In Summary... let’s not dilute Scrum
  102. 102. In Summary... let’s not dilute Scrum “Agile development is like teenage sex.
  103. 103. In Summary... let’s not dilute Scrum “Agile development is like teenage sex. Everyone says they're doing it, but only 10% are.
  104. 104. In Summary... let’s not dilute Scrum “Agile development is like teenage sex. Everyone says they're doing it, but only 10% are. And those who are -- ARE DOING IT WRONG.”
  105. 105. In Summary... let’s not dilute Scrum “Agile development is like teenage sex. Everyone says they're doing it, but only 10% are. And those who are -- ARE DOING IT WRONG.” - The Hacker Chick Blog
  106. 106. Remember...
  107. 107. Remember... “If you’re not having fun, you’re not doing it right!” - Joseph Pelrine, CST and Social Complexity Scientist
  108. 108. Your moment of Scrum Zen
  109. 109. Your moment of Scrum Zen Work towards:
  110. 110. Your moment of Scrum Zen Work towards: • High performance teams
  111. 111. Your moment of Scrum Zen Work towards: • High performance teams • Harmony with your environment and its challenges
  112. 112. Your moment of Scrum Zen Work towards: • High performance teams • Harmony with your environment and its challenges • Your ‘fitness peak’
  113. 113. Try...
  114. 114. Try... ✓ Targetting process improvement goals + discussing Scrum values, principles and what these mean ✓ Applying before inspecting and adapting ✓ Looking into the Scrum mirror ✓ Doing your homework on the backlog ✓ Sashimi slicing by business value ✓ Allowing the team to self-manage within a time-box ✓ Team-centric reviews and incentives ✓ Not demoing features that aren’t truly “done” ✓ Collaborative risk management ✓ Snapping out of overcommitment! ✓ Deep reflection and correction
  115. 115. I’m Rowan Bunning www.softwarewithstyle.com Rowan.Bunning@softwarewithstyle.com
  116. 116. I’m Thank you keep in touch Rowan Bunning www.softwarewithstyle.com Rowan.Bunning@softwarewithstyle.com

×