The term "scrumbut" could mean:
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?”
ScrumButs are reasons why teams can’t take full advantage of Scrum to solve the problems and realize the benefits.
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.
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.
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.