@shaykec/bridge 0.4.25 → 0.4.27

package/modules/risk-management/content.md

@@ -0,0 +1,162 @@
+# Risk Management — Identifying and Mitigating Project Risks
+
+<!-- hint:slides topic="Risk management: identification techniques, probability-impact matrix, response strategies, and risk register" slides="5" -->
+
+## What Is a Risk?
+
+A **risk** is an uncertain event or condition that, if it occurs, has a positive or negative effect on project objectives. In practice, we usually focus on *threats* (negative risks).
+
+**Risk = Uncertainty × Impact**
+
+Something is a risk when:
+1. **It might happen** (uncertainty)
+2. **It would matter if it did** (impact)
+
+"I'm 100% sure we'll miss the deadline" is not a risk—it's a problem. "There's a 30% chance the API vendor delays their release" is a risk.
+
+## Risk Identification Techniques
+
+### Brainstorming
+
+Gather the team and ask: "What could go wrong?" Use prompts:
+- Technical: integrations, performance, security
+- People: key person dependency, skill gaps
+- External: vendors, regulators, market
+- Process: coordination, handoffs, tooling
+
+### Pre-Mortem
+
+Imagine the project has failed. Ask: "What went wrong?" People are better at imagining failure than success. List causes without judging—quantity first, prioritize later.
+
+### SWOT Analysis
+
+| Strengths | Weaknesses |
+|-----------|------------|
+| Opportunities | Threats |
+
+Threats are risks. Weaknesses can become risks if they're exposed (e.g., "no automated tests" → risk of regression).
+
+### Dependency Mapping
+
+Draw a dependency graph: who/what do we depend on? Each dependency is a potential risk. External APIs, third-party services, other teams, legacy systems.
+
+## Risk Matrix (Probability × Severity)
+
+Plot risks on a 2×2 or 3×3 grid:
+
+```mermaid
+quadrantChart
+  title Risk Matrix
+  x-axis Low Impact --> High Impact
+  y-axis Low Probability --> High Probability
+  quadrant-1 Monitor
+  quadrant-2 Mitigate
+  quadrant-3 Accept
+  quadrant-4 Avoid or Transfer
+  "Vendor delay": [0.3, 0.8]
+  "Key person leaves": [0.7, 0.6]
+  "API rate limits": [0.5, 0.4]
+  "Scope creep": [0.8, 0.7]
+```
+
+| Probability | Low Impact | Medium Impact | High Impact |
+|-------------|------------|---------------|-------------|
+| **High** | Monitor | Mitigate | Avoid or Transfer |
+| **Medium** | Accept | Mitigate | Mitigate |
+| **Low** | Accept | Accept | Monitor |
+
+**High probability + High impact** = Address first. Avoid, transfer, or aggressively mitigate.
+
+**Low probability + Low impact** = Accept. Document and move on.
+
+## Risk Response Strategies
+
+| Strategy | Meaning | Example |
+|----------|---------|---------|
+| **Avoid** | Eliminate the risk by changing the approach | Don't use the risky vendor; build in-house |
+| **Mitigate** | Reduce probability or impact | Add integration tests; have a fallback API |
+| **Transfer** | Shift impact to someone else | Insurance, warranties, contracts, SLA penalties |
+| **Accept** | Acknowledge and plan for it | Document; have a contingency budget or buffer |
+
+You don't eliminate all risks. You choose which to address and which to accept.
+
+## Risk Register
+
+A **risk register** tracks identified risks, their assessment, and response.
+
+| ID | Risk | Prob | Impact | Response | Owner |
+|----|------|------|--------|----------|-------|
+| R1 | API vendor delays v2 | M | H | Mitigate: parallel prototype | Dev Lead |
+| R2 | Key architect on vacation during integration | L | H | Mitigate: knowledge share before | PM |
+| R3 | Performance regression in legacy module | M | M | Mitigate: load tests in CI | QA |
+
+Template:
+
+```markdown
+## Risk Register
+
+| ID | Risk Description | Probability | Impact | Response | Owner |
+|----|------------------|-------------|--------|----------|-------|
+| R1 | [What could go wrong] | L/M/H | L/M/H | Avoid/Mitigate/Transfer/Accept | [Name] |
+```
+
+## Dependency Mapping
+
+Map dependencies to surface risks:
+
+```mermaid
+flowchart LR
+  A[Our Service] --> B[Auth API]
+  A --> C[Payment Gateway]
+  A --> D[Legacy DB]
+  C --> E[Stripe]
+  D --> F[Ops Team]
+```
+
+Each arrow is a dependency—and a potential failure point. Document: What happens if B, C, or D fails? Who owns it?
+
+## Technical Risks
+
+| Category | Example Risks |
+|----------|---------------|
+| **Integration** | API changes, rate limits, auth failures, version mismatch |
+| **Performance** | Load, latency, scalability under peak |
+| **Security** | Vulnerabilities, credential exposure, compliance |
+| **Legacy** | Unknown behavior, no tests, single point of failure |
+| **Data** | Migration failures, corruption, GDPR/retention |
+
+For each, ask: What's the probability? What's the impact? What's our response?
+
+## Communicating Risks Without Being the "Doom Person"
+
+1. **Lead with context** — "Here are the risks we're tracking and how we're addressing them."
+2. **Pair risks with responses** — Don't just list problems; show the plan.
+3. **Use RAG status** — Red/Amber/Green. Amber = "we're watching it."
+4. **Avoid surprise** — Surface risks early. "I've been tracking this; here's the update."
+5. **Frame as ownership** — "We're on it" vs "Something bad might happen."
+
+The goal is *transparency*, not alarm. Stakeholders trust you when you show you're managing risk, not ignoring it.
+
+## Monitoring and Updating Risks
+
+Risks change. Review the register:
+
+- **Weekly** — In team sync; any new risks? Any change in probability/impact?
+- **At milestones** — Major phase gates; re-assess top risks.
+- **When triggers fire** — "If X happens, we re-evaluate." Define triggers.
+
+Close risks when they're no longer relevant (avoided, passed, or occurred and handled).
+
+## Risk Management Flow
+
+```mermaid
+flowchart TD
+  A[Identify] --> B[Assess]
+  B --> C[Prioritize]
+  C --> D[Plan Response]
+  D --> E[Implement]
+  E --> F[Monitor]
+  F -.->|Update| A
+```
+
+**Identify** → **Assess** (prob × impact) → **Prioritize** (matrix) → **Plan response** (avoid/mitigate/transfer/accept) → **Implement** → **Monitor** (and loop).

package/modules/risk-management/exercises.md

@@ -0,0 +1,86 @@
+# Risk Management — Exercises
+
+## Exercise 1: Pre-Mortem for a Release
+
+**Task:** Your team is shipping a "payments v2" release in 6 weeks. Run a pre-mortem: list 5 reasons the release failed. Prioritize the top 2 and for each, suggest one mitigation.
+
+**Validation:**
+- [ ] 5 failure modes listed
+- [ ] Top 2 selected and justified
+- [ ] Each has at least one mitigation idea
+- [ ] Mitigations are concrete (not "try harder")
+
+**Hints:**
+1. Think: integration, people, scope, vendors, testing
+2. "We underestimated" is common—dig into *what* was underestimated
+3. Mitigation examples: "Spike on Stripe API in week 1," "Document rollback runbook"
+
+---
+
+## Exercise 2: Risk Matrix and Prioritization
+
+**Task:** Plot these risks on a 3×3 matrix (Prob × Impact): (A) Vendor delays API by 2 weeks—M prob, H impact. (B) Dev leaves mid-project—L prob, H impact. (C) Minor UI bugs in edge cases—H prob, L impact. (D) Security audit finds critical flaw—L prob, H impact. Which do you address first? Why?
+
+**Validation:**
+- [ ] All 4 plotted correctly
+- [ ] Priority order explained
+- [ ] At least one "accept" (don't mitigate everything)
+
+**Hints:**
+1. A: Mitigate (parallel work, fallback)
+2. B: Mitigate (knowledge share) or Transfer (retention)
+3. C: Accept (low impact)
+4. D: Mitigate (early audit) or Avoid (security review upfront)
+
+---
+
+## Exercise 3: Risk Register for a Sprint
+
+**Task:** Create a risk register for a 2-week sprint. Include: (1) Integration risk with external API, (2) Key person on PTO, (3) Scope creep from stakeholder. For each: probability, impact, response strategy, and owner.
+
+**Validation:**
+- [ ] 3 risks in register format
+- [ ] Prob/impact assigned
+- [ ] Response is Avoid/Mitigate/Transfer/Accept
+- [ ] Owner is named
+
+**Hints:**
+1. Integration: Mitigate—spike early, mock for tests
+2. PTO: Mitigate—handoff, documentation
+3. Scope creep: Avoid—sprint goal lock; or Mitigate—"we'll add to backlog"
+
+---
+
+## Exercise 4: Dependency Map
+
+**Task:** Draw a dependency map for "User can reset password via email." Include: your app, email service, auth service, database, and any teams. For each dependency, note: failure mode and owner.
+
+**Validation:**
+- [ ] At least 4 dependencies
+- [ ] Failure mode per dependency
+- [ ] Owner identified
+- [ ] At least one external dependency (email, auth)
+
+**Hints:**
+1. Email: SendGrid/AWS SES—delays, rate limits, deliverability
+2. Auth: Your service or third-party—token validation
+3. DB: User records—availability, migration
+4. Owner: Who fixes it if it breaks?
+
+---
+
+## Exercise 5: Risk Communication Draft
+
+**Task:** Your highest risk is "Payment gateway may not support recurring billing by our launch date." Write a 4-sentence status for an executive. Include: the risk, current status, what you're doing, and when you'll know more.
+
+**Validation:**
+- [ ] No alarmist language
+- [ ] Risk + response included
+- [ ] Timeline or next check-in stated
+- [ ] Tone is "we're managing it"
+
+**Hints:**
+1. Lead: "We're tracking a dependency on the payment gateway."
+2. Status: "Confirmed support by [date] or we have a fallback."
+3. Action: "Weekly sync with vendor; fallback design in progress."
+4. Next: "Update at next steering."

package/modules/risk-management/module.yaml

@@ -0,0 +1,41 @@
+slug: risk-management
+title: "Risk Management — Identifying and Mitigating Project Risks"
+version: 1.0.0
+description: "Identify, assess, and mitigate project risks — risk matrix, response strategies, and stakeholder communication."
+category: project-management
+tags: [risk-management, project-management, mitigation, planning, dependencies]
+difficulty: intermediate
+
+xp:
+  read: 15
+  walkthrough: 40
+  exercise: 25
+  quiz: 20
+  quiz-perfect-bonus: 10
+
+time:
+  quick: 5
+  read: 20
+  guided: 50
+
+prerequisites: [sprint-planning]
+related: [stakeholder-communication, incident-response]
+
+triggers:
+  - "How do I identify project risks?"
+  - "What is a risk matrix?"
+  - "How do I mitigate technical risks?"
+  - "How do I communicate risks to stakeholders?"
+
+visuals:
+  diagrams: [diagram-mermaid, diagram-flow]
+  quiz-types: [quiz-matching, quiz-timed-choice]
+  slides: true
+
+sources:
+  - url: "https://www.pmi.org/pmbok-guide-standards"
+    label: "PMI PMBOK"
+    type: docs
+  - url: "https://www.amazon.com/Waltzing-Bears-Managing-Risk-Software/dp/0932633609"
+    label: "Waltzing With Bears by DeMarco & Lister"
+    type: book

package/modules/risk-management/quick-ref.md

@@ -0,0 +1,82 @@
+# Risk Management Quick Reference
+
+## Risk = Uncertainty × Impact
+
+Something is a risk when it *might* happen and *would matter*.
+
+## Identification Techniques
+
+| Technique | Use When |
+|-----------|----------|
+| Brainstorming | Team kickoff, broad sweep |
+| Pre-mortem | "Project failed—why?" |
+| SWOT | Strategic context |
+| Dependency mapping | Integration-heavy projects |
+
+## Risk Matrix
+
+| | Low Impact | Med Impact | High Impact |
+|---|------------|------------|-------------|
+| **High Prob** | Monitor | Mitigate | Avoid/Transfer |
+| **Med Prob** | Accept | Mitigate | Mitigate |
+| **Low Prob** | Accept | Accept | Monitor |
+
+## Response Strategies
+
+| Strategy | Meaning |
+|----------|---------|
+| **Avoid** | Change approach; eliminate risk |
+| **Mitigate** | Reduce prob or impact |
+| **Transfer** | Shift impact (insurance, contract) |
+| **Accept** | Document; have buffer/plan B |
+
+## Risk Register Template
+
+```
+| ID | Risk | Prob | Impact | Response | Owner |
+|----|------|------|--------|----------|-------|
+| R1 | [Description] | L/M/H | L/M/H | Strategy | [Name] |
+```
+
+## Technical Risk Categories
+
+- **Integration** — APIs, vendors, versions
+- **Performance** — Load, scale, latency
+- **Security** — Vulnerabilities, compliance
+- **Legacy** — Unknowns, no tests
+- **Data** — Migration, corruption
+
+## Communicating Risks
+
+1. Lead with context
+2. Pair risk + response
+3. Use RAG (Red/Amber/Green)
+4. No surprises—surface early
+5. "We're on it" tone
+
+## Dependency Map
+
+```
+[Our System] → [Dependency 1]
+            → [Dependency 2]
+            → [Dependency 3]
+```
+
+For each: What if it fails? Who owns it?
+
+## Mermaid: Risk Flow
+
+```mermaid
+flowchart LR
+  A[Identify] --> B[Assess]
+  B --> C[Prioritize]
+  C --> D[Plan]
+  D --> E[Implement]
+  E --> F[Monitor]
+```
+
+## Review Cadence
+
+- **Weekly** — Team sync; any changes?
+- **Milestones** — Re-assess top risks
+- **Triggers** — "If X, re-evaluate"

package/modules/risk-management/quiz.md

@@ -0,0 +1,73 @@
+# Risk Management — Quiz
+
+## Question 1
+
+A risk is best defined as:
+
+A) Something that has already gone wrong
+B) An uncertain event that, if it occurs, affects project objectives
+C) A guarantee of project failure
+D) A problem that needs immediate fixing
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: A risk is characterized by uncertainty—it might or might not occur. If it occurs, it has an effect (positive or negative) on project objectives. Problems are current; risks are potential future events. -->
+
+## Question 2
+
+In a risk matrix, a "high probability, high impact" risk should typically be:
+
+A) Accepted
+B) Monitored only
+C) Avoided, transferred, or aggressively mitigated
+D) Documented for later
+
+<!-- ANSWER: C -->
+<!-- EXPLANATION: High-probability, high-impact risks pose the greatest threat. The priority is to avoid (change approach), transfer (insurance, contract), or mitigate (reduce prob/impact). Accept is for lower-priority risks. -->
+
+## Question 3
+
+The "Transfer" risk response strategy means:
+
+A) Moving the risk to another project
+B) Shifting the impact to another party (e.g., insurance, contract)
+C) Delegating the risk to a junior team member
+D) Ignoring the risk
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: Transfer shifts the impact to another party. Examples: insurance, warranties, penalty clauses in contracts, SLAs. The risk may still occur, but the financial or operational impact is borne by someone else. -->
+
+## Question 4
+
+A pre-mortem is useful because:
+
+A) It predicts the future
+B) It helps people imagine failure and surface risks they might not otherwise consider
+C) It eliminates all risks
+D) It replaces the need for a risk register
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: In a pre-mortem, you imagine the project has already failed and ask "what went wrong?" This counterfactual framing helps people think more honestly about threats. It surfaces assumptions and blind spots. -->
+
+## Question 5
+
+When communicating risks to stakeholders, you should:
+
+A) Only share risks when they become problems
+B) Lead with context, pair risks with responses, and avoid alarmism
+C) Use dramatic language to get attention
+D) Hide technical risks from non-technical stakeholders
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: Effective risk communication builds trust. Lead with context ("here's what we're tracking"), pair each risk with your response plan, and maintain a calm tone. Avoid surprises; surface early. Frame as "we're on it." -->
+
+## Question 6
+
+Dependency mapping helps identify risks because:
+
+A) It shows the project timeline
+B) Each dependency is a potential failure point
+C) It replaces the risk register
+D) It guarantees no integration issues
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: Dependencies—external APIs, vendors, other teams, legacy systems—are points of reliance. If a dependency fails, your project is affected. Mapping dependencies surfaces "what if X fails?" risks systematically. -->

package/modules/risk-management/resources.md

@@ -0,0 +1,40 @@
+# Risk Management — Resources
+
+## Official and Standards
+
+- [PMI PMBOK Guide](https://www.pmi.org/pmbok-guide-standards) — Project Management Institute. Industry standard for project management; includes risk management knowledge area.
+- [PMBOK Risk Management](https://www.pmi.org/learning/library/risk-management-overview-7082) — Overview of risk processes from PMI.
+- [ISO 31000 Risk Management](https://www.iso.org/iso-31000-risk-management.html) — International standard for risk management principles and guidelines.
+
+## Books
+
+- **Waltzing With Bears: Managing Risk on Software Projects** by Tom DeMarco and Timothy Lister — Classic on software risk. Emphasizes quantifying and facing risks instead of pretending they don't exist.
+- **The Checklist Manifesto** by Atul Gawande — How simple checklists reduce risk in complex work (surgery, aviation, projects).
+- **Project Risk Management** by Chris Chapman and Stephen Ward — Academic but practical; risk analysis and response.
+
+## Articles and Readings
+
+- [Pre-Mortems: Being Smart at the Start](https://hbr.org/2007/09/performing-a-project-premortem) — Gary Klein, HBR. Origin of the pre-mortem technique.
+- [Risk Management in Agile](https://www.scrum.org/resources/blog/risk-management-agile-context) — Scrum.org. How risk fits in iterative delivery.
+- [Dependency Mapping for Risk](https://www.atlassian.com/agile/project-management/dependencies) — Atlassian. Mapping and managing dependencies.
+- [Risk Register Templates](https://www.smartsheet.com/content/risk-register-templates) — Smartsheet. Free risk register templates and examples.
+- [Communicating Risk to Stakeholders](https://www.pmi.org/learning/library/communicating-risk-stakeholders-7098) — PMI. Best practices for risk reporting.
+
+## Tools
+
+- [Jira](https://www.atlassian.com/software/jira) — Risk tracking via custom fields, labels, or linked issues.
+- [Linear](https://linear.app/) — Risks as issues; dependency linking.
+- [Notion](https://www.notion.so/) — Risk registers, dependency maps, databases.
+- [Miro](https://miro.com/) — Risk matrix and dependency mapping templates.
+- [Lucidchart](https://www.lucidchart.com/) — Dependency and flow diagrams.
+- [Risk Register Pro](https://www.riskregisterpro.com/) — Dedicated risk register tool (paid).
+
+## Videos and Podcasts
+
+- [Risk Management Fundamentals](https://www.youtube.com/results?search_query=project+risk+management+fundamentals) — Search for PMI or Coursera intros.
+- [Agile Uprising — Risk in Agile](https://agileuprising.com/) — Podcast episodes on risk and uncertainty in agile contexts.
+
+## Templates
+
+- [PMI Risk Register Template](https://www.pmi.org/learning/library/risk-register-template-6867) — Free downloadable risk register.
+- [Pre-Mortem Worksheet](https://hbr.org/2007/09/performing-a-project-premortem) — Gary Klein's pre-mortem format (from HBR article above).

package/modules/risk-management/walkthrough.md

@@ -0,0 +1,67 @@
+# Risk Management Walkthrough — Learn by Doing
+
+## Before We Begin
+
+**Diagnostic:** What's the difference between a *risk* and an *issue*? When something has already gone wrong, is it still a risk—or something else? How would you treat each differently?
+
+**Checkpoint:** You can explain that a risk is *potential* (it might happen); an issue is *actual* (it has happened). Your response to each is different.
+
+---
+
+## Step 1: Run a Pre-Mortem
+
+**Task:** Pick a project (real or hypothetical). Imagine it has failed. Write 5–7 plausible reasons it failed. Don't filter—just list. Then pick the top 2 that feel most likely.
+
+**Question:** Why does imagining failure surface risks more effectively than asking "what could go wrong?" What assumptions did you uncover?
+
+**Checkpoint:** At least 5 failure modes listed; top 2 selected with brief rationale.
+
+---
+
+## Step 2: Build a Risk Matrix
+
+**Task:** Take your top 2 risks and 2 more (e.g., "key person unavailable," "third-party API delay"). For each, assign probability (L/M/H) and impact (L/M/H). Plot them on a 3×3 risk matrix. Which one would you address first?
+
+**Question:** What makes "high probability + high impact" different from "low probability + high impact"? How might stakeholders disagree with your ratings?
+
+**Checkpoint:** All 4 risks are plotted; priority order is justified.
+
+---
+
+## Step 3: Choose Response Strategies
+
+**Task:** For each of your 4 risks, assign a response: Avoid, Mitigate, Transfer, or Accept. For at least 2, write one concrete action (e.g., "Mitigate: run load tests in CI before each release").
+
+**Question:** When is "Accept" the right choice? When would you avoid vs mitigate?
+
+**Checkpoint:** Each risk has a strategy; at least 2 have specific actions.
+
+---
+
+## Step 4: Create a Risk Register
+
+**Task:** Turn your 4 risks into a risk register. Include: ID, description, probability, impact, response, and owner. Add one more risk (e.g., technical: "integration test gaps") and fill it in.
+
+**Question:** Who should "own" a risk? What does ownership mean—tracking, reporting, or executing the response?
+
+**Checkpoint:** Register has 5 risks; format is consistent; owners assigned.
+
+---
+
+## Step 5: Map Dependencies
+
+**Task:** Draw a simple dependency map for your project: your system in the center, with 4–5 things it depends on (people, systems, vendors). For each dependency, note: What happens if it fails? Who owns it?
+
+**Question:** Which dependency would hurt most if it failed? Is that reflected in your risk register?
+
+**Checkpoint:** Map is drawn; each dependency has a failure implication.
+
+---
+
+## Step 6: Draft Risk Communication
+
+**Task:** Pick your highest-priority risk. Write a 3–4 sentence status update for a stakeholder. Lead with context, include the risk and your response, and avoid alarmism.
+
+**Question:** What would make you sound like the "doom person"? What would make you sound like you're on top of it?
+
+**Checkpoint:** Update is calm, includes response, and is stakeholder-appropriate.

package/modules/running-effective-standups/content.md

@@ -0,0 +1,119 @@
+# Running Effective Standups — Beyond Status Reports
+
+<!-- hint:slides topic="Effective standups: purpose (coordination vs status), format options, timeboxing, async alternatives, and anti-patterns" slides="5" -->
+
+## The Purpose of Standups
+
+A daily standup (or daily scrum) is **not a status report to your manager**. Its purpose is **coordination**: help the team align on the day, surface blockers, and decide who needs to talk to whom afterward. When standups become status reports, people disengage and the meeting loses value.
+
+**Scrum defines three questions** (what did I do, what will I do, any impediments?), but many teams find these lead to monologues. The key is to design the standup so it **enables coordination**, not reporting.
+
+## The Three Questions — and Why They Often Fail
+
+The classic format:
+
+1. What did I do yesterday?
+2. What will I do today?
+3. Any blockers?
+
+**Why it fails:** People recite lists. No one listens. Blockers get buried at the end. Managers use it to "check in," turning it into a status meeting. The antidote: refocus on **blockers and coordination**—what needs to happen *next*, and who needs to talk to whom.
+
+## Alternative Formats
+
+### Walk the Board
+
+Go column by column on your Kanban/Scrum board instead of person by person. For each in-progress or "ready" item: Who's working on it? Blocked? Needs help? This keeps focus on **work**, not people.
+
+**Example:** "The API integration story—Sarah, still in progress? Anyone blocked on it?"
+
+### Focus on Blockers
+
+Start with: "Anyone blocked or need help today?" Resolve those first. Then optionally do a quick round of "what's your focus today?" This flips the script: coordination first, status second.
+
+### Round-Robin vs Topic-Based
+
+- **Round-robin:** Each person speaks in turn. Predictable, but can feel like a checklist.
+- **Topic-based:** Organize by work item or theme. "Let's go through the payment migration—who's involved, what's the status?" Better for cross-cutting work.
+
+## Timeboxing — 15 Minutes Max
+
+Standups should be **short**. 15 minutes is the upper bound; many effective teams do 10 or less. If you're running over:
+
+- Take detailed discussions **offline**—"Let's sync on that after standup."
+- Use a timer. When someone drones, gently: "Can we pick this up in a breakout?"
+- Consider reducing frequency (e.g., three times a week instead of daily).
+
+## Async Standups
+
+**When they work:** Distributed teams, flexible schedules, or teams that don't need real-time coordination.
+
+**Tools:** Slack (threaded updates), Loom (short video updates), Geekbot, Standuply, or a shared doc (Notion, Google Doc) where everyone posts by a deadline.
+
+**Template example:**
+```
+Yesterday: [1–2 bullets]
+Today: [1–2 bullets]
+Blockers: [none / describe]
+```
+
+**Trade-offs:** Async saves meeting time but loses real-time discussion. Best when most work is independent; less ideal when lots of coordination is needed.
+
+## Sync vs Async Standup Flow
+
+```mermaid
+flowchart TD
+  subgraph Sync["Sync Standup"]
+    A[Team gathers same time] --> B[Quick round or walk the board]
+    B --> C[Blockers surfaced]
+    C --> D[Breakouts scheduled]
+  end
+
+  subgraph Async["Async Standup"]
+    E[Each person posts by deadline] --> F[Team reads updates]
+    F --> G[Blockers flagged in thread]
+    G --> H[Follow-up DMs or ad-hoc sync]
+  end
+
+  Sync -->|Real-time coordination| D
+  Async -->|Flexibility, no meeting| H
+```
+
+## Common Anti-Patterns
+
+| Anti-Pattern | Better Practice |
+|--------------|-----------------|
+| Status report to manager | Facilitate for the team; manager observes or doesn't attend |
+| Problem-solving in standup | "Let's grab 2–3 people and discuss after" |
+| Running long | Timebox 15 min; take discussions offline |
+| Low energy / no one listening | Change format (walk the board, focus on blockers); make it interactive |
+| Same person always talks longest | Use a timer or pass-the-ball; "One thing you're focused on today" |
+
+## Tips for Remote Standups
+
+1. **Cameras on** — Improves engagement and signals presence.
+2. **Stable video and audio** — Invest in good mics; lag kills flow.
+3. **Screen share the board** — So everyone sees the same view when walking the board.
+4. **Use chat for follow-ups** — "We'll sync in a thread / DM after."
+5. **Rotate facilitators** — Spread ownership; avoid one person dominating.
+
+## When to Skip Standup Altogether
+
+Consider skipping or reducing frequency when:
+
+- Work is highly independent and low-coordination
+- Team is very small (2–3 people) and already in constant contact
+- You've tried multiple formats and no one finds value
+- You're between sprints or in a light work period
+
+Standup is a **tool**, not a religion. If it doesn't serve coordination, change it or drop it.
+
+## Quick Format Comparison
+
+| Format | Best For | Risk |
+|--------|----------|------|
+| Three questions | Traditional Scrum teams | Becomes status report |
+| Walk the board | Kanban, visual teams | Requires up-to-date board |
+| Blockers first | Teams with many dependencies | Might skip "what I'm doing" context |
+| Async | Distributed, flex schedules | No real-time discussion |
+
+Choose based on your team's coordination needs and culture.