Courage in Scrum: Complete Guide to Doing the Right Thing & Facing Tough Problems

Courage in Scrum means team members have "the courage to do the right thing, to work on tough problems" - directly from the Scrum Guide (opens in a new tab). Without courage, empirical process control breaks down: teams hide problems until they explode, continue executing failing approaches, and compromise quality silently rather than defending standards openly.

Courage isn't the absence of fear; it's acting despite fear when success requires it. Teams working on complex products face genuine uncertainty. Courage means tackling hard problems without guaranteed solutions, telling stakeholders uncomfortable truths, and admitting when expertise is lacking. This vulnerability, grounded in trust, distinguishes high-performing teams from those going through mechanical motions.

This guide explores how courage manifests across roles and events, plus practical strategies for building courage in teams where fear currently dominates behavior.

Quick Answer: Courage in Scrum at a Glance

Aspect	Courage in Scrum
Definition	Willingness to do the right thing, work on tough problems, explore unknowns, and engage in respectful disagreements despite fear or discomfort
Scrum Guide Quote	"Scrum Team members have the courage to do the right thing, to work on tough problems"
Manifests Through	Admitting mistakes early, challenging questionable decisions, requesting help when uncertain, defending quality under pressure, pivoting when evidence demands change
Requires	Psychological safety where interpersonal risks don't result in punishment; trust that honesty leads to support; leadership that rewards truth-telling
Enables	Honest transparency (inspection), bold adaptation, addressing root causes vs symptoms, sustainable quality, continuous improvement
Common Failures	Hiding problems until critical, avoiding conflict to preserve harmony, following failing plans to avoid admitting error, compromising quality silently
Distinguished From	Recklessness (taking unnecessary risks), foolhardiness (ignoring evidence), stubbornness (refusing to adapt), confrontation (attacking rather than discussing)

Understanding Courage in Scrum

Courage in Scrum enables teams to navigate complexity honestly rather than maintaining comfortable fictions. Understanding what courage means - and what it doesn't - helps teams cultivate this essential value.

Courage vs Recklessness: Critical Distinction

Courage in Scrum IS:

• Taking calculated risks informed by evidence and team assessment
• Admitting uncertainty and exploring unknown territories systematically
• Challenging decisions respectfully with reasoning and alternatives
• Pivoting when inspection reveals better approaches exist
• Defending quality standards openly while explaining technical rationale

Courage in Scrum IS NOT:

• Recklessness: Taking unnecessary risks without considering consequences
• Foolhardiness: Ignoring evidence or expert advice to prove a point
• Stubbornness: Refusing to adapt when new information emerges
• Confrontation: Attacking people rather than addressing ideas
• Martyrdom: Working unsustainably to avoid difficult conversations

Courageous teams act despite fear because analysis suggests the action is right. Reckless teams act without fear because they haven't considered consequences. This distinction matters: courage is grounded in empiricism and team support, not individual bravado ignoring reality.

Eight Forms of Courage in Scrum

Courage manifests in specific, observable behaviors that enable empiricism:

1. Courage to Be Transparent About Progress

Teams demonstrate courage by honestly reporting actual status, especially when behind schedule or facing obstacles. This transparency under pressure enables early adaptation rather than last-minute surprises.

Example: During Daily Scrum, Developer courageously shares: "I underestimated this work. We won't achieve Sprint Goal if I continue alone. I need help." This vulnerability enables team adaptation.

2. Courage to Admit Not Knowing

Acknowledging knowledge gaps and requesting help requires vulnerability. Many technical professionals fear appearing incompetent. Courageous teams normalize asking questions and seeking expertise.

Example: Senior Developer admits during implementation: "I've never worked with this API before. Can someone pair with me to ensure we do this right?" This courage prevents hidden mistakes.

3. Courage to Hold Others Accountable

Addressing teammates who aren't meeting commitments creates interpersonal discomfort. Courageous teams have difficult conversations promptly rather than letting dysfunctions fester.

Example: Team member observes another consistently missing Daily Scrums. Courageously raises privately: "I notice you've missed several Daily Scrums. This impacts our coordination. What's preventing attendance?" Addresses issue directly.

4. Courage to Challenge Decisions and Assumptions

Questioning leaders, senior members, or established approaches requires courage, especially in hierarchical cultures. Courageous teams encourage constructive challenge regardless of seniority.

Example: Junior Developer questions Product Owner's priority during Sprint Planning: "This feature seems lower value than the one we deprioritized. Can you explain the reasoning?" Challenge leads to better decision.

5. Courage to Experiment and Potentially Fail

Innovation requires attempting approaches without guaranteed success. Courageous teams treat failures as learning rather than something to hide or avoid.

Example: Team proposes trying mob programming despite uncertainty about effectiveness. Commits to three-Sprint experiment with agreed success criteria. Courage enables innovation.

6. Courage to Engage in Productive Conflict

Disagreements about approaches, priorities, and technical decisions are inevitable. Courageous teams address conflicts directly and respectfully rather than avoiding them for false harmony.

Example: Two developers disagree on architecture approach. Both courageously present reasoning, discuss trade-offs, and defer to team consensus. Conflict produces better solution than either individual proposed.

7. Courage to Admit Mistakes

Acknowledging errors - technical, decisional, or behavioral - early limits damage. Courageous teams create environments where mistake admission leads to problem-solving, not punishment.

Example: Developer realizes their code change broke integration. Immediately announces to team: "I broke the build with my last commit. Rolling back now while I fix properly." Early courage prevents larger problems.

8. Courage to Defend Quality Standards

Under pressure to deliver faster, teams face temptation to compromise quality. Courageous teams defend Definition of Done by explaining technical debt consequences openly.

Example: Product Owner pressures team to skip automated tests to ship faster. Team courageously explains: "Skipping tests creates technical debt that will slow all future work. We propose reducing scope while maintaining quality." Protects long-term velocity.

Courage and Psychological Safety

Courage cannot flourish without psychological safety - the team climate where taking interpersonal risks doesn't result in punishment or humiliation. These concepts are interdependent:

Psychological Safety Enables Courage:

• When teams know honesty won't be punished, they courageously share bad news
• When failure is treated as learning, teams courageously experiment
• When questions are welcomed, people courageously admit uncertainty
• When conflict focuses on ideas not people, teams courageously disagree

Courage Builds Psychological Safety:

• When someone courageously admits mistakes and receives support, others feel safer
• When challenges lead to better decisions, questioning becomes valued
• When transparency about problems leads to help, openness increases
• When conflicts are resolved respectfully, disagreement becomes less threatening

Courage Across Scrum Roles

While all Scrum Team members need courage, each role demonstrates courage in role-specific ways.

Product Owner Courage

Product Owners require courage to maximize value despite stakeholder pressure:

Courage to Say "No":

• Declining feature requests from powerful stakeholders when they don't align with Product Goal
• Refusing to overload team with work beyond capacity despite pressure
• Saying "not now" to valuable features to maintain focus on higher-value work
• Defending Product Backlog ordering decisions with data and reasoning

Courage to Accept Negative Feedback:

• Demonstrating partially successful Increments at Sprint Review despite knowing stakeholders will be disappointed
• Pivoting product direction when market feedback reveals wrong assumptions
• Adapting Product Goal when evidence shows current direction isn't working
• Soliciting honest feedback even when receiving it is uncomfortable

Courage to Challenge Organizational Constraints:

• Advocating for team needs (tools, training, environment) despite budget pressure
• Pushing back on artificial deadlines not grounded in empirical forecasting
• Addressing organizational impediments that prevent team effectiveness
• Protecting team from excessive work-in-progress despite multiple stakeholder demands

Example: Product Owner faces executive pressure to commit that feature will launch by quarter-end. Empirical data suggests this timeline is unrealistic. Courageous PO: "Based on team's velocity and remaining complexity, Q2 launch is probable, Q1 is unlikely. I commit to maximizing value delivered by Q1 but won't promise scope that sets team up for failure. Here's phased approach that delivers core value Q1, full feature Q2."

Scrum Master Courage

Scrum Masters need courage to serve team effectiveness even when politically difficult:

Courage to Uphold Scrum Framework:

• Enforcing timeboxes even when powerful stakeholders want extended discussions
• Protecting team from mid-Sprint disruptions despite pressure from leadership
• Ensuring Sprint Retrospectives address real issues, not superficial topics
• Maintaining Definition of Done standards against pressure to lower them

Courage to Address Team Dysfunctions:

• Raising observations about unhealthy team dynamics even when uncomfortable
• Facilitating difficult conversations about performance or behavior issues
• Addressing when team member's actions undermine Scrum values
• Coaching individuals whose behavior impacts team effectiveness

Courage to Challenge Organizational Impediments:

• Escalating systemic issues to leadership even when politically risky
• Advocating for organizational changes that enable Scrum effectiveness
• Addressing when leadership behavior contradicts stated Agile values
• Pushing for resource allocation that supports team sustainability

Courage to Let Team Struggle Appropriately:

• Resisting impulse to solve every problem for team (servant leadership, not rescuing)
• Allowing team to experience natural consequences of decisions to enable learning
• Stepping back when team can self-organize rather than directing solutions
• Trusting team's capability even when nervous about outcomes

Example: Scrum Master observes leadership routinely overruling team's technical decisions, undermining self-organization. Courageously raises to leadership: "When technical decisions are overridden, it signals team isn't trusted. This reduces commitment and slows velocity as team waits for approval rather than acting. Can we discuss boundaries where team has autonomy?" Addresses systemic dysfunction.

Developers Courage

Developers demonstrate courage in technical work and team dynamics:

Courage in Technical Work:

• Refactoring complex code despite risk of introducing bugs
• Admitting technical debt needs addressing even when it slows feature delivery
• Trying new technical approaches without guaranteed success
• Asking for architectural guidance when facing unfamiliar problems
• Defending technical quality standards under pressure to ship faster

Courage in Team Collaboration:

• Requesting help when stuck rather than struggling silently for days
• Offering constructive feedback on teammate's code or approach
• Admitting mistakes early rather than hoping they won't be noticed
• Challenging team decisions when seeing potential problems
• Volunteering for difficult work rather than only selecting easy tasks

Courage in Stakeholder Interaction:

• Explaining technical constraints to stakeholders in non-technical language
• Defending realistic estimates despite pressure to promise faster delivery
• Demonstrating partially complete work that meets Definition of Done rather than showing incomplete work that looks impressive
• Addressing when stakeholder requests bypass Product Owner or break Scrum framework

Example: Developer realizes midway through Sprint that chosen technical approach has fatal flaw. Courageously announces immediately: "The architecture I proposed won't scale as required. I was wrong. We need to pivot to alternative approach. This impacts Sprint Goal - let's discuss as team how to adapt." Early courage enables adaptation; hiding would create larger problems.

Courage Across Scrum Events

Each Scrum event creates specific opportunities for courage.

Sprint Planning Courage

• Team courageously commits to challenging Sprint Goal that stretches capabilities without overcommitting
• Developers challenge unrealistic expectations respectfully with evidence
• Team courageously raises dependencies and risks that might prevent success
• Product Owner courageously defends priorities despite stakeholder pressure
• Team admits uncertainty about work complexity and builds in contingencies

Daily Scrum Courage

• Team members honestly share impediments and struggles, not just progress
• Developers courageously request help rather than struggling silently
• Team addresses when Daily Scrum becomes status report rather than adaptation opportunity
• Impediments raised immediately rather than hoping they resolve themselves
• Team courageously adapts plan daily rather than mechanically following Sprint Backlog

Sprint Review Courage

• Team demonstrates actual Increment meeting Definition of Done, not vaporware
• Product Owner courageously solicits critical feedback, not just praise
• Team discusses what didn't work alongside successes
• Stakeholder feedback leads to Product Backlog adaptation, not defensive explanations
• Team courageously pivots direction when feedback reveals misalignment with user needs

Sprint Retrospective Courage

• Team addresses real dysfunctions, not just surface-level process tweaks
• Individuals courageously share observations about team dynamics
• Team identifies systemic organizational impediments requiring leadership action
• Retrospectives address interpersonal conflicts productively when they impact effectiveness
• Team courageously commits to meaningful changes, not just comfortable adjustments

Industry-Specific Courage Examples

Courage manifests differently across industries due to varying risk profiles, regulations, and organizational contexts.

Healthcare / Medical Devices

Context: Patient safety is paramount; mistakes can cause harm; extensive regulations; blame-free culture is challenging.

Courage challenge: Reporting potential safety issues may delay launches and invite regulatory scrutiny; pressure exists to minimize issue severity.

Courage in action:

A medical device software team discovers during testing that algorithm occasionally produces incorrect dosage calculations in edge cases. While rare, potential consequences are severe.

Courageous response:

• QA engineer immediately reports issue to Product Owner and team despite pressure to launch
• Team halts Sprint to investigate root cause rather than documenting as "known limitation"
• Product Owner courageously informs stakeholders of delay despite executive pressure
• Team expands testing scenarios to uncover similar edge cases
• Issue escalated to regulatory compliance before considering partial release

Outcome: Launch delayed three Sprints. No patients harmed. Root cause addressed systematically. Team builds reputation for putting safety first.

Financial Services / Fintech

Context: Regulatory scrutiny, financial impact of errors, security criticality, compliance requirements.

Courage challenge: Pressure to launch features quickly conflicts with security rigor; admitting vulnerabilities invites audit scrutiny.

Courage in action:

Security review discovers vulnerability in payment processing that could expose customer financial data. Marketing has announced launch date publicly.

Courageous response:

• Security team member raises issue immediately despite knowing it impacts public commitments
• Product Owner courageously supports delaying launch to address vulnerability properly
• Team courageously informs legal and compliance teams of potential exposure
• CTO courageously communicates delay to board without minimizing severity
• Team implements fix, conducts penetration testing, and validates before launch

Outcome: Public launch delayed. No data breach. Customer trust maintained. Team demonstrates that security isn't negotiable.

Startups / High-Growth Companies

Context: Survival pressure, investor expectations, rapid iteration, competitive urgency.

Courage challenge: Pressure to ship features fast conflicts with building sustainable architecture; admitting technical debt threatens funding.

Courage in action:

Startup team recognizes their rapid prototyping approach created significant technical debt. System reliability declining; velocity slowing. Investors expect aggressive feature growth.

Courageous response:

• Engineering lead courageously presents data showing velocity decline due to technical debt
• Team proposes dedicating entire Sprint to technical health despite feature pressure
• Product Owner courageously defends technical Sprint to CEO and investors
• Team transparently demonstrates architectural improvements without visible features
• CTO courageously shares with investors that sustainable growth requires quality investment

Outcome: One Sprint with zero features launched. Velocity increases 40% in following Sprints. Investors appreciate transparency and long-term thinking.

E-Commerce / Retail

Context: High-traffic events (Black Friday), conversion optimization focus, customer expectations, competitive pressure.

Courage challenge: Pressure to maximize short-term conversion conflicts with sustainable practices; admitting capacity limits threatens revenue.

Courage in action:

Two weeks before Black Friday, load testing reveals current infrastructure won't handle projected traffic. Team projected 60% chance of outages during peak shopping. Leadership suggests "hoping for the best."

Courageous response:

• Infrastructure team courageously escalates capacity concerns to executive team with data
• Product Owner supports infrastructure investment despite feature delays
• Team courageously explains trade-off: delay feature launches or risk Black Friday outages
• CTO courageously allocates budget for infrastructure despite quarterly expense impact
• Team works intensively on capacity, transparently communicating daily progress

Outcome: Black Friday successful with zero outages. Revenue exceeds projection. Courageous decision to prioritize reliability over features pays off.

Regulated Industries (Pharma, Aerospace, Government)

Context: Extensive documentation requirements, audit trails, change control processes, regulatory approvals.

Courage challenge: Agile practices conflict with traditional controls; convincing regulators of Scrum's rigor requires courage.

Courage in action:

Aerospace team wants to adopt Scrum but faces regulatory requirements for extensive upfront design documentation. Traditional approach takes 6-9 months before coding starts.

Courageous response:

• Team courageously proposes incremental documentation approach aligned with Sprints
• Scrum Master works with regulatory affairs to map Scrum artifacts to compliance requirements
• Team courageously conducts pilot demonstrating that Sprint-by-Sprint documentation maintains traceability
• Leadership courageously presents approach to regulatory body despite uncertainty about approval
• Team documents empirical evidence that Scrum improves quality and maintains compliance

Outcome: Regulatory body approves approach with minor modifications. Documentation integrated into Definition of Done. Compliance maintained while gaining Scrum benefits.

Remote/Distributed Teams

Context: Geographic separation, time zones, cultural differences, limited face-to-face interaction.

Courage challenge: Remote work makes difficult conversations harder; cultural norms around directness vary; relationship building is limited.

Courage in action:

Distributed team across four time zones experiencing declining Sprint Goal achievement. Team members avoiding addressing performance concerns due to cultural differences and remote communication challenges.

Courageous response:

• Scrum Master courageously initiates conversation about performance concerns during Retrospective
• Team members from different cultures courageously share varying perspectives on directness and feedback
• Product Owner courageously addresses that some team members consistently deliver late, impacting others
• Team courageously creates working agreements about communication expectations across cultures
• Individual courageously acknowledges personal challenges working across time zones, asks for support

Outcome: Explicit communication norms established. Performance issues addressed directly but respectfully. Sprint Goal achievement improves. Team builds trust despite distance.

Common Courage Failures & Anti-Patterns

Understanding common courage failures helps teams recognize and address patterns undermining effectiveness.

Failure #1: Hiding Problems Until Critical

Problem: Team members conceal difficulties, hoping problems resolve themselves, until situations become catastrophic.

Why problematic: Late problem discovery eliminates adaptation options. What could have been minor adjustments become crisis situations requiring heroic efforts or failed commitments.

Manifestation:

• Developer struggles for three days before asking for help
• Team waits until last day of Sprint to admit Sprint Goal unachievable
• Security vulnerability hidden until customer reports it
• Technical debt accumulation concealed until velocity craters

Root cause: Fear that admitting problems will be interpreted as incompetence or lack of commitment. Organizational history of shooting messengers.

Fix:

• Create psychological safety through consistent positive response to early problem reporting
• Explicitly thank people who raise concerns early, even when uncomfortable
• Treat early transparency as strength, not weakness
• Leadership models admitting own mistakes and uncertainties

Failure #2: Avoiding Conflict to Preserve Harmony

Problem: Team avoids disagreements, difficult conversations, and challenging decisions to maintain surface-level harmony.

Why problematic: Lack of productive conflict leads to groupthink, suboptimal decisions, and simmering resentments that eventually explode or cause quiet sabotage.

Manifestation:

• Team agrees to questionable decisions without voicing concerns
• Poor performer's behavior never addressed
• Technical disagreements resolved through silence, not discussion
• Retrospectives focus on superficial improvements, avoid real dysfunctions

Root cause: Mistaking absence of conflict for team health. Conflict avoidance as cultural norm. Fear that disagreement damages relationships.

Fix:

• Distinguish productive conflict (idea-focused, solution-seeking) from destructive conflict (personal attacks)
• Frame disagreement as path to better solutions, not personal failure
• Scrum Master facilitates conflict resolution skills
• Celebrate instances where productive disagreement led to better outcomes

Failure #3: Following Failing Plans to Avoid Admitting Error

Problem: Team continues executing approach that inspection reveals won't work because pivoting means admitting initial plan was wrong.

Why problematic: Sunk cost fallacy wastes effort on approaches known to fail. Pride prevents adaptation that empiricism requires.

Manifestation:

• Team persists with technical approach despite mounting evidence of problems
• Architecture clearly won't scale but team continues rather than refactoring
• Sprint Goal unachievable but team doesn't adapt plan
• Product direction failing but Product Owner maintains course

Root cause: Interpreting adaptation as failure rather than empiricism. Ego attachment to being right. Organizational culture that punishes course changes.

Fix:

• Celebrate pivots based on evidence as empiricism in action
• Distinguish commitment to goals from commitment to plans
• Explicitly expect plans to change as learning occurs
• Frame Sprint retrospectives around learning, not blame

Failure #4: Compromising Quality Silently

Problem: Under pressure to deliver faster, team silently compromises quality rather than openly discussing trade-offs.

Why problematic: Technical debt accumulates invisibly until it cripples velocity. Quality degradation discovered only when customers report issues.

Manifestation:

• Team skips automated tests "temporarily" that becomes permanent
• Code reviews become rubber stamps rather than rigorous examination
• Definition of Done eroded gradually without explicit decisions
• Technical debt items perpetually postponed

Root cause: Fear that defending quality will be interpreted as slow or uncommitted. Pressure to show "progress" through feature counts.

Fix:

• Make quality metrics visible and discuss trends openly
• Frame quality investment as enabling sustainable velocity
• Product Owner explicitly values technical health in priorities
• Definition of Done is non-negotiable; scope adjusts instead

Failure #5: Not Challenging Senior/Authority Figures

Problem: Junior team members don't question senior members' decisions or approaches even when seeing potential problems.

Why problematic: Hierarchical deference prevents diverse perspectives from surfacing. Seniors make worse decisions when not challenged.

Manifestation:

• Junior developer sees architectural flaw but doesn't mention it
• Team doesn't question Product Owner's priorities even when confused
• Developers accept unrealistic estimates from tech lead without pushback
• New team members observe dysfunctions but stay silent

Root cause: Organizational hierarchy creates power distance. Cultural norms against challenging authority. History of negative consequences for juniors questioning seniors.

Fix:

• Explicitly invite challenge and questions from all team members
• Senior members model seeking input: "What am I missing? Challenge my thinking."
• Celebrate instances where junior insights improved senior decisions
• Scrum Master ensures all voices heard, not just senior/vocal members

Failure #6: Pretending Uncertainty Doesn't Exist

Problem: Team pretends to be more confident about estimates, approaches, or outcomes than reality justifies.

Why problematic: False confidence prevents appropriate risk management. Stakeholders make decisions based on unrealistic information.

Manifestation:

• Team provides confident estimates for unfamiliar work without acknowledging uncertainty
• Product Owner projects firm delivery dates despite unknowns
• Team commits to Sprint Goals without expressing concerns about feasibility
• Unknowns not explicitly called out during Sprint Planning

Root cause: Belief that admitting uncertainty signals lack of professionalism. Pressure for "commitment" interpreted as confidence requirement.

Fix:

• Normalize uncertainty as reality in complex work
• Use confidence levels explicitly: "70% confident we can achieve this Sprint Goal"
• Buffer Sprint commitments when working in unfamiliar areas
• Frame Sprint Planning discussions around hypothesis-testing, not guarantees

Failure #7: Over-Promising to Appear Committed

Problem: Team commits to aggressive goals to demonstrate commitment rather than realistic assessment.

Why problematic: Over-commitment leads to missed Sprint Goals, quality compromises, or unsustainable pace. Stakeholder trust erodes as commitments consistently missed.

Manifestation:

• Sprint Planning commitments routinely exceed capacity
• Team consistently misses Sprint Goals despite "commitment"
• Quality degraded to meet commitments
• Overtime becomes normalized to fulfill over-commitments

Root cause: Conflating commitment with over-promising. Mistaking conservative forecasts for lack of dedication. Pressure to impress stakeholders.

Fix:

• Distinguish commitment to goals from unrealistic promises
• Track Sprint Goal achievement; address patterns of over-commitment
• Celebrate realistic forecasting over impressive-sounding promises
• Product Owner shields team from pressure to over-commit

Failure #8: Courage Theater Without Action

Problem: Team talks about courage, identifies need for difficult conversations or changes, but never follows through.

Why problematic: Identifying problems without addressing them creates cynicism. Talk without action is worse than not identifying issues.

Manifestation:

• Retrospectives identify improvements never implemented
• Team agrees someone's behavior is problematic but never addresses it
• Technical debt identified repeatedly but never prioritized
• Organizational impediments raised but never escalated

Root cause: Courage to identify problems without courage to act on them. Lack of psychological safety to follow through. No accountability for improvement implementation.

Fix:

• Retrospectives limit to 1-2 improvements team will actually implement
• Assign ownership for improvements with clear accountability
• Scrum Master ensures follow-through, not just identification
• Product Owner allocates capacity for improvements, not just features

Building Courage in Your Team

Courage cannot be mandated - it must be cultivated through leadership example, psychological safety creation, and consistent reinforcement of courageous behavior.

Create Psychological Safety First

Courage requires safety. Without it, rational self-preservation prevents risk-taking:

Leadership Actions:

• Respond constructively to bad news: thank the messenger, focus on problem-solving
• Model vulnerability: share own mistakes and uncertainties
• Admit when decisions were wrong; demonstrate that changing course based on evidence is strength
• Never punish truth-telling, even when message is uncomfortable
• Address immediately any instance where someone faces negative consequences for honesty

Team Practices:

• Assume positive intent when conflicts arise
• Frame mistakes as learning opportunities in Retrospectives
• Celebrate instances where courage led to better outcomes
• Share stories of past situations where early honesty prevented larger problems
• Explicitly normalize asking questions and admitting uncertainty

Reward Courage Explicitly

What gets recognized gets repeated. Make courage visible and valued:

Recognition Practices:

• Thank people publicly who raise concerns early
• Celebrate pivots based on evidence: "Great empiricism showing courage to adapt"
• Acknowledge difficult conversations: "I appreciate your courage in raising this"
• Share stories of courageous behavior in team meetings
• Include courage in performance evaluations alongside technical skills

Start Small, Build Gradually

Teams with limited psychological safety can't immediately tackle most difficult issues:

Graduated Approach:

• Early Sprints: Practice courage on low-stakes issues (process tweaks, tool choices)
• Building confidence: Address medium-difficulty topics (technical disagreements, workload concerns)
• Mature safety: Tackle high-stakes issues (performance problems, leadership dysfunction)
• Retrospectives: Explicitly discuss what made courage possible in each situation

Make Courage Easier Through Structure

Scrum framework provides structures that reduce courage requirement:

Use Framework Intentionally:

• Timeboxes limit failure consequences, making experiments safer
• Sprint Reviews normalize demonstrating incomplete work (Increment, not perfection)
• Retrospectives create explicit forum for difficult conversations
• Definition of Done provides objective quality standard to defend
• Product Owner role centralizes difficult prioritization decisions

Address Courage Failures Directly

When courage lacking causes problems, address pattern explicitly:

Intervention Approaches:

• Name the pattern: "I notice we often avoid difficult conversations until situations are critical"
• Explore root causes: "What prevents us from raising concerns earlier?"
• Collaborative problem-solving: "How can we make it safer to share bad news promptly?"
• Try experiments: "Let's explicitly practice raising small concerns in next three Sprints"
• Retrospect results: "Did our experiment make early honesty easier? What helped?"

Leadership Modeling

Teams take cues from leaders. Leadership courage creates permission for team courage:

Leadership Examples:

• Admitting to stakeholders when estimates were wrong
• Changing strategy publicly when evidence demands
• Defending team against unrealistic pressure
• Acknowledging own blind spots and seeking diverse input
• Taking responsibility for failures rather than blaming team

Connect Courage to Team Success

Help teams see empirical connection between courage and outcomes:

Evidence-Based Conversation:

• Track situations where early courage prevented problems
• Compare outcomes when issues raised early vs late
• Discuss velocity impact of addressing technical debt courageously
• Show stakeholder trust improving as transparency increases
• Demonstrate how courageous adaptation enabled Sprint Goal achievement

Courage Indicators: Healthy vs Unhealthy

Teams can assess courage through observable patterns distinguishing healthy courage from either recklessness or fear-dominated behavior.

Healthy Courage Indicators

Early Problem Reporting:

• Issues raised during Daily Scrum rather than hidden until Sprint end
• Team members request help within hours of being stuck, not days
• Impediments surfaced immediately, not after they've blocked work for extended periods
• Risks and uncertainties explicitly discussed during Sprint Planning

Productive Disagreement:

• Technical disagreements surface and get resolved through discussion
• Team members challenge each other's ideas respectfully
• Decisions include considering dissenting viewpoints
• Conflicts focus on approaches and outcomes, not personalities

Adaptation Based on Evidence:

• Team pivots mid-Sprint when inspection reveals better approaches
• Product Owner adjusts roadmap based on Sprint Review feedback
• Retrospectives lead to meaningful changes in team practices
• Failed experiments discussed openly, learnings extracted and applied

Quality Defense:

• Definition of Done maintained under pressure
• Technical debt addressed rather than perpetually deferred
• Team openly explains quality impact when pressured to cut corners
• Refactoring happens proactively, not only when crisis forces it

Vulnerability and Support:

• Team members admit mistakes promptly without defensiveness
• Questions asked freely without fear of appearing incompetent
• Help requested openly and provided willingly
• Knowledge gaps acknowledged as opportunities for growth

Unhealthy Courage Indicators

Recklessness (Too Much "Courage" Without Wisdom):

• Team takes unnecessary risks without considering consequences
• Architectural changes made without adequate testing or review
• Production deployments rushed despite obvious risks
• Experimentation without hypothesis or success criteria
• Ignoring expert advice to prove independence

Fear-Dominated Behavior (Too Little Courage):

• Problems concealed until Sprint end or later
• Team agrees to unrealistic commitments without voicing concerns
• Technical debt accumulates because no one defends quality investment
• Retrospectives focus on safe topics, avoid real dysfunctions
• Conflicts suppressed; resentments build silently
• Questions not asked due to fear of appearing incompetent

Courage Theater (Talk Without Action):

• Issues identified in Retrospectives but never addressed
• Team discusses need for difficult conversations but never has them
• Plans made to address technical debt but never executed
• Performance problems acknowledged privately but never confronted
• Improvements proposed but not implemented due to discomfort

Assessment Questions

Teams can reflect on courage health:

1. Transparency: Do we share bad news early, or hide problems hoping they resolve?
2. Conflict: Do disagreements surface and get resolved productively, or stay hidden?
3. Adaptation: Do we pivot when evidence demands, or maintain failing approaches?
4. Quality: Do we defend standards under pressure, or silently compromise?
5. Vulnerability: Do we admit mistakes and uncertainty, or pretend confidence we lack?
6. Challenge: Do we question questionable decisions respectfully, or comply silently?
7. Accountability: Do we address performance issues directly, or avoid them indefinitely?
8. Leadership: Does leadership reward truth-telling or punish bearers of bad news?

If answers reveal fear-dominated patterns, teams should explicitly discuss what prevents courage and collaboratively work toward psychological safety that enables it.

Conclusion

Courage in Scrum - the willingness to do the right thing, work on tough problems, explore unknowns, and engage in respectful disagreements - enables the empirical process control at Scrum's core. Without courage, teams cannot inspect their work honestly or adapt their approach boldly. The three pillars of Scrum require courage at every turn: transparency demands courage to share uncomfortable truths, inspection requires courage to acknowledge what findings reveal, adaptation requires courage to change course when evidence demands it.

Courage isn't the absence of fear - it's acting despite fear when team success requires it. Courage exists within systems of support, not isolation. The Scrum framework deliberately creates psychological safety through timeboxed Sprints limiting failure consequences, Sprint Retrospectives normalizing learning from mistakes, and distributed accountabilities making difficult decisions shared rather than individual burdens.

Critical insights for teams:

• Distinguish courage from recklessness: Courage is calculated risk-taking informed by evidence; recklessness is unnecessary risk without considering consequences
• Eight forms of courage: Transparency about progress, admitting not knowing, holding others accountable, challenging decisions, experimenting, productive conflict, admitting mistakes, defending quality
• Psychological safety is prerequisite: Without safety, courage becomes self-destructive; with it, courage becomes normal team behavior
• Start small, build gradually: Teams can't immediately tackle hardest issues; practice courage on low-stakes situations first
• Leadership modeling is essential: Teams observe leadership behavior; leaders who admit mistakes enable team courage

As teams cultivate courage, they transform from groups mechanically executing Scrum ceremonies into genuinely empirical teams that inspect honestly and adapt boldly. This courage - grounded in psychological safety and supported by Scrum framework structures - enables teams to tackle the complex problems that attracted them to Scrum initially.

Explore the other Scrum values - commitment, focus, openness, and respect - to understand how they work together with courage to enable effective empiricism in complex product development.

Continue Reading

Frequently Asked Questions (FAQs) / People Also Ask (PAA)