Artikel

Scrum wurde für das durchschnittliche Team entwickelt. Es ist an der Zeit, höhere Ziele anzustreben.

Scrum hat eine solide Grundlage geschaffen, doch die künstliche Intelligenz weckt hohe Erwartungen daran, was moderne Produktteams gemeinsam erreichen können.

Robbin Schuurman

Aktualisiert Oktober 15, 2026

12 Minuten

Scrum wurde für das durchschnittliche Team entwickelt. Es ist an der Zeit, höhere Ziele anzustreben.

Artikel 9 von 9 in dieser Reihe.

Die meisten Teams antworten auf die Frage, wie sie arbeiten, mit einer Variante von „Wir arbeiten nach Scrum“. Damit meinen sie in der Regel, dass sie eine Sprint-Planung, ein Daily Scrum, eine Sprint-Review und eine Retrospektive durchführen. Sie führen ein Product Backlog. Alle zwei Wochen liefern sie die Arbeit eines Sprints aus. Sie führen einige Rituale durch, die dem im Scrum Guide beschriebenen ähneln, und belassen es dabei.

Obwohl die meisten Teams noch nie echtes Professional Scrum erlebt haben, war dies für die meisten akzeptabel, da das Ziel (für viele Organisationen) lediglich darin bestand, Software vorhersehbarer bereitzustellen; und dieses Ziel wurde in vielen Fällen erreicht. Dreißig Jahre lang war es eine beachtliche Leistung, in jedem Sprint zuverlässig hochwertige, funktionsfähige Software bereitzustellen. Die meisten Teams erreichten im Laufe der Jahre Vorhersehbarkeit; die konsequente Auslieferung hochwertiger, funktionsfähiger Software blieb jedoch den meisten von ihnen verwehrt. Die Teams, denen beides gelang, bezeichneten dies zu Recht als Erfolg.

Die KI legt die Messlatte höher. Das Minimum reicht nicht mehr aus. Wie sieht es aus, wenn Teams nicht mehr nur den Durchschnitt anstreben, sondern höhere Ziele als die im Scrum Guide festgelegten verfolgen?

Dies ist der abschließende Artikel einer Reihe über die Zukunft der KI-gestützten Produktentwicklung. Im ersten Artikel habe ich eine vom Team selbst festgelegte Wertdefinition vorgeschlagen. Im zweiten habe ich dargelegt, dass sich die Verantwortlichkeit durch den Beitritt neuer Akteure zum Team eher konzentriert als auflöst. Im dritten habe ich die Verfeinerung als „Option Framing“ neu definiert. Im vierten Artikel habe ich die Messlatte für Inkremente höher gelegt, sodass nicht nur die Nutzbarkeit, sondern auch die Akzeptanz gefordert wird. Im fünften Artikel habe ich die Sprint-Review im Demo-Stil durch eine „Evidence Review“ ersetzt. Im sechsten Artikel habe ich die „Steuer auf implizites Wissen“ benannt, die KI-gestützte Teams zahlen, oft ohne es zu bemerken. Im siebten Artikel schlug ich den „Context Lake“ als neues Kernartefakt des Produktmanagements vor. Im achten Artikel argumentierte ich, dass Transparenz und die Scrum-Werte aktiv verteidigt werden müssen, wenn das aktivste Mitglied des Teams ein nachweislich voreingenommener Akteur ist. Dieser neunte Artikel führt die acht Fäden zusammen.

Dies ist ein visionärer Beitrag, kein prognostischer. Ich kann Ihnen nicht sagen, wie die Produktentwicklung in fünf Jahren aussehen wird. Ich kann Ihnen jedoch darlegen, wie sich die Produktentwicklung nach Ansicht einer Gruppe erfahrener Professional Scrum Trainer weiterentwickeln dürfte und warum Ihr Team in diesem Sprint mehr Spielraum hat, höhere Ziele anzustreben, als Sie wahrscheinlich glauben. Die vollständige Liste der Mitwirkenden der Präsenzveranstaltung in Amsterdam finden Sie am Ende des Artikels. Die hier dargelegten Argumente stammen von mir. Die Überlegungen stammen von uns.

Im Scrum Guide wurde schon immer darauf hingewiesen, dass dies die Mindestanforderung ist

Der Scrum Guide 2020 enthält einen Satz, den die meisten Praktiker gelesen und übergangen haben, ohne ihn wirklich zu verinnerlichen:

„Das Scrum-Rahmenwerk ist bewusst unvollständig und definiert lediglich die Teile, die zur Umsetzung der Scrum-Theorie erforderlich sind.“

Zielgerichtet. Unvollständig. Das sind tragende Begriffe. Der Leitfaden war von Anfang an als Grundlage konzipiert. Als Minimum. Als eine Reihe erforderlicher Bestandteile, nicht mehr. Von den Teams wurde stets erwartet, dass sie darauf aufbauend ihre eigenen Praktiken, Disziplinen und Rituale hinzufügen. Im Laufe der Jahre haben viele auf „die Mängel von Scrum“ hingewiesen, mit Kritikpunkten wie „es geht nicht einmal auf das Produktmanagement ein“ oder „es berücksichtigt weder kontinuierliche Integration noch kontinuierliche Bereitstellung“. Diese Kritikpunkte sind berechtigt, doch Scrum war auch nie gegen irgendetwas davon. Tatsächlich glaube ich, dass alle meine Kollegen unter den Professional Scrum Trainern die Teilnehmer stets dazu ermutigt haben, über den Scrum Guide hinauszugehen.

Machen Sie also keinen Fehler: Der Leitfaden hat hier richtig gelegen. Ein Rahmenwerk, das versucht, jede Branche, jedes Produkt und jedes Team abzudecken, musste zwangsläufig minimalistisch bleiben. Das Problem liegt nicht im Dokument. Das Problem ist, dass die Community über dreißig Jahre hinweg das Minimum häufig als Maximum betrachtet hat. „Wir machen Scrum“ wurde eher zu einer Konformitätserklärung als zu einem Ziel.

Warum der Boden bisher (schon) Herausforderung genug war

Während des größten Teils der Geschichte dieses Frameworks stellte die Mindestanforderung bereits eine ausreichende Herausforderung dar, da es schwierig war, sie zu erreichen. Teams, die zuverlässig funktionierende, qualitativ hochwertige und benutzerfreundliche Software im Sprint-Rhythmus lieferten, ohne dabei zusammenzubrechen, waren wirklich selten und wertvoll. Das Erreichen dieser Mindestanforderung stellte einen Wettbewerbsvorteil dar.

Die KI hat es innerhalb von zwei Jahren dazu gebracht, dass das Erreichen des Mindeststandards zum Kinderspiel geworden ist. Ein KI-unterstütztes Team kann einen Sprint-Rhythmus einhalten, eine „Definition of Done“ erfüllen und ein nutzbares Inkrement ausliefern – und das mit weniger Aufwand, Fachwissen und handwerklichem Können, als es früher professionelle Teams auszeichnete. Das ist eine gute Nachricht, und es ist ein Problem. Eine gute Nachricht, weil nun mehr Teams die Mindestanforderungen erfüllen können. Ein Problem, weil das Erreichen dieser Mindestanforderungen kein Signal mehr für etwas Bedeutendes ist.

Die Teams, die sich in den nächsten fünf Jahren deutlich absetzen werden, sind diejenigen, die den Leitfaden nicht mehr als Zielvorstellung, sondern als Ausgangsbasis betrachten. Die Teams, die dies nicht tun, werden langsamer statt schneller werden, da ihre Mitarbeiter ihrer Praxis vorauslaufen.

Wie „höhere Ziele anstreben“ konkret aussieht

Die acht vorangegangenen Artikel vermitteln in ihrer Gesamtheit ein Bild davon, wie es aussieht, wenn man höhere Ziele anstrebt. Kein neues Rahmenwerk. Keine Neufassung. Eine Reihe konkreter, aufeinander aufbauender Vorgehensweisen, die über die Mindestanforderungen des Scrum-Leitfadens hinausgehen.

Eine Definition des Begriffs „Wert“ an der Wand (Artikel 1). Wird in einem Leitbild nicht implizit belassen. Es wird ausdrücklich formuliert, ist messbar, wird diskutiert und regelmäßig überprüft. Die Antwort des Teams auf die Frage, was bei diesem Produkt als Wert gilt.

Der Verantwortlichkeitstest, der für jedes von einem Agenten erstellte Artefakt durchgeführt wird (Artikel 2). Erklären, verteidigen, überarbeiten. Eine namentlich benannte Person trägt die Verantwortung für das Ergebnis. Die drei Scrum-Verantwortlichkeiten werden durch KI geschärft, nicht verwässert.

Der Optionsrahmen in jeder Verfeinerung (Artikel 3). Ergebnis, Optionen, Wette, Beweise. Die Verfeinerung ist nicht mehr eine Aufgabenzerlegung, sondern wird zur Gestaltung der Wette. Agenten generieren die Optionen; Menschen legen das Ergebnis fest und schließen die Wette ab.

Der Übergang von „nutzbar“ zu „genutzt und übernommen“ (Artikel 4). Eine Verbesserung gilt erst dann als umgesetzt, wenn eine bestimmte Zielgruppe sie innerhalb eines festgelegten Feedback-Zeitraums für den vorgesehenen Zweck genutzt hat. „Nutzbar“ reicht nicht mehr aus. „Genutzt“ und „übernommen“ sind die neuen Maßstäbe für die Umsetzung.

Die Überprüfung der Beweislage, die an die Stelle der Demonstration tritt (Artikel 5). Vier Fragen: Worauf haben wir gesetzt, was haben wir auf den Markt gebracht, wie haben die Nutzer damit umgegangen, und worauf setzen wir als Nächstes? Eine Arbeitssitzung, die Entscheidungen hervorbringt – und keinen Applaus.

Die „Steuer auf implizites Wissen“ – deren Höhe festgelegt und gegen deren Auswirkungen geschützt wurde (Artikel 6). Arbeitszeiten ausschließlich für Menschen. Lehrlingsausbildungsordnung. Die bewusste Weigerung, die hohen Abgaben an Vermittler abzugeben. Das Team behält sich die Möglichkeit zum Lernen vor.

Der Context Lake als zentrales Artefakt des Produktmanagements (Artikel 7). Der kuratierte, nachvollziehbare und durchsuchbare Ort, an dem die Ausrichtung, die Vorgaben und die Erkenntnisse für jeden Menschen und jeden Mitarbeiter im Team gebündelt sind. Die weiterentwickelte „Product Wall“ für ein Team, dessen Mitarbeiter im selben Raum arbeiten.

Transparenz und das Vermittlerprofil (Artikel 8). Die Ausrichtung, die Entscheidungen und der Akteur selbst wurden alle transparent gemacht. Bekannte Voreingenommenheiten wurden dokumentiert. Die fünf Scrum-Werte wurden erneut durchgesehen, präzisiert und aktiv verteidigt, während ein voreingenommener Teamkollege im Raum anwesend war.

Hängen Sie alle acht an die Wand des Teams, sodass sie bei jedem Sprint gut sichtbar sind, und diese Vorgehensweise unterscheidet sich grundlegend von einem rein zeremoniellen Scrum. Genau darum geht es.

Was dies für die drei Rechenschaftspflichten bedeutet

Die Aufgaben des Product Owners verändern sich erheblich. Befreit von der Aufgabe, Backlog-Details zu optimieren und die Auslastung zu überwachen, hat der Product Owner endlich den Spielraum, die Arbeit zu leisten, für die diese Rolle ursprünglich vorgesehen war: die Wertmaximierung. Der Schwerpunkt der Tätigkeit verlagert sich von der operativen Umsetzung hin zu strategischem Denken, einem tiefgreifenden Verständnis der Probleme und der Nutzer sowie dem Kontextmanagement. Dies ist eine anspruchsvollere, exponiertere und folgenreichere Aufgabe als die, die die meisten Product Owner heute ausüben; und es ist auch die Aufgabe, die es wert ist, wahrgenommen zu werden.

Die Aufgabe des Scrum Masters verändert sich in ihrer Art, nicht in ihrem Ausmaß. Gleiche Verantwortlichkeit, gleiche Teameffektivität – jedoch mit einem breiteren Spektrum an Handlungsmöglichkeiten. Der Scrum Master schützt den „Option Frame“, die „Evidence Review“, die Disziplin der „Tacit Knowledge Tax“, die ausschließlich von Menschen geleisteten Arbeitsstunden, den „Context Lake“ sowie die Transparenzpraktiken, die die Säulen am Leben erhalten. Effektivität ist in einer von KI geprägten Welt nicht dasselbe wie Effizienz. Der Scrum Master ist die Person, die diesen Unterschied bewahrt. Ich gehe zudem davon aus, dass sich die Rolle des Scrum Masters im Laufe der Zeit eher in Richtung eines „Performance-Coaches“ als in Richtung eines „Prozessmeisters“ verlagern könnte.

Die Arbeit der Entwickler verändert sich. Weniger Tippen. Mehr Urteilsvermögen. Mehr Erarbeitung von Optionen. Mehr Evidenzgestaltung. Der „Accountability-Test“ – Erklären, Verteidigen, Überarbeiten – wird zu einem persönlichen Maßstab, nicht nur zu einem teaminternen. Entwickler, die alle drei Aufgaben in einem KI-gestützten Kontext bewältigen können, werden die wertvollsten Fachkräfte des nächsten Jahrzehnts sein.

Was sich nicht ändert

Ich möchte dies ganz klar zum Ausdruck bringen, da im weiteren Verlauf dieser Serie für zahlreiche Veränderungen plädiert wurde. Die fünf Scrum-Werte – Mut, Fokus, Engagement, Respekt und Offenheit – sind nicht verhandelbar, nicht überholt und stehen nicht zur Überarbeitung an. Die Säulen Transparenz, Überprüfung und Anpassung bilden die empirische Grundlage, auf der alles in dieser Serie beruht. Selbstmanagement ist nichts, was durch KI überflüssig wird. Es ist etwas, dem die KI mehr Bedeutung verleiht.

Erhalten Sie die Artikel von Robbin Schuurman direkt in Ihren Posteingang:
. Melden Sie sich kostenlos bei Medium an, um Updates von diesem Autor zu erhalten.

Geben Sie Ihre E-Mail-Adresse ein:
Abonnieren

„Angemeldet bleiben“ für eine schnellere Anmeldung

Keine der acht oben genannten Praktiken funktioniert ohne die Werte und die Grundpfeiler, auf denen sie beruhen. Höhere Ziele anzustreben bedeutet nicht, Scrum aufzugeben. Es bedeutet vielmehr, Scrum endlich so einzusetzen, wie es ursprünglich vorgesehen war.

Die Rolle von Scrum.org und der Community

Ich möchte mich öffentlich bei Scrum.org dafür bedanken, dass diese Diskussion hier einen Platz gefunden hat. Die Präsenzveranstaltung in Amsterdam, aus der diese Reihe hervorgegangen ist, war eine Arbeitssitzung und kein Fototermin. Die Trainer diskutierten, waren unterschiedlicher Meinung, überarbeiteten ihre Ansätze und gingen mit mehr Fragen nach Hause, als sie mitgebracht hatten. So funktioniert eine Gemeinschaft, wie sie sein sollte.

Scrum.org hat bereits damit begonnen, Beiträge zu veröffentlichen, die höhere Ziele anstreben, darunter den kürzlich erschienenen Artikel über evidenzbasiertes Management im Zeitalter der KI. Ich gehe davon aus, dass weitere Beiträge dieser Art folgen werden. Ich hoffe, dass diese Reihe einen Beitrag dazu leistet.

Vier Dinge, die Sie in diesem Sprint tun können

Nicht vier neue Dinge. Dies ist der Abschluss dieser Serie. Ich möchte, dass Sie sich eine der acht Übungen aus den Artikeln 1 bis 8 aussuchen und damit beginnen.

Wählen Sie eine der acht Optionen aus. DoV, Verantwortlichkeitstest, Optionsrahmen, Einführungsinkrement, Evidenzprüfung, Steuer auf implizites Wissen, Kontextsee oder Transparenz und das Agentenprofil. Wählen Sie nicht zwei aus. Wählen Sie eines aus.
Hängen Sie es an die Wand. Im wahrsten Sinne des Wortes. Ausgedruckt. Sichtbar in Ihrem Teamraum oder oben auf Ihrem Sprint-Board angeheftet. Eine Vorgehensweise, die nur in einem Dokument existiert, existiert in Wirklichkeit gar nicht.
Führen Sie es in diesem Sprint einmal durch. Nicht ganz. Einmal. Besprechen Sie dies in Ihrer Retrospektive. Nehmen Sie Anpassungen vor.
Bewahren Sie es einen Monat lang auf. Eine Vorgehensweise, die Sie über vier Sprints hinweg konsequent umsetzen, wird die Zusammensetzung Ihres Teams stärker verändern als acht Vorgehensweisen, die Sie einführen und wieder aufgeben.

Abschließende Überlegungen

Ich habe diese Serie verfasst, weil ich davon überzeugt bin, dass wir uns am entscheidenden Wendepunkt in der Geschichte der professionellen Produktarbeit befinden. Dreißig Jahre lang war die Bereitstellung der Engpass. Diese Ära neigt sich dem Ende zu. Der Engpass verlagert sich nun auf Urteilsvermögen, Wertschöpfung und Lernen. Der Scrum Guide bot der Community eine solide Grundlage, auf der sie herausfinden konnte, wie man zuverlässig liefert. Nun hat die Community die Chance, auf dieser Grundlage etwas weitaus Ehrgeizigeres aufzubauen.

Ich behaupte nicht, dass Scrum versagt hat. Ich behaupte das Gegenteil. Das Framework wird endlich für das eingesetzt, wofür es ursprünglich konzipiert wurde: die kontinuierliche Schaffung wertvoller, nützlicher und akzeptierter Produktergebnisse durch selbstorganisierte Teams, die in jedem Sprint dazulernen.

Nun sind Sie an der Reihe

Wählen Sie eine Übung aus dieser Reihe aus. Wenden Sie sie einen Monat lang an. Berichten Sie mir, was passiert ist. Wenn es funktioniert hat, möchte ich davon erfahren. Wenn nicht, möchte ich es erst recht erfahren. Die Beiträge in dieser Reihe bilden den Abschluss meines Teils des Dialogs. Der nächste Sprint Ihres Teams entscheidet darüber, ob die Idee Bestand hat oder scheitert.

Vielen Dank für Ihre Aufmerksamkeit. Mein besonderer Dank gilt vor allem den unten genannten Personen, deren Ideen dies ermöglicht haben.

Mitwirkende

Dieser Artikel sowie die gesamte Artikelserie basieren auf 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