Courage in Scrum: Doing What’s Right

It’s easy to maintain the status quo, fake it till you make it, and cower in the face of power. Courage overcomes those inclinations and offers team benefits.

What is Courage

Courage is one of the five core values of Scrum. The other four are focus, openness, respect,  and commitment.

The Scrum Guide has this to say about courage:

“The Scrum Team members have the courage to do the right thing, to work on tough problems.”

- Scrum Guide

Mitch Lacey captured the essence of courage with his definition from The Scrum Field Guide:

“Courage is the ability to face difficulty in spite of your fears.”

Many people think that courage is the absence of fear, but if there is no fear, then you don’t need courage. One of the most terrifyingly awkward scenes I can remember from a movie is from Pee-wee’s Big Adventure.

Although you’re unlikely to face Large Marge as a member of an agile team, you will find yourself in some difficult situations.

I’ve been in a few awkward meetings where if given a choice between hopping in Large Marge’s truck versus standing up against the status quo, the first option would have been the lesser of the evils. And that’s saying a lot because Large Marge scared the hell out of me as a kid.

The Importance of Courage in Scrum

If you go solely based on the wording from the Scrum Guide, you might be thinking you have the whole courage thing licked. After all, there’s not been a lot of tough problems that have scared you away. But we’re not just talking about the solution to a complicated algorithm here. Understanding the essence of courage as it relates to a Scrum team requires some deep thought.

In my experience, a lack of courage manifests in two major scenarios. One is conflict avoidance. Multiple people disagree with a statement or a decision, but no one is willing to speak up because they don’t want to deal with the conflict. The second comes into play when team members try to avoid showing weakness because they do not want to be viewed as inferior in the eyes of their peers.

Ilan Goldstein makes the following statement regarding courage in his book Scrum Shortcuts Without Cutting Corners:

“without courage, the team won’t be willing to confront problems head on.”

- Ilan Goldstein

A lack of courage manifests in many ways. If teams can learn to leverage courage in these circumstances, they’ll unlock many benefits. Next, we’ll cover some scenarios that demonstrate a lack of courage and the benefit courage could bring to the situation.

The Benefits of Courage in Scrum

1. Solving Tough Problems

When I was in my twenties, growing up in eastern Kentucky, I tended to drive like I was at the Indy 500. I must have hit ten deer in a three-year period. Some of them didn’t do a ton of damage to the vehicle, while others did.

One particularly suicidal deer counted to thee as it stood on the road’s shoulder before jumping out directly in front of my 2002 Sunfire, which just happened to be tailgating the car in front of me. In my peripheral vision, I saw the deer start to make the illogical jump, and I swerved in an attempt to avoid hitting yet another deer. I managed to only clip the deer, but the impact was enough to break my passenger-side mirror off.

I checked the damage after arriving home and discovered that my side mirror was hanging on by a bundle of power cords. I was faced with a decision. I could schedule an appointment at the body shop to have my mirror replaced, or I could leverage the magic granted to me by the power of duct tape to “fix” my mirror.

Being young and inept at adulting, I went the duct tape route.

Three months and two rolls of duck tape later, I finally gave up the ghost and had my side mirror replaced. I knew the moment I borrowed the first roll of tape that it wasn’t the right way to fix the problem, but I told myself it was the best option I had available to me at the time. Mostly because I didn’t want to deal with the hassle of having to talk to another human being to schedule the appointment to have the mirror replaced.

Agile teams across the land make low-courage decisions like this every day. We see things in the codebase that we know aren’t correct, but we let them go because we’re not the one that introduced the issue or the timeline doesn’t allow for the proper fix.

It takes courage to maintain quality under pressure.

When agile team members see something that isn’t right, we want them to take the time to fix it. Struggling around a poor implementation will cost the development team more time in the long run.

This concept applies to more than just technical implementations as well. Inefficiencies in the process should be called out and dealt with accordingly. The problems won’t always be easy to solve. The people before you left them untreated because it was easier to let the sleeping dog lie.

The more issues we confront head-on, the less they’ll be able to sneak up on us later. The development team will gain speed and efficiency by fixing their issues.

2. Embracing Empiricism

Any time we take a risk, no matter how small, there is a chance that the risk won’t pay off. Scrum is all about embracing empiricism, which in turn is all about experimentation.

There is a non-zero chance that any experiment we try will fail. Yet, to learn and improve our process, we still have to have the courage to take the calculated risks which are required for learning.

If we don’t have the courage to try new things, our Sprint Retrospective will fall flat, severely hampering our continuous improvement.

3. Transparency

How many times have you been in the daily standup with a developer who’s been working on the same ticket for five days? Every day they have the same update. They nervously bite their nails and announce that they’ve made some progress and expect to be able to finish the ticket today, while inside, they’re feverishly hoping that they’re correct. Yet day after day, the ticket remains undone.

In this situation, there is a lack of courage emanating from both directions. The developer should have the courage to admit that they need help. When you’re stuck on something, you might toil away at it for three days and eventually get it done, but if you’d asked for help on day one, someone might have been able to pair with you and knock the ticket out in thirty minutes.

But the lack of courage isn’t just showing on the side of the currently assigned developer. Other developers should question the behavior. You’ve been saying that this ticket will be completed today for three days now. What’s the deal? More importantly, what can the team do to help? It’s the development team’s job to get all the stories across the finish line. If one of us fails, we all fail.

When team members are more transparent about the situation and have the courage to admit that they need help, it makes it easier for others to offer help. We’re going for a three-musketeer culture, not a ninja culture. Everyone needs to help everyone else get across the finish line instead of just looking out for themselves.

4. Team Growth

“I love that in the movie Rocky, Sylvester Stallone’s character says of his fiancée Adrian: “I got gaps, she’s got gaps, together we don’t got gaps.” That could be said of our coworkers and us. Instead of exploiting other people’s gaps to get ahead of them, why not fill in each other’s gaps and both get ahead?”

-John C. Maxwell

Sometimes, on a cross-functional team, a developer might have to work on a user story that doesn’t align with their strengths.

A truly collaborative team will seek to share knowledge in a way that closes these gaps over time. To be successful in that endeavor, however, each developer needs to have the courage to recognize and admit their weakness. For fellow team members to feel safe showing vulnerability, the team must work in a culture that promotes psychological safety.

When a developer asks for help or admits to not knowing something, this demonstrates the Scrum value of courage. Other team members that are stronger in that skill can help level others up. After all, the best way to learn is to teach.

This willingness to identify and fill gaps is what helps us build cross-functional teams. When multiple people know how to do the work, we reduce bottlenecks and give ourselves more options for organizing our work.

5. Avoiding Irrational Decisions

One of the hardest things to do in an agile project is to be the voice of reason when everyone else is delusional.

• The two-year project will not be done in two months.

• The functionality to make a button blink will not really be as useful as you think.

• Forcing a Product Backlog Item into the Sprint Backlog, even though it doesn’t meet the definition of done, will not make that issue go faster. It’s more likely to actually take longer.

It’s easy to follow the rest of the lemmings straight off the cliff. It takes courage to announce to all the other lemmings that a cliff is coming up.

Setting realistic expectations with stakeholders or the Product Owner may not make them happy, but it will reduce waste and prevent the complete destruction of trust. If you go along with unrealistic expectations like nothing is wrong just to show up empty-handed in the end, the outcome will be much worse.

Works Consulted

• Scrum Guide
• Scrum Field Guide, The: Agile Advice for Your First Year and Beyond
• Scrum Shortcuts Without Cutting Corners: Agile Tactics, Tools & Tips
• ‘Radical Candor’ is about respect, courage and openness
• There’s value in the Scrum Values
• Courage Exists in Many Forms
• How Can Management Benefit From the Scrum Values?
• How to Apply Scrum Values in the Day by Day?

TLDR

Learning to leverage courage will unlock many team benefits. Standing up for what is right even when it’s very uncomfortable to do so can save your team a lot of pain and help them become more efficient.