Hauptgedanke

Ein Product Manager, der seit drei Jahren mit demselben Entwickler arbeitet, muss nicht aufschreiben, was er für einen Entwickler aufschreiben muss, der vor drei Monaten dazugekommen ist. Ein Team, das täglich miteinander spricht, kann manches mündlich lassen; ein Team, das neu ist, verteilt arbeitet oder an einem riskanten Thema sitzt, muss mehr ausdrücklich machen. Wie viel Geschriebenes nötig ist, ist keine Eigenschaft des Themas, sondern eine Funktion dessen, was beide Seiten bereits gemeinsam haben.

Daher die spiegelbildliche Fehlentwicklung zum Ablegen von drei Zeilen: überall Vorlagen vorschreiben, Felder hinzufügen, jede Karte in ein Mini-Dossier verwandeln, schreiben, um sich abzusichern, statt um zu arbeiten. Orientierungshilfen wie die Definition of Ready und die Definition of Done helfen, solange sie lebendig bleiben; sie schaden, sobald sie das Urteil darüber ersetzen, was der andere schon weiß.

Warum das wichtig ist

Das erklärt, warum ein Schreibstandard, den man von einem Team ins andere überträgt, so oft scheitert: Er bringt eine Menge an Geschriebenem mit, die auf einen gemeinsamen Kontext abgestimmt ist, den es hier nicht gibt.

Es zeigt auch, welche Größe man tatsächlich im Auge behalten muss. Fluktuation, ein Neuzugang, der Wechsel zu verteiltem Arbeiten erhöhen den Bedarf an Geschriebenem, ohne dass sich an einem einzigen Thema etwas geändert hätte.

Nuancen und Grenzen

Der gemeinsame Kontext macht das Geschriebene für das heutige Team weniger nötig, nicht für das künftige. Ein Ticket, das zwei Personen verstehen, versteht die dritte, die dazukommt, nicht mehr – und auch nicht dasselbe Team sechs Monate später.

Und die Einschätzung dessen, was „schon geteilt“ ist, fällt naturgemäß zu optimistisch aus: Wer schreibt, überschätzt, was der andere im Kopf hat.

Offene Fragen

• Wer ist in der Lage festzustellen, dass der gemeinsame Kontext geschrumpft ist, wenn die Alteingesessenen es nicht spüren und der Neue glaubt, der Mangel liege bei ihm?