Ignite di Fabio Armani in occasione del Codemotion, 5 marzo 2011: http://www.codemotion.it

1. ScrumButs » but Scrum
Which is worse?

2. scrumbut [skruhmbut] noun
1. A person engaged in only partially Agile project
management or development methodologies
2. One who engages in either semi-agile or quasi-waterfall
development methodologies.
3. One who adopts only some tenents of the Scrum
methodology.
4. In general, one who uses the word “but” when answering
the question “Do you do Scrum?”

3. ScrumButs
 ScrumButs are reasons why teams can’t take full advantage
of Scrum to solve the problems and realize the benefits.
 Every Scrum role, rule, and timebox is designed to provide
the desired benefits and address the problems.
 ScrumButs mean that Scrum has exposed a dysfunction that
is contributing to the problem, but is too hard to fix.
 A ScrumBut retains the problem while modifying Scrum to
make it invisible so that the dysfunction is no longer a thorn
in the side of the team.

4. ScrumBut ≡
Quick Fixes
The problem arise when we try to
use quick fixes to adjust the
process.

5. ScrumBut syntax
 A ScrumBut has a particular syntax:
(ScrumBut) (Reason) (Workaround)
 Example: “(We use Scrum, but) (the daily Scrum meetings
are too much overhead) (so we only have them once a week,
unless we need them more often)”

6. "We're doing Scrum but..."
 our sprints are 6-8 weeks long ...
 we do two normal sprints and one bugfix sprint ...
 we do all our planning up front ...
 we skip the daily meeting ...
 our managers decide what's in each sprint ...
 we haven't read the books yet ...
 our team has 30 people ...

7. Some ScrumButs to avoid …
 Goalless, soulless Scrum
 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

8. ScrumButs can come from many sources
 The business doesn’t want to be involved
 Everyone wants their features first and can’t agree on a
priority
 Teams don’t know how to self-organize
 People aren’t available to work on teams full-time
 Timeboxes aren't adhered to
 Teams don’t see a need for a daily Scrum
 Teams can’t get a piece of functionality done in one Sprint
 Teams don’t have the skills to “do” something

9. ScrumButs can come from many sources
 Teams can’t fit testing into the same Sprint as development
 The Scrum Master tells the team what to do and how to do it
 Other managers can’t stay out of a Sprint
 Important things come up that require interrupting the Sprint
 The Sprints can’t start until all of the other groups do their up-
front work
 Other groups are building hardware or using waterfall
 have them once a week, unless we need them more often)”

10. Scrum changes
 Sometimes organizations make short term changes to Scrum
to give them time to correct deficiencies.
 For example, "done" may not initially include regression and
performance testing because it will take several months to
develop automated testing.
 For these months, transparency is compromised, but
restored as quickly as possible.

11. But Scrum …
 Yes, these are bad situations. But let's look at the flipside -
let's look at 'But Scrum.'
 'But Scrum' is when a person/team/organization flips off their
'thinking bit' and just burps up whatever Scrum tells them to
do.
 Want some examples?

12. Scrum Zombies …
Yesterday I zoodled Yesterday I zoodled
Today I’ll zoodlle
Today I’ll zoodlle No problem
No problem
Yesterday I zoodled
Today I’ll zoodlle
No problem

13. But Scrum says we estimate
 I have personally been around agile teams that don't
estimate all of their items in their backlog. Why? Multitudes
of reasons.
 A couple of examples:
 Teams break down their work far enough (day range) where the
variance in the estimates would be minuscule.
 A team works really well together and can accurately predict how
much they can get done, without worrying about points

14. But Scrum says we need self-
organizing teams
 Yep, self-organizing teams would be awesome. There is a
magic dashboard of work on the wall and people will just
naturally float over and create uber teams to crush out work.
 Most large organizations are still structured in classical,
matrixed manner. Telling their IT departments to 'self-
organize' is irresponsible.
 Most people multi-task. Is it a problem? Sure. Is it a reality?
 You betcha. Specialization is an output from our national
hiring structure - just look at any job boards for
confirmation. Good luck changing that inertia.

15. But Scrum says we need a
ScrumMaster
 By no means do I have hard numbers to back this up, but
look at it this way: If Scrum masters were making agile
software development and delivery so much better, then
given the rate of CSMs being handed out, we should have
some bad bamma jamma software coming out from the
majority of organizations.
 But we don't. I'm not even going to get into the whole
certification battle. Little known fact - Patrick Duffy is a Scrum
Master.

16. But Scrum says once we commit, the
backlog doesn't change
 By no means do I have hard numbers to back this up, but
look at it this way: If Scrum masters were making agile
software development and delivery so much better, then
given the rate of CSMs being handed out, we should have
some bad bamma jamma software coming out from the
majority of organizations.
 But we don't. I'm not even going to get into the whole
certification battle. Little known fact - Patrick Duffy is a Scrum
Master.

17. But Scrum says once we commit, the
backlog doesn't change
 Right, because market events and competition only happen
in nice, predictable cycles

18. But Scrum says our teams should be 7,
+- 2
 There are plenty of Scrum development teams out there
working well with a size over 10 as well as split
geographically.
 A team that works well together is a team that works well
together.

19. Which is worse ?
 Which is worse - 'Scrum but' or 'But Scrum'? They are both
horrible. One is giving excuses why you can't try and change;
the other is giving excuses why you can't change what you
are trying. Both are pointless..

20. Final thoughts
 The reality is developing a software product is hard.
 It requires thought, inspection, change, and risk.
 You have to think.