Why is Scrum not a methodology?

We work in the Scrum methodology. Is that true?

The arguing employees could not reach an agreement. The topic turned into a joke, started to circulate the company, and became a source of mutual teasing. The dispute reached its climax at a meeting where representatives of various departments were to determine the manner and scope of cooperation. The joke about methodology was already so popular that everyone in the audience knew its genesis. So there was a lot of biting remarks about the level of knowledge of those who used the word method instead of methodology (or vice versa).

Halfway through the meeting, it was time for Mr. X’s presentation. Mr. X, who after reading many books on the theory of running IT projects, was a leader in pointing out incorrect terminology to others. So, he started talking about how his team organizes work. Everything was going well until Mr. X said that they were working in a Scrum team. Mrs. Y momentarily picked up on this and pointed her weapon against Mr. X., “Isn’t that a framework, not a methodology?” That’s right, another term… So what’s it like, after all?

More than just a simple framework

As if to contradict the above story, I am not going to solve here the problem of nomenclature, which combined with language differences and translation from English, creates an explosive mixture. I think this is more of a challenge for Prof. Miodek. Or maybe the problem simply does not exist, and we focus on unimportant things?

Now, let’s forget about the classical terminology. From now on, I will distinguish only two terms: methodology (in simple terms, methodology or method – you can choose what suits you better) and framework.

Framework translated directly from English means the frame of work. A methodology, on the other hand, is a set of principles, a set of norms. It contains some kind of instruction or is itself a large instruction. So why do we say that Scrum is not a methodology? What makes us distinguish Scrum from other classical methodologies for developing information systems without focusing too much on the term framework itself?

Scrum, indeed, contains instructions, but it is not limited to them as it also, or perhaps above all, focuses on values.

I don’t think this statement is a misrepresentation. If you read the Scrum Guide, you can easily see that there is a big emphasis on values (called The Scrum Values) which are as follows:

• courage
• focus
• commitment
• respect
• openness

They are mentioned not only by Scrum developers but also by the people professionally close to Scrum. I have also found that Scrum may or may not work, and it depends very much on whether the team shares these values.

Scrum Values

Scrum won’t work (or at least that’s my experience) if the team doesn’t have enough courage, for example, to stand up against unnecessary documentation or to work on a problem that seems unsolvable. Everyone in the team should have the courage to openly say that we are doing something wrong, and it can be done better, simpler, differently.

The self-organizing team also needs to be focused, as this gives them a chance to create not only the planned functionality but also something over the top that ultimately brings additional value to the user. From my perspective, it can be more difficult than it seems. Let’s look at the development team’s work. The team focused on the goal, while working on a certain functionality can, by the way, come across another one that increases the project value, and neither users nor Product Owner defined it. Lack of focus may result in missing an important element of the project puzzle. A focused Product Owner has a perfect understanding of the product, which makes prioritizing easier and, more importantly, more accurate.

The values in Scrum are linked together, but they also connect the team members. A cohesive team is formed that can handle the most difficult challenges. Commitment is combined with focus – to create something better than initially expected (which is essentially why we use Scrum), you need people who are committed to the work. Ideally, they identify with what they are doing and can find meaning in it. Team engagement is the key in any IT project.

Respect for others, and their work, is no less important. It is a kind of base for all the scrum values. Without it, all the rest is unattainable – when there is the mutual respect in the team, it’s possible to create an ecosystem in which the scrum values are more than empty phrases. Self-organization can suffer when team members do not value each other’s work, time, and separateness (individuality).

A team working in Scrum should be open and aware of the realities in which they operate. This applies to current tasks as well as challenges that arise in the project. Let’s imagine a team that changes the testing mode. They stop with classic manual testing and decide to try, for example, Test Driven Development. Changing the mode may take time, and before the effects come, there will probably be a slight slowdown first. This is where openness is essential – it helps to accept the change and the time needed to implement it correctly.

Not all scrums are the same

The values I described are generally not described in methodologies. On the other hand, you can find many examples of teams succeeding by sharing values, and just as many of Scrum failing by not following them. And this is probably just the tip of the iceberg of the never-ending discussion about methodologies, frameworks, and their definitions.

For me, Scrum is much more than a manual. In addition to the description of the steps to execute the activities, I also see its psychological layer, related to values. The project’s success depends not only on its organization or the technical knowledge of the team members. It’s a solid base, but it’s not enough if there are no soft skills. Sometimes they are overlooked, sometimes underestimated. In my opinion, they are invaluable.

Courage, focus, commitment, respect, and openness. I will mention them again in conclusion because I had the pleasure to work with people who shared these values. They were often the creators and originators of the best improvements, most useful for the end-users of the implemented solution. So I am convinced that Scrum can work only in a team that respects these values. Only such a team will turn a general, “As an admin, I want to manage user rights,” into a real value. Planning every sprint only makes sense if the team is committed and willing to create the mythical value. Combining all the elements of Scrum, such as sprints, daily meetings, continuous improvement of assumptions, immediate feedback from users – this mix will work when the team shares not only rules and instructions but also ideas and values.