Der Adadot-Index sinkt: Welche Merge Requests gehören in die Retrospektive?

Der Sprint beginnt gut, doch gegen Ende wartet ein Stapel Code auf Reviews. Entwicklungsverantwortliche müssen verstehen, wie die Arbeit ins Stocken geraten ist, statt lediglich eine sinkende „Geschwindigkeit“ des Teams zu sehen. Adadot analysiert Entwicklungsaktivitäten und Zusammenarbeitsdaten gemeinsam und kann Hinweise für eine solche Retrospektive liefern. Was tatsächlich geändert werden sollte, lässt sich aber erst anhand konkreter Aufgaben und im Gespräch mit dem Team entscheiden.

Dieser Artikel analysiert das Szenario anhand offizieller Produktbeschreibungen und historischer Anwendungsbeispiele des Anbieters. Es wurde weder ein Teamkonto angebunden noch die Vorhersageleistung des Modells überprüft.

Auf seiner Website nennt Adadot den Zusammenhang zwischen Review-Wartezeiten und der Anzahl von Review-Kommentaren sowie „What if“-Szenarien als Einsatzmöglichkeiten. Damit können Verantwortliche konkretere Fragen stellen: Hätten frühere Reviews der Merge Requests den aktuellen Engpass möglicherweise entschärft? Das ist eine zu prüfende Hypothese, kein vom Modell bereits erbrachter Beweis für die Ursache.

Die nächste Retrospektive lässt sich als kleines Experiment gestalten. Legen Sie zunächst dasselbe Team, vergleichbare Projekte und gleich lange Beobachtungszeiträume zugrunde. Halten Sie fest, was sich verändert hat, und wählen Sie dann die Merge Requests aus, die innerhalb dieses Zeitraums bis zum Sprintende liegen geblieben sind. Prüfen Sie im ursprünglichen Entwicklungstool die Einreichungs- und Review-Zeitpunkte, den Umfang der Änderungen, die Diskussionsverläufe und mögliche kurzfristige Änderungen an den zugehörigen Anforderungen. Auch die FAQ von Adadot beschreiben das Produkt als Analyseschicht über den alltäglichen Tools und verweisen für Informationen auf Aufgabenebene weiterhin auf Jira oder Gitlab.

So lassen sich unterschiedliche Handlungsrichtungen erkennen: Wenn sich der Anforderungsumfang laufend verändert, hilft bloßes Drängen auf schnellere Reviews nicht. Sind Änderungen so groß, dass sie niemand rasch versteht, kann eine Aufteilung sinnvoll sein. Werden Reviewer erst ganz zum Schluss eingebunden, muss die Zusammenarbeit früher geplant werden. Diese Einteilung ist eine Methode für die Retrospektive, keine Behauptung, Adadot versehe jeden Request automatisch mit solchen Kategorien.

In einem im August 2022 veröffentlichten Bericht über das eigene Team beschreibt Adadot, wie es Arbeit anhand des Änderungsumfangs je Merge Request in kleinere Einheiten aufteilte. Bei der Diskussion über langsamere Merges in der zweiten Sprinthälfte stellte das Team außerdem fest, dass es einfache Aufgaben zuerst erledigte und schwierige, anfällige Aufgaben auf später verschob. Daraufhin nahm es die schwierige Arbeit früher in Angriff.

Dieser Bericht ist die Rückschau eines Anbieters auf sein eigenes Team. Daraus lässt sich kein Versprechen ableiten, ein anderes Team werde denselben Durchsatzgewinn erzielen. Er bietet jedoch einen nützlichen Ausgangspunkt: Diagramme machen Veränderungen sichtbar, das Team erklärt den Kontext, anschließend werden Aufgabenaufteilung oder Bearbeitungsreihenfolge geändert. Die Diskussion dazwischen darf nicht übersprungen werden, um aus einer einzelnen Punkteschwankung direkt auf die Leistung eines Mitarbeiters zu schließen.

Wählen Sie zunächst nur eine Anpassung, etwa Aufgaben mit externen Abhängigkeiten früher zu besprechen. Prüfen Sie im nächsten vergleichbaren Zeitraum nicht nur, ob Wartezeiten abnehmen, sondern auch, ob Nacharbeit zunimmt oder schwierige Arbeit lediglich aus dem Beobachtungszeitraum hinausgeschoben wurde. Steigt die Zahl erledigter Aufgaben, ohne dass die Probleme bei der Auslieferung abnehmen, ist eine erfolgreiche Verbesserung noch nicht belegt.

Laut FAQ normalisiert der Index Daten auf einen Bereich von 1–10 und verwendet Gewichtungen. Er eignet sich daher als Hinweis darauf, wo genauer hingesehen werden sollte, nicht als unmittelbares Äquivalent für Arbeitsstunden, Geschäftswert oder individuelle Beiträge. Aufgaben mit unterschiedlichem Hintergrund sollten ebenfalls nicht anhand eines einzigen Werts in eine Rangfolge gebracht werden.

Die Produktseite erklärt, individuelle Kennzahlen würden auf Teamebene aggregiert und anonymisiert; Teamkennzahlen setzten mindestens 3 Mitglieder voraus. Außerdem werde Code weder verarbeitet noch gespeichert. Vor einer regulären Anbindung sollten Verantwortliche dennoch gemeinsam mit dem Team prüfen, welche Felder im tatsächlichen Konto sichtbar sind, woher die Daten stammen, wer Zugriff hat und welche Nutzung die Organisation erlaubt. Die Produktaussagen ersetzen diese Prüfung nicht und erlauben auch nicht, in Retrospektiven beliebig personenbezogene Rohdatensätze zu zeigen.

Geht es lediglich darum, wer heute einen bestimmten Request übernimmt, ist eine direkte Abstimmung im bestehenden Aufgabentool angemessener. Adadots Analyseschicht wird vor allem dann einen Versuch wert, wenn Engpässe wiederholt auftreten, mehrere Aufgaben betreffen und das Team die Daten gemeinsam zur Prozessanpassung nutzen möchte. Das Ergebnis eines Tests sollte eine klar erklärbare, nachträglich überprüfbare Prozessänderung sein, keine aufwendiger gestaltete Rangliste einzelner Personen.