This article closes the series in which we review the fundamentals of Scrum complemented by infographics that explain them. It may sound strange to end with the overview, but now that we have the details, we can step back and see the whole in perspective.

Authors: Alonso Álvarez y Patricia Parreira

Scrum was born in the mid-1990s to solve a very specific problem: how to develop software effectively and efficiently with small teams?

Over time, Scrum has evolved a lot and along several lines: it has become one of the foundational components of the Agile movement, and has inspired (for better or worse) many other agile frameworks; it has incorporated many elements from other frameworks; it has opened up to other contexts and has long been applied outside of software. It has also dropped many things from its official definition, which is getting narrower by the day (such as the Daily’s three questions, which went into one edition and came out in the next).

The creators of Scrum, Shutherland and Schwaber, were inspired by several sources, starting with the article “The New New Development Game” by Professors Takeuchi and Nonaka to make an adaptation of the Lean philosophy originating at Toyota, combined with their own personal experience.

NOTE: “The new new development game” is also the inspiration for the name Scrum. The original article used the metaphor of rugby to explain how the ball is “passed” (the work) between team members. Sutherland and Schwaber chose “Scrum” (which in English is “Melee”), a rugby move in which the team pushes in unison to overcome an obstacle, the opposing team.

Scrum began in practice in 1993 (according to Shutherland, that’s when the first Sprint started) and then it was presented at a conference and articles and books began to appear. In 2001, Shutherland and Schwaber participated in the development of the Agile Manifesto and since then its influence has continued to grow. It is estimated that more than 80% of organizations that apply agile use Scrum, plus an additional percentage that use hybrids or variants.

Scrum is a Framework

Although it is common to hear the expression “Agile methodology” when talking about Scrum, the first thing to make very clear is that Scrum is not a methodology. Its authors define it as a lightweight framework. You only have to look at the Scrum Guide to realize that we are talking about something very non-prescriptive: 14 pages are enough to tell you everything you need to know about Scrum (14 in the original English version, 17 in the Spanish version, including cover, table of contents and acknowledgements). What’s more, this Guide has always been short, and has even been reduced over time from the 21 pages of its initial 2010 version.

Scrum is defined as “a lightweight framework that helps individuals, teams and organizations generate value through adaptive solutions to complex problems”. That is not to say that its application is simple: Scrum has traditionally been compared to chess, where simple rules lead to a game with many complex variants.

This justifies the amount of literature on Scrum: the enormous variability of situations in its application, the wide range of possible situations that can occur in a team, makes the experience of putting Scrum into practice a complement that enriches the simplicity of its design.

The fundamentals of Scrum

The most visible and well-known aspects of Scrum are its events, responsibilities and artifacts, but the only way to understand what we are talking about is to know what it is based on: its pillars and values.

Scrum is based on empiricism and Lean thinking. Empiricism states that knowledge comes from experience and making decisions based on what is observed. Lean thinking reduces waste and focuses on the essentials (Scrum Guide, 2020).

Empiricism, making decisions based on data and evidence rather than personal opinions and perceptions, is basic. This means that effective application of Scrum requires obtaining and analyzing that data. Scrum does not officially define metrics or indicators, but makes it clear that empiricism is the foundation on which everything else is built.

The pillars

And that “everything else” is, first of all, the pillars on which Scrum is based. There are three of them:

• Transparency. The work in a small team cannot have dark or private areas. It is not possible to make important decisions without having all the information. There is no effective work if information is compartmentalized, and, above all, lack of transparency prevents inspection and adaptation, the other two pillars of Scrum.
• Inspection. Scrum work, its progress and results must be inspected frequently to detect and anticipate difficulties, and identify areas for improvement. Scrum events are designed to help inspection. This pillar always goes hand in hand with the next one, adaptation.
• Adaptation. It makes no sense without inspection. Let’s remember that agility was born above all with the idea of enhancing the ability to adapt in complex environments subject to change. If deviations are detected during the work, or if the results are far from what was expected, what common sense dictates is to introduce changes, not to persevere blindly. The change, the adaptation, must be made as soon as possible to mitigate the effect of the deviation. Without prior knowledge (inspection) adaptation is not possible. Nor is it possible if the people involved do not have the capacity to make their own decisions, hence the importance of empowerment and self-management.

To finish linking this pillar with the previous one, it is said that a Scrum team adapts when it learns something new through the inspection process.

The values

The complement to the Scrum pillars are its values. In this case, there are five:

• Commitment. The Scrum team is defined as “self-managed”, with autonomy and a great capacity to make their own decisions. That is a real superpower, but we already know that “with great superpower comes great responsibility”, in this case it is the commitment to achieve the objectives set and to support each other to achieve them. All the team’s efforts must be directed towards achieving these objectives.
• Focus. The team must give its full attention to moving toward its objectives. This means that the main focus of its activity must be here. Avoiding distractions and deviations thus becomes a fundamental element of Scrum work.
• Openness. The work of the team is subject, like everything else, to inspection and adaptation. This is not possible if there is a rigid and inflexible vision. That is why it is so important that the team and its stakeholders are open to other possibilities about the work (the how and the what).
• Respect. This is something basic: team members respect each other, and are respected by the rest of the people around them.
• Courage. The people on the team have the courage (and feel empowered) to step forward and do the right thing. This courage implies the existence of “psychological safety”: there is no fear of expressing views and pointing out what is wrong.

Values and pillars are basic elements in Scrum, much more important than events, responsibilities or artifacts. To do Scrum without applying these values is to do it in a hollow and mechanical way. Scrum without values is a collection of meetings and responsibilities whose meaning escapes those who participate in them.

Pillars and values in practice

Does this all sound very abstract? Actually, it all has direct application in the day-to-day life of a Scrum team.

If we review Scrum events, we will see the imprint of these pillars and values in all of them. To begin with, the Sprint is a cyclical approach that promotes regular inspection and adaptation by the mere fact of generating and reflecting on results at regular intervals.

• In planning, changes and adjustments are introduced to align the work with the Product Objective. Planning is a time when commitment is exercised, but focus or courage also plays a role.
• During the Sprint, people work within an environment of respect, with focus on the work that allows them to meet their commitments, openness to new ideas and possibilities, and the courage to implement them.
• The Daily meeting is an event where Inspection and Adaptation is done to detect and correct misalignments of the Sprint Objective. It is necessary to focus on what is important to fulfill the commitments and to have the courage to change course if the objectives are at risk, and to point out the impediments detected.
• The Review is an event where, above all, the results are inspected, feedback is collected and adaptation actions are proposed to be materialized in the next Sprint. It is a moment for openness when talking to the team and stakeholders about difficulties and changes. It is also a moment to courageously point out deviations and show the team’s commitment to the objectives.
• The Retrospective is another event of Inspection and Adaptation on the team’s performance. As in the Review, openness to different ideas and options is exercised. In addition, in an environment of respect, one must have the courage to point out what is not working in order to commit to solving it, opening oneself to new ideas.

All of these events are learning opportunities. All of them require transparency in order to be carried out effectively. None of them can be understood without applying empiricism, that is, without using data and evidence to make decisions.

If we look at the responsibilities, we see that all of them require the exercise of values to achieve the objectives: commitment shared by all, focus on the work, mutual respect, openness to new ideas and possibilities, and courage not to miss opportunities to ask the necessary questions and introduce changes through inspection and adaptation. And all this under the premise of transparency, because without it, true teamwork is impossible.

Scrum is one of the different implementations of the agile philosophy. It is the most popular, but there are many other alternatives. Scrum is not a universal solution for the problems of an organization or a team, but it is a very effective way to bring them to the surface and offers tools for the team to solve them.

In the same way that agile is the most appropriate approach in certain types of contexts, Scrum is the most appropriate framework for certain types of problems and organizations. At other times it will be better to use other frameworks and techniques. Rigidly implementing Scrum without understanding what the team’s problem is can lead to frustration and dysfunction. Applying Scrum without paying attention to its fundamentals turns it into an empty and meaningless sequence of meetings that quickly become perverted.

Scrum allows to accommodate variants and improvements, but it should not break with the (very) minimum requirements established by the Guide. Weeklies, Reviews without feedback, dailies for reporting, Sprints without objective, PO and SM in the same person, no retrospectives or very occasionally, absent PO…? It is surprising the variety of dysfunctions that can be introduced in such a simple framework as Scrum.

Each element has a specific purpose and is essential to develop complex products. There is nothing superfluous, let’s not forget.

Scrum can be defined as a way of putting empiricism into practice, the true scientific management of work. When applied with rigor, being aware of what values and principles imply, and respecting the spirit of Scrum, the results are amazing. Scrum’s popularity is not accidental: it is not a magic solution, but it is a good way to discover our problems and give us the ability to solve them, instead of having someone else do it for us.

Download complete infographic

¿Do you want to know more about Scrum practices?

We recommend the “Agile Fundamentals” training, a 24h course to start learning the knowledge and skills of Scrum and Kanban, accredited by ICAgile.

Go to agile fundamental course