How fear can destroy empiricism
And the surprising effect taking risks has on psychological safety.
Our fear was building, and it was resulting in irrational behavior. The statements coming from my team members were crazy:
“We should demo our work even though we are not done. We can finish it next Sprint.”
“If we demo around the known defects, we can still show we made progress.”
“We can be ‘Done’ if we take on technical debt. We can pay it back in later Sprints.”
“We can’t have a zero for velocity this Sprint. This will tarnish our consistent track record. What can we do to recognize velocity for the work we have done?”
“Can we count velocity for what interrupted our Sprint?”
My Scrum team was at the end of its Sprint. The outlook was grim. We were certain no Product Backlog items would be “Done” before the end, and we would not achieve our Sprint Goal.
We were having an anxious discussion in the last Daily Scrum. The Sprint Review was coming up in the afternoon. And we had nothing to review.
The reason nothing was “Done” — an escaped defect — received no discussion. We discovered the defect in a feature developed two Sprints back. This feature formed the core of our rules engine. If we had not stopped to fix it, the entire release would be in jeopardy as no future features would work as intended.
We decided there was no option but to stop and fix the defect. After discussing with our Product Owner, we halted the current Sprint and swarmed to fix it. The defect was tricky and had ripple effects on several already completed features.
Fixing the defect was the right decision. But as a result, we were not delivering what we intended to deliver. Our stakeholders treated our Sprint as a commitment; the impending failure frightened us.
Not long ago, we decided as a team we would only review items meeting the Definition of Done in the Sprint Review. But this path now engendered fear in each of us. How could we get in front of our stakeholders with nothing to show given the looming due date of our release?
Heightening our anxiety, our primary business stakeholder had a low tolerance for mistakes. Her demand for excellence was legendary. And we knew our lackluster Sprint results would summon her wrath.
In the end, my team surprised me with how it handled the situation. I will tell you about this later. But my team was in anguish as it grappled with the dilemma.
Does my story seem familiar? More often than not, I see Scrum teams in a similar situation. Fear gets in the way and halts the value potential of Scrum.
Most organizations I start coaching do not provide a safe space to draw outside of the lines. Teams must follow standards, do what they’re told, and deliver what someone else promised. Responding to the reality on the ground is not an option.
Building a culture that promotes safe experimentation is not easy. It is difficult to build trust in failures not having adverse consequences. But safety is what Scrum needs to help generate value amidst complexity and uncertainty.
So what are Scrum Teams to do if they don’t feel safe? Do they need to continue to be opaque and wait until their organization creates a safe space? Or is there another option?
Let’s first investigate why safety enables Scrum to deliver value. Then, we will explore how to break through the fear barrier. Finally, I will tell you what my team ended up doing in the Sprint Review.
Safety opens the door to empiricism
Scrum’s foundation is empiricism. A team using empiricism relies on findings from experience to guide the next step they take. Adapting to reality means predictive behaviors do not dominate and cloud judgment.
To make empiricism work, teams must practice transparency, inspection, and adaptation. And to be transparent about problems, safety must be present. Without safety, the engine of empiricism breaks down.
“Safety is the foundation of all our activities.”
— Taiichi Ohno
The importance of safety in building an effective workplace is not isolated to Scrum. For one, Toyota made popular the principle, “Safety First.” And one of the principles of Modern Agile states, “Make Safety a Prerequisite.”
“For jobs where learning or collaboration is required for success, fear is not an effective motivator.”
— Amy Edmondson
Amy Edmondson wrote The Fearless Organization.¹ In her book, she emphasizes how psychological safety enables learning, innovation, and growth. Amy defines psychological safety as follows:
Psychological safety is a belief that one will not be punished or humiliated for speaking up with ideas, questions, concerns, or mistakes.
To be empirical, we can’t be afraid to speak up. Transparency is not only about what is going well. It is about revealing without pause what is going wrong, so we can course-correct early and often.
What to do if you don’t have safety
Building a safe environment from an unsafe one is a long journey. Months and years could pass as we nurture a safe space to fail. This should not dissuade us from the trip, but it is the reality.
Does this mean we can’t attempt Scrum until safety is present? No, it does not.
A lack of safety makes empiricism difficult. It does not make it impossible. But to counteract fear, you need to dig deep — you need courage.
“In calm water, every ship has a good captain.” — Grover Cleveland
Courage is a Scrum value.² It is also a value of Extreme Programming.³ And it is critical when facing your moment of truth.
You show courage when you take a stand for what is right when pressure mounts to do the opposite. When you take a risk to face fear in the name of what is right, you give trust a chance to start growing.
“We can choose courage or we can choose comfort, but we can’t have both. Not at the same time.”
— Brené Brown
Many of our greatest achievements have been the result of courage in the face of fear. And there is a direct relationship between risk and reward. The greater the risk, the greater the reward.
But sometimes the risk is too high regardless of the reward. To build incremental courage, take smaller steps in the direction you need to go. The smaller the step, the smaller the fall if you step wrong.
The moment of truth for my team
We started this post with the story of my team, facing our moment of truth before the Sprint Review. No feature was “Done.” We didn’t meet our Sprint Goal.
We felt we had failed, and fear had a grip on us. We could take the easy road and manufacture good optics for our plight. Or we could face the music and reveal the truth of what happened.
In the middle of our deliberations on how to sweep our failed Sprint under the rug, one team member took a stand. She said we should all grow up and tell it like it is. Her words hung in the air as we all stared at her.
She was right. We had done nothing wrong. And hiding the reality would only cause more problems down the road.
Her courage emboldened us to go against our nervous folly. We joined forces and gave the complete story at the Sprint Review as a unified team. We did not gloss over anything.
At first, the stakeholders at the Sprint Review were taken aback. The honesty of the team was a surprise. Most of the time, raw problems are not the story the stakeholders get.
At the end of the Review, the stakeholders gave glowing feedback, praising the team’s honesty. They were grateful the team decided to fix the defect rather than continue with the Sprint Goal. Even the primary stakeholder we feared praised our team’s forthright behavior.
The team’s courage had built trust with the stakeholders. And the stakeholders’ positive response to the problem built the team’s trust in them. There is no better way to build safety than this.
Taking it forward
Safety is critical for empiricism to take flight. But it can take time to build a safe environment when fear is present. To embrace transparency, we don’t have to wait for complete safety to appear.
Instead of waiting, we must use small steps of courage to face our fears, build trust, and create safety. More safety will increase our transparency, which builds further trust and safety. This cycle will continue and will help you increase value in a complex environment.
Scrum does not need to wait for safety, and neither do you. Don’t maneuver around your fear. Take a step through it, and embrace change today.
A special thanks to Maarten Dalmijn and Matt DiBerardino for their thoughtful contributions to this post.
For more content like this on my pursuit of Lean Leverage, delivered to your inbox, you can just join my email list. Or see my other related posts below to dive even deeper.
Related Reading
References
- The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth, Amy C. Edmondson, Wiley 1st Edition, November 20, 2018
- The Scrum Guide, Ken Schwaber and Jeff Sutherland, November, 2020
- Extreme Programming Explained — Embrace Change, Kent Beck, 2000
