Die Zukunft der KI-gestützten Produktentwicklung: Das Wissen, das Ihrem Team verloren geht

Artikel 6 von 9 in dieser Reihe.

Stellen Sie sich eine erfahrene Entwicklerin vor, die sich daran macht, ein Problem in der Produktion eines Dienstes zu beheben, für den ihr Team verantwortlich ist. Den Großteil des zugehörigen Codes hat sie nicht selbst geschrieben. Ein KI-Programmieragent hat im Laufe des letzten Jahres den Großteil davon unter der Anleitung ihres Teams und mit dessen Zustimmung generiert. Der Code ist gut dokumentiert. Die Tests werden bestanden. Die „Definition of Done“ wurde Sprint für Sprint erfüllt.

Sie kann die Fehlerquelle nicht intuitiv erkennen. Die üblichen Instinkte – jene, die einem erfahrenen Entwickler signalisieren, dass etwas nicht stimmt – setzen nicht ein. Schließlich bittet sie den Mitarbeiter, ihr dessen eigene Arbeit noch einmal zu erklären. Die Fehlerbehebung dauert vier Stunden statt vierzig Minuten.

Am Code gibt es nichts auszusetzen. Das Problem liegt ausschließlich im Wissen.

Dies ist der stillste, am wenigsten diskutierte und, wie ich meine, am meisten unterschätzte Wandel, der sich innerhalb von KI-gestützten Produktteams vollzieht. Die ersten fünf Artikel dieser Reihe konzentrierten sich auf sichtbare, strukturelle Veränderungen: eine Wertdefinition, gebündelte Verantwortlichkeit, Verfeinerung als Optionsrahmen, ein Einführungsinkrement sowie eine Evidenzüberprüfung. Alle fünf sind auffällige Veränderungen. In diesem Artikel geht es um eine stille Veränderung. Was geschieht mit dem impliziten Wissen, das ein Team früher durch die Ausführung der Arbeit angesammelt hat, wenn diese Arbeit zunehmend von einem Agenten übernommen wird?

Dies ist ein visionärer Beitrag, kein prognostischer. Ich kann Ihnen nicht sagen, wie die Lernkurve bei KI-gestützten Teams in fünf Jahren aussehen wird. Ich kann Ihnen jedoch darlegen, wie eine Gruppe erfahrener Professional Scrum Trainer dieses Risiko einschätzt und warum eine einfache Disziplin, die Sie bereits in diesem Sprint umsetzen, die Wissensbasis Ihres Teams schützen wird.

Zwei Arten von Wissen

Ikujiro Nonaka und Hirotaka Takeuchi haben in ihrem Werk „The Knowledge-Creating Company“ vor mehr als 30 Jahren eine Unterscheidung getroffen, die mit der Zeit nur noch an Bedeutung gewonnen hat. Explizites Wissen ist das, was sich schriftlich festhalten lässt: Dokumentationen, Wikis, Ticketverläufe, Architekturdiagramme, Leitfäden. Implizites Wissen ist das, was sich nicht ohne Weiteres schriftlich festhalten lässt: Instinkt, Mustererkennung, das Gefühl, dass dies schon einmal schiefgelaufen ist und worauf man nun achten muss.

Machen Sie keinen Fehler: Scrum hat Lernen, Selbstmanagement und Kaizen schon immer hochgeschätzt. Der Scrum Guide trägt keinerlei Schuld an den in diesem Artikel angesprochenen Punkten. Was sich geändert hat, ist der Mechanismus, durch den sich implizites Wissen früher angesammelt hat. Dreißig Jahre lang war dieser Mechanismus einfach: Teams entwickelten ihr Gespür, indem sie die Arbeit gemeinsam, unter Druck und mit Konsequenzen erledigten. Entwickler lernten den Code, indem sie ihn schrieben. Product Owner lernten den Markt kennen, indem sie mit Kunden sprachen. Scrum Master lernten das Team kennen, indem sie die schwierigen Momente gemeinsam durchstanden. KI-Agenten untergraben diesen Mechanismus still und leise, ohne dass es jemand bemerkt.

Wie Agenten den Lernkreislauf beeinflussen

Agenten liefern Ergebnisse, ohne dass das Team die Arbeit leisten muss, durch die früher die Erkenntnisse gewonnen wurden. Ein Element des Product Backlogs wird entworfen. Ein Entwickler schreibt nie die erste Version. Ein Kundeninterview wird zusammengefasst. Der Product Owner erlebt nie jene unangenehme Stille, durch die er gelernt hätte, was dem Kunden wirklich Sorgen bereitet. Eine Erkenntnis aus der Retrospektive wird extrahiert. Der Scrum Master muss niemals das Gespräch moderieren, durch das die gemeinsame Sprache des Teams für das, was schiefgelaufen ist, entstanden ist.

Der Code wird ausgeliefert, doch das Verständnis für den Code wächst nicht. Die Zusammenfassung wird erstellt, doch das Gespür für den Markt entwickelt sich nicht weiter. Das Dokument wird verfasst, doch die gemeinsame Intuition des Teams wird nicht geschärft.

Ich möchte diese unsichtbaren Kosten benennen. Nennen wir sie die „Steuer auf implizites Wissen“. Für jede Arbeit, die ein Teammitglied für das Team leistet, wird eine Steuer in Form von entgangenem implizitem Wissen gezahlt. Manchmal ist diese Steuer gering und es lohnt sich nicht, sich ihrer Zahlung zu entziehen; manchmal ist sie hoch und rächt sich achtzehn Monate später, wenn das Team mit einem neuartigen Problem konfrontiert wird und feststellt, dass niemand im Team über die praktische Erfahrung verfügt, um es zu erkennen. Die Steuer ist für die Führungsebene oder das Team selbst nicht immer sichtbar, aber sie ist stets still und leise real.

Wo die Steuern niedrig sind, wo sie hoch sind

Der Aufwand ist gering bei Aufgaben, die sich wiederholen, routinemäßig sind und bereits gut bekannt sind: Standardtexte, Konfigurationsdateien, Standarddokumentation, erste Entwürfe allgemeiner E-Mails, Zusammenfassungen von seit langem etablierten Sitzungsprotokollen. Das Team hat fast keinen Nachteil davon, wenn ein Agent diese Arbeit übernimmt.

Diese Arbeit ist mit hohem Aufwand verbunden – und genau so bilden Menschen ihr Urteilsvermögen aus: erste Kundenbefragungen, erste Debugging-Sitzungen, Architekturentscheidungen, Gespräche zur Verfeinerung wirklich neuartiger Themen sowie die Moderation von Retrospektiven. In jedem dieser Fälle ist die Herausforderung der Arbeit die Quelle des Lernens. Wenn Sie diese Herausforderung auslagern, erhalten Sie das Ergebnis, ohne daraus zu lernen.

Ein gut geführtes, KI-gestütztes Team zahlt die „billige Steuer“ bereitwillig und lehnt die „teure Steuer“ bewusst ab. Ein undiszipliniertes Team zahlt jede Steuer, lobt die Geschwindigkeit und stellt ein Jahr später fest, dass es kein Problem lösen kann, das die Agenten zuvor noch nicht gesehen haben.

Eine „Geschwistersteuer“: Nachhaltigkeit und Ressourcenkosten

Die „Steuer auf implizites Wissen“ ist jene kostspielige Belastung, die den meisten Teams verborgen bleibt. Eine zweite, damit eng verbundene und erwähnenswerte Steuer ist die Nachhaltigkeitssteuer. Jeder Agenten-Aufruf verbraucht Rechenleistung, Wasser und Strom. Die CO₂- und Ressourcenkosten, die durch Hunderte von Agenten-Aufrufen pro Ingenieur und Tag entstehen, sind auf Unternehmensebene nicht mehr zu vernachlässigen und gewinnen auch auf Kunden- und regulatorischer Ebene zunehmend an Bedeutung. Ein KI-gestütztes Team, das den Ressourcenverbrauch seiner Agenten nicht misst und nicht hinterfragt, ob eine bestimmte Aufgabe überhaupt einen Agenten erfordert, optimiert zwar die Geschwindigkeit, belastet dabei jedoch stillschweigend eine andere Art von Bilanz. Nicht jede Aufgabe erfordert eine KI. Teams, die bewusst entscheiden, für welche Aufgaben dies erforderlich ist, werden in fünf Jahren nicht weniger, sondern vielmehr als ausgefeilter gelten.

Und vergessen Sie nicht die Menschen, für die Sie entwickeln

Ein weiterer Schutzaspekt, der erwähnenswert ist und in Diskussionen über KI oft vergessen wird: Die Arbeit der Teams wird letztendlich von Menschen genutzt. UX, menschenzentriertes Design, Einfühlungsvermögen gegenüber Kunden und die Kunst, etwas so zu gestalten, dass es in den Kontext eines Menschen passt, sind keine bloßen Höflichkeitsfloskeln. Sie sind der Teil der Arbeit, bei dem ein Agent zwar unterstützen kann, für den er jedoch nicht die Verantwortung übernehmen kann. Schützen Sie die Zeit, die Ihr Team mit den Nutzern verbringt – indem es sie beobachtet, ihnen zuhört und für sie entwirft. Die Teams, die dies in einer KI-gestützten Welt als optional betrachten, sind jene, deren Inkremente zwar technisch gesehen die „Definition of Done“ erfüllen, aber stillschweigend den einzigen Test nicht bestehen, auf den es wirklich ankommt.

Drei Schutzmaßnahmen, die ein Team ergreifen kann

Zunächst einmal die Öffnungszeiten, die ausschließlich für Besucher gelten. Planen Sie ein bis zwei Stunden pro Woche ein, in denen das Team die Arbeit ohne Unterstützung durch KI erledigt. Fehlerbehebung. Ein Kundengespräch. Ein Gespräch zur Verfeinerung. Das Team baut das Gefühl wieder auf, das sich durch keine Zusammenfassung erfassen lässt.

Zweitens: Nutzen Sie den „Accountability-Test“ auf neue Weise. Die drei Fragen aus Artikel 2 – „Erklären“, „Begründen“, „Wiederholen“ – stellen bereits einen versteckten Test für implizites Wissen dar. Wenn ein Teammitglied die Arbeit nicht ohne den Beauftragten wiederholen kann, ist das implizite Wissen verloren gegangen. Das ist ein Warnsignal. Ergreifen Sie entsprechende Maßnahmen.

Drittens: die Reihenfolge der Ausbildungsberufe. Wenn Nachwuchskräfte und erfahrene Mitarbeiter mit Agenten zusammenarbeiten, kommt es auf die Reihenfolge an. Die Nachwuchskräfte erstellen den ersten Entwurf von Hand. Die Agenten unterstützen sie beim zweiten. Die erfahrenen Mitarbeiter überprüfen den dritten. Kehrt man diese Reihenfolge um, lernen die Nachwuchskräfte niemals, zu schreiben, Fehler zu beheben oder zu denken. Sie lernen, Anweisungen zu geben, und das ist nur ein dürftiger Ersatz für echtes Verständnis.

Wie dies in der Praxis aussieht

Stellen Sie sich zwei Teams vor, die seit einem Jahr im Einsatz sind. Beide setzen in hohem Maße KI ein. Beide liefern die gleiche Anzahl an Funktionen aus. Beide erfüllen die „Definition of Done“ und erreichen die „Adoption Increment“-Schwelle.

Team A betrachtet jede KI-gestützte Abkürzung als kostenlos. Die Team-Velocity ist in den ersten acht Monaten von Sprint zu Sprint höher. Team B schont eine Handvoll Kategorien: Kundeninterviews, Fehlerbehebung im ersten Entwurf sowie die Verfeinerung wirklich neuartiger Elemente. Die Velocity von Team B ist etwa fünfzehn Prozent niedriger.

Im fünfzehnten Monat tritt eine neue Art von Produktionsproblem auf, mit der die Mitarbeiter beider Teams bisher noch nicht konfrontiert waren. Team B löst es innerhalb eines Tages. Team A benötigt dafür sechs Tage. Die Dokumentation von Team A ist hervorragend. Die Intuition von Team A ist jedoch verloren gegangen.

Die Geschichte ist bewusst hypothetisch gehalten. Das Muster, auf das sie hinweist, ist es jedoch nicht. Anzeichen für diese sich verstärkende Belastung zeigen sich bereits in Produktentwicklungsabteilungen. Die Einzelheiten unterscheiden sich, das Muster jedoch nicht.

Vier Maßnahmen, die Sie in Ihrem nächsten Sprint umsetzen können

Die Wende

Der billigste Satz, den eine Führungskraft über KI sagen kann, lautet: „Dadurch arbeitet das Team zehnmal schneller.“ Das Teuerste, was eine Führungskraft tun kann, ist, diesem Satz Glauben zu schenken, ohne die Kosten der „Steuer auf implizites Wissen“ zu berücksichtigen. Ein Team, das darauf achtet, was still und leise verloren geht, behält sich die Möglichkeit zum Lernen vor. Ein Team, das dies nicht tut, tut es nicht.

Die Scrum-Werte – Mut, Fokus, Engagement, Respekt und Offenheit – setzen alle ein Team voraus, das in der Lage ist, aus seiner eigenen Arbeit zu lernen. Schützen Sie diesen Lernmechanismus, sonst werden die Werte zu bloßen Schlagworten.

Nun sind Sie an der Reihe

Wählen Sie eine Arbeitskategorie aus, die Ihr Team in den letzten sechs Monaten an einen Mitarbeiter delegiert hat. Fragen Sie sich: Wenn dieser Mitarbeiter morgen nicht mehr da wäre, könnte das Team diese Arbeit dann immer noch gut erledigen? Wenn die ehrliche Antwort „Nein“ lautet, haben Sie eine „Steuer auf implizites Wissen“ identifiziert, die sich still und leise angehäuft hat. Im nächsten Sprint beginnen Sie damit, diese abzubauen.

Der nächste Artikel befasst sich mit dem Ort, an dem das vom Team gesicherte Wissen untergebracht werden muss, damit es von den Menschen und den Agenten, die es benötigen, genutzt werden kann. Die „Product Wall“, die viele erfahrene Produktteams bereits pflegen, wird bald zu etwas Umfassenderem, Tragfähigerem und – zum ersten Mal – für einen Agenten ebenso verständlich sein wie für einen Menschen. Nennen wir es den „Context Lake“. Wir sehen uns dort.

Mitwirkende

Dieser Artikel entstand auf der Grundlage der PST-Präsenzveranstaltung Nr. 137 von Scrum.org in Amsterdam. Er wäre ohne die Gespräche mit folgenden Personen nicht möglich gewesen: Dave West, Merel van de Wiel-Riedeman, Tommi Kemppi, Sjoerd Nijland, Jesse Houwing, Robbin Schuurman, Martijn Magermans, Guus Verweij, Steven Deneir, Gregor Stuhldreier, Paul Kuijten, Mehdi Hoseini, Simon Kneafsy, Vivien Colas, Jeroen de Jong, Kate Hobler, Olivier Ledru, Roderick Schoon, Stephan Vlieland, Tiffanie Newton und Karel Smutný. Die hier dargelegten Argumente stammen von mir. Die Überlegungen stammen von uns.

< Lesen Sie den vorherigen Artikel

Quellen

„Das wissensschaffende Unternehmen“, Ikujiro Nonaka und Hirotaka Takeuchi

Die fünfte Disziplin, Peter Senge

Situatives Lernen, Jean Lave und Etienne Wenger

Der Scrum Guide, Schwaber und Sutherland

Man kann die Verantwortung nicht an einen Beauftragten delegieren – Artikel 2 dieser Reihe

Die Sprint-Review funktioniert nicht – Artikel 5 dieser Reihe