Agile Chaos? Four Prejudices about Scrum: True or False?

It was a few years ago when a friend's birthday party burned itself into my memory: After a few classic get-to-know-you questions ("What do you do?"), the party guests realized that Scrum was a common topic. And that's when I heard the sentence that stuck with me: "Scrum was only invented to make developers finally talk to each other."

This pointed opinion was, of course, expressed with a wink. But apart from the implicit prejudices against software developers, I noticed the following point: Scrum is reduced to a mere communication aid. This does not correspond to my experience. Scrum can do much more. It was not the first and not the last time that I encountered prejudices about Scrum and agility. I would like to clear up a few of them here and ask myself the honest question which ones might contain a spark of truth.

Illustration by Dovile Kietzmann www.dovile.de

Briefly The Pure Facts about Scrum

Scrum became known in the early 2000s as an agile method for software development. In the Agile Manifesto, the circle around Jeff Sutherland and Ken Schwaber formulated a number of methodological principles that promise faster and better product delivery. At the same time, they also convey their own mindset, which focuses on people and strives for collaboration in flat hierarchies. Scrum has now left its mark on more than just software development. And despite all the successes, prejudices about agility crop up from time to time.

Scrum Prejudice 1: "Just to Make Developers Talk to Each Other"

I would like to start by addressing the prejudice cited at the beginning. First of all, developers are not clumsy nerds with limited social skills who never talk to each other. But apart from that: What does the comment say about Scrum? Is the agile method a purely soft-skill-oriented means of communication?

Admittedly: Some Scrum artifacts, such as the sprint retrospective, are also used for interpersonal communication, not just for topic-related conversations. And the authors of the Agile Manifesto emphasize the importance of face-to-face communication, individuals and interactions. So yes: as a human-centered method, Scrum promotes communication within the team. Does this turn the framework into a feel-good event in which communication between colleagues is an end in itself? Not at all. The main goal is to meet customer needs and enable rapid delivery of the (software) product.

There is no doubt that improved communication can have a positive effect on interpersonal relationships. And why should that be a bad thing? There is no reason to underestimate "talking to each other". We have long known how important psychological safety is at work. Scrum promotes it.

Scrum Prejudice 2: "Things Are Chaotic Right Now. But We're Just Agile!"

I have come across this statement most often so far: Agility is equated with a chaotic way of working. In most cases, the statement came from people who had only recently started working with Scrum or were using a modified form of Scrum ("Scrum light"). There is nothing wrong with that. However, it is important to understand that Scrum and other agile frameworks follow a clear structure. They are not chaotic. It is true that short iterations are used to react quickly to changing requirements. However, the activities follow a clear release plan.

I would therefore recommend this: If you hear a similar statement in your work environment, it is worth taking a closer look: Are the project goals clear and visible to everyone? Do the people who are involved feel secure about their roles? Are the order and priority of tasks clear? As soon as the term "agile" is used to legitimize chaotic work, the reason might very well be a failure in how clearly people were informed and integrated.

Scrum Prejudice 3: "Scrum Is a Time Waster."

Some people perceive Scrum as a very time-consuming method. Yes, it is true that Scrum involves a number of meetings: Daily, Planning, Review, Retro, Estimation or even Backlog Refinement. However, the reason for the various routines is by no means micro-controlling, but rather transparency within the team. The regular exchange makes obstacles visible more quickly. They are cleared out of the way before they have consequences that are much more difficult to revise. The increased productivity should more than make up for the time invested.

Admittedly, it is difficult when people only spend a small part of their working time on a Scrum project. I have experienced this in companies where individual projects are implemented in an agile way. For example, the head of the brand management department is a 20% member of a website development squad. There is no one-size-fits-all solution to this problem for the individual person. Rather, it is the level of management and organizational development that is required here: should employees work in parallel worlds (day-to-day business vs. agile project)? Or should the company strive for holistic agile transformation?

Scrum Prejudice 4: "Scrum Light Is Enough."

It is true that a tool or method should always be used in such a way that it offers the greatest benefit for the specific application. There is no point in dogmatically insisting on certain principles if they only serve an end in themselves. It is therefore perfectly legitimate to modify the Scrum framework if it suits the project and the team better. Adapted forms of Scrum – e.g. without a Scrum Master, with Weekly instead of Daily, etc. – are referred to as "Scrum light". If the chosen Scrum Light form is satisfactory for everyone, then by all means continue!

In practice, however, I have often observed that Scrum is reduced to such an extent that nothing remains of the method except that tasks are visualized on a board. If there is no improvement, then something is probably missing. Don't underestimate the fact that agility is more than just a tool, it also has its own mindset. Agile frameworks unfold their full potential with the right mindset. If the rethink is simply skipped, the changes often fall short of expectations.

Revisiting these four prejudices, I see clearly that misunderstandings and disappointments often arise where the methodological innovation is perhaps implemented too quickly. In the Scrum Guide, the authors themselves point out that Scrum is "simple to understand, but difficult to master. "

In my experience, an agile transformation can succeed if its management gives the change process enough space and remains in dialog with the employees. Why is the method change important? What do we want to achieve together? What does each team member contribute? If you provide good answers here, everyone will identify with their own work and experience increased added value.

And then, instead of the Scrum prejudices, let's take the successes with us to parties as conversation topics.