Ein Team Charter und ein Working Agreement werden oft synonym verwendet, und die Überlappung ist real genug, um die Unterscheidung präzise zu treffen, statt beide als zwei Namen für dasselbe Dokument zu behandeln.
Der Unterschied im Umfang
Ein Working Agreement ist primär operativ: wie das Team bestimmte wiederkehrende Situationen handhaben möchte (Reaktionszeiten, Kernzeiten, wie Uneinigkeiten gelöst werden). Ein Team Charter sitzt eine Ebene höher. Er deckt typischerweise den Zweck des Teams ab (warum existiert dieses Team, wofür ist es verantwortlich), seinen Umfang und seine Grenzen (was gehört zum Team, was explizit nicht), seine Stakeholder (wer hängt von diesem Team ab, wovon hängt dieses Team ab), und erst dann, oft als einer von mehreren Abschnitten, seine Arbeitsnormen.
Einfach gesagt: Ein Working Agreement beantwortet "wie arbeiten wir zusammen". Ein Charter beantwortet "warum existiert dieses Team, und was bedeutet das für unsere Arbeitsweise".
Warum der Zweck-Abschnitt wichtiger ist, als er scheint
Teams, die direkt zu Arbeitsnormen springen, ohne zuerst echte, geteilte Klarheit über den Zweck herzustellen, finden ihre Working-Agreement-Diskussionen oft zirkulär, weil Uneinigkeiten über "wie wir arbeiten sollten" häufig Uneinigkeiten über "wofür wir hier eigentlich sind" sind, nur prozessual verkleidet. Ein Team, das sich nicht geeinigt hat, ob seine primäre Accountability Geschwindigkeit oder Qualität ist, wird sich schwertun, sich auf Normen für Code-Review-Tiefe, Release-Rhythmus oder den Zeitanteil für technische Schuld zu einigen, nicht weil die Normendiskussion schwer ist, sondern weil die zugrunde liegende Zweck-Uneinigkeit nicht ans Licht gebracht wurde.
Umfang und Grenzen verhindern ein konkretes, wiederkehrendes Scheitern
Teams ohne eine explizite, vereinbarte Grenze dessen, was innerhalb und außerhalb ihres Umfangs liegt, sammeln Arbeit tendenziell durch Drift an: Eine Anfrage kommt, sie ist angrenzend an das, was das Team tut, niemand hat Gründe, Nein zu sagen, und allmählich weicht die tatsächliche Arbeit des Teams von seinem beabsichtigten Zweck ab, ohne dass jemand das so entschieden hätte. Ein Charter, der den Umfang explizit festhält, gibt dem Team und der Product-Owner-Person echte Gründe, unpassende Arbeit abzulehnen oder umzuleiten, statt sich auf Ad-hoc-Urteile zu verlassen, die verschiedene Teammitglieder unterschiedlich treffen könnten.
Stakeholder-Mapping als Teil des Charters, nicht als Nachgedanke
Explizit zu benennen, wem das Team dient und von wem es abhängt, als Teil des Charters statt als separate Übung, hält diese Information mit dem erklärten Zweck des Teams verbunden. Ein Team, dessen erklärter Zweck kundengerichtete Zuverlässigkeit ist, dessen tatsächliche Stakeholder-Karte aber von internen Reporting-Anfragen dominiert wird, hat eine sichtbare Diskrepanz, die es sich direkt zu adressieren lohnt, und ein Charter, der Stakeholder neben dem Zweck enthält, macht diese Diskrepanz leicht erkennbar.
Wann einen schreiben, und wann ein Working Agreement reicht
Ein vollständiger Charter lohnt sich für ein neues Team, das sich um ein neues Mandat bildet, oder ein bestehendes Team, dessen Zweck genuin unklar oder umstritten geworden ist. Ein Team, das bereits klaren Zweck und Umfang hat und sich nur über Alltagsnormen abstimmen muss, braucht die volle Charter-Übung womöglich nicht. Ein Working Agreement, das die operativen Fragen abdeckt, reicht oft aus. Der Charter dient dazu, festzulegen oder neu festzulegen, warum das Team existiert; das Working Agreement dient dazu, wie es operiert, sobald das geklärt ist.