Scrum Pillars: Enabling Empiricism

September 14, 2022

5 min read

Without bacon, lettuce, and tomato, there can be no BLT, and without transparency, inspection, and adaptation, there can be no empiricism.

Scrum Pillars

The three pillars of empiricism reference the foundational principles of transparency, inspection, and adaptation. They are powered by the Scrum Values of focus, openness, respect, courage, and commitment.

Since the Scrum framework relies on empirical process control, which in turn depends on these three pillars, the three pillars are sometimes referred to as the Scrum pillars or the three pillars of Scrum.

Pit bull missing front left leg — This dog is doing fine with his three remaining legs, but he would be rendered immobile if he were to lose one more.

The image of pillars signifies that all three are required to lend support. If we remove any of the three, empiricism, and therefore Scrum, comes crashing down. If your culture lacks either transparency, inspection, or adaptation, it will lack empiricism in Scrum.

Empirical Process Control

It’s easier to understand what empirical process control is by starting with understanding defined process control. In defined process control, you follow a defined process step by step and are confident the process will result in the same outcome.

With empirical process control, you’re learning as you go. You don’t know the exact steps required to accomplish the desired outcome and are left to experiment, learn, and figure it out as you go.

Puzzled chef holding bright red spiny fish — A lot of trial and error goes into creating a new recipe. But once you discover the perfect combination of ingredients and directions, you can follow the same steps and know that they'll produce the same dish. Creating a recipe is empirical process control. Following an established recipe is empirical process control.

Leadership is sometimes confused by how difficult it is to build working, valuable software. As professional developers, we do this every day. We’ve done this before; why does every day seem to bring a new struggle?

Although we may have previously built software, we haven’t built this software. Every day is a new struggle because we’re doing something new every day.

Just like the process we follow when developing a recipe differs from the process we follow when executing an existing recipe, the process we follow when building new software must allow for empiricism.

Empiricism vocabulary card

Empiricism is a manner of working that values experience and bases decisions on factual evidence.

We need room to experiment, learn, and figure out what works best.

One of the common criticisms I hear of the Scrum framework is that it’s rigid and inflexible. Another common complaint is that the process isn’t detailed enough on the specific steps needed to succeed. These two criticisms always crack me up because they’re practically making the exact opposite claims, and how can both be accurate?

But I think a rudimentary misunderstanding of Scrum leads to both of these opinions. Scrum doesn’t tell you exactly how to do everything because that is something that will be unique to your team and your organization. Scrum is just a framework that helps you work through this continuous discovery process.

“Scrum is open-minded. If something isn’t working, there is a very simple guideline: inspect and adapt.”
-Ilan Goldstein

Scrum is what you follow when you’re trying to develop a recipe, and there is no recipe that you can follow when you’re formulating the recipe.

Scrum works for all development teams because it’s a general framework. I compare it to the scientific method. The scientific method has general applications because it’s just a framework that helps you execute an experiment, just like Scrum helps you continuously develop whatever process applies to your team and organization. There isn’t just one perfect process we’re looking to uncover; business needs are constantly changing. To keep up, we also need to change our processes continuously. An empirical approach helps us respond to constant change and allows our workflow to emerge.

“To improve is to change; to be perfect is to change often.”
-Winston Churchill

Although I tend to focus on the process side of things when discussing empiricism, these concepts also apply to individual Product Backlog Items. Each user story we take on will have a mini-experiment and learning process. Do we understand this requirement? How can we remove ambiguity? Is this working as designed? At every step throughout our SLDC, we’re incrementally applying what we’ve learned to date so that we can create valuable working software.

“These important elements are applied to both the product under development and the development process being utilized to ensure that continuous improvement is occurring across the board. “Inspect and adapt” is Scrum’s core mantra.”
-Ilan Goldstein

Transparency

In Essential Scrum, Kenneth Rubin defines transparency as:

Transparency vocabulary card

One of the three pillars of empirical process control; open access to the unbiased information required for inspection and adaptation.

The Scrum Guide has this to say about transparency:

“Transparency enables inspection. Inspection without transparency is misleading and wasteful.”
-Scrum Guide

My husband has perfected his kick-ass chili over the years. It’s better now than when it started, and there have been times he tried something that didn’t work.

As I pointed out before, the process of developing a recipe is different than the process of executing a recipe. The first step toward trying a new experiment with the chili was for my husband to be transparent about what was different.

Was shrimp added? Is he just trying a new cooking method (crockpot vs. stove top)? Did he change the heat level of the added beans from mild to hot? Before we can make any decision on whether this experiment was successful or not, it’s helpful to know what changed.

Without transparency, we might base our feedback on guesses or preconceived ideas instead of observations of reality.

Inspection

In Essential Scrum, Kenneth Rubin defines inspection as:

Inspection vocabulary card

One of the three pillars of empirical process control, involving thoughtful examination and processing of feedback to make adaptation decisions regarding the process or product.

The Scrum Guide has this to say about inspection:

“Inspection enables adaptation. Inspection without adaptation is considered pointless. Scrum events are designed to provoke change.”
-Scrum Guide

Each time my husband runs a new chili experiment, he interviews each of his consumers. Can we tell the difference? If so, is it better or worse than the chili we had last time? What did we learn from this taste test? Maybe someone chokes on jalapeños or is allergic to shrimp.

Some Scrum teams track metrics hoping that the information will help them improve, but they never look at that information critically. This would be like my husband never asking what anyone thought of the chili. He’s blinding trying all these different things but never soliciting feedback. How would he know what worked and what didn’t?

Adaptation

In Essential Scrum, Kenneth Rubin defines adaptation as:

Adaptation vocabulary card

One of the three pillars of empirical process control; feedback is used to make an adjustment to the work product being developed or the process by which it is being developed.

The Scrum Guide has this to say about adaptation:

“Adaptation becomes more difficult when the people involved are not empowered or self-managing. A Scrum Team is expected to adapt the moment it learns anything new through inspection.”
-Scrum Guide

The last step of my husband’s chili experiments is always to decide whether the change was a keeper or not. Shrimp was too much effort, and Hermione was allergic, so that’s probably a no-go.

Adaptation is a crucial step that I think a lot of teams forget. They’re tracking data and discussing it, but they never really get around to changing their process to accommodate what they’re learning and make any decision. This lack of adaptation is also a common issue in Sprint Retrospectives. The event turns into a complaint session, but no change ever happens. Retrospectives without adaptation are worse for a team than skipping the Sprint Retrospective altogether. Eventually, the meeting intended to make positive change turns into an echo chamber of negative feedback.

This would be like my husband ignoring all the feedback we gave him on the chili. If he was going to do whatever he wanted, why waste our time? Also, if he starts junking up his chili with pasta and potatoes, I, for one, will not continue to be a satisfied customer.

Works Consulted

TLDR

Transparency, inspection, and adaptation are the three Scrum pillars. They support empiricism in Scrum, the basic foundational model that Scrum leverages to tailor the framework for your team and organization. For your empirical process to be successful, you can’t miss any of the pillars, just like a BLT isn’t a BLT if it’s missing bacon, lettuce, or tomato.