Wie wir arbeiten, weiß Lisa. Lisa hat Urlaub.

Wer im Projekt mitarbeitet, braucht klare Absprachen und muss nachlesen können, was gilt. Sonst hängt die nächste Entscheidung davon ab, wer gerade im Büro ist.

Montag, 09:07 Uhr. Ein fiktives Entwicklungsteam begrüßt einen neuen Kollegen. Jonas hat einen Laptop, Zugang zum Repository und eine freundliche Nachricht: „Schön, dass du da bist! Zum Einstieg hätten wir direkt eine kleine Aufgabe.“

Kunden sollen ihre Rechnungsadresse im Portal selbst korrigieren können. Überschaubarer Auftrag. Jonas öffnet das verlinkte Issue, liest das README und schaut in den Code. Um 09:31 Uhr hat er einen ersten Ansatz.

„Warum schaust du in den alten Service?“, fragt ein Entwickler.

„Der steht im README.“

„Ja, das müssten wir mal aktualisieren.“

Die Product Managerin kommt dazu. „Das Issue ist auch schon älter. Wir brauchen nur die Korrektur vor dem Rechnungsversand. Die aktuelle Anforderung steht in Jira.“

Der Architekt blickt auf den Entwurf. „Und bitte nicht direkt in diese Datenbank schreiben. Das hatten wir ausdrücklich ausgeschlossen.“

Jonas nickt und stellt die Frage, mit der man als neuer Kollege zuverlässig Bewegung in ein Team bringt: „Wo steht das?“

„Das weiß Lisa.“

Lisa hat Urlaub.

Irgendwo öffnet jemand Microsoft Teams und scrollt zurück bis Juli. Zwei andere diskutieren, ob die Entscheidung vor oder nach dem Workshop gefallen ist. Der Kaffee wird kalt. Jonas hat inzwischen fünf hilfreiche Menschen kennengelernt. Wie er seine Aufgabe angehen soll, weiß er immer noch nicht.

Technisch war er nach zwanzig Minuten arbeitsfähig. Organisatorisch fehlen ihm nur noch drei Jahre Betriebszugehörigkeit.

Das Problem ist alt. Unser Tempo verändert sich.

Solche Situationen entstehen auch ohne eine einzige KI-generierte Codezeile. Wissen verteilt sich auf Repositories, Aufgabenboards, Dokumente, Gespräche und die Köpfe der Menschen, die gerade dabei waren. Das Team trifft eine Entscheidung, eine Anforderung ändert sich, ein neuer Service ersetzt den alten. Nur der Link im README hält tapfer die Stellung.

Wer lange genug im Projekt arbeitet, ergänzt die Lücken automatisch. Man weiß, welcher Service wirklich produktiv ist und welches Architekturdiagramm noch gilt. Man kennt die Bedeutung von „eigentlich fertig“. Und irgendwann merkt man kaum noch, dass ein neuer Kollege für dieselbe Orientierung mehrere Gespräche braucht.

Ich sehe in KI eine große Chance, effizienter zu arbeiten und schneller zu brauchbaren Ergebnissen zu kommen. Sie kann uns beim Verstehen, Entwerfen, Implementieren und Prüfen unterstützen. Ein Agent muss dabei ebenso wie Jonas wissen, welche Anforderung aktuell ist, welche Entscheidungen gelten und wie das Team vorgeht.

Mehr Beteiligte ersetzen diese Informationen nicht. Zehn Menschen, zehn Agenten oder hundert von beiden müssen weiterhin herausfinden können, was gilt und wer entscheidet.

Je schneller wir arbeiten und je häufiger wir zwischen Aufgaben wechseln, desto weniger können wir uns darauf verlassen, dass alle denselben Stand im Kopf haben. Bei jeder Übergabe muss sich nachlesen lassen, was bereits geklärt wurde. Sonst beschleunigen wir vor allem die Wiederentdeckung alter Diskussionen.

Deshalb interessiert mich vor allem eine Frage: Wie schaffen wir es, dass alle nach den vereinbarten Abläufen arbeiten und bei der nächsten Übergabe nicht wieder die Hälfte erklären müssen?

Verbindliche Abläufe, unterschiedliche Projekte

Mein Vorschlag: Wir vereinbaren für jedes Projekt, wie wir Anforderungen klären, offene Fragen diskutieren, Entscheidungen treffen und Änderungen prüfen. Wir benennen die Verantwortlichen und halten die Absprachen an einem bekannten Einstiegspunkt fest. Sie gelten für alle im Projekt, auch für die Kollegen, die schon jede Abkürzung kennen.

Welche Schritte und Werkzeuge wir dafür brauchen, hängt vom Projekt ab.

Ein kleines Website-Projekt kann seine Aufgaben, Diskussionen und Reviews vollständig in GitHub organisieren. Bei einer Änderung an einem zentralen Abrechnungssystem können Jira, zusätzliche fachliche Prüfungen und gesonderte Freigaben sinnvoll sein. Ein Kundenprojekt arbeitet vielleicht bereits mit einem gut funktionierenden Vorgehen, das wir übernehmen.

Schon die Frage, was die Software für ihre Nutzer leisten soll, führt zu unterschiedlichen Abläufen. Ein Dokumentenportal nimmt Unterlagen entgegen, prüft sie und unterstützt die Entscheidung über einen Antrag. Im Kundenportal muss eine korrigierte Adresse anschließend auch in der Rechnungsstellung ankommen. Wir brauchen dafür andere Gespräche, andere Prüfschritte und zum Teil andere Menschen am Tisch.

Ich will beim Projektwechsel einen vertrauten Einstieg vorfinden. Die einzelnen Schritte, Rollen und Werkzeuge dürfen sich unterscheiden. Aber niemand sollte sich erst jede Regel einzeln zusammenfragen müssen, bevor er mitarbeiten kann.

Dass ein Team Jira verwendet und ein anderes GitHub Projects, ist gut handhabbar. Schwieriger wird es, wenn „das Ticket“ je nach Gespräch drei verschiedene Dinge meint.

Ein Abrechnungssystem darf dabei andere Sorgen haben als eine Veranstaltungswebsite. Es wäre auch etwas beunruhigend, wenn beide denselben Freigabeprozess für einen neuen Button hätten.

Eine kleine Landkarte namens workspace

Geben wir Jonas für denselben Auftrag einen solchen Einstieg: einen Ordner workspace/. Darin liegen eine Übersicht in YAML und einige gut lesbare Markdown-Dokumente. Er öffnet zuerst das README und findet von dort die aktuelle Anforderung, die beteiligten Systeme und die Absprachen des Teams.

Für den Anfang könnten vier Dateien reichen:

Dazu kommen Verweise auf Architektur, Fachwissen und Entscheidungen. Diese können beispielsweise unter workspace/architecture/, workspace/knowledge/ und workspace/decisions/ liegen. Gibt es dafür bereits gepflegte Quellen, werden diese verlinkt. Niemand muss ein funktionierendes Architektur-Wiki abschreiben, damit wir anschließend zwei Versionen veralten lassen können.

Gehören mehrere Repositories zum Projekt, legen wir fest, wo der gemeinsame Einstieg liegt, zum Beispiel in einem eigenen Projektrepository. Die READMEs der beteiligten Repositories verweisen dorthin. So führt auch der Einstieg über das Backend zu denselben Absprachen wie der über das Frontend.

Die Übersicht für unser Kundenportal könnte so aussehen:

version: 1
name: customer-portal
overview: workspace/README.md
repositories:
  - url: https://github.com/EXAMPLE/portal
    role: frontend
  - url: https://github.com/EXAMPLE/portal-api
    role: backend
work:
  system: jira
  project_key: PORTAL
  board_url: https://EXAMPLE.atlassian.net/jira/software/c/projects/PORTAL/boards/42
reviews:
  system: github
knowledge:
  domain: workspace/knowledge/
  architecture: workspace/architecture/
  decisions: workspace/decisions/
process:
  guide: workspace/working-agreement.md
  responsibilities: workspace/stakeholders.md

Damit weiß Jonas, welches Repository zum Frontend gehört und wo die aktuelle Aufgabe steht. Wie er mit einer offenen Fachfrage oder einem widersprüchlichen Ticket umgeht, liest er anschließend im Working Agreement nach.

Das Format schlage ich hier vor; Agenten kennen es nicht automatisch. Das verwendete Werkzeug muss es unterstützen, oder wir müssen den Agenten ausdrücklich anweisen, diese Dateien zu lesen. Der Agent braucht außerdem Zugriff auf Jira, GitHub oder das Wiki. Die YAML richtet keine Verbindung ein. Ein Link ist eine Adresse. Noch kein Schlüssel.

Auch workspace ist kein magischer Name. Entscheidend ist, dass Menschen und Werkzeuge den Einstieg finden und seine Verweise verstehen. Ein weiteres Dokument namens final_final_wirklich.md wäre an dieser Stelle keine strukturelle Verbesserung.

Wo gearbeitet wird, muss eindeutig sein

„Wir verwenden GitHub“ ist als Orientierung ungefähr so präzise wie „Unsere Büros befinden sich auf der Erde“. Welches Repository? Welches Project? Welche Aufgabenquelle führt, wenn sich zwei Beschreibungen widersprechen?

Für unser Portal könnte die Vereinbarung lauten: Priorität und aktuelle Anforderung stehen in Jira. Dort bleiben auch der laufende Plan und fachliche Rückfragen. Der Pull Request in GitHub zeigt die konkrete Umsetzung und die ausgeführten Prüfungen. Wesentliche Architekturentscheidungen werden als eigene Notizen verlinkt.

Andere Projekte können diese Arbeit anders aufteilen: etwa Jira für den geplanten fachlichen Umfang, die Priorität und die Kapazität; GitHub für die technischen Aufgaben und ihren Bearbeitungsstand. Die Aufgaben verlinken auf das zugehörige Vorhaben. Entscheidend ist, dass sich nachlesen lässt, welche Quelle wofür gilt, und dass dieselbe Aufgabenliste nicht zweimal gepflegt wird.

Wir brauchen den aktuellen Plan nicht gleichzeitig im Ticket, im Chat und in einer zusätzlichen Markdown-Datei. Spätestens nach der zweiten Änderung eröffnet sonst jede Fassung ihre eigene kleine Realität. Zwei unabhängig gepflegte Statusfelder für dieselbe Arbeit sind eine Terminvereinbarung für den nächsten Widerspruch.

Jonas liest auf diesem Weg gezielt das Produktziel, seinen Auftrag und die Entscheidung zur betroffenen Schnittstelle. Ein Agent kann denselben Weg nehmen und die dafür nötigen Fach- und Architekturdokumente laden. Das ganze Projektarchiv bei jeder Aufgabe erneut durchzuarbeiten, wäre für beide eine fragwürdige Begrüßungszeremonie.

Vom Wunsch bis zum nutzbaren Ergebnis

Im Working Agreement findet Jonas die nächsten Schritte. Ein kurzer Ausschnitt für unser fiktives Portal-Team könnte so aussehen:

1. Vor der Umsetzung: Ziel und Akzeptanzkriterien stehen im Jira-Ticket. Fachliche Fragen, die die Umsetzung blockieren, klären wir mit der dort benannten Product Managerin.
2. Bei Widersprüchen: Wir markieren die offene Frage im Ticket und beziehen die zuständige Person ein. Über das gewünschte fachliche Verhalten entscheidet die Product Managerin, über die betroffene Systemgrenze der verantwortliche Architekt. Das Ergebnis halten wir an der jeweiligen verbindlichen Quelle fest.
3. Für das Review: Der Pull Request verweist auf das Ticket und zeigt die vereinbarten Prüfungen sowie offene Punkte. Im Ticket steht, wer das fachliche Ergebnis abnimmt.
4. Vor der Veröffentlichung: Die im Projekt benannte verantwortliche Person gibt die Veröffentlichung frei. Die Zustimmung zum Plan oder der Merge allein reichen dafür nicht.
5. Mit der Änderung: Wer einen Service, einen Arbeitsablauf oder eine wichtige Architekturentscheidung ändert, aktualisiert die betroffenen Verweise und Dokumente. Für eine neue wesentliche Architekturentscheidung halten wir auch die Gründe fest.

Das sind Beispielvereinbarungen für dieses Projekt. Ein anderes Team kann eine andere Methode oder einen bestehenden Kundenablauf nutzen. Manchmal braucht es zuerst eine technische Erkundung, bevor sich eine Anforderung genauer festlegen lässt. Dann sollte auch klar sein, was dabei ausprobiert wird und welche Entscheidung anschließend möglich sein soll.

Jonas kann mit diesen Absprachen arbeiten. Im aktuellen Ticket entdeckt er allerdings den Satz: „Die neue Adresse wird direkt in der Portaldatenbank gespeichert.“ Die verlinkte Architekturentscheidung schließt genau das aus. Zwei Quellen zu finden war also erst der Anfang. Jetzt muss jemand den Widerspruch klären.

Er markiert die Stelle im Ticket und fragt die Product Managerin und den verantwortlichen Architekten.

„Brauchen wir wirklich diesen Schreibzugriff“, fragt er, „oder soll die nächste Rechnung an die richtige Adresse gehen?“

„Die Rechnung muss stimmen“, sagt die Product Managerin. „Bisher müssen Kunden dafür den Support kontaktieren. Der Datenbankzugriff ist aus einem alten Lösungsvorschlag übrig geblieben.“ Eine neue Adressverwaltung wäre für dieses Ziel möglicherweise viel mehr Software, als das Problem verlangt.

Der Architekt erklärt, warum der direkte Datenbankzugriff ausgeschlossen wurde: Eine bestehende Schnittstelle prüft die Änderungen und gibt sie an die Rechnungsstellung weiter. Wer daran vorbeischreibt, kann im Portal die richtige Adresse anzeigen und trotzdem eine Rechnung mit der alten verschicken. Die bisher etwas geheimnisvolle Architekturvorgabe bekommt einen nachvollziehbaren Grund.

Jonas fragt nach dem Fehlerfall: Was sieht der Kunde, wenn diese Schnittstelle gerade nicht erreichbar ist? Eine grüne Erfolgsmeldung wäre optisch beruhigend, fachlich aber eine gewagte Interpretation des Wortes „gespeichert“.

Die Product Managerin ergänzt die Akzeptanzkriterien: Bei einem Ausfall wird die Änderung nicht als gespeichert bestätigt. Der Kunde erhält einen verständlichen Hinweis und kann es erneut versuchen. Eine spätere automatische Übermittlung gehört vorerst nicht zum Auftrag. Der Architekt bestätigt, dass der Weg über die bestehende Schnittstelle dafür passt.

Die Product Managerin korrigiert den alten Lösungssatz im Ticket. Jonas verlinkt die weiterhin gültige Architekturentscheidung und hält das Ergebnis der Rückfrage fest. Jetzt beschreibt auch der Auftrag wieder, was gebaut werden soll.

Damit wird auch „fertig“ konkreter. Ein Test muss zeigen, dass die neue Adresse in der Rechnungsstellung ankommt. Fällt die Schnittstelle aus, muss der Kunde verstehen können, was passiert ist und was er tun kann. Auch die anderen Anwendungen, die diese Schnittstelle nutzen, müssen weiter funktionieren. Im Pull Request steht, was Jonas geprüft hat und welche Prüfungen noch ausstehen.

„Alle Tests grün“ ist hilfreich. Es sagt etwas über die tatsächlich ausgeführten Tests aus. Ob die Änderung dem Kunden wirklich hilft, müssen wir am vereinbarten Anwendungsfall prüfen.

Dieser Ablauf gilt genauso, wenn ein Agent den Code schreibt. Auch er braucht eine geklärte Aufgabe, muss bei offenen Fragen an die richtige Person gelangen und zeigen, was er geprüft hat. Wer fachlich entscheidet, Änderungen freigibt und den Betrieb verantwortet, bleibt dabei klar benannt.

Der Aufwand sollte zur Änderung passen. Niemand braucht für „Speichern“ statt „Absenden“ ein Architektur-Komitee mit Gründungsmanifest. Bei einer Änderung am zentralen Datenmodell muss dagegen rechtzeitig die Person eingebunden werden, die über die betroffene Architektur entscheidet.

Mit dem Merge ist die Aufgabe also noch nicht beim Kunden angekommen. Nach der Veröffentlichung interessiert uns, ob die Adresskorrektur auch im Alltag funktioniert und Kunden sich den Umweg über den Support tatsächlich sparen. Wenn Fehler auftreten oder Rückmeldungen eine Lücke zeigen, bessern wir die Software und die dazugehörigen Informationen nach. „Abgenommen“, „veröffentlicht“ und „hilft dem Kunden“ sind drei verschiedene Aussagen.

Dabei lohnt sich ein Blick darauf, wie viel Arbeit das Team gleichzeitig prüfen und zusammenführen kann. Wenn sich Pull Requests stapeln, sollten wir erst Hindernisse aus dem Weg räumen, Reviews abschließen und begonnene Änderungen fertigstellen. Kleine Änderungen machen das leichter. Sonst ist die Warteschlange vor dem Review irgendwann das am stärksten gewachsene Produkt – auch bei beeindruckendem Umsetzungstempo.

Entscheidungen aufschreiben, bevor die Gründe verschwinden

Warum die Schnittstelle wichtig ist, wissen wir jetzt. Der nächste Kollege sollte dafür nicht wieder dieselbe Besprechung brauchen.

Solche Entscheidungsnotizen lassen sich als Architecture Decision Record, kurz ADR, führen. Darin stehen Kontext, Entscheidung, betrachtete Alternativen und Folgen. Dazu gehören Status, verantwortliche Entscheider und Verweise auf betroffene Systeme oder andere Entscheidungen.

In Jonas’ Projekt stehen diese Gründe bereits in der gefundenen Notiz: warum Adressänderungen über die Schnittstelle laufen und welche Folgen ein direkter Schreibzugriff hätte. Entscheidet sich das Team später anders, bleibt die alte Begründung erhalten und bekommt einen Link auf die neue Entscheidung. So können wir nachlesen, was heute gilt und wie es dazu kam.

Am besten entsteht die Notiz beim Entscheiden, solange die Gründe noch bekannt sind. Drei Monate später erinnern sich erstaunlich viele Menschen sehr genau daran, dass sie damals eine andere Meinung hatten.

Nicht jeder erledigte Auftrag braucht einen ADR. Der aktuelle Plan und die Diskussion bleiben beim Auftrag, der Pull Request zeigt den Code und die ausgeführten Prüfungen. Haben wir etwas gelernt, das auch für spätere Aufgaben wichtig ist, ergänzen wir es dort, wo das Team sein Fachwissen nachliest. Am Ende einer Iteration kann eine kurze Zusammenfassung helfen: Was haben wir erreicht? Was ist offen? Was haben wir entschieden?

Ein vollständiger Chatverlauf hilft dabei selten. Er bewahrt sehr gewissenhaft auch die halbe Stunde, in der alle am falschen Problem vorbeigeredet haben. Für die nächste Aufgabe brauchen wir vor allem das Ergebnis der Diskussion und die Gründe dafür.

Eine Dokumentationswebsite kann die Texte leichter lesbar machen. Eine grafische Übersicht kann zeigen, welche Entscheidung eine andere ersetzt. Damit das hilft, müssen die Inhalte und Verweise aktuell sein. Eine bunte Linie zwischen zwei vergessenen Dokumenten löst das Orientierungsproblem nur sehr dekorativ.

Wir legen außerdem fest, wer den Einstieg aktuell hält. Wird ein Service abgelöst, ändern wir den Verweis. Wandern die Aufgaben in ein anderes System, passen wir die Übersicht an. Wird eine Entscheidung ersetzt, verlinken wir den neuen Stand. Das gehört jeweils zur Änderung dazu. Eine spätere große Aufräumaktion ist erfahrungsgemäß ein sehr geduldiger Kalendereintrag.

Der nächste Neue ist der beste Test

Ich würde mit einem Projekt und einem echten Auftrag anfangen. Wir verlinken die aktuellen Quellen, schreiben auf, wie das Team arbeitet, und lassen jemanden damit loslegen: eine Kollegin aus einem anderen Team, einen neuen Entwickler oder einen KI-Agenten.

Dann beobachten wir:

1. Findet die Person oder der Agent das Ziel und die aktuelle Anforderung?
2. Wird klar, welche Systeme, Regeln und Entscheidungen relevant sind?
3. Wird klar, wie das Team offene Fragen klärt, Entscheidungen trifft und Änderungen prüft?
4. Ist klar, wen man bei einer offenen Frage anspricht?
5. Kann der nächste Beteiligte nachlesen, was herauskam und warum?

Wo die Orientierung scheitert, verbessern wir gezielt den Einstieg. Vielleicht fehlt ein Link. Vielleicht widersprechen sich zwei Quellen. Vielleicht haben wir selbst noch nicht entschieden, wer eine bestimmte Frage klärt. Das zu erkennen, hilft dem Projekt bereits vor der nächsten Implementierung.

Ob es hilft, merken wir daran, dass wir dieselben Fragen seltener erklären, weniger nacharbeiten und Ergebnisse schneller prüfen können. Die Anzahl erzeugter Dateien ist dafür eine eher kreative Ersatzmetrik.

Wir brauchen einen vereinbarten Ablauf, an den sich alle halten. Das nötige Wissen muss leicht zu finden sein. Und bei wichtigen Entscheidungen schreiben wir auf, warum sie so gefallen sind. Das war schon immer wichtig. Je mehr Menschen und Agenten mitarbeiten und je schneller Aufgaben wechseln, desto weniger können wir darauf verzichten.

Vielleicht braucht Jonas am nächsten Montag immer noch Unterstützung. Aber dann besprechen wir seinen konkreten Entwurf, statt gemeinsam den richtigen Chatkanal zu suchen.

Lisa darf währenddessen gern weiter Urlaub haben.

Welche Absprache spart euch im Projekt wirklich Rückfragen – und wo seid ihr immer noch darauf angewiesen, dass die richtige Person gerade Zeit hat?