Teamwork & Roles
Teamwork & Roles 🤝
High-performing teams are intentional about structure, accountability, and feedback. Tools are secondary; behavior is primary.
Core Roles & Rotation Philosophy (teamwork/roles.md)
Every student will meaningfully experience multiple perspectives. Roles are not silos; they are emphases for stewardship.
| Role | Primary Focus | Key Deliverables / Signals | Common Anti‑Patterns |
|---|---|---|---|
| Iteration Lead | Flow of work, goals, status report | Goals issue/doc, updated board, on-time report | Hero syndrome, doing instead of enabling |
| Backend Lead | APIs, data modeling, service boundaries | ADR input, schema migrations, stable endpoints | Gold‑plating architecture |
| Frontend / UX Lead | User flows, accessibility, usability | Component patterns, UI consistency, a11y audit | Ignoring performance / semantics |
| QA / Testing Lead | Test strategy execution, quality gates | Test coverage trends, failing test triage | Acting only at end of iteration |
| DevOps / Release Lead | CI/CD, environments, tagging, developer productivity | Green pipelines, release notes, automation PRs | “Works on my machine” tolerance |
Recommended rotation across 5 iterations for a 5-person team (example):
| Iteration | Lead | Backend | Frontend | QA/Testing | DevOps/Release |
|---|---|---|---|---|---|
| 1 | A | B | C | D | E |
| 2 | B | C | D | E | A |
| 3 | C | D | E | A | B |
| 4 | D | E | A | B | C |
| 5 | E | A | B | C | D |
Smaller teams: collapse DevOps into QA or merge Backend + DevOps; larger teams: introduce specialized roles (Data, Security) while keeping rotation for core leadership.
Working Agreement Essentials (teamwork/working-agreements.md)
Must answer at minimum: - Communication channels & expected response windows - Core collaboration blocks / meeting cadence - Definition of “blocked” & escalation path - Code review SLA (e.g., < 24h first response) - Decision recording policy (ADR vs issue comment) - Conflict resolution approach (escalation or vote rules)
Revisit after Iteration 1 retro—teams evolve; so should the agreement.
Feedback & Code Review (teamwork/feedback.md)
Principles: 1. Clarity over cleverness – explain why not just what. 2. Early feedback > late rework – draft PRs welcome. 3. Respect the diff size – small PRs invite thoughtful review. 4. Ask, don’t command – “Could we extract…?” vs “Extract this.” 5. Review the problem context – read the linked issue first.
Sample structured PR comment:
Observation → Impact (risk, readability, testability) → Suggestion → (Optional) Reference.
Decision Making
Use lightweight consensus. If unresolved in 10 minutes, create an issue or ADR stub and time-box exploration. Avoid Slack-only decisions—leave an artifact.
Accountability Signals
| Signal | Healthy | Needs Attention |
|---|---|---|
| Board Movement | Cards move daily | Stagnant > 3 days |
| Reviews | ≤ 24h turnaround | PR pile-up ( > 5 open ) |
| Role Stewardship | Proactive support | Role hoarding / abdication |
| Status Report | Honest scope variance | Spin / omission of risks |
Integration with Planning Labs
- Planning A: Working Agreement + DoR/DoD authored collaboratively
- Planning B: Roles tentatively mapped to iterations
- Planning C: Role rotation finalized & published (README or team doc)
- Iteration 1+ : Rotation executed; retro notes refine expectations
Conflict Triage Framework
- Clarify misunderstanding (repeat back assumed intent)
- Identify constraint (time, scope, quality, feasibility)
- Offer alternatives (A/B trade-offs)
- Decide (consensus or lead call) and document
- Verify resolution in next retro
Retro Prompts (Lite)
Use 10–15 minutes at iteration end: - What energized us? - What slowed us? - What quality risk emerged? - What single change improves flow next iteration?
Capture 1–2 action items—avoid exhaustive laundry lists.