Everyone is doing Scrum. Or are they? If you’re just practicing sprints and dailies and have no idea why, then you might have a good old case of the ScrumButs. Here are 4 symptoms to recognize the malaise, and how you could get back on the road to being healthy and Agile.
Many years ago, when I was still freelancing, a customer asked me to be a part of his Scrum project. I wasn’t familiar with it yet. Suddenly, I was participating in morning standups, reporting out what I had done yesterday, what I would do today, and if I had any blockers. My name was on the board with other stories in the to-do column. We had sprints, dailies, and occasional planning and retros. Everything was facilitated by the team leader.
My next customers also practiced what they called Scrum. After taking part in a handful of projects, I started wondering: What is Scrum, actually? What’s the point of all these rituals, sprints, and dailies? Why does everybody do it somewhat differently, but they all call it the same?
These questions led me to take a Certified Scrum Master course. Apparently, everything I knew was wrong. What I have been practicing all these years wasn’t Scrum—it was ScrumBut (from scrum.org):
A ScrumBut has a particular syntax:
(ScrumBut)(Reason)(Workaround)
Here are some ScrumBut Examples:
"(We use Scrum, but) (having a Daily Scrum every day is too much overhead,) (so we only have one per week.)"
"(We use Scrum, but) (Retrospectives are a waste of time,) (so we don't do them.)"
"(We use Scrum, but) (we can't build a piece of functionality in a month,) (so our Sprints are 6 weeks long.)"
"(We use Scrum, but) (sometimes our managers give us special tasks,) (so we don't always have time to meet our definition of done.)"
In short, ScrumBut is a derivative version of Scrum. People pick their Scrum practices of choice and ignore the rest of the framework. If you suspect something smells fishy in your Scrum, here are four signs to help you identify that you are practicing ScrumBut.
The real purpose of the Daily Standup in Scrum is to encourage communication, solve issues quickly, and help the Scrum Team focus. It should be used to check the team’s progress towards the Sprint Goal and make adjustments for the coming workday. For example: getting help on technical issues, refining backlog items, scheduling separate meetings, or whatever is deemed necessary to help meet the Sprint Goal. One sure thing is these should not be status meetings.
What does your daily standup look like? If none of this is happening, sorry, it sounds like you’ve got a ScrumBut in your hands.
In Scrum, the team is supposed to be self-managed. When the team makes their own decisions, it lets them make progress more quickly, increases their sense of meaning, and raises team morale. Of course, in the real world, there may be various stakeholders that have time constraints and request certain deadlines. The Scrum Team should be in close contact with them and take everything into account, yet have the authority to make the final call.
Why is this relevant? Most organizations claiming to practice Scrum are usually hierarchical. Scrum Teams often end up being managed by someone above the command chain, e.g., the team manager, the CTO, or even the CEO, who ends up calling the shots while forcing the team to follow. A lack of self-management in the team is a definite sign of ScrumBut.
Each Sprint should have a goal. The goal gives the team something to focus on, while also being transparent about it. At the end of the sprint, the team examines whether it reached the goal, added some value, and shows this progress to the stakeholders. If the team misses the Sprint Goal, it can investigate why and improve for the next Sprint.
Is your team using sprints, though without any goals? Or maybe you are defining goals, yet they are arbitrary and don’t add any real value to your users? As Master Yoda would say: ScrumBut it is.
If you really want to practice Scrum, you need a dedicated Scrum Master. The Scrum Master is basically a servant—of the process, the team, the product owner, and even the whole organization. The Scrum Master supports healthy and open communication, helps solve conflicts, increases the team’s effectiveness, and much more. In other words, a Scrum Master’s true purpose is to get the Scrum Team working so smoothly that no Scrum Master is needed at all. As this rarely happens, you need a proper Scrum Master.
ScrumBut practitioners don’t have a dedicated Scrum Master. Plain and simple. Is your Scrum Master also the product owner or project manager? Do they only tend to facilitate events, send calendar invites, and not much else? Then it’s more likely a ScrumBut Master.
First of all, don’t panic! You're not alone. Luckily, the first step to solving a problem is recognizing there is one. Now that you have, you may choose to educate yourself by reading the Scrum Guide and checking out articles, videos, and books about Scrum. You might even do some training, like taking a Certified Scrum Master course, or consider hiring a Scrum Master.
It may be difficult to bring up the topic of ScrumBut in your team and organization. You should probably do it slowly, highlighting pitfalls of your current ScrumBut practice while clearly showing how everyone could benefit from proper Scrum practice. Whatever you do, I hope you’ll be well on your way to a successful Scrum, no ifs or buts.
Do you need a dedicated Scrum Master to do things right? Our Scrum Masters are here to help.
