The Dark Side of Scrum: 2 Big Mistakes You Should Stop Doing

So you’re doing Scrum. You have a neat backlog, you have a product owner, heck, you even have a designated Scrum master. Great. But is it really working? Is it really adding value to your customers? To your team?

Scrum is no longer a new trend being tossed around as the latest hip buzzword in project management. It was formally introduced by Ken Schwaber and Jeff Sutherland over twenty years ago, and earlier versions of it have been practiced even earlier by other teams who didn’t call it “Scrum”. It is now embraced by many companies and organizations around the world and is the center of a lively, growing community. But as more and more companies foster this framework — and an agile state of mind in general — you can see more and more mistakes being made. Many teams just fail to realize the full potential of Scrum, and usually these mistakes can be divided to two common types. Teams may either get too caught up in conducting the ceremonies without asking themselves if they’re effective at all, or take only a random subset of its elements and justify it by raising the “we’re so agile” flag. These are basically two extremes of the same scale, and as much as it’s easy to make these mistakes, they can also be easily avoided.

We should probably start by asking the following quick question: What are the benefits of having an effective Scrum process? While there are many advantages in using Scrum and doing it well, I would say it all boils down to the following:

• Happier customer: Probably the biggest and easiest win of Scrum is that it helps you better understand the customer and deliver what he actually needs, while delivering the most important requirements first.
• Happier team: If you’re doing Scrum right, you’ll have a more engaged and productive team which can do things faster, while actually being able to grow, both personally and as a team.
• Happier manager: Somewhat the result of the first two benefits, having an effective Scrum process will lead to less waste and reduced costs on the one hand, while providing more value to the customer and bigger revenues for the company on the other hand.

Keeping these benefits in mind, it should be fairly simple to see why the following adaptations of Scrum are a miss. Let’s begin!

First mistake: Getting lost in the routine

One of the reasons Scrum is so successful is that it’s simple. You basically have a backlog of tasks, a board, three roles and four recurring meetings — Planning, daily standup, demo and retrospective. Having a more complex framework would kind of miss the point, wouldn’t it? This is why it’s easy for teams to focus mainly on having these roles and meetings in place, while losing sight of what’s really important: having a process which actually helps in gaining the benefits mentioned above. You shouldn’t do Scrum because it’s cool or because everyone else is doing it, or even because your manager’s manager decided this is what he wants. You should do Scrum because it works for you. So you better make sure it actually does.

If you’re working in an agile organization, you’ve probably seen it yourself at least to some extent. Such a team would be very much caught up in the Scrum routine, and less in the agile state of mind. They would have all the ceremonies in their schedule, and they would be strict about actually conducting them and by all the rules in the book. So far so good. The problem begins when the team becomes more focused on having these meetings and on the dry rules, rather than having meetings which are actually effective. There are many examples to that. Just to name a few:

• Demo takes place at the end of every sprint, but no stakeholders from outside the team are present, so no objective feedback or knowledge sharing is actually taking place.
• Demo takes place at the end of every sprint, but the team tends to be unprepared so the actual demo is boring and stuttering.
• Retrospective takes place at the end of every sprint with everyone including the product owner present, but the discussion is dull and no real learning is achieved between sprints.
• Standup takes place every morning at the right time and is limited to a short amount of time, but is focused on the wrong things so it doesn’t help the team work more efficiently for the rest of the day.
• Planning takes place as the first step of every sprint and the team dedicates a significant amount of time for it, but the discussion on every task is inefficient so the team ends the planning without being actually prepared for the sprint.

I could go on and on, but the idea should be clear at this point. It’s not about religiously following the Scrum pattern, but rather following the framework in a way that allows the team to deliver more value to the customer, faster, while becoming a stronger team from sprint to sprint.

Luckily, avoiding this pitfall is pretty easy. Awareness gets you halfway there. Team members — and especially Scrum masters — should not only participate in these meetings, but also ask themselves: “Is this working well? Are we actually achieving what this meeting is supposed to achieve?”. If not, well, let’s think how this can be changed. The solution will usually be simpler than you would expect and will only require some common sense.

The demo isn’t working? Let’s save some time on the last day of the sprint for preparation.

The retrospective is boring? Let’s try a different format and search for some fun activity to try out next time.

Stakeholders don’t show up for the demo? Let’s ask them why, and let’s ask ourselves if there’s a point in having these demos without them.

In other words, if it’s broken — fix it. And you know what? There’s a great time for discussing all these questions — the next retrospective. On the other hand, if some hard questions rise very often, you should ask yourself if this whole Scrum thing is working for you. Usually it should be, sometimes it shouldn’t. Maybe you should try something else?

Second mistake: Over-customizing the process

Scrum is with no doubt one of the main players in the movement which we call “Agile software development”, or simply “Agile”. That’s no accident, Scrum parents Schwaber and Sutherland are two of the people that created the “Agile Manifesto”, along with other software development pioneers like Martin Fowler and Extreme Programming creator Kent Beck. Indeed, often when people say “Agile” they mean “Scrum”, and vise versa. But the fact that Scrum is so strongly related to Agile, which is all about being lean, simple and flexible, may cause teams to make a different kind of mistake in their approach to facilitating Scrum. What I’m referring to is teams that are interested in the benefits of Scrum, but pick only the parts of Scrum that they feel like doing. This is basically the opposite of the first phenomenon we discussed.

You should always improve and adjust your process, but take your freedom too far and you just might end up with a weird Scrum-like process which is missing the point. “Yeah, we do Scrum, but the team decided retrospectives are a waste of time”. “Of course we do Scrum, but we set the backlog and the priorities once every quarter”. Sounds familiar? Sometimes these awkward decisions will be backed up by saying the team is so much into agile, that they decided to remove the parts that they felt were wasting their time. Let me translate: The agile concept made them feel comfortable enough as to remove the parts of Scrum which they felt were annoying.

Ok, I might have been a little harsh here, so don’t get me wrong. You should definitely make adjustments in the process so it works for you. These adjustments may even change as time passes, the product evolves and the team grows. Your process should be dynamic, that’s actually a very healthy thing. But it does not mean you can skip appointing a product owner, have three months long sprints and meet once a week for “daily” standups, and still call it Scrum and enjoy its benefits, right?

My advice to you is this: before removing (or adding) anything to the basic Scrum framework, ask yourself the following questions:

1. Do you have a good reason for removing this part? Or is it mainly due to plain laziness or fear of confronting the team and explaining them its significance?
2. Can you solve the problem within the limits of the standard framework? For instance, could this issue be overcome by changing how we conduct some ceremony? (Spoiler alert: usually the answer is “yes”!)
3. What’s the price? Are you losing something by removing this? For instance, if you stop doing retrospective, are you introducing some other tools for the team to facilitate learning and improvement?

I would also not commit to any big modifications, but rather try them for a few sprints first and only then make a decision as a team. It’s a bad idea to sit in the retrospective after a demo that felt like a waste of time, declare that these demos are good for nothing, and decide to remove them from your process altogether. It may however be a good idea for some teams to sit in the retrospective after a demo that felt like a waste of time, ask themselves why it feels that way, and consider skipping the demo in the next sprint and check how that feels. When you make big changes you may strike gold, but you may also fix your team on a broken process, and that’s just too bad.