Is Scrum really the root of your team’s problems?

Written by Micha? S.

As a software industry we do like to follow trends. We quickly jump on the bandwagon of new technologies and methodologies. We unquestioningly adopt and become believers of the new and shiny. But just as quickly as we grow excited about those, equally as fast we become disillusioned and start complaining about them.

It’s no different with Scrum. There was a time, several years ago, when scrum was gaining momentum on top of Agile popularity. People saw it as a silver bullet that will make all the projects deliver seamlessly and guarantee great developer experience.

And now, after some time, many people become disillusioned with Scrum. They start to see the Scrum as a source of the problem, rather than the solution. They often attribute the things that are wrong with their organisation to Scrum. But although Scrum can be inefficient and is far from perfect:

If your project is failing or if your team is unhappy, it is most probably not because of Scrum.

In this article, we will take a look at Scrum. We will see what are the popular complaints against it, judge if they are well-founded and examine what are Scrum’s good and bad sides.

Why people dislike Scrum

Today you can find a ton of articles and presentations on why Scrum is bad, inefficient and responsible for the world's evil. However although Scrum has its drawbacks, I find most of the arguments against it to be misguided for one of following reasons:

• Some teams don’t follow the Scrum guide and then blame Scrum. There is even a term for that called ScrumBut . It does not mean you should never deviate from what the Scrum Guide says, but if you do, you are doing it at your own risk.
• Some people treat many of the practices and tools built on top of Scrum as mandatory parts of the framework. There are a lot of tools and practices that are there to help implement Scrum and get the most out of it. However, introducing them blindly into your project, just because others are doing it, is never a good idea.
• Many organisations adopt Scrum without really understanding and embracing Agile principles. Following the letter of the Scrum, but not understanding its spirit.

One could say that if following a framework is so hard that nobody does it right, it must be the framework that is at fault. In reality managing large software projects in a complex business environment is hard, regardless which framework or methodology you choose.

But if most of the complaints against Scrum are misguided, does it mean that Scrum is perfect?

Scrum - the good

There is a lot of good about scrum. It offers a nice structure that is especially valuable for the new teams, or less experienced developers. Scrum’s language has become ubiquitous, providing a common platform in how we talk about our organising work in the teams and delivering value.

Scrum encourages delivering an increment at least once per sprint (step towards continuous delivery) and offers multiple opportunities for reflection and improvement. It helps ensure that certain tasks are completed for example, that there is a refined backlog in place. It introduces cadence, which can be helpful when planning or retrospecting.

Scrum inspires direct cooperation between developers, product and business. It introduces the role of Product Owner as a single point to manage backlog. Most people know Scrum and can easily start contributing to a Scrum team.

Because of all of this Scrum can be a good starting point and a reference for a new team starting work on a project.

Scrum Scrum - the not so good

Naturally Scrum is not perfect. It has evolved over time to better meet the needs of the teams. It became less prescriptive, put even more focus on upper bounding the duration of meetings, added focus on why and introduced other subtle changes. However, there are still some inefficiencies that are rooted in the core of Scrum's design. Following is a subjective list of Scrum drawbacks.

Scrum ceremonies

Scrum introduces a lot of overhead. Scrum events can take a lot of time and many teams find them to be a burden rather than a benefit. The good side is that the duration of all those meetings is upper bound. It requires some discipline, but they can be run efficiently.

Scrum master

Scrum master is the role that is not very well understood and often made fun of. It is becoming to be seen as an unnecessary cost when it comes to the team structure. According to the Scrum Guide, Scrum master is responsible for “establishing Scrum as defined in the Scrum Guide”. Is Scrum so hard or so revolutionary that self managing and self organising teams of professionals really need someone to establish it? Or is Scrum master a person that makes sure that the meetings take place on time? But although made fun of, the role of Scrum Master, if performed by a skillful individual can actually help. Many teams decide to connect it with other role in the team, like a tech lead.

Sprint goal

Scrum puts a lot of emphasis on the sprint goal. Sprint goal is something that is the focus of daily scrums and that sprint success is measured against. While in theory it seems like a good idea, because by decoupling sprint success from the stories/tasks delivered gives the team focus and flexibility, in reality it can offer some practical problems.

For example, it is often hard to define a single, tangible and meaningful goal that can be achieved by the scrum team within the sprint. It might not be possible for the whole, or even most of the team to work towards the spring goal, as not all the work can be done in parallel, or for the goal to be tangible it might be just too large to fit in the single sprint. At the same time having multiple smaller goals takes away the focus.

Failing to select the right sprint goal can decrease developer satisfaction or cause us to optimise against incorrect metrics. At the same time focusing too much on the sprint goal may lead the team away from doing other important work that might be needed for operational reasons or to maintain high quality of software.

This is, in my opinion, the most serious issue I find with Scrum. However I find that most people naturally work around this and without even being aware implement a ScrumBut approach, either reducing emphasis on the Scrum goal, or being creative as to what it is going to be. In either case it is important to make the decision consciously and introspect on it and it's influence on the team and ability to deliver.

Above I have listed some of the most important issues I find with Scrum. Those issues do lead to inefficiencies or can reduce dev team satisfaction, but they can be worked around and are in no way dealbreakers.

The verdict

Managing large software projects in a complex business environment is hard, regardless which framework or methodology you choose. It requires a lot of experience, skill and effort from everyone involved to deliver good quality software in a sustainable and predictable way.

Saying you are doing Scrum just because you work in sprints and have dailies and retros is not enough. Both you and your organisation need to fully embrace an agile approach. You need to accept the iterative process of creating software.

In the end, Scrum is just a framework. While not perfect, it is really well designed and thought through to address and protect against common project management pitfalls.?

Personally, although I'm not a huge fan of Scrum, I don't think it is bad either. Teams of engaged professionals don’t need a formalised framework to deliver business value with commitment, ownership and initiative. And the most difficult challenges that the teams face cannot be simply solved by adopting such a framework.

Scrum can offer a good, common starting point for the teams and might help them find their own path in the future. It can act as a reference when talking about how we work and a set of ideas and practices we can borrow from to better organise our work. Regardless, what route you take, remember agile manifesto which values: Individuals and interactions over processes and tools. Achieving perfect Scrum is not the goal in itself.

Unfortunately Scrum has fallen victim to its own popularity and the hopes that people have put in it. It is far from perfect, but it is not to blame for failed projects or lack of dev satisfaction. This is just bad management.

What actually stood the test of time is Agile with its principles. So regardless what methodology or framework you choose, do remember to follow Agile.

Here is the article on how to make your team adaptable and agile again.