# Facilitation Techniques

Practical methods for facilitating scrum events effectively. A good facilitator ensures every voice is heard, discussions stay focused, and events produce clear outcomes within their timebox.

---

## Core Facilitation Principles

| Principle | Application |
|---|---|
| **Neutrality** | Facilitate the process, not the content - do not push your own opinions on what to build |
| **Equal voice** | Create space for quieter members; prevent dominant voices from monopolizing |
| **Purpose-driven** | Every event has a goal - redirect when the discussion drifts |
| **Timebox respect** | Time constraints create focus - enforce them consistently |
| **Safe space** | People contribute honestly only when they feel psychologically safe |
| **Outcomes over activity** | A meeting without clear outcomes is a meeting that should not have happened |

---

## Timeboxing Strategies

### Setting and Enforcing Timeboxes

| Technique | Description |
|---|---|
| **Visible timer** | Use a shared timer visible to all participants - removes the SM as the "bad guy" |
| **Halfway check** | At 50% of the timebox, check progress and adjust scope if needed |
| **Five-minute warning** | Alert the group five minutes before the timebox ends to wrap up |
| **Parking lot** | Capture off-topic items on a visible list for discussion after the event |
| **Consent to extend** | If the timebox must extend, get explicit team agreement and set a new hard stop |

### Timebox Recovery

When a discussion is running long:

1. Summarize what has been decided so far
2. Identify what remains undecided
3. Ask: "Can we resolve this in two minutes, or should we take it offline?"
4. If offline: assign an owner, set a deadline, move on
5. Never let a single topic consume the entire event

---

## Ensuring Participation

### Techniques for Balanced Participation

| Technique | When to Use | How It Works |
|---|---|---|
| **Round robin** | When a few people dominate | Go around the room, each person speaks in turn |
| **Silent writing** | When groupthink is a risk | Everyone writes ideas independently before sharing |
| **Dot voting** | When prioritizing many items | Each person gets a fixed number of votes to distribute |
| **1-2-4-all** | When the group is large or shy | Think alone (1), discuss in pairs (2), share in fours (4), then whole group |
| **Fist of five** | When checking consensus | Hold up 1-5 fingers to indicate agreement level |
| **Lean coffee** | When the team wants to set the agenda | Topics proposed, voted on, discussed in timeboxed rounds |

### Handling Dominant Participants

1. Acknowledge their contribution: "Good point. Let's hear from others on this."
2. Use structured formats (round robin, silent writing) that distribute speaking time
3. Redirect privately if needed: "I value your input. Can you help me draw out the quieter members?"
4. Set ground rules at the start: "Let's aim for everyone to speak before anyone speaks twice."

### Drawing Out Quiet Participants

1. Ask specific, non-threatening questions: "What is your perspective on this?" rather than putting them on the spot
2. Use silent writing so they can contribute without speaking first
3. Create smaller breakout groups where quieter people feel more comfortable
4. Follow up individually after the meeting to understand barriers to participation
5. Never force someone to speak - create opportunities, not obligations

---

## Handling Conflict

### Healthy vs Unhealthy Conflict

| Healthy | Unhealthy |
|---|---|
| Disagreement about ideas and approaches | Personal attacks or blame |
| Challenging assumptions with evidence | Dismissing others without listening |
| Passionate debate that leads to better decisions | Repeated arguments without resolution |
| Openness to changing your mind | Entrenched positions defended out of ego |

### Conflict Resolution Techniques

| Technique | When to Use |
|---|---|
| **Name it** | "I notice we have different views on this. Let's explore both." |
| **Separate people from positions** | "What problem are we trying to solve?" rather than "Why do you want X?" |
| **Time-bound exploration** | "Let's spend five minutes hearing each perspective, then decide." |
| **Data over opinions** | "What evidence supports each approach? Can we run a small experiment?" |
| **Parking lot** | If the conflict is blocking progress on other topics, park it and address it separately |
| **Break** | If emotions are high, take a five-minute break before continuing |
| **Offline resolution** | If two people are stuck, facilitate a private conversation after the event |

### Escalation Path

1. Let the team attempt to resolve it themselves
2. Facilitate a structured discussion if they are stuck
3. If the conflict persists across multiple Sprints, address it in a one-on-one coaching session
4. If it affects team performance, involve management with the team's knowledge

---

## Retrospective Formats

### Choosing a Format

| Format | Best For | Structure |
|---|---|---|
| **Start-Stop-Continue** | General purpose, simple | Three columns: what to start doing, stop doing, continue doing |
| **Mad-Sad-Glad** | When morale or team dynamics need attention | Three columns based on emotions about the Sprint |
| **4Ls** | Structured reflection | Four columns: Liked, Learned, Lacked, Longed for |
| **Sailboat** | Visual teams, goal-oriented | Wind (what propels us), Anchor (what holds us back), Rocks (risks), Island (goal) |
| **Timeline** | After a complex or eventful Sprint | Plot events on a timeline, identify patterns and turning points |
| **Starfish** | Nuanced version of Start-Stop-Continue | Five categories: More of, Less of, Keep doing, Start doing, Stop doing |
| **Three Questions** | Quick, focused | What went well? What did not? What will we do differently? |

### Retrospective Flow

Regardless of format, follow this five-phase structure:

1. **Set the stage** (5 min) - Welcome, check in, state the purpose, review working agreements
2. **Gather data** (15-20 min) - Collect observations using the chosen format; silent writing first, then sharing
3. **Generate insights** (15-20 min) - Group related items, identify root causes, look for patterns across Sprints
4. **Decide what to do** (10-15 min) - Select 1-3 actionable improvements; each must have an owner and deadline
5. **Close** (5 min) - Summarize actions, thank the team, quick check-out

### Common Retrospective Mistakes

| Mistake | Fix |
|---|---|
| Skipping the retrospective when the Sprint went well | Good Sprints have lessons too - what made it good and how to sustain it |
| Too many actions | Limit to 1-3 actions per Sprint; more leads to none being completed |
| Actions without owners | Every action needs a named person and a deadline |
| Never reviewing previous actions | Start every retrospective by reviewing the status of previous actions |
| Manager attendance killing honesty | Retrospectives are for the team; managers attend only by team invitation |
| Same format every time | Rotate formats to prevent staleness and surface different types of insights |
| Focusing only on negatives | Explicitly ask what went well - reinforcing good practices is as important as fixing problems |

---

## Event-Specific Facilitation Tips

### Daily Scrum

- It belongs to the Developers, not the Scrum Master - the SM ensures it happens but does not run it
- Focus on progress toward the Sprint Goal, not individual status reports
- Three useful prompts: "What did I do yesterday toward the Sprint Goal? What will I do today? What is blocking me?"
- If it consistently runs over 15 minutes, the team is discussing solutions instead of identifying topics - move detailed discussions to after the event
- Walk the board (review the Sprint Backlog) as an alternative to round-robin status

### Sprint Planning

- Ensure the Product Owner has a refined backlog before the event starts
- Facilitate Sprint Goal creation first (Topic 1) before selecting items (Topic 2)
- Developers own the selection and decomposition - the SM facilitates, does not decide
- If planning consistently takes the full timebox, coach the team on pre-refinement

### Sprint Review

- This is not a demo session - it is an inspect-and-adapt event for the product
- Invite stakeholders and encourage their feedback
- Compare what was delivered against the Sprint Goal
- Discuss what to do next based on feedback and market changes
- The Product Owner may adjust the backlog based on stakeholder input

---

## Facilitation Checklist

Before any scrum event:

- [ ] Purpose of the event is clear to all participants
- [ ] Timebox is set and a visible timer is ready
- [ ] Required participants are present and available for the full duration
- [ ] Pre-work is complete (refined backlog for planning, data for retro)
- [ ] Facilitation format is chosen and materials are prepared
- [ ] Parking lot is ready for capturing off-topic items
- [ ] Previous action items are ready for review (retrospective)
