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.

1. ic k me
K
Kicking
ScrumBut
Rowan Bunning
Certified Scrum Trainer
Software WithStyle

4. There are pitfalls on the journey

5. There are pitfalls on the journey
How can we help each other to avoid them?

6. 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.

7. 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?

8. Some ScrumButs to avoid...

9. 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

10. Avoid: Goalless Scrum
“We use Scrum but... only because [insert latest fad].”
Is your Scrum implementation goalless?

11. Avoid: Goalless Scrum
“We use Scrum but... only because [insert latest fad].”
Is your Scrum implementation goalless?

12. Avoid: Goalless Scrum
“We use Scrum but... only because [insert latest fad].”
Is your Scrum implementation goalless?
• Why are you using Scrum?

13. 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?

14. 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?

15. Try: Targeting process
improvement goals

16. Try: Targeting process
improvement goals

17. Try: Targeting process
improvement goals
• Consider using Scrum to
govern the introduction of
Scrum

18. Avoid: Soulless Scrum
Is your Scrum implementation soulless?

19. Avoid: Soulless Scrum
Is your Scrum implementation soulless?
• Are you just practicing Scrum by rote?

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?

21. 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?

22. 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

23. Avoid: Cherry-picking practices
“We use Scrum but... only the
practices that are most appealing”

24. Agile methods as systems

25. Agile methods as systems
“No single practice works well by itself, each needs the other
practices to keep them in balance.”

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.”

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

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

29. 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.

30. 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

32. Try: applying before
inspecting and adapting

33. Try: applying before
inspecting and adapting
“[Apply] Scrum as proposed... for at least 3 Sprints.”
- Christian Schmidkonz, SAP.

34. 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

35. Shooting the Scrum messenger
“We use Scrum but… we
don’t like it because it
makes life more difficult.”
m
S cru

36. 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

37. 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

38. 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!”

40. “Scrum is a mirror.”
- Alistair Cockburn

41. “Scrum is a mirror.”
- Alistair Cockburn
Try: Looking into the Scrum mirror

42. “Scrum is a mirror.”
- Alistair Cockburn
Try: Looking into the Scrum mirror

43. “We use Scrum but… we're still
not confident about our plan
after two days of Sprint planning!

44. Avoid: Planning Paralysis
“We use Scrum but… we're still
not confident about our plan
after two days of Sprint planning!

45. 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

46. 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

47. Avoid: Mis-aligned Stories

48. Avoid: Mis-aligned Stories
e.g. Building screens
rather than workflows

49. Try: Sashimi slicing by value

50. Try: Sashimi slicing by value
Try: • Slicing by business value
• Being user task-centric
• Going end-to-end
through technology stack

51. Avoid: Command and control-
style micro-management
“We use Scrum but… a manager
keeps telling team members
which tasks to do when!”

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?

53. 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!

54. 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?

55. 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

56. 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?

58. Try: Allowing the team to
self-manage within a
time-box

59. Try: Allowing the team to
self-manage within a
time-box
Do: • Let go!
• Emphasise goals
• Offer to help
• Facilitate learning

60. 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.

61. Individual Heroics
Individual heroics

62. Individual Heroics
Individual heroics
“We use Scrum but… individuals hoard work and
boast about it!”

64. Try: Team-centric reviews and
incentives

65. Try: Team-centric reviews and
incentives

66. Try: Team-centric reviews and
incentives

67. Try: Team-centric reviews and
incentives
Try:
• Emphasising team achievement
• Dampening individual heroics
• Teamwork-biased incentives

68. 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.

69. 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.

71. What you can’t see...

72. What you can’t see...

73. What you can’t see...
Try: Not demoing features that aren’t truly “done”

74. Avoid: Lack of risk management

75. 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

76. 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.

77. Scrum risk reduction strategies
Source: Schwaber, K., Beedle, M., Agile Software Development with Scrum, Prentice Hall, 2001.

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.

79. 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.

80. 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.

81. 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.

82. 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.

83. 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.

84. 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.

85. 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?

86. Try: Creating a safe-fail environment

87. Try: Creating a safe-fail environment
• Time-boxing

88. Try: Creating a safe-fail environment
• Time-boxing
• Areas of risk/
uncertainty early in
release cycles

89. Try: Creating a safe-fail environment
• Time-boxing
• Areas of risk/
uncertainty early in
release cycles
• Prioritisation bias
towards areas of risk

90. 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

91. 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

92. 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

93. 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.

94. 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.

95. 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.

96. 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.

97. 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.

98. 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

99. Try: Snapping out of overcommitment!
Raise visibility, get buy-in, create a sense of urgency, action!

100. Stalled improvement
“We use Scrum but… we've still
got the same issues that we had
a few sprints ago! ”

101. 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’?

102. 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

104. Try: Deep reflection & correction

105. Try: Deep reflection & correction

106. Try: Deep reflection & correction
Keep Problem Try
Puzzles

107. 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.

110. In Summary... let’s not dilute Scrum

111. In Summary... let’s not dilute Scrum

112. In Summary... let’s not dilute Scrum
“Agile development is like teenage sex.

113. In Summary... let’s not dilute Scrum
“Agile development is like teenage sex.
Everyone says they're doing it, but only 10% are.

114. 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.”

115. 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

116. Remember...

117. Remember...
“If you’re not having fun, you’re not doing it right!”
- Joseph Pelrine, CST and Social Complexity Scientist

118. Your moment of Scrum Zen

119. Your moment of Scrum Zen
Work towards:

120. Your moment of Scrum Zen
Work towards:
• High performance teams

121. Your moment of Scrum Zen
Work towards:
• High performance teams
• Harmony with your environment and its challenges

122. Your moment of Scrum Zen
Work towards:
• High performance teams
• Harmony with your environment and its challenges
• Your ‘fitness peak’

123. Try...

124. 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

125. I’m
Rowan Bunning
www.softwarewithstyle.com
Rowan.Bunning@softwarewithstyle.com

126. I’m
Thank you
keep in touch
Rowan Bunning
www.softwarewithstyle.com
Rowan.Bunning@softwarewithstyle.com