AIND deckt nur die Vorgehensweise bei der Entwicklung vom Bedarf über die Spezifikation bis zum geprüften Code ab, nicht aber, wer welche Aufgaben übernimmt, was abgestimmt und freigegeben ist, wie Sprints geplant werden und wie der Aufgabenvorrat verwaltet wird. Diese Koordination erfolgt dort, wo Teams sie ohnehin organisieren: in Jira oder einem vergleichbaren Werkzeug. Trotzdem verändern Coding-Agenten nicht nur die Implementierung, sondern auch die Teamarbeit.

Was wird aus Scrum?

Dass Coding-Agenten die agile Zusammenarbeit verändern werden, ist absehbar. Wenn ein größerer Teil der Umsetzung an Agenten wandert, verschieben sich Taktung, Rollen und der Zuschnitt von Aufgaben grundlegend. Wie stark und in welche Richtung, kann heute aber niemand genau vorhersagen.

Genau deshalb wäre es ein Fehler, jetzt einen neuen, auf KI fokussierten Koordinationsmodus von oben zu verordnen. Der bessere Weg ist evolutionär: An bestehende Zusammenarbeit andocken, sie mit besseren Informationen versorgen und beobachten, wo sich das Zusammenarbeitsmodell tatsächlich verändert. Das ist das agile Prinzip auf sich selbst angewendet.

Der Engpass wandert zur Abstimmung

Wenn Coding-Agenten die Implementierung beschleunigen, verschieben sich die Arbeitsanteile. Der Aufwand für die Code-Erzeugung sinkt, während der Aufwand für Spezifikation, Abstimmung und Prüfung relativ mehr Raum einnimmt. Das verändert die Granularität der Zusammenarbeit. Aufgaben müssen klarer spezifiziert und entscheidungsreifer vorbereitet werden, bevor ein Agent sinnvoll Code bauen kann. Akzeptanzkriterien, Zusicherungen, Abhängigkeiten und offene Fragen müssen früher geklärt werden. Ein Ticket, das früher durch erfahrene Entwickler*innen während der Implementierung präzisiert wurde, muss nun stärker vor der Umsetzung verstanden sein.

Dieser Wandel ist kulturell nicht trivial. Viele Entwickler*innen haben ihre Produktivität bisher gerade daraus gezogen, technische Probleme über längere Zeit konzentriert zu lösen. Jetzt liegt ein größerer Teil ihrer Wertschöpfung in der kommunikativen Arbeit: Spezifizieren, Rückfragen klären, Entscheidungen dokumentieren, prüfen.

Gerade deshalb darf KI nicht bei der Codeerzeugung stehen bleiben, sondern muss auch die Zusammenarbeit unterstützen — nicht als Ersatz für Abstimmung, sondern indem sie diese vorbereitet, verdichtet und entscheidungsfähiger macht. Wie das in den einzelnen Scrum-Zeremonien aussieht, zeigt der nächste Abschnitt.

Der Schwerpunkt von Scrum verschiebt sich

Scrum-Zeremonien werden auch mit Coding-Agenten nicht überflüssig, aber ihr Gewicht liegt anders.

Im Refinement kann die KI helfen, unscharfe Tickets zu erkennen und Fragen zu klären wie: Ist die fachliche Absicht klar? Fehlen Akzeptanzkriterien? Gibt es offene Entscheidungen? Ist die Aufgabe so beschrieben, dass ein Agent damit sinnvoll arbeiten kann? Und vor allem: KI muss dabei unterstützen, die relevante Information verständlich zu transportieren, auf einem Abstraktionslevel, das für die neue Herangehensweise angemessen ist. Nicht mehr auf der Ebene der technischen Details, sondern auf einer konzeptionellen Ebene.

Im Planning kann KI die geplante Arbeit gegen Abhängigkeiten, Risiken und Spezifikationsreife spiegeln. Sie entscheidet nicht, was in den Sprint kommt, aber sie macht sichtbar, welche Aufgaben noch nicht entscheidungsreif sind oder welche Zusicherungen fehlen.

Im Daily kann KI aus AIND-Artefakten, Statuswechseln und Übernahme-Nachrichten einen knappen Arbeitsstand erzeugen: Was wurde begonnen, was ist blockiert, welche Entscheidung fehlt? Das Daily dient weniger zur Statusabfrage als zur Klärung von Blockern.

Im Review kann die KI zusammenführen, was sonst mühsam zusammengesucht wird: Welche Anforderung lag zugrunde? Welche Zusicherungen wurden umgesetzt? Welche Code-Änderung wurde übernommen? Welche Abweichungen hat der Abgleich gefunden? Review wird damit stärker an Spezifikation und Prüfbarkeit gebunden.

In der Retrospektive kann die KI Muster aus tatsächlichen Arbeitsdaten sichtbar machen: Wo waren Anforderungen zu weich? Wo entstanden unnötige Korrekturschleifen? Welche Tickets waren zu groß geschnitten? Wo musste der Agent mehrfach nacharbeiten?

Der Mensch entscheidet, was wichtig ist aber auf besser vorbereiteten Informationen.

AIND dockt an die Team-Koordination an

Damit diese feinere Abstimmung nicht zu Mehraufwand für die Pflege führt, muss sie dort ankommen, wo Teams ohnehin arbeiten: im Backlog, im Sprint, im Vorgang. AIND ersetzt Jira oder vergleichbare Werkzeuge deshalb nicht, sondern liefert ihnen Informationen zurück. Dazu wird ein AIND-Artefakt, z.B. eine Komponente oder eine Umsetzungsaufgabe, mit einem Jira-Vorgang verknüpft. Von da an kann die Verbindung weitgehend automatisch gepflegt werden:

• Der Status wandert in den Jira-Ablauf: Beginnt oder endet die Arbeit an einem Artefakt, bewegt sich der zugehörige Vorgang mit.
• Das System schreibt einen prägnanten Statuskommentar in den Vorgang, knapp und lesbar, ohne dass jemand ihn von Hand pflegen muss.
• Die Übernahme-Nachricht, mit der eine Änderung in den Code aufgenommen wird, trägt die Absicht des Vorgangs mit sich. Dadurch bleibt die Verbindung zwischen fachlicher Aufgabe und technischer Änderung erhalten.
• Prüf- und Abweichungsinformationen können in die Team-Koordination zurückgespielt werden: Was wurde umgesetzt, was ist noch offen, wo braucht es eine Entscheidung?

Das Team arbeitet also weiter in Jira wie bisher, und AIND füttert diese Koordinationsebene. So ist zumindest die Jira-Anbindung angelegt, mit der wir derzeit arbeiten.

Kontrollierte Grenze und Datenhoheit

Die Anbindung ist bewusst so angelegt, dass sie erstens, über eine kontrollierte Grenze vermittelt wird: Der Agent bekommt keinen wahllosen Zugriff auf alle Vorgänge, sondern arbeitet über eine definierte, geprüfte Schnittstelle. Nach derselben Logik, wie in den vorherigen Beiträgen beschrieben, erhalten die Agenten stets nur begrenzte, kontrollierte Fähigkeiten.

Zweitens ist die Anbindung datensouverän: Alle Entwickler*innen handeln mit eigener Identität. Statuswechsel und Kommentare erscheinen unter der Person, die die Arbeit tatsächlich verantwortet und nicht unter einem anonymen Automaten. So bleiben Nachvollziehbarkeit und Verantwortlichkeit erhalten, was gerade im Zusammenarbeitsmodell entscheidend ist. Wenn die KI einen Status erzeugt, Entscheidungen vorbereitet oder Blocker sichtbar macht, darf die Verantwortung nicht verschwimmen. Die KI kann die Abstimmung vorbereiten und verdichten, aber entscheiden und verantworten muss weiterhin das Team.

Veränderung der Teamarbeit auf Basis der Erfahrung

Der eigentliche Nutzen liegt darin, dass die bewährte Zusammenarbeit bestehen bleibt und sich in der laufenden Praxis weiterentwickelt: Ein Team führt die KI-gestützte Entwicklung ein, ohne seinen Koordinationsmodus umzustürzen, und lernt im Betrieb, wo sich Abläufe tatsächlich ändern. Scrum trägt diese Entwicklung also mit, statt ihr im Weg zu stehen: Es erlaubt dem Team, mit Hilfe von KI die erforderlichen Abstimmungsprozesse zu steuern und kontrolliert abzuwickeln, damit Spezifikation, Entscheidung und Prüfung mit dem schnelleren Bauen mithalten können.

Bleibt die Frage, wohin die Reise geht: Heute sind Agenten noch Werkzeuge, die losgelöst von der Methodik sind; morgen werden sie tiefer in sie eingebettet. Darum geht es im letzten Teil dieses Kapitels.