Просмотр новости
Найдите то, что Вас интересует
Спутники
РН
SpaceX
Роскосмос
NASA
СпутникиРНSpaceXРоскосмосNASABraucht es noch Scrum Teams – jetzt, wo wir KI haben?Ich stelle mir diese Frage selbst und wahrscheinlich bin ich nicht der Einzige. Auf meiner Suche nach Antworten schaue ich auf die Menschen, die die agile Softwareentwicklung geprägt haben. Einer von ihnen ist Henrik.Henrik hat Jahrzehnte in der Softwareentwicklung gearbeitet – als Entwickler, Coach, Designer, Unternehmer. Bis Mitte 2022 hatte er eine klare Antwort auf diese Frage: Ja. Menschen werden immer gebraucht. Die Übersetzung von Anforderungen in Code – „the manual translation layer“ – sei schlicht unvermeidbar.Dann kam ChatGPT. Nicht perfekt. Aber Henrik war trotzdem fassungslos. Seine Antwort änderte sich leise.Als GPT-4 kam, zog sich Henrik für eine Woche in eine Hütte im Stockholmer Schärengarten zurück. Kein Telefon. Nur er und die KI. Wie er in seinem Blog schreibt: „Der Fortschritt ist atemberaubend.“ Er kam nicht mit Notizen zurück, sondern mit einem fertigen Spiel: WhoDunit, ein KI-gestütztes Detektiv-Rollenspiel, bei dem GPT den Code schrieb, die Geschichten generierte und die Charaktere spielte.Heute hält Henrik GPT-4 für „wirklich schlecht" – seine Worte.„Die Geschwindigkeit in diesem Bereich ist ein bisschen absurd.“Und wir sprechen hier von keinem Geringeren als Henrik Kniberg – der Stimme hinter „Spotify Engineering Culture“, „Agile Product Ownership in a Nutshell“ und der Skateboard-Metapher für Produktentwicklung. Einem der erfahrensten Köpfe in der agilen Community. Aber ich denke, jeder von uns spürt es am eigenen Leib. KI verändert Softwareentwicklung grundlegend. Schneller, als uns Agilisten manchmal lieb ist.Brauchen wir Scrum Teams also noch?Vielleicht dringender denn je – denn je mächtiger das Werkzeug, desto lauter wird eine andere Frage. Eine, die längst in Gerichtssälen angekommen ist.Wer haftet für Aussagen von KI-Chatbots?Am Oberlandesgericht Hamm ging es kürzlich um den Chatbot einer Klinik.Patienten nahmen online Kontakt auf, um Termine zu buchen oder Fragen zu stellen. Der Bot antwortete dabei, die Ärzte seien „Fachärzte für plastische und ästhetische Chirurgie" und „Fachärzte für ästhetische Medizin“ – was nicht zutraf. Laut Website bieten Dr. Rick und Dr. Nick lediglich ästhetische Gesichtsbehandlungen an. Die Auskunft des Bots konnte Patienten also in die Irre führen und damit greift das Verbot irreführender Geschäftspraktiken.Die maßgebliche Vorschrift lautet:„Unlauter handelt, wer eine irreführende geschäftliche Handlung vornimmt, die geeignet ist, den Verbraucher oder sonstigen Marktteilnehmer zu einer geschäftlichen Entscheidung zu veranlassen, die er andernfalls nicht getroffen hätte.“Die Antworten des Chatbots konnten die Entscheidung von Patienten beeinflussen, weil sie ein falsches Bild über Qualifikation und Status der behandelnden Ärzte vermittelten.Das Gericht urteilte daraufhin, dass ein KI-Chatbot kein eigenständiger Dritter ist, sondern ein Werkzeug des Unternehmens. Seine Aussagen werden dem Betreiber unmittelbar zugerechnet, und zwar unabhängig davon, ob die KI „halluziniert" oder korrekte Eingangsdaten falsch verarbeitet. Deshalb sehen die Richter den Betreiber des Bots in der Verantwortung. Das letzte Wort ist in diesem Fall noch nicht gesprochen. Aber die Richtung ist klar genug, um auch Scrum Teams hellhörig zu machen. Denn bei aller Euphorie über KI, Effizienzgewinne und schnellere Entwicklung stellt sich eine unbequeme Frage:Wenn KI Teile unseres Produkts erzeugt, wer übernimmt dann Verantwortung für das, was ausgeliefert wird?Verantwortung lässt sich nicht an KI delegierenHaftet der Unternehmer für das Produkt? Welche Verantwortung tragen die Entwickler, die den Code geschrieben haben? Welche Verantwortung tragen Product Owner, die diese Features in Auftrag gegeben haben?Die Antwort ist nicht neu – aber wir müssen uns erinnern.„Ein Computer kann niemals zur Verantwortung gezogen werden. Deshalb darf ein Computer niemals eine Managemententscheidung treffen.“Mir gefällt wie es im IBM Training Manual bereits 1979 formuliert wurde. Verantwortung bedeutet demnach mehr als Haftung oder Compliance. Es geht darum, dass Menschen bewusst entscheiden, welche Arbeit sie an KI abgeben und welche Prüfung sie trotzdem selbst übernehmen.Also Verantwortung für unser Handeln zu übernehmen, auch wenn sich die Situation ändert.Linux zeigt: KI darf helfen, aber Menschen haftenDie Entwicklung des Linux-Kernels führt den Gedanken von IBM heute fort. In den Richtlinien für KI-Coding-Assistenten steht:„Nur Menschen können den Developer Certificate of Origin (DCO) rechtlich bestätigen. Die einreichende Person ist verantwortlich dafür:allen KI-generierten Code zu prüfen,die Einhaltung der Lizenzanforderungen sicherzustellen,den eigenen Signed-off-by-Tag hinzuzufügen, um den DCO zu bestätigen,die volle Verantwortung für den Beitrag zu übernehmen.“In der Entwicklung von Linux ist KI also nur ein weiteres Werkzeug. Denn wer schlechten Code einreicht, wird die Dokumentation ohnehin nicht lesen. Deshalb sollte sich die Kernel-Entwicklung darauf konzentrieren, menschliche Entwickler zur Verantwortung zu ziehen, statt ihre KI-Helferlein zu kontrollieren.Also nicht das Werkzeug wird zur Verantwortung gezogen, sondern der Mensch, der den Code einreicht. Wollen wir KI ethisch vertretbar nutzen, dann darf KI menschliche Arbeit verstärken. Sie darf Vorschläge machen, Code schreiben, Dokumentation strukturieren und Entscheidungen vorbereiten. Aber sie darf nicht an die Stelle menschlicher Verantwortung treten.Von IBM 1979 zu Linux 2026: Die Technologie hat sich radikal verändert. Das Prinzip nicht. Werkzeuge können unterstützen.Verantwortung bleibt menschlich.Wie wird Verantwortung in Scrum festgehalten?Was Richtlinien für den Entwicklungsprozess bei Linux sind, ist in Scrum die Definition of Done.„Die Definition of Done ist eine formale Beschreibung des Zustands des Increments, wenn es die für das Produkt erforderlichen Qualitätsmaßnahmen erfüllt. [...] Die Developer müssen sich an die Definition of Done halten.“Es handelt sich also um eine Verpflichtung der Entwickler, Verantwortung zu übernehmen.Mit dem Einsatz von KI ändert sich die Situation, und Scrum Teams sind gefordert, ihre Definition of Done anzupassen. Hier einige Beispiele, die ich bei Teams gesehen habe, die ich in den letzten Monaten unterstützt habe.KI-Ergebnisse werden stichprobenartig auf Halluzinationen getestet.Werden Falschaussagen des Bots gemeldet, wird ein definierter Fallback-Prozess strikt umgesetzt.Rechtlich kritische Aussagen (Qualifikationen, Preise, medizinische Infos) sind für den Chatbot explizit gesperrt, und dies wird wöchentlich durch Menschen geprüft.Ein Logging-Mechanismus ist aktiv, damit fehlerhafte Outputs nachvollziehbar sind.Allerdings ist KI nicht deterministisch. Ein Restrisiko bleibt immer.
Solche Praxis-Beispiele und weitere KI-Playbooks für Scrum Teams teile ich wöchentlich auch auf meinem Substack-Newletter „Scrum mit KI".KI ist ein mächtiges Werkzeug, aber kein FreifahrtscheinKI wird nicht automatisch gefährlich, nur weil sie mächtig ist.Sie ist gefährlich, wenn wir ihr zu viel Spielraum geben, ohne vorher Vertrauen aufgebaut zu haben. Henrik Kniberg hat diesen Zusammenhang in einem Bild veranschaulicht, das passenderweise die Überschrift aus Spider-Man trägt.
Image
Wir unterscheiden zwei Achsen:Wie breit ist der Aufgabenbereich?Und wie viel Zugriff auf Tools und Daten bekommt die KI?Oben rechts liegt der größere Hebel. Dort kann ein KI-Agent komplexe Aufgaben übernehmen, mehrere Tools nutzen, Daten verbinden und eigenständig nächste Schritte vorbereiten. Der mögliche Nutzen ist deutlich höher.Aber auch das Risiko.Somit ist der Einsatz von KI auch immer ein Kompromiss. Ein Kompromiss zwischen Effizienz und Risiken.Und genau dieser Kompromiss wird in der Diskussion etwa über KI-unterstütztes Programmieren gerne übersehen:Entwickler schreiben den Code manuell, ohne KI-Hilfe.KI schlägt Code vor. Der Entwickler bekommt Ideen daraus, schreibt ihn aber manuell.KI schreibt den Code. Der Entwickler liest ihn und passt ihn an.KI schreibt den Code. Der Entwickler überfliegt ihn und macht einen Plausibilitätscheck.KI schreibt den Code. Der Entwickler schaut ihn sich nicht einmal an.Ziel ist es nicht, Stufe 5 zu erreichen. Es geht darum, ein Urteilsvermögen zu entwickeln, um die verantwortungsbewusste Stufe für das Problem zu wählen.Was für jeden einzelnen Entwickler gilt, beschreibt Microsoft als organisatorische Konsequenz: Wenn Agenten mehr Arbeit ausführen, müssen Unternehmen bessere Systeme bauen, um diese Arbeit zu bewerten, zu steuern und daraus zu lernen.Für Scrum Teams heißt das:Eine KI-sichere Definition of Done beschreibt deshalb nicht einfach, dass ein Team KI nutzt. Sie legt fest, welche KI-Ergebnisse vor der Auslieferung menschlich geprüft, begrenzt, dokumentiert und verantwortet werden müssen. Denn am Ende liefert nicht die KI eine neue Version des Produkts aus.Das Scrum Team tut es.