Wenn der Fokus ständig wechselt: Was Softwareteams vor dem nächsten Meeting klären sollten

Eine Idee begeistert alle. Das Team beginnt zu arbeiten. Ein paar Gespräche später steht nicht mehr die Umsetzung zur Diskussion, sondern die Frage, warum man das überhaupt braucht.

Für die Menschen, die daran gearbeitet haben, fühlt sich das wie eine Vollbremsung an. Für die Person, die nachfragt, vielleicht nur wie eine längst überfällige Klärung.

Mich beschäftigt dieser Unterschied. Nicht, weil Entscheidungen niemals geändert werden dürften. Sondern weil ich wissen möchte: Wie verhindern wir, dass ein Team immer wieder von vorn anfängt, obwohl alle glauben, an derselben Sache zu arbeiten?

Meine These: Bevor wir wechselnden Fokus mit mangelnder Disziplin erklären, sollten wir prüfen, ob es überhaupt eine gemeinsame, ausdrücklich getroffene Entscheidung gab.

Wir reden über dieselbe Technik und meinen verschiedene Dinge

Nehmen wir ein hypothetisches Beispiel aus der Logistik. Ein Unternehmen möchte Lieferzeiten besser vorhersagen. Die Entwicklung führt Daten aus Lager, Spedition und Auftragssystem zu einer verlässlichen Grundlage zusammen und trainiert darauf ein erstes Prognosemodell. Der Vertrieb stellt sich vor, dass Kunden ihren voraussichtlichen Liefertermin selbst nachsehen können. Die Geschäftsführung denkt darüber nach, die Prognosen an Handelspartner weiterzugeben.

Alle nennen es „unser KI-Projekt“.

Wenn das Modell zuverlässige Werte liefert, hat die Entwicklung einen wichtigen Meilenstein erreicht. Der Vertrieb vermisst möglicherweise noch eine Ansicht, die Kunden tatsächlich nutzen. Die Geschäftsführung fragt, was die Partner davon hätten. Diese Fragen widersprechen sich nicht. Sie beziehen sich auf verschiedene Ebenen des Vorhabens.

Für solche Unterschiede gibt es einen passenden Forschungsansatz: Technological Frames. Wanda Orlikowski und Debra Gash beschreiben damit die Annahmen, Erwartungen und Kenntnisse, mit denen unterschiedliche Gruppen auf Technologie schauen. Stark voneinander abweichende Deutungen können zu Schwierigkeiten und Konflikten bei Entwicklung und Nutzung führen.¹

Das ist keine Diagnose einzelner Menschen. Es ist eine hilfreiche Frage an die Zusammenarbeit: Haben wir wirklich dieselbe Vorstellung davon, was diese Technik leistet und wozu wir sie einsetzen wollen?

Technisches Potenzial muss übersetzt werden

Eine funktionierende Schnittstelle ist für Entwickler oft mehr als ein einzelnes Feature. Sie kann eine Grundlage sein, auf der verschiedene Anwendungen aufsetzen. Wer nur auf die sichtbare Oberfläche schaut, sieht diese Möglichkeit vielleicht nicht.

Aber daraus folgt nicht, dass jeder skeptische Blick ein Wissensdefizit ist.

„Das lässt sich jetzt anbinden“ beantwortet eine technische Frage. Es beantwortet noch nicht, ob jemand die Anwendung braucht, ihr vertraut oder dafür bezahlt. Umgekehrt entwertet eine offene Vermarktungsfrage nicht automatisch die bereits geschaffene technische Grundlage.

Deshalb würde ich den Stand eines solchen Projekts in drei getrennten Sätzen erklären:

• Das funktioniert bereits: mit einer kurzen, nachvollziehbaren Demonstration.
• Das wird dadurch möglich: als Option, nicht als stillschweigend beschlossenes Folgeprojekt.
• Das ist noch ungeklärt: beispielsweise Nutzerbedarf, Qualität, Zugriffsrechte, Betrieb oder Zahlungsbereitschaft.

Auch die Entwicklung hat hier eine Verantwortung. „Darauf müssen wir nur noch eine Oberfläche setzen“ kann für einen Prototyp stimmen. Für ein verkaufbares Produkt gehören möglicherweise noch Berechtigungen, Abrechnung, Support und Qualitätskontrollen dazu. Wer diese Unterschiede offen benennt, macht den erreichten Fortschritt glaubwürdiger.

Für maschinelles Lernen beschreiben Sculley und Kollegen in „Hidden Technical Debt in Machine Learning Systems“, wie Datenabhängigkeiten, versteckte Rückkopplungen und Konfiguration die langfristige Wartung erschweren können.² Der Beitrag stammt aus der Zeit vor dem heutigen LLM-Boom und untersucht keine Führungsentscheidungen. Ich nehme daraus eine technische Vorsicht mit: Eine überzeugende Demo ist ein wichtiger Fortschritt, aber noch keine Antwort auf alle Fragen zum Betrieb.

Begeisterung ist noch kein Auftrag

Ein Satz wie „Das wäre richtig gut“ ist angenehm zu hören. Er ist aber erstaunlich ungenau.

Soll die Idee ins Backlog? Sollen wir ihre Machbarkeit testen? Ist ihre Umsetzung beschlossen? Hat sie Vorrang vor der bisherigen Arbeit?

Wenn das offen bleibt, können alle ein Meeting zufrieden verlassen und am nächsten Morgen unterschiedliche Dinge für vereinbart halten. Dafür braucht es weder böse Absicht noch jemanden, der absichtlich sein Wort bricht.

Ich halte deshalb eine kurze Rückfrage für sinnvoller als die nächste lange Präsentation:

„Ist das gerade eine Idee, ein Prüfauftrag oder eine Entscheidung zur Umsetzung?“

Bei einem Prüfauftrag gehört dazu, was wir herausfinden wollen. Bei einer Umsetzungsentscheidung gehört dazu, welche andere Arbeit dafür zurücksteht. Ein zusätzliches Ziel schafft schließlich keine zusätzliche Kapazität.

Ein Richtungswechsel braucht einen Grund, keinen Schuldigen

Natürlich darf sich eine Richtung ändern. Ein Kundengespräch kann eine Annahme widerlegen. Ein neuer technischer Befund kann einen Plan unbrauchbar machen. Auch ein wirtschaftlich sinnvolles Vorhaben kann gerade nicht finanzierbar sein.

Die Prinzipien des Agilen Manifests begrüßen ausdrücklich auch späte Anforderungsänderungen. Zugleich fordern sie ein nachhaltig haltbares Arbeitstempo und Aufmerksamkeit für technische Qualität.³ Für mich gehört das zusammen: Änderungen ermöglichen und ihre Folgen für die laufende Arbeit ernst nehmen.

Ich würde deshalb nicht zählen, wie oft ein Team seine Meinung ändert. Ich würde fragen, ob es die Änderung erklären kann:

• Was galt bisher?
• Welche neue Erkenntnis haben wir?
• Was entscheiden wir deshalb anders?
• Welche Arbeit stoppen wir, welche bleibt wertvoll?
• Wer trägt die Entscheidung mit?

Wenn es neue Erkenntnisse gibt, kann ein Kurswechsel gutes Lernen sein. Wenn nur eine alte Diskussion ohne Bezug zum bisherigen Stand wieder beginnt, fehlt möglicherweise etwas anderes: eine gemeinsame Erinnerung an die Entscheidung und ihre Gründe.

Eine explorative Fallstudie von Dasanayake und Kollegen passt zu dieser Frage: In 15 Interviews bei einem europäischen Softwareunternehmen identifizierten sie Kommunikationsprobleme, Informationsverzerrung und externe Abhängigkeiten als Ursachen wechselnder Anforderungen; zu den berichteten Folgen gehörten schwer nachvollziehbare Architekturbegründungen und erhöhte Komplexität.⁴ Das ist ein einzelner Unternehmensfall, keine allgemeingültige Erklärung. Auch ist eine veränderte Anforderung nicht dasselbe wie eine neue Priorität. Die Studie gibt aber einen guten Anlass, neben einzelnen Entscheidungen auch den Informationsfluss im Team zu betrachten.

Gute Protokolle sind kein Misstrauensvotum

Ich habe selbst erlebt, wie viel eine einfache Protokollroutine verändert. In einem früheren Team war bei unseren Meetings klar, wer mitschreibt. Wenn später unterschiedliche Erinnerungen aufkamen, konnte jemand auf das damalige Gespräch hinweisen. Wir haben ins Protokoll geschaut und hatten wieder einen gemeinsamen Ausgangspunkt.

Für mich entstand daraus eine gute Meeting-Kultur. Nicht, weil niemand seine Meinung ändern durfte. Sondern weil wir nicht jedes Mal erst klären mussten, worüber wir überhaupt schon gesprochen hatten.

Der Zweck ist für mich ausdrücklich nicht: „Hier steht, dass du schuld bist.“

Sondern: „Das war unser damaliger Stand. Gilt er noch?“

Besonders deutlich wird das bei einer bestimmten Art von Wendung: Eine Anforderung wird früh als unnötig eingestuft – und Wochen später als Grund genannt, warum das Ergebnis nicht reicht. Das muss kein Widerspruch sein. Vielleicht hat sich der Einsatzzweck verändert, oder es ist eine neue Erkenntnis dazugekommen. Ohne Protokoll steht in so einem Moment Erinnerung gegen Erinnerung. Mit Protokoll reicht ein Satz: „Am soundsovielten haben wir entschieden, darauf zu verzichten, weil … Gilt dieser Grund noch?“ Dann reden wir über die Sache und nicht darüber, wer was gesagt hat.

Dazu muss nicht jeder Satz jedes Beteiligten festgehalten werden. Wichtiger sind Vorschläge, relevante Einwände, Entscheidungen, Gründe und Zuständigkeiten. Eine Wort-für-Wort-Aufzeichnung kann viel Material erzeugen und die eigentliche Entscheidung trotzdem offenlassen. Auch eine automatisch erzeugte Zusammenfassung ist zunächst ein Entwurf, den die Beteiligten prüfen sollten.

Mit LLMs und Agenten wird das noch wichtiger

Seit wir mit LLMs und Agenten arbeiten, ist der Arbeitsalltag deutlich schneller geworden. In einer Woche entstehen Prototypen, Varianten und Zwischenstände, für die früher ein Monat nötig war. Dabei geht zwangsläufig mehr verloren. Das ist kein Vorwurf, dass sich jemand nichts merken kann. Es ist schlicht die Menge: Wer in diesem Tempo arbeitet, kann nicht jede Abstimmung der letzten Wochen im Kopf behalten. Was dieses Tempo im eigenen Kopf anrichtet, habe ich in KI-Arbeit ohne Struktur: der stille Kollaps beschrieben. Im Team wirkt derselbe Effekt, nur verteilt auf mehrere Köpfe. Umso wichtiger ist es, festzuhalten, was gesagt und entschieden wurde.

Gleichzeitig machen dieselben Werkzeuge Protokolle viel nützlicher als früher. Niemand muss sich mehr durch Dutzende Meetingnotizen arbeiten. Eine Frage an den eigenen Agenten genügt: „Hatten wir das nicht schon besprochen?“ Der Agent findet das Meeting, in dem es um genau diesen Punkt ging, samt Begründung. Oder er stellt fest, dass dazu nirgends etwas festgehalten wurde – auch wenn sich jemand sicher ist, sich daran zu erinnern.

Auch diese zweite Antwort ist wertvoll. Sie zeigt nicht, wer recht hat. Sie zeigt, dass es keine festgehaltene Entscheidung gibt. Und genau dort setzt ein Entscheidungsprotokoll an.

Ein kleines Entscheidungsprotokoll reicht als Anfang

Aus der Softwarearchitektur kenne ich einen brauchbaren Ansatz: Architecture Decision Records. Michael Nygard schlägt kurze Aufzeichnungen wichtiger Entscheidungen vor. Wird eine Entscheidung ersetzt, bleibt die alte erhalten und wird als überholt gekennzeichnet. So geht ihre Begründung nicht verloren.⁵

Übertragen auf Produkt- und Projektentscheidungen würde ich mit diesen Feldern beginnen:

• Frage: Was müssen wir entscheiden?
• Optionen: Welche Wege haben wir betrachtet?
• Beschluss und Status: Was gilt — vorgeschlagen, beschlossen oder ersetzt?
• Begründung: Auf welchen Annahmen und Erkenntnissen beruht das?
• Verantwortung: Wer entscheidet, wer setzt um?
• Folgen: Was beginnt, was wartet, was stoppen wir?
• Überprüfung: Wann oder bei welcher neuen Erkenntnis schauen wir wieder darauf?

Am Ende des Meetings wird der Beschluss kurz vorgelesen und bestätigt. Offene Einwände bleiben sichtbar. Eine spätere Änderung bekommt einen neuen Eintrag, statt die alte Entscheidung still umzuschreiben.

Das ist mein praktischer Vorschlag, keine Garantie gegen Konflikte. Ein Protokoll kann eine fehlende Entscheidung nicht ersetzen. Es kann aber sichtbar machen, dass sie fehlt.

Ein erster Schritt für das nächste Meeting

Wer das ausprobieren will: Fragt im nächsten Meeting einmal, ob etwas eine Idee, ein Prüfauftrag oder eine Entscheidung ist, und schreibt die Antwort in einem Satz auf. Mehr braucht es für den Anfang nicht.

Wir dürfen unsere Meinung ändern. Aber wir sollten gemeinsam festhalten können, was wir ändern — und warum.

Footnotes

1. Orlikowski und Gash (1994): Technological frames. https://dl.acm.org/doi/10.1145/196734.196745 ↩

2. Sculley et al. (2015): Hidden Technical Debt in Machine Learning Systems. https://proceedings.neurips.cc/paper_files/paper/2015/file/86df7dcfd896fcaf2674f757a2463eba-Paper.pdf ↩

3. Prinzipien hinter dem Agilen Manifest. https://agilemanifesto.org/iso/de/principles.html ↩

4. Dasanayake et al.: Impact of requirements volatility on software architecture. https://arxiv.org/pdf/1904.08164 ↩

5. Michael Nygard: Documenting Architecture Decisions. https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions ↩