What does Scrum mean – What is Scrum?
Scrum has been the most widely used Agile framework since its inception and still is today. Its popularity is demonstrated by the fact that the word Scrum is sometimes used as a synonym for Agile, which unfortunately leads to many misunderstandings. It is therefore important to clarify the difference between the two concepts and their exact relationship.
What is the Scrum framework?
Scrum is a simple, lightweight framework that provides practical answers to the question of how to implement Agile values, principles and an Agile mindset in product development. If you are unfamiliar with these concepts of Agile, we suggest reading our article – What Does Agile Mean – before you proceed.
What is a framework?
As the term implies, Scrum is not a detailed, prescriptive set of rules or a methodology that defines even the smallest details of product development. The professed goal of the creators of Scrum is to provide product development teams with a tool that can be used across the widest range of industries. Thus, although, like Agile, it was born in the software industry, contrary to popular belief, Scrum does not include any software development or programming techniques. It merely sets out a framework and the main cornerstones of a product development methodology that can therefore be used to put agility into practice. What are these cornerstones?
– The Scrum values
– The roles, i.e. the essential participants in product development, their tasks and responsibilities
– Events, i.e. formal events held at regular intervals during product development, their purpose and structure
– and the Scrum Artefacts, i.e. the valuable deliverables (such as the product itself) that are produced while running the framework
The relationship between Scrum and Agile
It is particularly important to distinguish between Agile and Scrum because their application areas do not fully coincide. Only a portion of the organisations and teams that could benefit from the Agile mindset and approach have the conditions and prerequisites that are essential to use Scrum. So, to recall a familiar pattern from elementary school, we can say that all Scrum teams are Agile, but not all Agile teams are using Scrum. (To be on the safe side, let’s state that not all teams who say they are using Scrum are really working in Scrum.) A good Agile consultant will therefore never “sell” Scrum to a client, but will always look for the Agile framework that is most appropriate for the specific situation.
At the end of this article, we will discuss the prerequisites for implementing Scrum.
The Scrum Guide
In contrast to the Agile Manifesto, the official description (the rules of the game) of Scrum, the Scrum Guide is a copyrighted document that is regularly updated. Its authors are Jeff Sutherland and Ken Schwaber, still active consultants who maintain the Scrum Guide based on their own personal experience. The main reasons for changes to the framework:
– Clarification. Particularly in the first versions, certain elements of the framework needed clarification and more detailed explanation.
– Generalisation. With the increase in the number of teams and industries using Scrum, it is becoming more and more apparent which approaches and formulations would tie the framework to IT, and which points need a more general approach and formulation.
– Simplification. Scrum is designed to minimise the prescriptive nature of the framework, so its creators are constantly looking for points where the framework can be further simplified. This is partly a good thing, as the simpler the framework is, the easier it is to understand (the current version of the Scrum Guide is only 13 pages). The downside of simplicity is that it gives a lot of freedom, so applying the framework to specific situations is often much more difficult, and the help of an experienced consultant is essential.
You can read more about this in our article about the changes in the latest version of the Scrum Guide.
What is the Scrum team?
The Scrum Team is a small product development team of permanent members (up to ten people). As indicated, the Scrum framework is not suitable for all environments. One of the most important prerequisites for using Scrum is a team of dedicated members working together towards common goals.
Scrum defines three roles, together they form the Scrum Team.
One person, the sole business responsible for the product. It is their responsibility to decide what the team develops.
A single person, the coach of the team and the whole organisation, with a thorough knowledge of the methodology. Responsible for the how of the product development process.
Professionals performing the technical tasks of product development. They are responsible for all technical decisions and the actual development of the product.
You can learn more about each role in our Scrum training.
How does Scrum product development work?
Scrum breaks down development into short (up to one month), equal-length time slices. Each of these time slices is called a Sprint, and the goal of each Sprint is to produce a valuable, potentially releasable product increment. So, unlike traditional methodologies, where a valuable product that can be delivered to the customer is only produced at the end of product development, Scrum produces a new, releasable, valuable product version during each Sprint, at least once a month in the worst case.
The second prerequisite of Scrum is being able to produce real customer value, a real deliverable, saleable product in such short time frames. In other words, the prerequisite is that the product can be delivered incrementally (in slices of incrementally increasing value). The easiest way to understand this is through two examples. A mobile game can easily be delivered incrementally: the first version has fewer levels and can only be played against the computer, but it is already fun. Later updates will add new maps and a two-player mode, further increasing the value of the game. But it’s not a good idea to incrementally deliver lasagne at an event of 300 people if it means that each guest gets five sheets of pasta first, a bowl of beef stew half an hour later, then a bowl of Béchamel sauce, and then finally the grated parmesan arrives as well. Not only do the individual portions lack value; once guests have received all the elements of the dish, they still will not be able to enjoy the whole meal.
If a team insists that their product cannot be incrementally developed and delivered, they may be wrong, often we just need to find the right breakdown of the product. In the example above, serving three hundred people can easily be done incrementally, we just need to think a little differently. Deliver full meals, but only to a portion of the guests each round. For example, for groups of fifty, with a quarter-hour delay between each round. Thus the “product” is easily broken down into smaller, valuable chunks.
When and for whom do we recommend Scrum?
So far, we have learned about two important prerequisites for Scrum: a dedicated and permanent team and an incrementally deliverable product. The third key prerequisite is estimability. In order for the team to be able to deliver in such small timeboxes, it is essential to be able to estimate the size of each little piece of work with a good enough degree of accuracy. Examples of items that cannot be estimated well:
– correction of an error of unknown cause. If, for example, my ceiling leaks, there can be a very simple solution (the upstairs neighbour is out of town and forgot to turn off the tap in the bathroom, I’ll call him to come home) or a very complex one (wall opening, pipe replacement, etc.)
– those researches where the time required for each experiment is unpredictable.
Again, we emphasise that although there are strong prerequisites for using Scrum, not all environments are unsuitable for Scrum implementation, which may seem to be at first sight. Often you just need to approach the issue from a new perspective.
However, it is essential that the whole organisation is involved, actively supportive and committed to the Scrum transformation’s success.
Scrum and Kanban – What is the difference?
The most common alternative to Scrum for organisations aspiring to become Agile is the Kanban methodology. The main difference between the two tools is that while Scrum implements development in strict timeboxes, with a fixed team and regular deliveries, Kanban approaches development as a continuously fed automaton, with tasks arriving regularly at the beginning of the automaton and solutions falling out one by one at the end. Kanban is even less prescriptive than Scrum. For more information on the two tools, see our earlier article, Kanban or Scrum? Which one should I choose?