Why Scrum is not a Process

Job advertisements for Scrum Masters can now be found across all industries. Not all of these advertisements describe the activities of a Scrum Master correctly, and often the agile maturity level of the company can be seen from the chosen phrases. One common mistake concerns the description of the Scrum Master as the person responsible for the implementation and execution of the “Scrum process“. This article explains why Scrum is not a process and how the development process of a company can be embedded in Scrum.

How Scrum is Defined

Let’s first take a look at how the Scrum Guide itself defines Scrum. This gives us a valid and solid starting point for our considerations.

Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.

Scrum is a framework that helps us to find solutions for problems. Already the definition of the Scrum Guide clearly indicates that Scrum is not a process. Furthermore, the Scrum Guide also establishes a relationship to the processes within an organization.

Various processes, techniques and methods can be employed within the framework. Scrum wraps around existing practices or renders them unnecessary. Scrum makes visible the relative efficacy of current management, environment, and work techniques, so that improvements can be made.

Scrum therefore has the ability to be integrated with existing processes and procedures of an organization. It provides the organization with basic rules and a framework in which requirements are transformed into a product through the development process. Let’s now take a closer look at why Scrum is not a process, what it offers organizations as a framework and how existing processes can find an implementation in Scrum.

Why Scrum is not a Process

Let’s first take a look at the definition of a process. This will give us our first clues as to why Scrum is not a process. The American National Standards Institute (ANSI) defines a technical process as follows.

In engineering, a process is a series of interrelated tasks that, together, transform inputs into a given output.
ANSI/EIA-632-1998 Processes for Engineering a System, Appendix A, p66

A very similar definition is provided by the German Institute for Standardization (DIN).

Totality of interacting processes in a system by which matter, energy or information is transformed, transported or stored.
DIN IEC 60050-351: Internationales Elektrotechnisches Wörterbuch – Teil 351-21-43: Leittechnik

As we can see, a process includes all operations within a system that are necessary to convert, transform or process a given input into a corresponding, desired output. In the Scrum Guide, however, there is no statement about even one of these points. Accordingly, Scrum cannot be a process by definition. This raises the question what Scrum is then. Let us now take a look at what Scrum offers an organization in terms of methods and tools, and how these differ from a process.

What Scrum Provides to You and Your Team

The Scrum Guide defines the following added values for Scrum teams. The five Scrum Events, the five Scrum Values, the three Scrum Artifacts and the three specific responsibilities of the Scrum Master, Product Owner and the Developers.

In order to understand why Scrum is not a process, we need to take a closer look onto the five Scrum events. The Sprint serves as a container for all other events. Here, the Sprint creates a framework for short iteration cycles and thus also for short feedback loops.

The Sprint is framed by the three events Sprint Planning, Sprint Review and Sprint Retrospective. Within this frame, the requirements from the Sprint Backlog are processed into the Increment. The Daily Scrum creates even shorter planning and feedback cycles on a daily basis. The number of Daily Scrum events within your Sprint depends on the length of your Sprint, obviously.

As we can see, Scrum itself does not define the development process, but it defines a framework within which processes can be established. Let’s see how Scrum and processes combine with each other.

How Scrum and Processes Combine

The five Scrum Events form the PDCA cycle in a Scrum organization. To be able to shed more light on the combination of Scrum and processes, we need to take a closer look at the Scrum Events and the purpose they serve.

During Sprint Planning, the Scrum Team creates the Sprint Backlog from four inputs. Those are the Increment of the last Sprint, the Product Backlog, the teams velocity and its projected capacity for the next Sprint. As a result, the Sprint Backlog is the Scrum Teams mid-term plan for the tasks to be completed in the coming weeks.

In the Sprint Review, the Scrum Team and the stakeholders examine the result of the last Sprint. Here, a look is taken at the Sprint Backlog and all done tasks. The Increment is inspected and it is discussed which tasks and steps can be implemented next in relation to the product. The result is a revised Product Backlog. This in turn serves as input for the next Sprint Planning.

In the Sprint Retrospective, the Scrum Team inspects itself, its processes, tools and techniques. The focus is on possible improvements that can be implemented in the next Sprint or one of the subsequent Sprints. These are added to the Product Backlog as tasks and can therefore also appear in the next Sprint Backlog after Sprint Planning.

In contrast, the Daily Scrum implements a small PDCA cycle on a daily basis. Here the review of the results of the last day and the planning of the next steps are handled in the same event. The goal of the Daily Scrum is the creation of a plan for the tasks that the Scrum team wants to complete in the next 24 hours. Here, a very short feedback loop is established.

The connection between Scrum and the development processes of an organization is now slowly becoming clearer. At the beginning of a sprint, Sprint Planning serves a Scrum team as a planning event. Here, the requirements to be realized are selected and summarized under a clear Sprint Goal in the Sprint Backlog. At the end of each Sprint, the increment is reviewed and the next implementation steps are discussed in consultation with the stakeholders. This results in a revised version of the Product Backlog.

However, there is one question that is not answered by Scrum. This is the question about the way in which requirements are transformed into increment. This happens through the development process. This process varies from organization to organization. It can even be different between teams of the same organization.

Scrum and its values, artifacts, events and responsibilities are the same for all organizations in the world. The development process is the set of steps, procedures and rules by which a requirement is transformed into a part of the final product. This process is not defined by Scrum. That’s why Scrum is not a process. Scrum provides an organizational framework and foundation for the implementation of the actual development process.

Abschließende Gedanken

Now that we have highlighted the difference between Scrum and a development process, there is still room for some concluding words. Scrum offers teams a framework with short feedback loops to structure their process organization. This framework is formed by the Sprint and the other four Scrum events. Within this framework, it is up to the teams and organizations to define effective and efficient processes. In fact, the implementation of waterfall processes within Scrum would also be possible, although not recommended for reasons of risk minimization. (Please choose and define your processes responsibly!) Scrum is not a process – this fact makes Scrum so universally applicable and allows combinations with many different process models and other frameworks.