Working-Agreements-Liste mit 5-10 konkret formulierten Regeln, Owner für Cadence-Review, Ablageort (Team-Wiki), Datum und Review-Termin. Maximal eine Seite.
Working Agreements
Vorbereitung
Was vor Start vorliegen muss
Whiteboard oder Miro-Board mit Spalten Erwartung, Vorschlag, Vereinbarung; Haftnotizen; Dot-Voting-Punkte; Timer; Template für finale Agreements-Liste.
Ein Facilitator, der psychologische Sicherheit hält und Konkretisierung einfordert; drei bis zwölf Teammitglieder; ein Scribe für die finale Liste; bei Bedarf ein neutraler Coach.
Arbeitskontext in 2-3 Sätzen (Sprint-Team, Cross-Functional, Remote, etc.); bekannte Reibungspunkte aus letzten Wochen; bestehende Working Agreements (falls vorhanden); Anlass des Workshops (Kickoff, Retro, Reset).
45-90 min
Drei-Spalten-Layout am Board. Beispielzeile sichtbar. Regel ansagen: Working Agreements sind keine Policy-Liste, sondern selbst gewählte Verhaltenserwartungen.
Kernfrage
Die eine Frage, die diese Methode beantwortet
Welche konkreten Verhaltenserwartungen erleichtern die Zusammenarbeit, und welche davon will das Team verbindlich vereinbaren?
Ablauf
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Kontext und Erwartungen sammeln | 15-20 min | Facilitator beschreibt Kontext in 2 min. Solo-Phase 5 min: jede Person schreibt mindestens drei Erwartungen („Was brauche ich, um gut arbeiten zu können?“) und mindestens eine Beobachtung („Was hat zuletzt nicht funktioniert?“). Kleben in Spalte Erwartung. | Solo-Schreiben verhindert Dominanz lauter Stimmen. Beobachtungen sind oft konkreter und ehrlicher als allgemeine Erwartungen. |
2Phase 2: Vorschläge formulieren | 20-30 min | Erwartungen clustern. Pro Cluster Vorschlag für eine Regel formulieren („Wenn jemand X tut, dann Y“). Konkret, beobachtbar, prüfbar. | Vermeide Negativ-Regeln. Statt „Niemand kommt zu spät zum Standup“ besser „Wir starten den Standup pünktlich, auch wenn nicht alle da sind“. |
3Phase 3: Diskussion und Commitment | 15-25 min | Pro Vorschlag kurz diskutieren: lebbar? wichtig? Dot-Voting auf maximal 7-10 Regeln. Strittige Regeln länger besprechen, ggf. umformulieren oder verwerfen. | Commitment ist nicht Mehrheitsentscheidung. Wenn auch nur eine Person eine Regel nicht trägt, lieber umformulieren oder weglassen. Sonst wird sie ignoriert. |
4Phase 4: Review-Cadence und Ownership | 5-15 min | Wer überwacht die Agreements? Wann werden sie geprüft (typisch in jeder Retro oder alle 4-8 Wochen)? Wo werden sie sichtbar gemacht? Was passiert bei wiederholtem Bruch? | Agreements ohne Review werden Tapete. Mindestens eine Pflichtprüfung pro Retro mit konkreter Frage: welche Regel hat geholfen, welche stört? |
Artefakt
Was am Ende rauskommt
- Confluence-Seite im Team-Space, im Channel angepinnt
- Notion-Seite mit Update-Log
- Markdown im Team-Repo unter docs/team/working-agreements.md
- Sichtbares Poster im Teamraum oder Pinned-Slack-Post
Pro Iteration eigener Eintrag mit Datum. Geänderte Regeln markieren. Drei Versionen reichen meist (Kickoff, Mid-Review, Reset).
Working Agreements Checklist
Checkliste für konkrete, überprüfbare Arbeitsvereinbarungen im Team.
- [ ] Vereinbarung ist beobachtbar formuliert
- [ ] Gilt für alle im Team
- [ ] Enthält keine reinen Absichtserklärungen
- [ ] Konfliktfall ist beschrieben
- [ ] Review-Termin gesetzt
- [ ] Owner für Pflege benanntBeispielausgabe
Konkret gefülltes Szenario
## Working Agreements — Activate Team (18.05.2026)
**Kontext**: Cross-funktionales Team von 6, hybrid (3 Remote, 3 Office), Sprint-Rhythmus 2 Wochen.
**Agreements**:
1. Standup täglich 9:30, max 15 min, Async-Update bis 9:15 für Remote-Tage.
2. Async-Antworten auf Pings in Working Hours (9-18) in unter 4 h; außerhalb keine Erwartung.
3. Code Review innerhalb 1 Working Day, danach automatischer Reminder.
4. Diskussionen über 5 Slack-Nachrichten → 30 min Sync-Call mit Decision.
5. Meeting-freie Vormittage Mi und Fr (vor 12:00 nur Standup).
6. Camera-Optional in Meetings, aber Decision-Meetings mit Camera.
7. Konflikte zuerst 1:1, dann Lead, dann Retro.
**Ownership**: Anna ist Cadence-Owner. Sichtbar im Slack-Channel-Topic und Confluence.
**Review**: in Retro alle 4 Wochen (nächste 15.06.). Frage: welche Regel hat geholfen, welche stört, welche fehlt?Stolperfallen
Symptome erkennen, gegensteuern
Regeln zu vage
Liste enthält „Wir kommunizieren transparent“ ohne beobachtbares Verhalten.
Pro Regel konkretes Verhalten verlangen. „Wann gilt sie als befolgt?“ Wenn nicht beantwortbar, umformulieren.
Zu viele Regeln
Liste hat 20+ Punkte, niemand erinnert sich an alle.
Auf maximal 7-10 Regeln begrenzen. Was nicht passt, kommt in Backlog für nächste Iteration.
Negativ-Regeln
Viele „Niemand soll X“ oder „Wir tolerieren Y nicht“ Formulierungen.
Positiv umformulieren: was tun wir stattdessen? Negativ-Regeln erzeugen Defensive.
Kein Commitment
Regeln werden durchgewinkt, aber eine Person hat Bauchschmerzen und schweigt.
Pro Regel explizite Bestätigung („Trage ich das mit?“). Wenn Zögern, umformulieren oder verwerfen. Stilles Aushalten zerstört Glaubwürdigkeit der Methode.
Keine Review-Cadence
Agreements verschwinden in Confluence, niemand prüft sie wieder.
Review-Termin im Kalender. Pflichtthema in Retro. Owner verantwortet Sichtbarkeit (z. B. Slack-Channel-Topic).
Abbruchkriterien
Done-Signale, in unter einer Minute prüfbar
Run Sheet durchgearbeitet?
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.