Scrum Values: Courage Examples

Courage is speaking the truth to peers and authority. Though this comes in many forms, it primarily involves having the determination to say what others won’t.

Developers

As a developer on a Scrum team, you’ll have several opportunities to exemplify courage.

Enforcing Technical Excellence

The ninth principle of the Agile Manifesto states:

“Continuous attention to technical excellence and good design enhances agility.”

Enforcing technical excellence against deadlines will take courage. It’s all too easy to cut corners for the sake of a deadline. But the later a bug is discovered, the most costly it is to resolve. The greater the time between the bug’s origin and identification, the greater the time will be to refamiliarize yourself with the code to fix the undesirable behavior.

In some circumstances, it might make sense to take on technical debt strategically, but the team should always plan to pay that down. Technical debt should only be leveraged temporarily by the team to hit a goal. Make sure to distinguish technical debt from a lack of craftsmanship.

“A mess is not a technical debt. A mess is just a mess. Technical debt decisions are made based on real project constraints. They are risky, but they can be beneficial. The decision to make a mess is never rational, is always based on laziness and unprofessionalism, and has no chance of paying off in the future. A mess is always a loss.”

- Bob Martin

Facing Challenges Head On

Another example of courage in Scrum is being open to working on complex problems when effortless work is available. If you’re going to enable the Product Owner to meet their goal of maximizing the product’s value, then you can’t always work on the easy things.

Various prioritization techniques recommend evaluating the level of effort when prioritizing PBIs, but there should be other considerations. WSJF (weighted shortest job first), for example, also takes into consideration business value, time criticality, risk reduction, and opportunity enablement.

The user story that provides the most value will only sometimes be the easiest to implement. There is an inherent fear of failure that comes with working on complex challenges, and it takes courage to tackle a problem that doesn’t have an immediate solution.

Openness to Experimentation

In this same vein, experimentation also requires a lot of courage to overcome the fear of failure.

Scrum is all about empiricism, which requires experimentation. Trying new things helps the Scrum Team uncover better ways of working. Given that there’s always a chance that our experiments might fail, it takes courage to be willing to take risks. By avoiding experimentation, we limit continuous improvement.

Product Owner

Being a Product Owner requires a ton of courage because they have to learn how to say no from several different perspectives.

Yes to One Item is No to Another

Typically the team’s Product Backlog will contain more items than the developers can finish in a single Sprint. This limited capacity means that someone will have to wait for their feature. Ensuring that high-value PBIs are near the top of the Product Backlog is the Product Owner’s responsibility.

Ultimately, by bubbling certain PBIs to the top of the backlog, the Product Owner decides which items to defer to future Sprints. It requires courage to communicate to stakeholders that the feature they want will have to wait until the developers complete higher-value work.

Misalignment with Product Vision

A similar situation requiring courage occurs when a stakeholder requests a feature that does not align with the Product Vision.

I once served as a Product Owner for an application that ultimately determined the bonuses paid to healthcare professionals. Busy department leads would often miss the final submission step in the process. To combat this, my primary stakeholder requested that we add a feature to make the ‘submit’ button blink.

Though this is technically possible, it goes against UI best practices. Also, the tactic was unlikely to solve the underlying issue.

I could have taken the easy way out and asked the developers to make the change instead of trying to point out the flaws in this particularly opinionated stakeholder’s suggested approach. However, the right thing to do was to find a better solution, even if that required a difficult conversation. I mustered up my courage and worked with the stakeholder to determine the root cause of the undesired behavior.

Once we agreed on the problem statement, I suggested alternative workflows better aligned with the Product Vision. After we landed on an option that better solved the problem, I indicated that we wouldn’t need the blinking button with the new design, and he concurred.

Culling Product Backlog Items

Another way the Product Owner must say no is by culling low-value or unlikely items from the Product Backlog. Long-lived products generate many feature requests. Without routine Backlog refinement, a backlog can quickly become too large to manage efficiently.

I once worked on a team where we captured every idea in our work-tracking tool. We had so many PBIs that it became hard to find any particular item. Having such a massive pile of work when only the top-priority items got attention started to make leadership nervous that we might be losing high-value requests in the Product Backlog. To address this, we began having quarterly meetings to review everything on the backlog.

Eventually, we separated the backlog into two parts. We referred to higher-value items as the backlog and those of lower value as the ‘bottom of the backlog.’ This process lasted a couple of months until we needed to split the backlog again. In keeping with the genius naming convention, we ended up with a backlog, the bottom of the backlog, and the bottom of the bottom. Almost everyone was seeing red flags at this point.

Eventually, someone dared to ask a rhetorical question: Are we ever going to get to the PBIs on the bottom of the bottom?

“Simplicity—the art of maximizing the amount of work not done—is essential.”

- Agile Manifesto

It takes courage to point out when your backlog has surpassed a reasonable length.

Document but Don’t Commit

The most common question stakeholders ask is, “when will it be done?” This question is only possible for the Product Owner to answer with input from the Development team.

In her article on the Scrum Values, Vanessa Franchi makes a subtle point that I’d like to highlight.

“… [T]he Product Owner must be careful to absorb customer demands without committing to them until obtaining and respecting the opinion of the Development Team, as changes that undermine the Sprint Goal consequently impact the product evolution.”

- Vanessa Franchi

It takes courage for a Product Owner to document but not commit to a feature request. When you’re face to face with the customer, and they need to know when the developers will complete the work, it can be uncomfortable to reiterate the prioritization and planning process. In a moment of weakness, the Product Owner might be inclined to tell the stakeholder what they want to hear. Even vague comments like “we’ll try to get this done next sprint” or “we’ll get this done as soon as possible” can set unrealistic expectations.

Only when the Product Owner orders the request in the backlog will we know how many other Product Backlog Items we’ll need to complete ahead of it. Although this request might be the top priority for this particular stakeholder, that doesn’t mean it’s the most valuable item on the entire backlog that serves multiple stakeholders.

Even if this user story is near the top of the Product Backlog, there is no guarantee that the developers will select it during Sprint Planning. The team could determine that the PBI doesn’t meet the definition of ready and thus cannot be pulled into the Sprint Backlog. If this PBI isn’t at the top of the Product Backlog, higher PBIs may consume the team’s capacity before they get to this item in Sprint Planning.

It’s best not to commit to work for the Development Team, but depending on your stakeholders, it can take courage to stick to team processes.

Scrum Master

When it comes to the Scrum Master, they typically exemplify courage by instigating and facilitating conversations that others would rather avoid.

Difficult Conversations

Although constructive criticism is essential to the growth of individuals, few people are happy to give or receive it. Having these frank conversations with team members takes a lot of courage.

Critical feedback isn’t the only difficult conversation a scrum Master will have. Acting as a change agent will also require this particular skill.

Catalyst for Cultural Change

Barry Overeem points out in his white paper on The 8 Stances of a Scrum Master that a Scrum Master also serves the role of change agent.

Being a catalyst for cultural change requires pointing out things that need change and suggesting better ways of working. Standing up against the status quo can take a lot of courage.

“A good Scrum Master helps a Scrum Team survive in an organization’s culture. A great Scrum Master helps change the culture so Scrum Teams can thrive.”

- Geoff Watts, Scrum Mastery

Surfacing Impediments

The Scrum Master can also apply courage in the Daily Scrum to help the team surface impediments. Regardless of which Standup agenda you use, teams tend to get caught up in the repetitiveness of it and can start to default to going through the motions without deeply thinking about what they’re saying.

You may need to interrupt the flow and draw attention to things that sound like impediments even when members didn’t explicitly call them out as such. Asking who can help resolve the issue can facilitate appropriate planning for the next 24 hours. Assisting the team in clarifying whether something mentioned in passing is an actual impediment can ensure that it gets the attention required.

It may initially seem rude to interrupt the flow, highlight an impediment that someone else (intentionally or not) breezed past, and then elicit volunteers to help remove it. The easiest path is to let the conversation continue; however, having the courage to slow things down and ensure that team members deal with impediments will help increase team efficiency and collaboration.

Enforcing the Rules

Enforcing the rules of Scrum is another area that will require courage from the Scrum Master. I agree with Barry Overeem that it’s inaccurate to think of the Scrum Master as the Scrum Police. It’s less about zealously following the rules and more about appropriately leveraging the framework to help the team improve.

Enforcing the timebox for a Sprint Event is a perfect example. It’s easier to let the team go on and on, but it takes courage to enforce that the event ends at the scheduled time.

Mark Summers provides a perfect example of this in Understanding Scrum Values: Courage. Even though the team didn’t get through all the work in a Sprint Review, ending the event on time highlighted inefficiencies that the Product Owner subsequently resolved.

Another example of enforcing rules comes into play when the Scrum Master reminds the team of their working agreements. Amidst constant activity, the team might forget that they agreed to follow a particular process. Given that the working agreements are created by the team and for the team, it seems reasonable that they’d want to follow them. If they’re not following them, it’s worth questioning why. If we have processes that have become obsolete, we should update our working agreements. If steps are still relevant, we should follow them consistently.

Scrum Team

There are some ways team members can exemplify courage agnostic of any particular Scrum accountability(Scrum Master, Product Owner, or Developers).

Commitment to Transparency

One way the Scrum Team exemplifies courage is by agreeing to be transparent. In Nonviolent Communication, author Marshall Rosenberg postulates that American culture continually seeks to reward or punish people. We seem to always be at one end of the spectrum or the other. We’re so awesome that our peers should reward us, or we’re so terrible that our betters should punish us. When you view work through that lens, it’s hard to be transparent because you’ll feel like you’re just giving someone else facts that they can use against you.

Insisting on Continuous Improvement

In many instances, Scrum will uncover cultural impediments outside the team’s immediate control to resolve. Though it takes courage to bring up these impediments, it takes more courage to insist that the company remove them.

The Sprint Retrospective should result in incremental changes that increase the team’s efficiency over time. We want to avoid creating a backlog of issues that the team continues to ruminate on every retrospective, as it will be de-motivational to the team.

The Scrum Guide firmly points to the Scrum Master for removing organizational impediments.

“Scrum Masters are true leaders who serve the Scrum Team and the larger organization.

The Scrum Master serves the Scrum Team in several ways, including:

[…]
Causing the removal of impediments to the Scrum Team’s progress; and,
> […]

The Scrum Master serves the organization in several ways, including:

Leading, training, and coaching the organization in its Scrum adoption;

Planning and advising Scrum implementations within the organization;”

- Scrum Guide

Though it may be the accountability of the Scrum Master to facilitate the removal of impediments, they may need to collaborate with other team members to develop strategies to accomplish this. And it’s the entire team’s responsibility to highlight the most critical impediments and to persist until they have what they need to be efficient.

Speak Truth to Power

It takes a lot of courage to speak truth to power.

It’s common to need to collaborate with co-workers up and down the chain of command within the company. We may need to discuss requirements with our boss’ boss, collaborate with the VP of [insert important title here], or work with more senior team members. It can be easy to be intimidated by those that we perceive to be of a higher rank than ourselves.

In these interactions, we must remain transparent and honest with how we understand the situation. This may come in many forms:

Pointing out previously unconsidered edge cases that invalidate a proposed solution Being realistic about deadlines and forecasts Pointing out when a solution is not technically feasible

The best way to ensure effective collaboration is to be transparent and strive toward a shared understanding.

Disagree

Scrum Team members will not always agree on the best path forward. However, there will be times when we still need to reach a decision and act on it, even if everyone doesn’t agree.

Everyone should provide feedback to ensure that we have the best chance of reaching the best decision. The team will likely have disagreements, but functional teams don’t avoid healthy conflict. Being open to hearing the opinions of others will ensure that we reach the best solution possible.

The Five Dysfunctions of a Team points out that the best way to reach commitment is to allow everyone to have input on the decision. It can require courage to provide input when you disagree with others on the team.

If the team has heard your feedback but decided to go a different direction, everyone on the team still needs to commit to executing the ultimate decision.

This is also one of Amazon’s Leadership Principles: Have Backbone; Disagree and Commit.

Works Consulted

• Agile Manifesto
• Updates to the Scrum Guide: The 5 Scrum values take center stage
• Courage exists in many forms
• There’s value in the Scrum Values
• How to Apply Scrum Values in the Day by Day?
• Understanding Scrum Values: Courage
• Scope can be renegotiated with product owner
• The 8 Stances of a Scrum Master
• Scrum Mastery
• Weighted Shortest Job First

TLDR

Although it can be tough to have courage and stand up for what you believe is right, especially when everyone else isn’t motivated to take the risk, there are many benefits to courage. So don’t be afraid to stand up to those more powerful than you and speak your mind. Being courageous doesn’t require being an asshole; you can still do it with respect.