Rituale binden ein Team ein. Sie schaffen Austausch, machen jeden sichtbar und geben dem Team einen Ort, an dem es lernt und sich Verbesserungen vornimmt. In der agentischen Entwicklung ändert sich allerdings das Tempo so stark, dass sich auch die Inhalte dieser Rituale verändern müssen. Eine fertige Antwort, wie sie künftig aussehen, hat im Moment noch niemand. Einige Richtungen zeichnen sich aber ab.

Rituale, die ein Team einbinden

Im E-Commerce-Team des Medizintechnik-Unternehmens haben wir über fünf Jahre nach Scrum gearbeitet, mit Planning, Stand-ups, einem Review alle zwei Wochen und einer Retrospektive alle vier Wochen. Alles kurz, alles knapp, im Standardrahmen von Scrum. In der Retrospektive konnte jeder sagen, wie es ihm geht, das Team kam in den Austausch, lernte aus dem Vergangenen und nahm sich konkrete Verbesserungen vor.

Bei Nakoa gibt es zusätzlich feste Techniksprechstunden. Jeder kann vorbeikommen, sich informieren, Themen abladen und diskutieren oder nachfragen, wenn er etwas nicht versteht. Zugleich erzählen wir dort, was aus technischer Sicht passiert ist. Für Marketing-Managerinnen und -Manager, die aus dem Business kommen, ist das oft nicht leicht zu greifen, und genau hier entsteht die Verbindung zwischen Technik und Business.

Wenn täglich Dutzende Änderungen durchlaufen

In der agentischen Entwicklung gehen heute schon an einem Tag bis zu 50 Pull Requests durch, werden gemergt und verändern die Entwicklungsumgebung oder das Staging-System. Über den Fortschritt einzelner Tickets zu sprechen, ergibt bei diesem Tempo wenig Sinn. Ob für ein Feature ein Button an eine bestimmte Stelle gehört und welcher Wert dafür in die Datenbank geschrieben wird, muss kein Ritual mehr klären. Die klassischen Rituale zum Projektfortschritt verändern sich deshalb gerade grundlegend, und jeder experimentiert damit, wie man den Überblick behält.

Über das Outcome sprechen

Wir brauchen Rituale, in denen wir darüber sprechen, was außerhalb passiert: wie mit unserem Produkt umgegangen wird und was sich draußen messen lässt. Beim Nakoa Brain sprechen wir zum Beispiel darüber, wie sich die Vorschläge des Systems zur Veränderung von Kampagnen über die Zeit auswirken und was passiert wäre, wenn wir nichts getan hätten. Dazu rechnen wir gegen einen fortgeführten Trend. Wir prüfen, ob sich etwas verbessert hat, weil wir die Agenten, die diese Vorschläge machen, weiterentwickelt haben, etwa indem sie mehr Input über die Mechanismen der Marktplätze bekommen.

Ein zweites Thema ist die Effizienz. Wir sprechen darüber, wie viele Tokens die SQL-Abfragen und das Reasoning einer Analyse verbrauchen und wie gezielt Kontext in diese Analyse einfließt. Statt alles in den Kontext zu geben, geben wir gefiltert hinein, was für die jeweilige Fragestellung relevant ist: ein begrenztes Schema und die Einträge aus dem Datenkatalog, die beschreiben, welche Daten wie kombiniert werden und was die einzelnen Kennzahlen bedeuten. Reicht der minimale Kontext nicht, kommt in einer weiteren Schleife mehr hinzu (siehe Kontextmodellierung ist die eigentliche Engineering-Aufgabe und Beobachtbarkeit vor Kontrolle einbauen).

Was davon trägt

Der Zweck der Rituale bleibt derselbe: das Team einbinden, gemeinsam lernen und sich verbessern. Ihr Gegenstand verschiebt sich vom Fortschritt der Arbeit zum Ergebnis, das sie draußen erzeugt. Das passt zu kleinen Teams, die Verantwortung für ein Outcome tragen (siehe Allein bauen, wofür früher ein Team nötig war – und warum das nicht das Ziel ist).