✍️ OffenIhre Organisation führt KI-Assistenten für alle Scrum Teams ein. Der Vorstand erwartet eine Produktivitätssteigerung von dreißig Prozent. Nehmen Sie als Scrum Master dazu Stellung.
Musterantwort: Zuerst würde ich die Zielgröße selbst hinterfragen. "Produktivität" ist in der Produktentwicklung keine brauchbare Größe, weil sie Ausbringung misst, nicht Wirkung: Dreißig Prozent mehr gelieferte Funktionen bedeuten nicht dreißig Prozent mehr Wert, wenn ein erheblicher Teil ohnehin kaum genutzt wird. Zudem wird eine vorgegebene Prozentzahl zur Zielvorgabe und lädt zur Optimierung der Zahl ein, etwa über größere Schätzungen oder kleinteiligere Einträge.
Dann würde ich benennen, wo Beschleunigung realistisch entsteht und wo nicht. Assistenten wirken auf die Zeit, in der tatsächlich gearbeitet wird. In den meisten Organisationen liegt der größere Teil der Durchlaufzeit aber in Wartezeiten: auf Freigaben, auf Abhängigkeiten, auf Rückmeldungen von Stakeholdern. Diese Zeit verkürzt kein Werkzeug. Wer dort nichts ändert, wird den erwarteten Effekt nicht sehen, unabhängig davon, wie gut die Assistenten sind.
Drittens würde ich auf die Risiken hinweisen, und zwar nicht als Bedenken, sondern als messbare Größen. Schneller erzeugter Code, den niemand vollständig versteht, erhöht Produktionsvorfälle und technische Schuld; die gewonnene Kapazität fließt dann in Nacharbeit. Deshalb würde ich Durchlaufzeit niemals allein betrachten, sondern gemeinsam mit Vorfallzahl, Nacharbeitsanteil und dem Anteil der Kapazität, der für Neues zur Verfügung steht.
Als Vorgehen schlage ich vor: einen Zielzustand statt einer Prozentzahl, ein begrenztes Vorgehen mit wenigen Teams über einige Sprints, vorab festgelegte Kennzahlen über mehrere Wertbereiche und eine ausdrückliche Anpassung der Definition of Done um eine menschliche Prüfpflicht. Parallel sind Lizenzfragen, Datenverarbeitung und die Beteiligung des Betriebsrats zu klären.
Schließlich: Die Entscheidung über Werkzeuge im Sprint gehört zur Selbstverwaltung der Developers. Eine verpflichtende Nutzungsvorgabe erzeugt Widerstand und verdeckt gerade die Erfahrungen, die man für die Bewertung bräuchte.
Bewertet werden: Kritik an Produktivität als Ausbringungsgröße und an der Prozentvorgabe als Zielvorgabe + Wartezeit als dominierender Anteil der Durchlaufzeit + Qualitätsrisiko mit Gegenkennzahlen + Zielzustand und begrenztes Vorgehen statt Vollrollout + Anpassung der Definition of Done + Selbstverwaltung bei Werkzeugentscheidungen.