Artikel

Sie können die Verantwortung nicht an einen Beauftragten delegieren

Künstliche Intelligenz kann Entscheidungsprozesse unterstützen und die Arbeit beschleunigen, doch die Verantwortung für die Ergebnisse liegt nach wie vor bei den Menschen und den Teams.

Robbin Schuurman

Aktualisiert Oktober 15, 2026

10 Minuten

Die Zukunft der KI-gestützten Produktentwicklung

Artikel 2 von 9 in dieser Reihe.

Derzeit tauchen in Produktteams zunehmend drei Sätze auf: „Der Agent hat sich darum gekümmert.“ „Copilot verwaltet nun unser Backlog.“ „Der Programmier-Agent hat es veröffentlicht.“ Sie klingen modern, effizient und zukunftsorientiert. Tatsächlich handelt es sich dabei jedoch um eine Verwässerung der Verantwortlichkeit, die mit neuen Begriffen verschleiert wird.

Im ersten Artikel dieser Reihe habe ich dargelegt, dass der Product Owner zum ersten Mal in der dreißigjährigen Geschichte von Scrum die Zeit haben wird, die im Scrum Guide beschriebene Aufgabe zu erfüllen. Ich spreche hier nicht vom Backlog-Management, sondern von echter Wertmaximierung. Auch wenn KI-Agenten immer mehr Aufgaben übernehmen, verlieren die drei Verantwortungsbereiche in Scrum nicht an Bedeutung. Sie werden vielmehr präziser, folgenreicher und stehen stärker im Fokus. Wer ist für das verantwortlich, was der Agent gerade getan hat?

Dies ist ein visionärer Beitrag, kein prognostischer. Ich kann Ihnen nicht genau sagen, wie sich die Rechenschaftspflicht in den nächsten fünf Jahren entwickeln wird. Ich kann Ihnen jedoch darlegen, wie sich eine Gruppe erfahrener Professional Scrum Trainer diese Entwicklung vorstellt und warum diese Antwort für Ihr Team in diesem Sprint von Bedeutung ist. Die vollständige Liste der Mitwirkenden der Präsenzveranstaltung in Amsterdam finden Sie am Ende des Artikels.

Der Scrum Guide hat dies im Jahr 2020 richtig erkannt

Der Scrum Guide ist in einem Punkt ungewöhnlich klar und hat sich bemerkenswert gut bewährt. Er nennt drei Verantwortungsbereiche: den Product Owner, den Scrum Master und die Entwickler. Drei Verantwortungsbereiche. Nicht drei Rollen. Nicht drei Berufsbezeichnungen. Verantwortungsbereiche.

Machen Sie keinen Fehler: Die Wortwahl war bewusst, sorgfältig und – im Nachhinein betrachtet – zukunftsorientiert. Im Scrum Guide wurde stets betont, dass jemand die Verantwortung für das Ergebnis übernehmen muss. KI ändert nichts an dieser Verpflichtung. KI erhöht jedoch den Einsatz, da KI-gestützte Teams weniger „die Kontrolle haben“ als wir es heute tun.

Verantwortung ist nicht dasselbe wie Rechenschaftspflicht

Verantwortung bezeichnet die Person, die eine Aufgabe ausführt. Rechenschaftspflicht bezeichnet die Person, die für das Ergebnis verantwortlich ist und sich dafür verantworten muss – sei es bei einem guten, einem schlechten oder einem angefochtenen Ergebnis. Diese Unterscheidung ist alt, langweilig und von entscheidender Bedeutung.

Ein Agent kann Verantwortung übernehmen. Er kann einen Eintrag im Product Backlog entwerfen, Akzeptanzkriterien verfeinern, Code erstellen oder die Release-Hinweise verfassen. All dies steht im Zusammenhang mit Verantwortung bzw. der Ausführung von Aufgaben. Was ein Agent jedoch nicht tun kann, ist, bei einer Sprint-Review zu stehen und die hinter der Arbeit stehende Ermessensentscheidung zu verteidigen, vor einem Kunden zu stehen, dessen Vertrauen erschüttert wurde, oder vor einem Prüfer zu stehen, dessen Frage zur Compliance gerade gestellt wurde. Das sind Momente der Rechenschaftspflicht. Sie erfordern jedes Mal eine namentlich benannte Person.

Die drei Verantwortlichkeiten – eine Neuinterpretation für eine von KI geprägte Welt

Die drei Scrum-Verantwortlichkeiten kommen klar zum Ausdruck, wenn man sie gemeinsam mit den Agenten im Raum noch einmal durchliest.

Produktverantwortlicher, verantwortlich für den Wert des Produkts. Ein Mitarbeiter kann Elemente entwerfen, Varianten erstellen und diese anhand einer Wertdefinition bewerten (Artikel 1 dieser Reihe). Nur der Product Owner ist dafür verantwortlich, dass das Produkt einen echten, akzeptierten und nachgewiesenen Wert schafft. Dies erfordert ein tiefes Verständnis und Einfühlungsvermögen gegenüber Kunden und Nutzern. Dabei geht es darum, sicherzustellen, dass das Produkt keine (un)ethischen Grenzen überschreitet.

Scrum Master, verantwortlich für die Effektivität des Teams. Ein Agent kann rückblickende Analysen durchführen, Stimmungen zusammenfassen und Muster kennzeichnen. Allein der Scrum Master trägt die Verantwortung dafür, dass das Team (einschließlich seiner KI-Agenten) im Laufe der Zeit besser, stärker und leistungsfähiger wird. Dass es innerhalb (ethischer) Grenzen arbeitet – mit Mut, Engagement, Offenheit, Konzentration und Respekt.

Entwickler, die für das Inkrement verantwortlich sind. Ein Agent kann Code schreiben, Testgerüste erstellen und Dokumentation generieren. Ausschließlich die Entwickler sind dafür verantwortlich, dass das Sprint-Inkrement den vereinbarten Qualitätsstandards entspricht, skalierbar und wartbar aufgebaut ist und die Freigabe rechtfertigt.

Lesen Sie den Text noch einmal sorgfältig durch: Diese Verantwortlichkeiten nehmen in einer von KI geprägten Welt nicht ab. Sie konzentrieren sich vielmehr. Die Menschen, die diese Verantwortlichkeiten tragen, werden nicht ersetzt. An sie werden höhere Anforderungen hinsichtlich Urteilsvermögen, Rechenschaftspflicht und Eigenverantwortung gestellt.

Eine Teamform, die durch diese Konzentration plausibel wird, ist erwähnenswert. Es ist durchaus realistisch, davon auszugehen, dass es in den nächsten fünf Jahren Teams geben wird, die aus mehreren Produktmanagern und einem einzigen Entwickler bestehen und von einer Gruppe spezialisierter Agenten unterstützt werden – anstelle des heute üblichen Teams mit drei bis neun Entwicklern. Das ist kein Argument gegen Entwickler. Es ist vielmehr ein Argument dafür, dass die Verantwortung dafür, was entwickelt wird und ob dadurch Wert geschaffen wird, zunehmend zu einer Aufgabe wird, die sich nach der Anzahl der Mitarbeiter richtet, während die Arbeit an der Erstellung des Inkrements zunehmend zu einer Aufgabe wird, die sich nach der Anzahl der Agenten richtet. Teams, die ihre Struktur unter Berücksichtigung dieser Tatsache neu gestalten, werden anders aussehen als Teams, die dies nicht tun.

Der Rechenschaftstest

Hängen Sie einen kurzen Test an die Wand, neben die Definition von Wert aus dem ersten Artikel. Stellen Sie zu jedem von einem Akteur geschaffenen Artefakt drei Fragen.

Erläutern Sie dies bitte. Kann ein namentlich genannter Mitarbeiter des Teams erläutern, was der Mitarbeiter erstellt hat und warum?
Verteidigen. Kann diese Person die Entscheidung gegenüber einem Kunden, einem Prüfer oder einem Kollegen, der anderer Meinung ist, begründen?
Wiederholen. Kann diese Person die Arbeit erneut erledigen, falls der Mitarbeiter morgen nicht mehr zur Verfügung steht?

Sollte eine der Antworten „Nein“ lauten, geht die Verantwortlichkeit verloren. Die Arbeit wird zwar erledigt, doch die Eigenverantwortung fehlt. In dieser Lücke versagen Vertrauen, Qualität und die Einhaltung von Vorschriften still und leise.

„Die KI war es“ – das wird nicht funktionieren

Ich möchte ganz offen auf ein Muster eingehen, das mir zunehmend auffällt. Führungskräfte und gelegentlich auch Product Owner beginnen, KI als Ausrede zu nutzen. Der Satz „Die KI war es“ schleicht sich zunehmend in die Auswertung von Vorfällen, in Kundenbeschwerden und in Gespräche mit Lieferanten ein.

Rechtlich gesehen ist dies nicht haltbar. Sowohl das NIST-Rahmenwerk für das Risikomanagement im Bereich der KI als auch das EU-KI-Gesetz verankern die menschliche Verantwortlichkeit als unverhandelbare Anforderung. Auch aus ethischer Sicht ist dies nicht haltbar. Ein Akteur ist ein Werkzeug. Ein Hammer verfehlt den Nagel nicht. Eine Person, die einen Hammer schwingt, tut dies jedoch.

Und gegenüber Kunden zieht diese Argumentation absolut nicht. Ein Kunde, dessen Daten offengelegt wurden, der Geld verloren hat oder dessen Vertrauen erschüttert wurde, möchte nicht hören, dass ein Mitarbeiter den Fall bearbeitet hat. Er möchte hören, dass ein Mensch aus Ihrem Team die Verantwortung für das Geschehene übernimmt und Abhilfe schaffen wird.

Wie dies in der Praxis aussieht

Stellen Sie sich ein SaaS-Team vor, das einen Agenten einsetzt, um aus Kundenfeedback Elemente für das Product Backlog zu generieren. Der Agent erstellt ein gut formuliertes Element zu Zugriffskontrollen für eine neue Unternehmensstufe. Der Eintrag erfüllt die „Definition of Done“ des Teams. Die Arbeit wird ausgeliefert. Drei Wochen später stellt ein potenzieller Kunde in einem Beschaffungsgespräch eine direkte Frage: Warum haben Sie sich dafür entschieden, ein bestimmtes Berechtigungsmuster zuzulassen? Niemand im Team kann diese Frage beantworten. Der Agent hat diese Entscheidung getroffen. Kein Mensch hat diese Entscheidung jemals wirklich verstanden.

Das Team verliert den Auftrag. Noch wichtiger ist jedoch, dass es den Faden verliert.

Im folgenden Sprint führen sie den Verantwortlichkeitstest für jedes vom Agenten erstellte Artefakt durch, bevor dieses in einen Sprint aufgenommen wird. Ein Entwickler erläutert das Element, begründet die Designentscheidung und bestätigt, dass er es auch ohne den Agenten erneut erstellen könnte. Der Product Owner bestätigt die Wertannahme. Der Scrum Master weist bei der Retrospektive darauf hin, dass sich das Team zu sehr daran gewöhnt hatte, die Entscheidung dem Agenten zu überlassen. Die Verfeinerung verlangsamt sich um etwa zehn Minuten pro Element. Das Vertrauen der Kunden steigt wieder an, und der Geschäftszyklus folgt diesem Trend.

Das ist der Unterschied, den die Rechenschaftspflicht ausmacht.

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

Kennzeichnen Sie jedes von einem Agenten erstellte Artefakt mit dem dafür verantwortlichen Mitarbeiter. Posten, Codeänderung, Test, Dokumentation. Wenn ein Sachbearbeiter dies erstellt hat, muss eine namentlich genannte Person dies abzeichnen. Einfach, transparent und überraschend schwer zu widerlegen.
Lesen Sie die drei Verantwortungsbereiche als Team noch einmal gemeinsam durch, wobei AI im Raum anwesend ist. Nehmen Sie sich bei Ihrer nächsten Retrospektive zwanzig Minuten Zeit. Gehen Sie jeden Verantwortungsbereich durch. Fragen Sie: Wo übernimmt der Akteur Verantwortung, und wo trägt der Mensch noch die Verantwortung? Die Lücken werden deutlich.
Wenden Sie den Verantwortlichkeitstest auf einen aktuellen, von einem Agenten erstellten Beitrag an. Wählen Sie ein Element aus dem Product Backlog, eine Codeänderung oder eine mit Unterstützung eines Agenten erstellte Versionsnotiz aus. Führen Sie die Schritte „Erklären“, „Verteidigen“ und „Wiederholen“ durch. Sie werden wahrscheinlich ein oder zwei Stellen finden, an denen kein Mensch alle drei Schritte vollständig ausführen kann. Optimieren Sie diese Stellen als Erstes.
Erstellen Sie eine Rollback-Richtlinie und legen Sie die Sicherheitsvorkehrungen fest. Wenn die Arbeit eines Agenten hinsichtlich des Nutzens, der Effektivität oder der Qualität des Inkrements versagt, wer entscheidet dann über deren Einstellung? Wer informiert die Kunden? Wer dokumentiert die gewonnenen Erkenntnisse? Legen Sie die zuständigen Personen im Voraus fest. Warten Sie nicht, bis sich ein Vorfall ereignet hat, um sie zu ermitteln. Und wenn es sich um einen Agenten handelt, der sein eigenes Verhalten im Laufe der Zeit anpassen kann, benötigt die Rollback-Richtlinie des Teams eine Ergänzung: eine Reihe expliziter Leitplanken, die in regelmäßigen Abständen überprüft werden und den Rahmen definieren, innerhalb dessen der Agent autonom agieren darf, sowie die Punkte, an denen ein Mensch seine Zustimmung erteilen muss, bevor er fortfahren darf. Selbstoptimierende Systeme ohne Leitplanken stellen keinen Effizienzgewinn dar. Sie sind ein Governance-Vorfall, der nur darauf wartet, sich zu ereignen.

Die Wende

Seit Jahren dreht sich die vorherrschende Erzählung über KI in der Produktentwicklung um den Ersatz menschlicher Arbeitskraft. Agenten werden das Backlog bearbeiten. Agenten werden den Code schreiben. Agenten werden die Überprüfung übernehmen. Ich glaube nicht an diese Erzählung, und ebenso wenig glaubt daran die Gruppe, die mehrere Tage lang in Amsterdam darüber diskutiert hat.

Genauer gesagt geht es um Konzentration. Da die Agenten einen größeren Teil der Ausführung übernehmen, verteilt sich die Verantwortlichkeit nicht. Sie konzentriert sich auf eine geringere Anzahl menschlicher Entscheidungsinstanzen. Die drei Verantwortungsbereiche in Scrum sind genau diese Entscheidungsinstanzen. In einer von KI geprägten Welt sind sie die prägnantesten, exponiertesten und unverzichtbarsten Bestandteile des Betriebsmodells des Teams.

Nun sind Sie an der Reihe

Denken Sie an das letzte von einem Agenten erstellte Artefakt, das Ihr Team ausgeliefert hat. Wer war dafür verantwortlich? Könnte diese Person den Verantwortlichkeitstest heute bestehen? Falls nicht, ist dies ein Thema, das Sie bei Ihrer nächsten Retrospektive ansprechen sollten.

Der nächste Artikel dieser Reihe befasst sich mit jenem Scrum-Event, bei dem die Verantwortung am häufigsten stillschweigend abgegeben wird: der Verfeinerung. Wenn ein Teammitglied in der Zeit, die zum Lesen eines einzigen Product-Backlog-Elements benötigt wird, fünf tragfähige Lösungen erarbeiten kann, ist die Verfeinerung keine Übung zur Aufgabenzerlegung mehr. Sie wird zu einer Übung zur Abgrenzung von Optionen. 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