The Problems with Scrum?

Whenever a useful idea, like Scrum, reaches a certain level of awareness, it can be occasionally applied imperfectly. If it’s simple in concept but hard to do, the imperfect examples might overwhelm the good ones, and people begin to complain about the thing, rather than the bad implementation of the thing.

I’ve seen people do things that they call “Scrum” poorly. The process they used was inflexible and bureaucratic, and it didn’t deliver the right software quickly. That wasn’t a flaw of Scrum, because the organizations weren’t actually doing Scrum, even as they were using the name.

Often, people want a simple-to-implement recipe to solve the hard problem of delivering the right software effectively. While the steps seem simple, doing them in a way that gets the benefits of Scrum takes practice. Scrum can require significant process (including technical process) and mindset change to be done well. That’s not a flaw of Scrum. Scrum is hard. But there are easy steps you can take to improve how you work, in small, continuous steps.

I won’t go through every aspect of Scrum here, but I’ll highlight some of the common complaints.

The Scrum Guide is quite simple in its description, defining a small number of roles and events. But some teams may need some guidance on how to implement it, and there are a number of guides on topics like:

• The product backlog.

• Planning mechanics.

• Feedback sessions: reviews and retrospectives.

• Sprint structure.

Two common complaints are:

• The lack of technical practices in Scrum

• Sprints

Scrum doesn’t prescribe any technical practices. That’s by design; the process should facilitate identifying technical practices. If you didn’t start the process with the right kind of unit testing or CI/CD practices, your review and retrospectives should expose gaps that these practices might close.

Some argue that having any planning interval — or Sprint — isn’t “agile” because things can change. Keep in mind that Scrum was an answer to organizations doing long-range planning without acknowledging the importance of change and feedback. If you were planning quarterly, going to 2-week cycles might be a challenge, but also an improvement.

Scrum says nothing about Sprint duration, only that there are feedback points where you compare what you planned to do with what you did. Two weeks is a common first choice. Longer can make it harder to iterate and lead to later work items. Shorter needs more discipline to work well. A Sprint could be a week, a day, or less if you have the capacity to get work done that quickly.

While all the Roles, events, and artifacts in the Scrum guide are part of Scrum, and following the guide is a good way to learn the process, it is easy to fall into a pattern when you go through the motions without following Scrum principles (Commitment, Focus, Openness, Respect, and Courage).

The goal of Scrum is to help teams collaborate towards a goal with minimal overhead. If you find that following the process seems bureaucratic, raise this at your retrospective. Some common patterns to look out for are:

• Daily Scrum meetings that are long and focus on status reporting. Or if people share with a manager rather than each other.

• Sprint Reviews that take a long time to prepare for and are viewed as evaluations of work rather than measures of progress.

• Planning meetings seems to lack a clear vision from a Product Owner.

• Parts of the process seem pro-forma rather than useful

An example of the last point is compulsive adherence to the common user story format: User Stories are not part of the Scrum Guide, but understanding the Who, What, and Why of something you want to do is essential to having a good backlog item.

Making things more complicated is that Scrum is meant to be adaptable, so some teams choose to “adapt” it out of the box by removing some of the feedback cycles.

A common example of this is teams skipping the retrospective. The retrospective is an essential feedback point for adapting and improving the process. Done well, they are enjoyable and valuable. Done poorly, they feel like a waste of time. Too many organizations do them poorly, thereby creating a self-fulfilling cycle. It’s rare for an organization to take the time to prepare for retrospectives or to train those who will facilitate them. And even those who do may not be consistent in incorporating the feedback to improve the process.

While it might be tempting to skip steps that “seem” useless, changing your practice is a key part of forming new habits. Most teams choose to explore a framework like Scrum because their current process isn’t working. Radically adapting a framework out of the box isn’t consistent with adapting a framework in an attempt to improve your work.

Adopting a process before you adapt it is often the right approach when you are trying to make some changes to your work environment and culture. And be very reluctant to remove the feedback points from your version of Scrum.

Scrum can add significant value to a team struggling to deliver more useful software. If it’s not working for you, consider whether it’s the right solution for your problem; it might not be. But also check whether you have the right feedback steps in your process and whether you are taking advantage of them.