Scrum is founded on empiricism
Repetition is the key to mastery
In a previous article, I discussed how Scrum promotes lean thinking. To manage complexity, Scrum also relies on empiricism.
Scrum is founded on empiricism and lean thinking. Empiricism asserts that knowledge comes from experience and making decisions based on what is observed. — SG2020
In a nutshell, empiricism means working in a fact-based, experience-based, and evidence-based manner. Scrum implements an empirical process where progress is based on observations of reality, not plans rooted in speculation.
Let’s explore what empiricism means in Scrum. To do that, we first need to understand what empiricism is.
Empiricism: a way of gathering knowledge
In philosophy, empiricism is a theory that states that knowledge comes primarily from sensory experience. Empiricism emphasizes the role of experience and evidence in the formation of ideas and acquisition of knowledge. That is, for empiricists, we are born with an empty mind and it acquires content as we perceive and experience through the senses. This view is aligned to the scientific method, which states that knowledge is probabilistic, falsifiable, and subject to continuing challenge.
- Knowledge is probabilistic, meaning that we can never be 100% certain that something is true. We know something if our confidence in it happening is greater than a threshold, say 95%.
We must act based on the best available knowledge. This leaves us almost entirely with probabilistic knowledge, which means we must act with confidence and caution appropriate to the probability, being especially careful in realms where knowledge is uncertain and consequences of error are large. […] I mean like this definition of probabilism: (noun, as used in philosophy) the doctrine, introduced by the Skeptics, that certainty is impossible and that probability suffices to govern faith and practice.
— Ed Gibney, in his blog on Evolutionary Philosophy
- Knowledge is falsifiable if it can be logically contradicted by observation. The purpose of falsifiability is to make a hypothesis predictive and testable, thus useful in practice.
- Knowledge is subject to continuing challenge because knowledge is reviewed and revisioned over time. The scientific method is an ongoing process of challenging knowledge. New observations raise new hypotheses. Challenging our beliefs, even if they are true, may lead us to real knowledge. This is visualised in the diagram below.
Examples of empiricism
We tend to understand empiricism within the realm of science. The image of someone wearing a lab coat, experimenting in a laboratory, comes to mind.
We can find other examples of applying empiricism in our daily lives:
- Learning a language:
— For a child, learning to speak depends a lot on experience. The child knows the words within the environment, listening to them and learning the meanings that others attribute to each one
— Learning additional languages (or simply improving in your mother tongue) requires experience. Studying words and grammar is necessary, but applying those concepts to real scenarios (in conversation or writing) is what makes them stick - Learning that something hurts or is dangerous:
— Knives are sharp. You can cut yourself. You can hurt others. It doesn’t matter how many times we heard this as kids. We didn’t understand until we cut ourselves (I have a scar in a finger that proves I learned the lesson)
— Fire burns. It is so obvious it sounds stupid. To a kid, however, fire is fascinating (at least it is to my 6-month-old daughter). Despite being told not to touch it, sooner or later she will burn her hand trying to touch it and then she will learn that she should not do it anymore
- Learning by trial and error:
— Learning to walk, learning to ride a bicycle, or learning martial arts. These are examples of learning by rehearsing something over and over again until we find the way that gives the best result
—Learning to play a game. To win at a game (or, at least, to play better) we need to become familiar with the rules of the game and apply them in different ways to see what strategies are useful
—Making different decisions results in different outcomes. In the image below, a kid has learnt that choosing a different menu option was a mistake
The risks of empiricism
Using evidence to show what has happened is not as straightforward as one might think. We can gather a lot of data and still reach the wrong conclusions. Some examples of risks associated with using data to make decisions are:
- Confusing correlation with causation. When two things are related it is tempting to think that one causes the other.
- Cognitive biases can invalidate results or conclusions. It is not easy, but sometimes it is better to approach a problem without any assumptions or expectations, relying solely on empirical evidence. This approach is known as Naïve Empiricism.
- The quantitative fallacy is the mistaken belief that something must be true because it is supported by numbers. Being exposed to manipulated statistics can cause this fallacy.
- Avoiding to experiment “because we know we’re doing this right”. Certainty brings complacency. The biggest risk is posed by those things you are completely sure about. Complexity is the realm of the unknown unknowns. Unknown unknowns are risks that come from situations that are so unexpected that they would not be considered. Experiments should be designed to raise those unknown unknowns so we can be aware of them. We can’t consider what we are not aware of, and that limits our learnings.
Empiricism and Scrum
Sjoerd Nijland has written extensively about Scrum in his Road to Mastery series. He discusses in great detail what the empirical pillars of Transparency, Inspection and Adaptation mean in Scrum. The Road to Mastery is a rabbit-hole of wisdom and I want you to keep reading, so I reserved a section at the end of the article for the relevant links to his articles. 😉
For now, let’s see how Scrum promotes empiricism.
Scrum promotes hypothesis validation through experimentation
In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision making — SG2020
Scrum Teams pursue a single Product Goal at a time. This long-term objective acts as a target for Scrum Teams to plan against. Product Goals can be seen as the complex problems that Scrum Teams aspire to solve. To navigate complexity and to decrease uncertainty requires incremental delivery. The cone of uncertainty shows this relationship.
[…] the more the Developers know about their past performance, their upcoming capacity, and their Definition of Done, the more confident they will be in their Sprint forecasts.
— SG2020
Discovering how to build an Increment that solves a complex problem requires experimentation. The Scrum Team is responsible for designing and executing the necessary experiments to:
- Gain confidence that they are building the right product or produce evidence that supports a strategic change (solving the right problem). In other words, the goal is to know more about the product.
- Perfect the skills required to build quality products (solving the problem right).
To increase the reliability of the results, experiments need to be carried out in a container. In Scrum, the Sprint serves as a container for the experiments that the Scrum Team wants to carry out:
- Sprint Planning initiates the Sprint. During Sprint Planning, hypotheses are formulated and the details to carry out the experiments emerge (why, what, and how).
- The Scrum Team work to build a valuable, useful Increment by the end of the Sprint. During the Sprint, the Scrum Team execute the necessary experiments.
- The purpose of the Sprint Review is to inspect the outcome of the Sprint and to present the results of the work of the Scrum Team to key stakeholders. During Sprint Review all participants discuss the results of the experiments carried out during the Sprint. Based on that information, participants hypothesise on what the next steps could be.
- The Scrum Team may have decided to execute experiments related to their process during the Sprint. In that case, the Sprint Retrospective serves as space to discuss the results and generate new hypotheses.
Scrum is designed to reduce the risks associated with empiricism
In the face of the unknown, when we are uncertain if things will go well under complex circumstances, the wisdom of a group tends to be more reliable than the wisdom of an individual.
To reduce the risks associated with empiricism mentioned earlier, Scrum promotes collaboration and cross-functionality. Scrum Teams are cross-functional and self-managing. They are accountable for creating a valuable, usable Increment every Sprint. Also, they collaborate with stakeholders at the Sprint Review on what to do next based on data.
“In God we trust. All others must bring data.” — W. Edwards Deming
The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed. During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next.
— SG2020
These conversations should be accompanied by data. Different indicators and measures serve as input for the event. If a single person were to analyse all the information to produce a decision, there would be a great risk of falling into the trap of cognitive biases or fallacies. Instead, the collective intelligence of the group tends to balance out the individual biases.
This is also true for the remaining Scrum Events. During Sprint Planning and every day of the Sprint “decisions are made based on what is observed”. The collective wisdom of the Scrum Team favours a holistic view of the Product and the challenges associated with producing an Increment that fulfils the Sprint Goal.
Scrum promotes learning by doing
Scrum is a lightweight framework. It is intended to guide you in your quest to find the best way to maximise the value of your product. To succeed, Scrum Teams need to experiment and learn, exactly like in games. The Scrum Guide contains the rules of the game.
In a nutshell, Scrum requires a Scrum Master to foster an environment where:
1. A Product Owner orders the work for a complex problem into a Product Backlog.
2. The Scrum Team turns a selection of the work into an Increment of value during a Sprint.
3. The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.
4. Repeat
Scrum is simple. Try it as is and determine if its philosophy, theory, and structure help to achieve goals and create value.
— SG 2020
Every activity in that list has a learning curve:
- Product Owners need to learn how to translate complex problems into Product Backlog items. They need to learn how to craft meaningful Product Goals that capture what is most valuable for stakeholders and customers.
- Scrum Teams need to learn how to create high-value Increments every Sprint. Scrum Teams need to learn how to reach a high-performing state. This is easier said than done. An image of Tuckman’s stages of group development comes to mind.
- Scrum Teams and their stakeholders need to discover the best way to interact to focus on building the right thing, right.
Succeeding with Scrum requires becoming a pro at playing the game.
Scrum is simple, but difficult to master. As a Dark Souls fan, I can only say this: “Git Gud”.
P.S.
As promised, here are the links to the Road to Mastery series that dive deeper into the empirical pillars of Transparency, Inspection and Adaptation in Scrum:
