Q. What’s something everybody does, but nobody does the
same? A. Scrum!
In today's post we'll debate this
question: Is it important to fully adopt Scrum as a software methodology, or is
it sufficient to just use the parts that seem useful?
I’ve wanted to write something on
this subject for years now, but I’ve hesitated given how explosively charged
Internet debates on software methodologies can be. Let me state at the onset
that I am neither a Scrum Worshipper nor a Scrum Hater: I wrote quality
software before Agile existed and now I write quality software using Scrum. I
value what we have gained with Agile methodologies, but I also bemoan what
they've cost us.
ScrumBut: We Do Scrum, But Not All Of It
Without question, Agile Scrum has taken over as the software methodology of choice, just as Github has taken over as the software repository of choice. Scrum's pervasiveness ought to mean that when a developer who knows Scrum joins a software organization using Scrum they can hit the ground running. In my experience that's hardly ever true, and one of the common reasons is the lack of consistency in how teams apply Scrum.
Over the last 12 years I've consulted with and worked with lots of teams that practice Agile Scrum. That includes 5 years as a national consulting practice manager, so I've had exposure to a great many customer projects beyond the ones I contribute to personally. When the customer controlled the process, the majority of those teams didn't really follow Scrum, they practiced ScrumBut: as in "We do Scrum, but not all of it." Do some online research and you'll find plenty of others reporting the same; ScrumBut is a well-recognized phenomenon.
Over the last 12 years I've consulted with and worked with lots of teams that practice Agile Scrum. That includes 5 years as a national consulting practice manager, so I've had exposure to a great many customer projects beyond the ones I contribute to personally. When the customer controlled the process, the majority of those teams didn't really follow Scrum, they practiced ScrumBut: as in "We do Scrum, but not all of it." Do some online research and you'll find plenty of others reporting the same; ScrumBut is a well-recognized phenomenon.
Here are some of the things I’ve personally
seen teams drop from their practice of “Scrum”:
- We do Scrum, but we don’t do sprint reviews
- We do Scrum, but we don’t do sprint planning meetings
- We do Scrum, but we don’t do the daily stand-up meetings
- We do Scrum, but we don’t have a product owner
- We do Scrum, but we don’t have a scrum master
- We do Scrum, but we don’t have a product backlog
- We do Scrum, but the product owner assigns work to team members
Some of you reading this are Scrum
champions who only work with teams that rigorously enforce Scrum and are shaking your heads. Perhaps it’s
your job to see that Scrum is followed well. That’s great, but I assure you such teams are the minority. Understanding why and whether it's always a negative is important.
Why does ScrumBut happen? After all,
Scrum is a lightweight methodology.
It doesn’t ask much. It only has a few roles, artifacts, and ceremonies. I’ve
identified four reasons:
- Human nature. If you’ve ever listened to a debate over a political issue or a point of religion, you’re well aware that even people who share common values can disagree endlessly on the finer points. Not everyone is going to weigh things the same way.
- Software is a vast realm. There are many kinds of software and many kinds of developer, with a wide range of skills, maturity, and experience. Developing a web site is way different from creating a video platform or working on an operating system. Expecting one methodology to work equally well across that spectrum is rather optimistic.
- Agile itself is partly to blame because its underlying message is often misinterpreted as “you don’t have to do everything”. It seems the effect of Agile trimming away practices deemed to be of secondary importance may have encouraged people to just keep doing away with things.
- Distrust. Older generations are more likely to place implicit trust in a system and give it a chance, but the younger generation is less persuaded.
Let's consider the case for doing
full scrum (following the methodology) and the case for doing only some of it
(buffet-style) with an honest attempt to be open-minded about the question.
All or Nothing: The Case for Full Scrum
I'll fully admit my own inclination
is to use full Scrum. The line of reasoning here
is that Scrum is a methodology: that is, a system whose various
elements are designed to support and complement each other. When you don't
apply all of the parts, you're removing legs from the chair that holds you up.
Dismantling parts of a system undermines the system. Will it still work? Maybe, but not as well as when it's complete.
Imagine you have a friend with an
alcohol problem and you bring them to an AA meeting. Here’s what you would not
hear: “We have a very successful 12-step
program; which steps do you feel are right for you?” Of course that
wouldn’t happen: the program is only effective if it’s taken as a whole, with
all steps being done in the intended order. We recognize that it’s a system. There’s
a second point to be made here: the person with the alcohol problem is not an
expert on how to recover and is hardly in a position to design their own
treatment. In the same way, a software methodology should be viewed as a system
to be adhered to.
It needs to be acknowledged that
even among those who do full scrum there are differences between how it is
practiced. Some organizations overdo Scrum, becoming what is sometimes referred
to as a Church of Agile. We should always keep in mind that the team
does not serve the methodology: rather, the methodology serves the team.
Like anything else popular in the computer world, Scrum is also subject to the
hype cycle which accessorizes the methodology with inflated services,
certifications, self-important titles, expensive software packages, condescending
attitudes, and a sometimes crazy obsession with points and charts. In The State of Agile Software in 2018, Martin Fowler calls this the Agile Industrial Complex and calls for its dissolution. Full Scrum
can be over the top if it is obsessed over and becomes the objective rather
than the means.
If doing full Scrum is critical to
project success, there ought to be some clear evidence that full Scrum tends to
work and partial Scrum tends to fail. While I’ve encountered plenty of Scrum
champions with that opinion based on
their own experiences, I’ve yet to discover objective results that conclusively
support this conviction. For all the personal examples you or I could cite,
that’s not statistically meaningful. If I reflect on my own experiences, yes
I’ve seen software projects fail where oftentimes a lack of discipline
(including a poor understanding of Scrum) is an ingredient; on the other hand,
I’ve seen projects succeed where ScrumBut was applied.
Why Is It Useful? The Case for ScrumBut
Partial Scrum is far more common than Full Scrum by every measure I can make. I’ve noticed ScrumBut teams fall into two distinct
categories: those who don’t know any better, and those who consciously choose
partial Scrum. I’ll call them the Naive Scrumbutters and the Intentional
Scrumbutters.
Naive Scrumbutters
The Naive Scrumbutters are those who
don’t know any better. A great many teams and organizations will proudly tell
you they are practicing Scrum, and in their minds they are. Sadly, they suffer
from a superficial understanding of Scrum. We're holding a daily Scrum
meeting, therefore we're doing Scrum.
Scrum naivete is rampant. I’ve seen
these kinds of activities go on regularly which indicate a poor command of
Scrum principles:
- Sprint planning is where the executive tells the team what they will work on that sprint
- The sprint has started but the stories aren’t ready yet
- The product owner decides in advance who will work on what
- We have to get all of this work done this sprint because that’s the deadline
- Software written this sprint isn’t tested until a later sprint
- We can’t wait for the end of sprint, we need to release software sooner
Naive Scrumbutters are the ones likely to have many project problems. They’ve removed too many of Scrum’s underpinnings, and they don’t even know it.
Intentional Scrumbutters
The other group, Intentional
Scrumbutters, knows full well what Scrum entails, but have decided to leave out
some of its precepts. This approach views Scrum more as a list of potentially
useful practices rather than as a system whose parts reinforce each other. They
treat Scrum like a buffet, taking only the items they like. Reasons given by
organizations for skipping some elements of Scrum include the following:
- Someone in control of the process
thinks they know better.
I’ve seen [what we do here] work time and time again. Trust me.
- Someone in control of the process
doesn’t see value in some of its elements.
Our roadmap for the rest of the year is already defined. We don’t need a Product Owner.
- Team members don’t see value in some
of its elements.
Why is a sprint review meeting useful? I don’t think it’s a good use of my time.
- There are difficulties carrying out
some of the elements.
Everyone here has freedom of schedule, and some of the team live in other states or countries. There’s no way to realistically schedule a daily stand-up meeting.
- Skepticism
There’s no point in having a sprint retrospective, because nothing is ever going to change around here.
“Why is this useful?” is a question
I am often asked by younger developers when I ask them to start doing Scrum
ceremonies they are not used to—even about Sprint Planning and Sprint Review
meetings. Well, that’s always a fair question to ask, but it reveals something
about the person doing the asking; clearly they do not put trust in the system
they’re being asked to follow. Perhaps they will after they’ve seen it work.
While many Intentional Scrumbutters
are clearly making questionable decisions when they tinker with Scrum, it’s not always the
case. I’ve seen Silicon Valley tech companies practice ScrumBut with
spectacularly successful results, consistently producing quality software over
and over. However, I believe these are the exceptions rather than the rule. These companies have very experienced engineering
leadership and capable and committed developers across the board, and
I suspect the omissions from Scrum are compensated for by other
engineering practices. This article is worth a
read: Why Scrumbut Shouldn't Be a Bad Word.
SlimScrum: An Alternative to ScrumBut
As we’ve seen, ScrumBut happens a
lot. For a variety of reasons, some of them valid, organizations sometimes
jettison elements of Scrum. This results in ScrumBut, which is dangerous
because now the system is incomplete.
What can you do if you are part of
such an organization and would like to practice full Scrum? Depending on your
position and situation, you may or may not have the standing to make changes. If
you can’t authorize outright changes, there is an alternative to ScrumBut which
I call SlimScrum.
SlimScrum means you find a way to include
all the roles, artifacts, and ceremonies of Scrum—but are willing to be
flexible in how they are implemented. To my thinking, having all the
elements of Scrum (even if reinterpreted somewhat) is far preferable to leaving
some of them out altogether. Let's consider a few examples.
If it’s truly impractical to get
everyone together for that short daily stand-up meeting, consider using Slack
or an equivalent enterprise social network. In fact, I find it so useful for
team members to list what they worked on
yesterday / plan to work on today / blocks on Slack that I like to have it
even when teams do have a daily stand-up meeting.
If long meeting times are given as a
reason to not do full Scrum, consider how long sprint planning and sprint
review meetings really need to be. Do you need a 4-hour sprint retrospective
meeting if no one thinks anything needs to be discussed? I am not suggesting
arbitrarily shortening these meetings, but I think there is room to adjust them
based on how your team engages and whether anything useful is being
accomplished.
Missing Scrum roles is perhaps the
toughest omission to deal with. How do you make up for not having a product
owner? If you’re unable to fix that problem in the organization but your
immediate team is onboard with trying to solve it, have someone in sprint
planning and sprint review meetings assume
the role of product owner. Using a proxy can work if that person can reach
out to stakeholders between meetings to stay informed. It’s not ideal, but it’s
better than being directionless. You can do the same with the scrum master role.
In Conclusion
Scrum consistency is a widespread
problem: you run into ScrumBut all over the place. We’ve identified some of the
reasons for it, and looked at both the naive and intentional Scrumbutters. Naive Scrumbutters need to be educated about what Scrum actually is. Intentional Scrumbutters are advised to consider what they might be missing. Even if tinkering with Scrum works for you, it still puts a barrier in place for new hires trained in Scrum which is inefficient.
I urge teams to treat Scrum (or any methodology) as a system to be followed completely, not a buffet where you only take what you like. You’ll get a lot more out of the system if you give it a chance to work for you.
I urge teams to treat Scrum (or any methodology) as a system to be followed completely, not a buffet where you only take what you like. You’ll get a lot more out of the system if you give it a chance to work for you.