Scrum and the Agile Manifesto

Agile Manifesto

Scrum has been around for a long time, longer even than the Agile Manifesto, which describes what Agile “means”. To many, Agile and Scrum go together like a horse and carriage, which isn’t completely true, of course. It’s absolutely possible to be Agile and not use Scrum.

Somewhat paradoxically, Scrum seems to be criticised lately for not being “Agile” (enough). It is deemed too prescriptive, and for that reason doesn’t measure up to what some people consider to be the meaning of Agile. I thought I’d examine this using both the Scrum Guide and the Agile Manifesto as yardsticks.

The agile manifesto defines four guidelines:

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

Each of the guidelines should be read keeping in mind the following:

“That is, while there is value in the items on the right, we value the items on the left more.”

This is important, because it implicitly says that, for example, creating documentation is completely acceptable, it should however never become the goal; the goal is working software. This holds for all four guidelines: the item on the left trumps the item on the right.

Now, let’s see how Scrum measures up to these guidelines.

1. Individuals and interactions over processes and tools

Scrum is defined as a framework: “a basic structure underlying a system, concept, or text”. The framework defines a container called the Sprint, and four events where individuals can and should interact: Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. It defines time boxes for each of the events, but doesn’t address how each event should be carried out.

It does however prescribe the order of events, so in this respect you could view it as a process (“a series of actions or steps taken in order to achieve a particular end.”). The particular end, in this case, is the Increment and some form of improvement. Funnily, the Scrum Guide itself has a couple of mentions of the “Scrum process”, sometimes denoted as the “Scrum process framework” (see: Sprint Retrospective). Scrum’s foundation lies in empirical process control, which is described in the Scrum Guide. Ironic, isn’t it?

Still, Scrum really doesn’t prescribe that much in terms of process, and definitely not in terms of tools. Sure, the “Scrum process framework” is immutable, deviating from it means you are no longer doing Scrum, but other than that Scrum implementations have many freedoms when it comes to processes and tools. Pair or mob programming are not only allowed, but even encouraged, and the same goes for TDD or other testing and programming practices. But in the end, the events defined in Scrum are mainly targeted at interaction: bring people together and communicate about what’s going on.

You don’t have to stop there, because Scrum doesn’t say that these are the only allowable events for interaction, just the minimum.

2. Working software over comprehensive documentation

The word ‘documentation’ isn’t mentioned once in the Scrum Guide. Working software, however, is implied in the output of the Scrum process: the Increment. Scrum is not restricted to building software, but it is mentioned as one of the uses of Scrum. That the output of the Sprint should be ‘working software’ can be inferred from this sentence in the Scrum Guide: “The increment must be in usable condition regardless of whether the Product Owner decides to release it.”

Naturally, comprehensive documentation can be created, but it may never get in the way of creating a usable increment.

3. Customer collaboration over contract negotiation

The customer plays an important role in Scrum. The Sprint Review is an event where key stakeholders (who are or represent the customer) should be invited by the Product Owner to inspect what was done in the Sprint. They can provide feedback and collaborate with the entire team “on the next things that could be done to optimize value”.

Scrum doesn’t say anything about ‘contract negotiation’.

4. Responding to change over following a plan

Scrum is designed to contain risks. The absolute maximum time a Sprint may ever take is one month, and as such the business risk is contained to (at most) one month. However, many companies have decided to use shorter sprints, because they feel one month is too long. Common Sprint lengths are one or two weeks. All events, save the Daily Scrum, are shortened accordingly, e.g., the Sprint Review would be time boxed to two hours for a two week Sprint.

During Sprint Planning, the team constructs a plan for the upcoming Sprint, and decides on the Product Backlog items that should be worked on. This combination of Product Backlog items and the plan to deliver the increment is called the Sprint Backlog. These should be chosen in such a way that they contribute to reaching the Sprint Goal. The Sprint Goal provides guidance to the team as to the why it is building the increment.

Now, a common misunderstanding is that the Sprint Backlog is immutable during the Sprint. This is not true. The Sprint Backlog evolves during the Sprint. New work may emerge, which is added to the Sprint Backlog. Items that are no longer necessary can be removed from it. Still, this should always be viewed in light of the Sprint Goal.

To some, this may still seem rather rigid. How is responding to change valued more than sticking to the plan, even if we can respond after only a short time (max. one month)? Well, there is an important rule that handles rapidly changing circumstances: a Sprint can be cancelled if and only if the Sprint Goal becomes obsolete.

The plan may be discarded if the ‘why’ of building the increment for the current Sprint is no longer sensible. If circumstances change and sticking to the plan no longer makes sense from a business perspective, the Sprint should be cancelled. However, “due to the short duration of Sprints, cancellation rarely makes sense.” It really is a last resort.


In my opinion, Scrum adheres quite closely to the four guidelines stated in the Agile Manifesto. Sure, the Scrum framework itself is immutable, but it still provides enough freedom to learn from the past and implement changes to do better in the future.

For many companies, doing Scrum right is already quite a challenge for various reasons. For those companies, having a well-defined process framework may be quite suitable, because it fixes a few degrees of freedom, allowing teams to focus on creating value for the customer.

For extremely mature organisations, Scrum may pose too many limitations. In this case, it makes sense to move away from Scrum, at which point you should stop calling what you’re doing Scrum.

Wherever you are in this spectrum, Scrum definitely provides the agility within the guidelines of the Agile Manifesto.

End note

In addition to the four guidelines, the Agile Manifesto also provides twelve principles. In a future post, I may discuss how Scrum holds up to those, completing a more comprehensive picture of Scrum within the Agile Manifesto.