Empiricism in Scrum: Rational Decision Making

Do you sometimes feel like your team is making irrational decisions? Is there a tendency toward emotional reactions or making mountains out of molehills? Your team may benefit from a dose of empiricism.

What is Empiricism?

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

I compare this to the scientific method we learned about in grade school. We started with a question, did some research, came up with a hypothesis, ran some tests, analyzed the outcome, and drew some conclusions.

The empirical process is very similar but focuses on experience.

Using an empirical approach, we might start by identifying an issue that negatively affects our ability to deliver customer value. Researching the problem, we’ll think about what we know about our current processes. We’ll seek to find any tangible information that will help us reach a root cause analysis and decide how we might resolve the problem. We’d leverage the experience of others on the team to determine possible solutions.

When forming a hypothesis, we’ll try to tie the evaluation to something measurable. We’ll try our idea for one to two sprints and evaluate how that change affected our measurement. Based on the outcome of that test, we might make another tweak to our process. We should take an iterative approach and repeat this process until we’re satisfied with our test’s outcome.

The key takeaway is that our actual experiences drive our decisions, and we evaluate the success or failure of the experiment on factual evidence. We don’t just do things because we read them in a book, and we don’t just stop doing something because it feels like they aren’t working. We make an effort to prove or disprove our assumptions based on data, and we evaluate to determine if we’re moving in the direction we’d hoped.

The Three Pillars of Empiricism

Transparency, inspection, and adaptation are referred to as the three pillars of empiricism because, without all three, empiricism is unattainable.

Since these concepts are essential to empiricism, let’s talk about each in depth.

Transparency

Transparency has to do with the visibility or accessibility of information.

Depending on the environment, transparency can be a real struggle. It can be hard to have the courage to be open about information people don’t want to hear.

When we have true transparency, we’re presenting the facts as is - sans hidden agendas. Anyone can access the information without cutting through a ton of red tape.

Making a Sprint burndown chart accessible by anyone in the organization is an example of transparency.

Inspection

Inspection in Scrum is the review of any artifact that provides information pertinent to help us improve our people, processes, or tools.

If transparency is about having access to unbiased information, inspection is about actually reviewing that information. We want to see our current position vs. our target.

Sticking with the burndown chart example, inspection might involve reviewing this information radiator in the daily standup to determine if we need to adjust our plan to hit our Sprint Goal.

Adaptation

Adaptation in Scrum happens due to inspection coupled with a desire to affect change on the thing we’re inspecting.

If inspection is about reviewing information, adaptation is about deciding to change something based on the information we’ve reviewed.

We want to frequently look for changes that can make us better today than yesterday. As a result of adaptation, we can achieve continuous improvement.

“If you always do what you’ve always done, you always get what you’ve always gotten.”

-Jessie Potter

Empirical Process Control

All three pillars of empiricism (transparency, inspection, and adaptation) are required for empiricism to be successful. It’s essential to know how each aspect of empiricism is interdependent on the other to identify and resolve gaps we may have to harness each pillar.

Inspection without transparency

Transparency requires an element of honesty and access to the information, which includes the need to be honest with ourselves.

After purchasing my first home, I decided it might be good to sit down and make a budget. Homeownership comes with many additional bills that I’d not had to manage in my previous life as a renter, and I wanted to feel a bit more comfortable that I’d be able to afford to buy food and keep the lights on. So I sat down and made a list of my bills and totaled them up. I then compared that total to my monthly paychecks and confirmed I made enough to cover my bills.

So imagine my surprise when I ended up with $20 left in my account and an $80 electric bill. On top of that, I still had to worry about grocers and gas for the week. So, what went wrong?

As it turns out, I was spending a lot of money that I hadn’t tracked in my plan—going out with friends, rushing through the drive-through on a busy day. These things add up over the month, and I hadn’t accounted for them in my budget.

My budget inspection lacked transparency, and as a result, I missed my target of paying my monthly bills.

Inspection without transparency may result in an incorrect understanding of the situation.

Adaptation without Transparency

I once was part of a traditionally managed project team that was massively behind due to scope creep. Executive leadership kept pushing the team to hit a deadline dictated by a contract with a consulting firm. If we didn’t hit that deadline, we’d need to give the consultants more money to stay engaged, which everyone wanted to avoid.

Our project plan indicated that we constantly missed delivery dates, and executive stakeholders began questioning our team’s efficacy. Based on this perception that our development team was behind, talks were underway to bring in contractors to increase the team’s throughput.

Then we had a bit of a paradigm shift. After looking closely at our project plan and doing some root cause analysis on why dates were slipping, the team determined that requirements were missing. In many instances, development hadn’t started because we didn’t have clear requirements. However, nothing on the project plan indicated we were waiting on requirements, so it’s only fair to say that leadership was just trying to make the best decision based on the information they had at their disposal.

If we had brought in contractors, we would still have missed our start dates because the contractors wouldn’t have had what they needed to do the work either. Even worse, our developers would have needed to split their focus between finishing the project and onboarding the new developers.

Adaptation without transparency may result in making matters worse.

Transparency without Inspection

In a past role, motivated by an article I once read about information radiators, I decided to build out some elaborate dashboards. The idea was that stakeholders would be able to see the progress we were making at a glance. We could begin to direct questions the team was fielding about when we’d finish to these dashboards, and it would improve overall trust with our stakeholders.

I spent a ton of time researching how to best display this information given our tools, work structure, and typical requests for updates. I built out all these elaborate dashboards in Azure DevOps, and I’m chagrined to admit I was a little proud of myself.

As you can imagine, the stakeholders never looked at these dashboards. They were offended that we even mentioned that this information was available via other means in most cases. No amount of coaching or cajoling would convince them that looking at this information was better than just interrupting Harry to ask when he’d be done.

Now, there are a lot of issues with this situation that are clear to me in retrospect. However, the point that is particularly relevant here is that there can be a lot of waste in creating transparency if there is no intention of reviewing it.

Transparency without inspection may result in wasted effort.

Adaptation without Inspection

I was once part of an agile transformation where the best way I can describe it is to say that a command and control culture accidentally hired an agile coach.

Before this new person joined the company, it seemed to be popular opinion that the development team couldn’t get any work done. From the development team’s perspective, the popular opinion was that constantly changing priorities were the culprit.

Once the new leader started in their role, the teams went through an agile transformation. The development team rebooted their process, shifting to a more strict following of Scrum. We instituted a portfolio management process where initiatives were stack ranked with the expectation that we would work them in order.

It’s a funny thing, though, how some wounds take a while to heal. The team was so accustomed to changing priorities that we continued to point to that as a blocker to progress. Even the new leadership had bought into this as the root cause of our predictability woes. Eventually, I was approached and asked to analyze the notes from the past six months’ portfolio management meetings to determine how often leadership had decided to switch the focus of the team.

Now, I’ll be honest, at first, I wasn’t sold on this exercise. I foresaw that we’d come up with a list of twelve times things shifted, and I worried that the only purpose of such a list would be to fling blame. If we need to have a conversation about changing priorities, I felt it could happen without building a case. Going into that discussion loaded with evidence as if it were exhibit A in a murder trial seemed like it went against the value of collaboration over contract negotiation. I just couldn’t see how this would end well. I voiced my concerns but acquiesced to the request out of respect.

I poured through six months of emails comparing the top 10 priorities week after week, noting the shifts. And I was shocked at the outcome.

As it turns out, the team’s priorities shifted zero times.

Now granted, this isn’t what anyone expected, and I believe the agile coach expected to find several instances of shifts. If we’d gone ahead with that discussion as I thought was best at the time, we would have been unjustified in our stance. We were on a mission to solve a non-existent problem.

This just goes to show that adaptations without inspection may result in focusing on the wrong problem.

Inspection without Adaptation

Like most Americans, I’ve struggled with my weight for most of my adult life. I blame my love of fried chicken (especially from Lee’s in Mt. Sterling, KY). Like many others, I’ve tried various schemes and other tactics to drop the pounds.

I recall several “healthy eating” days when I hopped on the scales and saw no change. Depressed by this revelation, I’d decide to get an Oreo Blizzard from Dairy Queen.

I can’t say I’m proud of all of my decisions.

Faced with relatively the same weight every day, it can be hard to feel like you’re making progress. It’s easy to fall back into comfortable habits and assume that change isn’t possible.

But by not making a lasting change, you’re exiling yourself to this Groundhog’s Day existence of experiencing the same letdowns repeatedly.

This is why experts recommend that you weigh yourself once a week and not every day.

Inspection without adaptation may result in demotivation.

Transparency without Adaptation

Sticking with the whole weight loss theme, I went through several phases of tracking my food intake. Armed with data, I thought I’d be more motivated to make lasting change. However, I had a terrible tendency to follow the same patterns. Unfortunately, the three calories I burned logging those Blizzards were nowhere near enough to drop any weight whatsoever. If I genuinely want to see a significant change in my weight, I can’t only track my intake, but I need to adjust my eating habits such that the calories I consume fall within acceptable limits.

This point may seem obvious, but there are a lot of agile teams going through the motions of reviewing metrics but not using them to make decisions. They check their velocity or look at the burndown chart, but they don’t take the time to think about what it’s telling them and how they can make adjustments to move the needle in the desired direction. Eventually, we don’t even think about why we have access to information.

Transparency without adaptation may result in complacency.

Works Consulted

• The Three Pillars of Empiricism (Scrum)
• There’s value in the Scrum Values
• Quote Investigator

TLDR

The next time you need to make a decision, try being more empirical. What can our past experiences tell us about the situation? Look for metrics that might help establish a trend in team performance. Can we set a target and track progress toward our goal? Do we have access to data that will provide insights? Our decisions will be much stronger when based on factual evidence instead of emotional assumptions.