Scrum Guide Expansion pack - deutsch

Der Scrum Guide bleibt die relevante Grundlage – warum diese Erweiterung trotzdem Gold wert

Das Scrum Guide Expansion Pack bringt Leben in den offiziellen Scrum Guide (2020): Es übersetzt das abstrakte und allgemein gültige Rahmenwerk in konkrete Praxis. Mit einer Fülle an erprobten Methoden, Tools und Beispielen hilft es dir, Scrum nicht nur zu verstehen – sondern erfolgreich anzuwenden.

Du erhältst Einblicke in bewährte Vorgehensweisen, typische Stolperfallen in Unternehmen und clevere Tipps, wie du Scrum Schritt für Schritt einführen und nachhaltig verankern kannst. Entwickelt wurde diese praxisnahe Erweiterung von einem Autorenteam rund um Dr. Jeff Sutherland, Mitbegründer von Scrum Inc – für alle, die Scrum wirksam nutzen wollen.

Inhalt Scrum Guide Extension Pack

• Hintergrund

• Sinn und Zweck des Scrum Guide Expansion Packs

• Scrum kurz zusammengefasst

  Unterstützende und ergänzende Theorie

• Komplexität – Das Argument für Scrum

• Emergence

• Self-Managing Scrum Team

• Professionalität

• Lean Thinking

• Empirie

• Kadenz
  

  Die drei Säulen von Scrum’s Empirical Process Control

• Transparenz

• Überprüfung

• Anpassung

  Die Scrum-Werte

  Weitere unterstützende und ergänzende Theorie

• Product Thinking

• Systems Thinking

• Discovery

• Leadership

• First Principles Thinking

• Menschen und Veränderung

  Die Scrum-Rollen im Expansion Pack

• Stakeholder

• Unterstützer

• Künstliche Intelligenz

• Product Developer

• Product Owner

• Scrum Master

  Die Scrum-Artefakte im Expansion Pack

• Produkt

• Commitment: Definition des Outcome Done

• Increment

• Commitment: Definition des Outputs Done

• Product Backlog

• Product Backlog Einträge

• Akzeptanzkriterien

• Outcome Kriterien

Scrum kurz zusammengefasst

Scrum ist ein Rahmenwerk zur Lieferung von komplexen Produkten (30–35), bei dem Fachwissen zwar wichtig, aber nicht ausreichend ist, und Ursache-Wirkungsbeziehungen oft erst retrospektiv verständlich sind. Scrum adressiert den vollständigen Produktlebenszyklus, der (aber nicht ausschliesslich) das Erstellen, Ersetzen, Erhalten, Anpassen, kontinuierliche Verändern, Warten und Ausmustern von Produkten oder Funktionen umfasst. Scrum hilft Einzelpersonen, Teams und Organisationen, flexibel zu werden und zu bleiben und durch Anpassung an Veränderungen Wert zu schaffen.

Scrum fördert ein Umfeld, in dem die Bedürfnisse der Stakeholder verstanden und kohärent beantwortet werden können. Der iterative und inkrementelle Ansatz von Scrum reduziert Risiken und unterstützt kontinuierliche Verbesserung. Scrum hilft einem Team, ein Gleichgewicht zu finden zwischen dem Erkunden von Problemen, dem Erkennen der Bedürfnisse von Stakeholdern (einschliesslich, aber nicht beschränkt auf Kundschaft), der Entwicklung von Lösungen, dem proaktiven Risikomanagement und der Validierung von Wert. Ein Risiko ist jeder Faktor, der zu einer künftigen negativen Folge führen kann. Da die Risikobelastung auch im Zeitverlauf unvorhersehbar bleibt, ist Antizipation entscheidend. Risikobelastung kann (aber nicht ausschliesslich) Markt-, Problem-Lösungs-Fit, Produkt-Markt-Fit, Technologie, Signalerkennung, Reaktionsfähigkeit, Compliance, Behebung, schlechte Abwägungsentscheidungen usw. umfassen. Scrum unterstützt proaktives Risikomanagement und das Entdecken von Chancen.

Scrum ermutigt dazu, die bestehende Trennung zwischen Stakeholdern, die Probleme oder Chancen einbringen, und jenen, die sie lösen, zu verringern.

Kurzgefasst basiert Scrum auf einem Umfeld, in dem:

• unterstützende Stakeholder, nachfolgend Unterstützer genannt, das tun, was notwendig ist, um die Einführung von Scrum proaktiv zu unterstützen und zu fördern – geleitet und unterstützt vom Scrum Master

• ein Product Owner das Produktziel festlegt, entscheidend zur Realisierung von Stakeholder-Wert beiträgt

• das selbstorganisierte Scrum Team (47) die Arbeitsauswahl definiert, verfeinert und in wertvolle Ergebnisse umsetzt

• das Scrum Team und die Stakeholder die Ergebnisse während des Sprints überprüfen und anpassen

• Unterstützer dem Scrum Team helfen, erfolgreich zu sein

• Wiederholen

Ein Release ist der Prozess, eine neue oder aktualisierte Version eines Produkts für Stakeholder (einschliesslich, aber nicht beschränkt auf Kundschaft, Entscheidungsträger und Endnutzer) verfügbar zu machen. Es markiert einen Wendepunkt im Entwicklungszyklus und stellt den Übergang des Produkts von der Entwicklung zur Nutzung und zur möglichen Realisierung von Stakeholder-Wert dar.

Scrum ist absichtlich unvollständig. Anstatt detaillierte Prozesse vorzuschreiben, bietet es ein Rahmenwerk, das Beziehungen und zweckgerichtete Interaktionen leitet. Verschiedene Prozesse, Techniken und Methoden können Scrum ergänzen – ihre Anwendung hängt jedoch vom Kontext ab und variiert je nach Einsatz von Scrum.

Scrum integriert sich in bestehende Praktiken oder macht sie in manchen Fällen überflüssig oder obsolet. Durch transparente Bewertung der Effektivität von Scrum Team, Supportern, aktuellem Management, Arbeitsumfeld und Techniken ermöglicht Scrum kontinuierliche Verbesserung.

Im Kontext von Wissensarbeit wurde der Begriff Scrum, entlehnt aus dem Rugby, von Takeuchi und Nonaka (29) geprägt, um Teams zu beschreiben, die auf diese Weise arbeiteten, wobei Wissen sich schnell im gesamten Unternehmen verbreitete, um herausragende Produkte zu liefern.

Unterstützende und ergänzende Theorie

Scrum basiert auf einem selbstorganisierten Scrum Team (47), Emergenz, Empirie (67) und Lean Thinking (63). Es wird gestützt durch die nachfolgend ergänzende Theorie und Konzepte wie:

● Verantwortlichkeit,
● Reduktion von nicht wertschöpfendem Aufwand/Verschwendung (einschliesslich organisatorischer Ineffizienzen),
● Arbeit als Problem- oder Chancenrahmen,
● Entdeckung, Lieferung und Wertrealisierung, und
● kontinuierliche Verbesserung.

Komplexität – Die Begründung für Scrum
Bei komplexer Arbeit, wie der Entwicklung von Produkten, gibt es mehr Unbekanntes als Bekanntes. Fachwissen allein ist wertvoll, aber unzureichend, und Ursache und Wirkung sind nur rückblickend kohärent. Komplexitätsdenken (30–35) bietet wertvolle Werkzeuge und Ideen und ermöglicht Erkenntnisse. Die Mitglieder des Scrum Teams brauchen Zeit zum Nachdenken, um sich gegenseitig zu helfen, Nacharbeit zu leisten oder einen Richtungswechsel vorzunehmen. Kognitive Diversität und Empirie können helfen, mit komplexer Arbeit umzugehen.

Alles, was als „bekannt“ gilt – einschliesslich Markt und Stakeholder (einschliesslich, aber nicht beschränkt auf Kundschaft) – kann sich als falsch erweisen. Einige Erwartungen, Bedürfnisse oder Wünsche entstehen oder verlieren im Laufe der Zeit an Bedeutung oder Dringlichkeit. Ein empirischer Ansatz bietet Mechanismen zum Testen von Annahmen sowie zur Überprüfung und Anpassung.

Im Allgemeinen bleibt nichts für immer im gleichen Zustand. Das Scrum Team könnte sich am Rand des Chaos befinden, wenn es etwas noch nie Dagewesenes erforscht und bearbeitet. Mit der Zeit, wenn Muster und Heuristiken entdeckt werden, wird es weniger chaotisch und komplexer. Später kann sich das Scrum Team in Richtung eines geordneten Bereichs bewegen – etwas, das nicht einfach, aber planbar ist. Oder die Entwicklung kann sich umkehren. Es ist eine gute Praxis für das Scrum Team, innezuhalten und zu reflektieren, ob es sich in dem Bereich befindet, den es für die jeweilige Situation angenommen hat. Der entscheidende Punkt ist, dass Produktentwicklung oft mit Unvorhersehbarkeit verbunden ist – und Scrum kann ein nützlicherer Ansatz sein als andere, die sich einer trügerischen Planbarkeit hingeben.

Die Chancen, die durch Emergenz entstehen – durch Überprüfung und Anpassung des Wer, Warum, Was, Wie, Wo und Wann – sind zahlreich. Es ist wichtig, das, was nicht funktioniert, abzuschwächen und das, was funktioniert, zu verstärken. Transparenz, Überprüfung und Anpassung in Richtung gesetzter Ziele, informiert durch Ergebnis-Feedback (und unbeabsichtigte Folgen), schaffen Wert, Einsichten, Risiken und stellen Annahmen in Frage; das kann kontinuierliche Verbesserung fördern.

Vertrauen entsteht durch ein selbstverwaltendes Team, Überprüfung, Anpassung, das Liefern von wertvoller Arbeit und das Aufdecken neuer Erkenntnisse.

Emergenz (engl. emergence)
Von Emergenz (71) spricht man, wenn sinnvolle Muster oder Verhaltensweisen aus den Interaktionen innerhalb komplexer (30-35) Systeme entstehen - Muster, die man nicht vorhersagen kann, wenn man sich nur die Teile ansieht. In Scrum wird Emergenz nicht streng kontrolliert, sondern durch Rahmenbedingungen wie Timeboxes, Rollen und Feedbackschleifen gesteuert, die die Voraussetzungen für Selbstmanagement und Anpassungsfähigkeit schaffen, ohne genaue Ergebnisse vorzuschreiben. Diese Strukturen wirken wie „Inseln“ in einem Meer der Unvorhersehbarkeit, ähnlich wie physikalische Systeme spontan organisierte Muster inmitten des Zufalls bilden können, wie es in Stephen Wolframs Werk beschrieben wird (38). Der Schlüssel liegt darin, dass die Struktur von Scrum den Teams genügend Anleitung bietet, um sich selbst zu organisieren und neue Lösungen entstehen zu lassen, anstatt jedes Detail vorzuschreiben.

Scrum Teams, die als komplexe adaptive Systeme agieren, werden durch kurze, parallele, fehlersichere Experimente und kontinuierliches Feedback beeinflusst, nicht gelenkt. Muster (53, 54) wie Swarming, Stable Teams und Kaizen helfen dabei, emergentes Verhalten zu erkennen und zu gestalten. Anstatt Ergebnisse zu erzwingen, befähigt Scrum das Scrum Team, wünschenswerte Muster zu entdecken, einschliesslich, aber nicht beschränkt auf innovative Lösungen oder neue Arbeitsweisen, und diese zu verstärken, während nicht hilfreiche Muster reduziert werden.

Dieser Ansatz erkennt an, dass Selbstmanagement (47) nicht etwas ist, das von oben nach unten entworfen werden kann, sondern etwas, das in der richtigen Umgebung zu entdecken ist - einer Umgebung, die sich zielgerichtet, kohärent und lebendig anfühlt, in Anlehnung an Christopher Alexanders „Quality Without a Name“ (39). Letztendlich behandelt Scrum Emergenz nicht als ein Risiko, das es zu eliminieren gilt, sondern als eine Kraft, die es zu kultivieren gilt, um Spitzenleistungen in der Produktentwicklung zu erzielen.

Selbstorganisiertes Scrum Team
Ein selbstorganisiertes Scrum Team (47) prüft, ob es auf dem richtigen Weg ist. Wenn nicht, ergreift es Massnahmen. Es entscheidet, wie es arbeiten soll, und löst Konflikte und Probleme innerhalb des Scrum Teams. Das bedeutet, dass Manager (111), wenn sie Teil der Struktur sind, dem Scrum Team in der Regel nicht sagen, was es zu tun hat, oder entscheiden, welches Scrum Team Mitglied beiseite genommen werden muss, um Probleme zu lösen, direkt oder indirekt. Wenn es Manager gibt, ist es im Allgemeinen besser, wenn sie Leadership zeigen.

Selbstorganisierte Scrum Teams, die sich am Ziel der Wertschaffung orientieren, sind für die kreative Problemlösung und das Erfassen von Emergenz von entscheidender Bedeutung; Die Fähigkeit, mit Komplexität umzugehen, wird durch den Einsatz von nicht selbstorganisierten Scrum Teams behindert (30-35). Selbstorganisierte Scrum Teams (47) sind nicht zu verwechseln mit dem Selbstmanagement von Individuen. Es ist das reibungslose Zusammenspiel, das ein grossartiges Team entstehen lässt. Die Erleichterung der Teamautonomie sowie eine effizientere Entscheidungsfindung innerhalb einer nicht hierarchischen Struktur können Scrum Teams dabei helfen, ihr Selbstmanagement zu verbessern.

Professionalität
Professionalität bedeutet, nach Spitzenleistungen zu streben und zusammenzuarbeiten, um auf respektvolle, transparente und verantwortliche Weise Werte zu schaffen. Professionell zu sein bedeutet, dass man bestimmte Dinge immer tun wird und andere niemals, unabhängig von den Umständen.

Professionell zu sein bedeutet, die volle Verantwortung für das Produkt zu übernehmen, von der Wiege bis zur Bahre, während seines gesamten Lebenszyklus. Professionell zu sein bedeutet auch, das Produkt zu warten, oft in Form von Unterhalt, und den Product Developer ideale Möglichkeiten zu bieten, um aus den technischen Ergebnissen zu lernen.

In einem Softwareentwicklungskontext beinhaltet Professionalität technische Exzellenz, ist aber nicht darauf beschränkt (112). Technische Exzellenz umfasst u.a. Folgendes: Specification by Example, Clean Code, Unit Testing, Test-Driven Development, Testautomatisierung, Continuous Integration, Continuous Delivery, Architektur und Design, Acceptance Testing sowie die gezielte und bewusste Berücksichtigung von Tests.

Lean Thinking
Lean Thinking (63) reduziert die Verschwendung bei der Arbeit und der Art und Weise, wie sie ausgeführt wird, und konzentriert sich auf den Wertfluss und die kontinuierliche Verbesserung. Die Lean-Prinzipien beruhen auf kontinuierlicher Verbesserung und Respekt vor den Menschen. Durch die Konzentration auf die Lean-Prinzipien können Organisationen ihre Effektivität zu den niedrigsten langfristigen Kosten verbessern und den Kunden einen besseren Wert bieten, während sie gleichzeitig ein Klima des ständigen Lernens und der Entwicklung fördern.

Empirie
Empirie (67) ist der Grundsatz, Entscheidungen auf der Grundlage objektiver oder beobachtbarer Beweise in oft explorativen Lernzyklen zu treffen. Dies ist in Situationen nützlich, in denen mehr als nur Fachwissen gefragt ist. Scrum basiert auf Empirie. Entscheidungen werden auf der Grundlage von Beweisen oder Beobachtungen getroffen. Ein empirischer Ansatz umfasst fortlaufende Beobachtungen, die Entwicklung/Verfeinerung von Theorien, die Operationalisierung und das Testen/Modifizieren, um effektive Feedbackschleifen zu etablieren.

Empirie kann Scrum Teams dabei helfen, etwas zu liefern, das für die Stakeholder wertvoll ist, wenn das Was oder das Wie ungewiss ist. Bei Scrum geht es darum, das Unwahrscheinliche wahrscheinlich zu machen, indem man Werte entdeckt, liefert und realisiert; dies schliesst oft Kompromisse oder Experimente ein.. Experimente beruhen in der Regel auf überprüfbaren Hypothesen, manchmal aber auch auf fundierten Vermutungen. Eine wichtige Reaktion auf Experimente ist die faktengestützte Entscheidungsfindung.

Innehalten und Reflektieren verbinden Elemente der Empirie und des Lean Thinking, schaffen die Grundlage für Transparenz, Überprüfung und Anpassung in Bezug auf das Produktziel und helfen dem Scrum Team und den Unterstützern, sich selbst und ihr Umfeld weiterzuentwickeln.

Eine effektive Nutzung von Scrum verringert die Distanz zwischen den Stakeholdern, die Probleme oder Möglichkeiten äussern, und den Menschen, die mit ihnen zu tun haben, indem sie die Ziele konkret und verständlich formuliert und schnell und häufig Werte liefert. Die Stakeholder haben oft ein falsches Gefühl der Gewissheit über das Was und das Wie.

Das Scrum Team hat oft ein falsches Gefühl von Sicherheit darüber, wer betroffen ist. Überprüfen und Anpassen sollte wichtiger sein als das Einhalten von Versprechen oder das Bedienen der falschen Stakeholder. Alle Annahmen können falsch sein.

Kadenz
Die Arbeit in Sprints bietet einen konsistenten Rhythmus, der dem Scrum Team hilft, sich auf klare, kurzfristige Ziele zu konzentrieren. Diese Kadenz unterstützt die regelmässige Überprüfung und Anpassung und ermöglicht es dem Scrum Team, auf der Grundlage von Feedback zu lernen und sich anzupassen. Mit der Zeit entsteht so ein nachhaltiges Liefertempo, das die Vorhersagbarkeit verbessert und die kontinuierliche Verbesserung fördert.

Die drei Säulen der empirischen Prozesskontrolle von Scrum

Die Empirie ist im Kern die Philosophie, dass Wissen aus Erfahrung und Beobachtung entsteht. Wertvolle Erkenntnisse ergeben sich aus Neugier, Erfahrung, Experimenten, Daten, Visualisierung und Beobachtung. Empirische Prozesssteuerung (64-66) ist eine Methode zur Steuerung komplexer (30-35) Prozesse, wie sie in Scrum vorkommen, durch Anpassung auf der Grundlage von Beobachtungsergebnissen, die sich auf die drei Säulen Transparenz, Überprüfung und Anpassung stützen.

Transparenz
Transparenz ist eine Säule von Scrum. Sie schafft Klarheit über Realität und Arbeit und ermöglicht Empirie. Transparenz ermöglicht eine genauere Einschätzung der Situation und ist der Ausgangspunkt für Überprüfung und Anpassung. Der entstehende Prozess, die Arbeit und die Ergebnisse müssen für diejenigen sichtbar sein, die die Arbeit ausführen oder die Inputs in Form von Zielen, Product Backlog Items und die zugehörigen Outputs in Form von Increments erhalten. Wichtige Entscheidungen basieren auf den Artefakten, Experimenten, Releases oder Ergebnisrückmeldungen. Geringe Transparenz kann die Überprüfung beeinträchtigen und zu Entscheidungen führen, die den Wert mindern und das Risiko erhöhen. Transparenz ermöglicht Überprüfung.

Der entstehende Prozess, die Arbeit und die Ergebnisse müssen für diejenigen sichtbar sein, die die Arbeit ausführen oder die Inputs in Form von Zielen, Product Backlog Items und zugehörigen Outputs in Form von Increments erhalten. Wichtige Entscheidungen basieren auf den Artefakten, Experimenten, Releases oder Ergebnisrückmeldungen. Geringe Transparenz kann die Überprüfung beeinträchtigen und zu Entscheidungen führen, die den Wert mindern und das Risiko erhöhen. Transparenz ermöglicht Überprüfung.

Ergebnis-Feedback sind Daten, idealerweise sowohl quantitativ als auch qualitativ, die sich aus Änderungen am Produkt oder der Umgebung ergeben können. Sie tragen zum Wert, zum Aufwand, zu den Ressourcen oder zu den Kosten für die Stakeholder bei. Menschen sind keine Ressourcen. Das Erreichen von Transparenz ist unrealistisch und potenziell nicht anwendbar, wenn es institutionelle Ineffizienzen oder einen Mangel an Vertrauen gibt. Infolgedessen kann Scrum institutionelle Ineffizienzen transparent machen, und mit kollektivem Willen kann Vertrauen aufgebaut werden.

Überprüfung
Überprüfung ist eine der Säulen von Scrum. Überprüfung ist die Betrachtung der Realität, angesichts der Entwicklungsrichtung des Produkts (des Produktziels) und der Wirksamkeit des Scrum Teams und der Stakeholder. Überprüfung ermöglicht Anpassung. Bei der Überprüfung geht es darum, die Wirklichkeit bewusst zu betrachten, und sie stützt sich auf die Dinge, die transparent gemacht wurden, einschliesslich Beweise oder Beobachtungen. Um Überprüfung und Anpassung zu fördern, bietet Scrum eine Kadenz in Form von Ereignissen.

Die Scrum-Artefakte, die damit verbundenen Verpflichtungen und der Fortschritt auf dem Weg zu den vereinbarten Zielen müssen häufig und sorgfältig überprüft werden, um Emergenz zu erkennen (71). Die Überprüfung von Artefakten, Experimenten, Releases, den Marktentwicklungen oder Ergebnisrückmeldungen kann zu Erkenntnissen oder Begleiterscheinungen führen. Nebenwirkungen oder Begleiterscheinungen sind unerwartete oder unbeabsichtigte Ergebnisse oder Konsequenzen.

Eine Überprüfung ohne Transparenz ist nicht fundiert, verwirrend und überflüssig.

Anpassung
Anpassung ist eine Säule von Scrum. Angesichts der Ausrichtung des Produkts wird vom Scrum Team und den Stakeholdern erwartet, dass sie sich an die Realität anpassen, sobald sich Verbesserungsmöglichkeiten ergeben. Diese sind beispielsweise Ergebnisse von Experimenten, Erkenntnisse, Risiken oder Chancen. Die Anpassung wird schwieriger, wenn es institutionelle Ineffizienzen gibt oder wenn die beteiligten Personen nicht bereit, willens oder in der Lage sind, das zu tun, was getan werden muss.

Die Anpassung beginnt mit der Akzeptanz der „Realität“ auf der Grundlage von Erkenntnissen. Die Anpassung erfolgt typischerweise in den Scrum-Artefakten, den damit verbundenen Commitments für das Scrum Team, die Stakeholder, die Führungskräfte und die Organisation. Wenn irgendwelche Aspekte ausserhalb akzeptabler Grenzen liegen oder das resultierende Produkt inakzeptabel ist, müssen so schnell wie möglich Anpassungen vorgenommen werden, um den Kurs zu korrigieren.

Ohne Anpassung sind Transparenz und Überprüfung nutzlos.

Die Scrum-Werte

Die Scrum-Werte - Fokus, Offenheit, Engagement, Mut und Respekt - helfen dabei, ein Scrum Team Umfeld zu schaffen, das psychologische Sicherheit und positive Zusammenarbeit fördert, die mit Prinzipien übereinstimmen, die in der Neurowissenschaft als förderlich für Lernen und effektive Teamarbeit identifiziert wurden. Bedenken Sie den Kontext.

Die Scrum-Werte fördern Transparenz und Vertrauen und stellen sicher, dass Worte und Taten übereinstimmen. Zusammen bilden sie eine starke Grundlage für die Zusammenarbeit, Leistung und Kohärenz innerhalb eines Scrum Teams.

Die erfolgreiche Einführung von Scrum hängt davon ab, dass das Scrum Team und die Supporter (und andere Stakeholder) als Profis mit gutem Beispiel vorangehen. Die Scrum-Werte können helfen, das Vertrauen zwischen dem Scrum Team und den Stakeholdern zu verbessern. Die Scrum-Werte fördern auch die Ethik (57), das Vokabular, den Ton, die Arbeit, das Verhalten und das Handeln, die das Vertrauen fördern. Sie helfen auch, eine Kluft zwischen Worten und Taten zu verringern oder zu vermeiden. Das Scrum Team und die Unterstützer vereinbaren, offen über die gesamte Arbeit und die Herausforderungen zu sprechen. Bescheidenheit unterstützt Offenheit. Offenheit erfordert Vertrauen, und Vertrauen erfordert Offenheit. Das Scrum Team und die Unterstützer sollten konstruktives Feedback einfordern und weitergeben. Sie arbeiten routinemässig zusammen und lernen durch Gespräche mit hoher Bandbreite und qualitatives oder quantitatives Feedback.

Gespräche mit hoher Bandbreite sind Gespräche, die die Kommunikation auf eine Art und Weise fördern, die den reichhaltigsten, schnellsten und klarsten Austausch von Informationen ermöglicht. Dazu gehören in der Regel Gespräche von Angesicht zu Angesicht - entweder persönlich, über Videoanrufe, visuelles Management oder Whiteboards (physisch oder digital), bei denen die Teilnehmenden nicht nur Worte, sondern auch den Tonfall, die Mimik, Zeichnungen oder die Körpersprache nutzen können, um einander vollständig zu verstehen.

Da die Sprints kurz sind, sollten eventuelle Misserfolge klein und schnell sein, und das Risiko wird durch schnelles und offenes Feedback erkannt und gesteuert. Das einzige wirkliche Versagen ist vielleicht das Fehlen von Lernprozessen.

Das Scrum Team und die Unterstützer sollten den Mut haben, das Richtige zu tun und sich schwierigen Herausforderungen zu stellen. Sie sollten den Mut haben, Unbekanntes zu erforschen, die Richtung zu ändern, Informationen anzufordern und weiterzugeben und sich auf höfliche Meinungsverschiedenheiten einzulassen, z. B. auf gesunde Konflikte und konstruktive Meinungsverschiedenheiten. Das Scrum Team sollte bei Bedarf Unterstützer und Leiter um Hilfe bitten.

Das Scrum Team verpflichtet sich, das Sprint Goal zu erreichen und sich gegenseitig zu unterstützen. Commitment bedeutet, die relevante Arbeit am Sprint Goal so zu erledigen, dass sie spätestens am Ende des Sprints, besser noch viel früher, der Definition des Outputs entspricht. Commitment bedeutet auch, die gewünschten Ergebnisse durch Wertrealisierung zu erreichen.

Ihr primärer Fokus ist es, den bestmöglichen Fortschritt hinsichtlich des Sprintziels zu erzielen. Ihr sekundärer Fokus ist es, den bestmöglichen Fortschritt hinsichtlich des Produktziels zu erzielen. Die Unterstützer verpflichten sich, dem Scrum Team einen psychologisch sicheren Raum und ein sicheres Umfeld für die Lieferung von Increments zu bieten. Innerhalb ihres Fokus verpflichten sich das Scrum Team und die Unterstützer, Zeit für kontinuierliches Lernen und Anpassung sowie für den Lerntransfer zwischen Scrum Teams zu schaffen, um langfristige Effektivität sicherzustellen. Das Scrum Team und die Stakeholder sollten sich bewusst mit Kompromissen auseinandersetzen, einschliesslich der Berücksichtigung kurzfristiger Gewinne mit langfristigen Folgen.

Das Scrum Team und die Unterstützer (und andere Stakeholder) respektieren sich gegenseitig als erfahrene Fachleute; sie würdigen die unterschiedlichen Fachkenntnisse und Perspektiven der anderen und sind konstruktiv, wenn sie anderer Meinung sind. Respektvolles Verhalten fördert das Vertrauen. Mit dem Ziel. wirksamere Optionen zu finden, kritisieren das Scrum Team und die Unterstützer die Idee oder den Ansatz, jedoch nicht die Person(en).

Respekt trägt dazu bei, die anderen Scrum-Werte nicht als Waffe einzusetzen. Respekt gezeigt wird mit echtem Lob, gegenseitiger Unterstützung, Bescheidenheit, psychologischer Sicherheit, konstruktiven Meinungsverschiedenheiten und kognitiver Vielfalt.

Scrum Team-Mitglieder und Stakeholder können die Scrum-Werte durch die Linse von John Boyds OODA (99, 100, 102) betrachten. OODA wurde von John Boyd, Colonel der U.S. Air Force, entwickelt, um Piloten zu helfen, in schnell wechselnden Situationen schnelle und kluge Entscheidungen zu treffen, indem sie vier Schritte durchlaufen: Beobachten, Orientieren, Entscheiden und Handeln. Es ist eine einfache, kontinuierliche, iterative, leistungsstarke, wenn auch oft unbewusste Methode, mit Ungewissheit umzugehen - wie das Wahrnehmen von Marktveränderungen (Beobachten), das Analysieren von Trends und Risiken (Orientieren), das Auswählen von Produktmerkmalen zum Testen (Entscheiden) und deren Umsetzung (Handeln). OODA hilft dem Einzelnen, flexibel zu bleiben und gut auf alles zu reagieren, was auf ihn zukommt. Scrum kann OODA verbessern.

Einzelne Scrum Teammitglieder können die Scrum-Werte durch die Linse von John Boyds OODA betrachten und Scrum nutzen, um emergente Lösungen zu fördern. In einem Scrum-Kontext gelten die Scrum-Werte für die gesamte OODA, insbesondere helfen sie wie folgt:

● Beobachten - Offenheit und Respekt können das Sammeln aller relevanten Beweise und verschiedener Perspektiven fördern.

● Orientieren - Mut ist erforderlich, um die Realität zu interpretieren, Unsicherheiten zu bewältigen und Anpassungen oder Umschwünge zuzulassen, wobei möglicherweise eine Denkpause genutzt werden kann, um Annahmen in Frage zu stellen und neue Erkenntnisse zu gewinnen.

● Entscheiden - Die Entscheidung, was zu tun ist, erfordert eine rechtzeitige Analyse, z. B. die Verfeinerung des Backlogs, und die Fokussierung potenzieller nächster Schritte durch parallele „safe-to-fail“-Experimente zum Testen von Hypothesen, wie z. B. kleine Sonden (Sonden sollten klein, parallel und so konzipiert sein, dass ein Scheitern überlebensfähig und informativ ist).

● Handeln - Mit Klarheit darüber, was getan werden muss, warum und von wem, kann Commitment das Team dazu bringen, innerhalb von Rahmenbedingungen wie zeitlich beschränkte Sprints effektiv zu arbeiten und so neue Lösungen zu fördern.

Weitere unterstützende und ergänzende Theorie

Product Thinking
Menschen konsumieren Produkte und Dienstleistungen, nicht Projekte. Ein Produkt dient der Bereitstellung von Werten und stellt dabei ein Gleichgewicht zwischen Kurz- und Langfristigkeit her. Aus diesem Grund gibt es bei Scrum einen Product Owner und keinen Project Owner. Produkte sind langfristig angelegt und müssen während ihrer gesamten Lebensdauer betreut werden, während ein Projekt zeitlich begrenzt ist und oft ein verwaistes Produkt zurücklässt, sobald das Projekt abgeschlossen ist.

Product Thinking (86-88) befasst sich mit dem Spannungsfeld (111), dass sich Produkte oft auf kurzfristiges Wachstum konzentrieren, aber auch langfristige Belange berücksichtigen müssen, z. B. die Gewinnung von Anhängern der ersten Stunde, das „Überqueren der Kluft“(‘crossing the chasm’)(5), die Erweiterung, die Aktualisierung von Produktversionen, die kontinuierliche Veränderung, den Customer Lifetime Value und die Gesamtbetriebskosten.

Um die Kluft zu überwinden, ist ein Strategiewechsel von der Ausrichtung auf versierte, risikofreudige Kunden hin zur Gewinnung pragmatischer, risikoscheuer Käufer, Entscheidungsträger, Benutzer oder anderer Stakeholder erforderlich, indem man sich auf einen bestimmten Nischenmarkt oder ein bestimmtes Ziel konzentriert und eine vollständige, zuverlässige Lösung liefert, die echte Probleme löst. Dieser Schritt ist entscheidend für den Übergang eines Produkts von einem Nischenerfolg zu einer weit verbreiteten Akzeptanz, da es nicht mehr nur die frühen Anwender anspricht, sondern die frühe Mehrheit. Die frühe Mehrheit benötigt oft einen klaren Beweis für die Zuverlässigkeit und die Problemlösungsfähigkeiten des Produkts in einem bestimmten Kontext. Indem sich ein Unternehmen auf eine Nische konzentriert und eine Komplettlösung anbietet, kann es Glaubwürdigkeit aufbauen, Referenzkunden gewinnen und eine starke Marktposition etablieren und so die „Kluft“ zwischen frühen Anwendern und dem Mainstream-Markt effektiv überbrücken.

Product Owner müssen den Umgang mit Kompromissen zwischen dem Hier und Jetzt und der erwarteten Zukunft (dem Dort und Dann) (148) durch Mut, Bescheidenheit, Beratung, Zusammenarbeit, gesunde Konflikte usw. beherrschen.

Nehmen wir an, die beteiligten Personen denken ausschliesslich kurzfristig. In diesem Fall werden sie wahrscheinlich langfristige Nebenwirkungen wie technische Schulden, niedrige Scrum Team-Moral, Geschäftigkeit, Output-Fokus usw. erleben. Aus diesem Grund müssen Faktoren geschaffen werden, die die langfristigen Auswirkungen abmildern.

Technische Schulden sind die zusätzliche Arbeit, die sich - bewusst oder unbewusst - ansammelt, wenn man bei der Implementierung oder beim Design Abkürzungen nimmt, um etwas schneller zu liefern. Im Laufe der Zeit verlangsamen sie sich, genau wie echte Schulden - mit Zinsen -, weil sie künftige Änderungen erschweren und riskanter machen. Fachleute bemühen sich, technische Schulden und Schlamperei so weit wie möglich zu minimieren. Wenn sie sich dazu entschliessen, Schulden zu machen, sollte dies transparent sein, und wenn möglich, sollte ein Notfallplan zur Schadensbegrenzung vorhanden sein.

Für Produkte unterstützt Scrum die Machbarkeit, Nutzbarkeit, Wünschbarkeit, den Wert und die Durchführbarkeit innerhalb ethischer (57) Grenzen durch:

● Produktdesign
● Produktmanagement
● Bewusste Berücksichtigung des konsequenten Zusammenspiels von Stakeholdern, Forschung, Zielen, Entdeckung, Design, Lieferung und kontinuierlicher Wertrealisierung
● Im speziellen Fall von Technologieprodukten durch Produktentwicklung.

Scrum begünstigt ein gesundes Gleichgewicht zwischen Kurzfristigkeit und Langfristigkeit. Die Zielorientierung ermöglicht potenzielle Ergebnisse durch die Betonung von Wert und Risikominderung. Das Sprintziel (hier und jetzt) sollte ein Schritt in Richtung des Produktziels (dort und dann) sein, das den Weg zum langfristigen Ziel ermöglicht. Das Produktziel unterstützt häufig die Produktstrategie und die Produktvision.


Systems Thinking
Systems Thinking, auf Deutsch Systemdenken (55), erkennt die Verflechtung von Elementen innerhalb organisatorischer und sozialer Kontexte an und weiss, dass sich Massnahmen in einem Bereich auf eine Weise auswirken, die nicht immer vorhersehbar oder linear ist. Theoriebasierte Experimente, Rückkopplungsschleifen und anschliessende Datenanalysen helfen, wertvolle und umsetzbare Erkenntnisse zu gewinnen. Das Systemdenken liefert wertvolle Werkzeuge und Ideen und erleichtert den Erkenntnisgewinn.

Damit eine Organisation anpassungsfähig wird (80), müssen lokale Suboptimierungen vermieden werden, z. B. die Senkung der Stückkosten bei gleichzeitiger Erhöhung der langfristigen Kosten, die Aushöhlung von Qualitätszielen, nur um das Vertrauen der Kunden zu verlieren, oder die Verbesserung eines Scrum Teams, Arbeitsablaufs oder Prozesses, der nicht existieren sollte. Bei komplexer Arbeit (30-35) ist es nicht immer möglich, Ursache und Wirkung zu verknüpfen, ausser im Nachhinein. Dennoch ist es hilfreich, mögliche und tatsächliche vorgelagerte, stromübergreifende und nachgelagerte Auswirkungen von Eingriffen zu berücksichtigen.

Discovery
Discovery (50-51) (auf Deutsch auch “Entdeckung” oder “Ermittlungsarbeit”) beginnt oft mit dem Verstehen der Erwartungen, Bedürfnisse und Wünsche der Menschen durch Beobachtung, Analyse, Gespräche und Synthese in Richtung eines gewünschten Ergebnisses. Sobald ein Scrum Team Erkenntnisse gesammelt hat, formuliert es das Problem oder die Gelegenheit und ordnet sie nach ihrem potenziellen Wert. Das Scrum Team sucht nach möglichen Lösungen, ohne sie vorschnell zu beurteilen. Wenn der potenzielle Wert hoch ist, aber es keine Beweise dafür gibt, dass der Wert realisiert werden kann, sollte das Scrum Team Nachforschungen anstellen, Annahmen testen oder einfache Prototypen bauen, die es mit echten Kunden, Entscheidungsträgern oder Benutzern testen kann. Die Erkundung ist nie abgeschlossen; denken Sie an regelmässige Interviews oder Beobachtungen von Kunden, Entscheidungsträgern oder Benutzern.

Bei der Erkundung geht es darum, durch Priorisierung, Umsetzung, Vermeidung oder ständige Verbesserung von Ideen, die durch Beobachtung der Benutzer, Feedback oder andere Erkenntnisse gestützt werden, auf ein gewünschtes Ergebnis hinzuarbeiten. Discovery betont die Zusammenarbeit, die Kreativität und die Bereitschaft, zu scheitern und es erneut zu versuchen. Discovery rahmt die Arbeit als Probleme oder Gelegenheiten ein und hilft dem Scrum Team, Lösungsoptionen zu erstellen, zu priorisieren und zu testen, die ein Gleichgewicht zwischen den Wünschen der Menschen, den technischen Möglichkeiten und dem geschäftlichen Nutzen herstellen - und dabei Spass machen.

Wenn Discovery erforderlich ist, sollte sie (soweit möglich) auf eine Weise einbezogen werden, die mit Scrum vereinbar ist. Zum Beispiel wird die Discovery-Arbeit im Product Backlog und im Sprint Backlog transparent gemacht, die Mitglieder des Scrum Teams üben Discovery und andere Fähigkeiten, die Erkenntnisse werden während des Sprints und bei den Scrum-Events diskutiert, und in jedem Sprint wird mindestens ein Increment produziert (und idealerweise freigegeben), unabhängig davon, wie viel Discovery gemacht wird. Es muss ein Gleichgewicht gefunden werden: Discovery kann helfen, zu vermeiden, dass etwas Falsches gebaut wird, aber es kann auch übertrieben werden, und am Ende ist das Ergebnis-Feedback am wichtigsten.

Leadership (Führung)
Leadership, auf Deutsch Führung, ist die Fähigkeit, eine Gruppe von Menschen zu beeinflussen, zu leiten und zu inspirieren, um ein gemeinsames Ziel zu erreichen und gleichzeitig Demotivation zu vermeiden. Sie inspiriert das Denken, Handeln und die Leidenschaft und fördert eine klare strategische Ausrichtung. Sie umfasst zielgerichtetes und absichtliches Sehen, Hören und Verstehen, das Sammeln von Fakten und Beobachtungen, um Entscheidungen zu treffen, besser bekannt als Genchi Genbutsu (84).

Führung ist ein dynamischer sozialer Prozess, der Verantwortung, Beziehungsaufbau und Befähigung beinhaltet. Erfolgreiche Führung resultiert in der gemeinsamen Erarbeitung einer Marschrichtung, der effektiven Ausrichtung der benötigten Ressourcen und Mitarbeiter und dem gegenseitigen Engagement der Gruppenmitglieder.

Scrum strebt eine besondere Art der Führung an, nämlich eine Führung für Resilienz, eine Reihe von Qualitäten, nicht eine Managementposition. Daher muss Führung u. a. Folgendes beinhalten: Kultivierung eines Umfelds für sich selbst verwaltende Scrum Teams, Klarheit, Vertrauen, Transparenz, Auftauchen (71) in einer Richtung, Erfüllung bei der Arbeit, Umarmung von Ungewissheit (72) und Fehlern, Sammeln von Beweisen für bessere Entscheidungen, proaktives Risikomanagement und Beseitigung organisatorischer Ineffizienzen.

Führung geschieht aus allen Blickwinkeln, sollte auf allen Ebenen stattfinden und fördert die Reflexion zum richtigen Zeitpunkt. Führung sollte rücksichtslos nach Werten streben und gleichzeitig mitfühlend und ethisch sein. Führung erfordert beharrliches Handeln, um Arbeitsabläufe, Prozesse, Systeme und das Arbeitsumfeld zu verändern; dies gilt auch (aber nicht nur) für das Personal-, Finanz- und Lieferantenmanagement. Eine Führungspersönlichkeit ist jemand, der Führung demonstriert.

Product Owner und Scrum Master halten ein Gleichgewicht zwischen Führung, Autorität und subtiler Kontrolle, indem sie klare Absichten vorgeben, die Initiative fördern und die Verantwortlichkeit stärken. Sie leiten eher an, als dass sie Mikromanagement betreiben, und stellen sicher, dass das Scrum Team die Vision und die Ziele versteht, die Autonomie hat, sie auszuführen, und für die Ergebnisse verantwortlich bleibt. Wenn ein Eingreifen erforderlich ist, greifen sie entschlossen ein, während sie die Verantwortung des Scrum Teams für die Ergebnisse aufrechterhalten. Product Developer demonstrieren ihre Führungsqualitäten durch ihre selbstverwaltende Teamorientierung, Professionalität und Zielorientierung; Selbstmanagement geht mit Verantwortung einher. Unterstützer demonstrieren Führung, indem sie die Beseitigung kurz- und langfristiger Hindernisse unterstützen, die Kohärenz von Managementprozessen mit Scrum verbessern und aufkommende Veränderungen in eine starke Richtung unterstützen, wenn dies gewünscht wird.

First Principles Thinking
First principles thinking ist eine Problemlösungsmethode, bei der Herausforderungen in ihre grundlegendsten Wahrheiten zerlegt und Lösungen von Grund auf gefunden werden. Anstatt sich auf Analogien oder etablierte Konventionen zu stützen, fragt dieser Ansatz: „Was wissen wir mit Sicherheit?“ und rekonstruiert das Verständnis und die Lösungen aus diesen grundlegenden Elementen. Beispiele hierfür könnten sein, sind aber nicht beschränkt auf

● Ermutigung des Scrum Teams, sich auf die Kernfaktoren für Effektivität, Anpassungsfähigkeit (80) und Aktualität zu konzentrieren - wie Autonomie, Transparenz und Anpassung -, anstatt blindlings Prozessen zu folgen oder zu kopieren, was andere getan haben.

● Hinterfragen aller Annahmen und Rekonstruieren von Lösungen auf der Grundlage von Fakten und wesentlichen Grundsätzen, was zu Durchbrüchen führen kann.

● Förderung originellen Denkens, kontinuierlicher Verbesserung und des Mutes, den Status quo in Frage zu stellen - was Kreativität freisetzt und transformative Ergebnisse ermöglicht.

Menschen und Veränderung
Der Schwierigkeitsgrad der Einführung von Scrum sollte nicht unterschätzt werden. Scrum bietet durch seine Elemente einige Leitprinzipien. Es bietet einen Ansatz, um zu den ersten Prinzipien zurückzukehren.

Bei Scrum geht es nicht um die Einführung von Tools. Und Scrum endet nicht mit der Beseitigung von Hindernissen. Ein Hindernis in Scrum ist alles, was den Fortschritt blockiert oder verlangsamt. Es ist von entscheidender Bedeutung, bewusst, unnachgiebig und hartnäckig mit Menschen, Veränderungen und Kommunikation umzugehen. Die Veränderung umfasst oft Personalentwicklung, Entwicklung von Designs, Arbeitsabläufen, Prozessen, Systemen, Einstellungen, Verhaltensweisen, Sprache, Gewohnheiten und Förderung eines guten Arbeitsklimas. Die Kultur ist ein entstehendes Ergebnis.

Eine effektive Scrum-Einführung verwendet einen iterativen Ansatz, verfügt über effektive Change Agents und findet die begeisterte Unterstützung derjenigen, die davon betroffen sind oder es beeinflussen. Intention und täglicher Fortschritt bei der Einführung sind entscheidend. Die Einführung sollte nicht das Letzte sein, um das man sich kümmert, nachdem alles andere erledigt ist.

Beginnen Sie mit einer disziplinierten, aufkommenden Veränderung in eine bestimmte Richtung. Streben Sie danach, dass emergente Veränderungen so normal werden, dass sie schliesslich Teil der geplanten Arbeit werden. Eine Scrum-Anpassung hat eine Richtung, aber kein vordefiniertes Ziel. Die Veränderung ist emergent und daher nicht vorhersehbar. Neugierde ermöglicht ein Muster des Erspürens, Zuhörens, Lernens und Anpassens in eine bestimmte Richtung. Es ist wichtig, Beziehungen zu pflegen, Perspektiven zu verstehen und zu hören, was nicht gesagt wird und was nicht geschieht. Veränderung ist harte, aber erfüllende Arbeit.

Die Scrum Rollen im Expansion Pack

Die vier Scrum-Rollen sind Product Owner, Product Developer, Scrum Master und Stakeholder. Sie geben, belohnen und verdienen Vertrauen und ermöglichen eine kohärente Führung. Nur die drei Verantwortlichkeiten, Product Owner, Product Developer und Scrum Master, sind Teil des Scrum Teams.

Eine Person kann mehrere Scrum-Rollen innehaben. Wenn man mehrere Rollen übernimmt, muss man darauf achten, seine jeweiligen Kompetenzen nicht zu überschreiten. Die Scrum-Rollen sind so konzipiert, dass sie Kontrolle und Gleichgewicht gewährleisten.

Ein Scrum Team ist eine Gruppe von Personen, die Scrum praktizieren und die drei Scrum-Rollen des Scrum Masters, des Product Owners und der Product Developer einnehmen. Das Team befasst sich mit Problemen oder Möglichkeiten der Stakeholder (einschliesslich, aber nicht beschränkt auf Kunden oder Benutzer) und liefert aus den Perspektiven des Scrum Teams und der Stakeholder nützliche, brauchbare und potenziell wertvolle Increments für das Produktziel.

Bei komplexer (30-35) Arbeit sollte ein Scrum Team klein, kognitiv vielfältig und selbstorganisiert sein, wobei sich die menschlichen Teammitglieder, die oft durch Technologie unterstützt werden. Die Teammitglieder sollten sich für die Arbeit der anderen interessieren und die Bereitschaft mitbringen, zu lernen, wie man die Aufgaben der anderen erledigt.

Das Scrum Team sollte funktionsübergreifend sein, d. h. es sollte multidisziplinär sein und sowohl technische als auch betriebswirtschaftliche Kenntnisse mitbringen. Es gibt keine explizite Hierarchie innerhalb des Scrum Teams. Das Scrum Team sollte über alle Fähigkeiten und Unterstützung verfügen, die benötigt werden, um:

● Entdecken (inkl. Forschung und Design) nach Bedarf,

● Liefern (ggf. inkl. Technik); und,

● Validierung der Wertrealisierung (und zusätzlich der Verwendbarkeit, Wünschbarkeit und Durchführbarkeit innerhalb ethischer (57) Grenzen).

Das Scrum Team ist mit Hilfe der Unterstützer dafür verantwortlich, Probleme oder Möglichkeiten zu finden, Produkte zu entwickeln und zu liefern, zu prüfen, ob sie funktionieren, sicherzustellen, dass sie von guter Qualität sind, sie zu verkaufen und zu prüfen ob sie hinsichtlich des Produktzieles Mehrwert liefern. All dies geschieht, um das Produktziel zu erreichen. Das Scrum Team strebt nach kontinuierlicher Verbesserung. Als selbstorganisiertes Team(47) entscheidet es selbst, wer was, wie, wann und wo tut.

Wertvalidierung ist die Bestätigung (oder Nicht-Bestätigung) innerhalb bestimmter Grenzen, dass das/die erwartete(n) Ergebnis(se) erreicht worden sind.

Das Scrum Team liefert in jedem Sprint ein oder mehrere Increments, führt ein kontinuierliches Selbstmanagement (47) durch, um Probleme zu finden und zu beheben, synchronisiert sich kontinuierlich und macht häufig Releases. Das Scrum Team ist klein genug, um wendig zu bleiben, und gross genug, um innerhalb eines Sprints umfangreiche Arbeiten abzuschliessen. Kleinere Scrum Teams kommunizieren oft besser und sind produktiver.

Scrum basiert auf selbstorganisierten Scrum Teams (47) innerhalb einer definierten Organisations- oder Produktstruktur. Es besteht Autonomie, die jedoch durch Scrum-Ereignisse, Verantwortlichkeiten, Artefakte, Commitment, Säulen, Werte und organisatorische Anforderungen begrenzt ist.

Scrum bezieht Gruppen von Menschen ein, die gemeinsam alle Fähigkeiten und Fachkenntnisse besitzen oder erwerben, um die Arbeit zu erledigen und diese Fähigkeiten bei Bedarf zu teilen. Um die Chancen auf erfolgreiche Ergebnisse zu verbessern, sind gezielte Interaktionen erforderlich, die von den Führungskräften unterstützt werden.

Der Schwerpunkt sollte darauf liegen, das Produktziel auf die effektivste Weise und mit dem richtigen Mass an Investitionen zu erreichen und dabei wertvolle Ergebnisse zu liefern.

Scrum fördert die kollaborative Teamarbeit, indem es die kontinuierliche Interaktion und die gemeinsame Verantwortlichkeit anstelle von sequenzieller, in Silos isolierter Arbeit fördert. Dieser Ansatz ermöglicht es dem Scrum Team und den Stakeholdern, Ungewissheit in Kauf zu nehmen (72), was schnellere Anpassungen auf der Grundlage von kontinuierlichem Lernen und Feedback ermöglicht. Die Überschneidung von Entdeckung, Entwicklung und Wertvalidierung gewährleistet einen anpassungsfähigeren (80), wertorientierten Ansatz für die Produktentwicklung.

Überschneidungen in der Arbeit fördern die gemeinsame Verantwortung des Scrum Teams, was das Commitment und den Einsatz erhöht. Das Scrum Team lenkt die Aufmerksamkeit auf die Bewältigung von Herausforderungen und Chancen, fördert proaktives Verhalten, kultiviert vielfältige Fähigkeiten und erhöht das Bewusstsein für die Marktdynamik bei allen Beteiligten.

Das Scrum Team befasst sich mit allen produktbezogenen Aktivitäten, von der Zusammenarbeit mit den Stakeholdern bis zur Wertvalidierung, inkl. Verifizierung, Unterhalt, Betrieb, Experimenten, Forschung und Entwicklung und allem, was sonst noch erforderlich sein könnte. Das Scrum Team sorgt für Qualität. Die Unterstützer sorgen dafür, dass die Organisation das Klima und das Arbeitsumfeld strukturiert und das Scrum Team zum Selbstmanagement befähigt (47). Die Arbeit in Sprints in einem nachhaltigen Tempo verbessert den Fokus und die Konsistenz.

Das Scrum Team und die Stakeholder wissen nicht, was sie lernen werden. Manches Lernen bietet mehr Sicherheit, anderes schafft mehr Unsicherheit (72). Themen könnten auftauchen, verblassen, wegfallen oder an Priorität verlieren.

Ein Scrum Team hat eine abgestimmte Autonomie. Ausgerichtete Autonomie bedeutet, dass das Scrum Team die Freiheit hat, selbst zu entscheiden, wie es Probleme löst, solange es auf gemeinsame Ziele und Ergebnisse fokussiert bleibt. Dadurch sind sowohl Innovation als auch organisatorische Kontinuität möglich. Die Förderung eines kognitiv vielfältigen Scrum Teams ist wesentlich. Wenn die Mitglieder eines Scrum Teams zusammenarbeiten, sich gegenseitig vertrauen und ihre eigene Leistung reflektieren können, ist die Wahrscheinlichkeit grösser, dass Ideen ausgetauscht werden (“gegenseitige Befruchtung”).

Für erfolgreiche Ergebnisse sollten das Scrum Team und die Unterstützer die Bereitschaft kultivieren, überholte Prinzipien zu verlernen. Überprüfung und Anpassung erfordern ein Umfeld, das Fehler antizipiert und toleriert. Es ist wichtig, dass Kritik auf Ideen und nicht Personen gerichtet wird. Alle Mitglieder des Scrum Teams „spielen in der gleichen Mannschaft”, wobei sich die Arbeiten sinnvoll überschneiden, und sie sind gemeinsam für den Erfolg verantwortlich.

Stakeholder
Stakeholder ist eine Rolle. Ein Stakeholder ist eine Einheit, Einzelperson oder Gruppe, die sich für Inputs, Aktivitäten und Ergebnisse interessiert, davon betroffen ist oder diese beeinflusst. Stakeholder haben ein direktes oder indirektes Interesse innerhalb oder ausserhalb der Organisation, ihrer Produkte oder Dienstleistungen.

Beispiele für Stakeholder sind u. a. Kunden, Entscheidungsträgerinnen, Nutzer, Lieferanten, Einflussnehmerinnen, Manager, Kollegen, Führungskräfte, Gesetzgeberinnen, Finanzsponsoren, Fachexperten und die Aufsichtsbehörde. Unbelebte, nicht-menschliche Stakeholder wie das Gesetz oder KI sollten nicht ignoriert werden. Einige Stakeholder haben mehr Einfluss oder sind stärker betroffen als andere, und jeder von ihnen kann unterschiedliche Faktoren begünstigen. Jeder Stakeholder hat ein unterschiedliches Mass an Macht oder Einfluss.

Ein Kunde ist jeder Stakeholder, der einen Nutzen aus dem Produkt zieht, indem er es kauft und/oder auswählt. Zu den Kunden können Käufer:innen (diejenigen, die für das Produkt bezahlen oder es erwerben), Entscheidungsträger:innen (diejenigen, die seine Einführung genehmigen) und Endbenutzer:innen (diejenigen, die direkt mit dem Produkt interagieren) gehören. Manchmal ist der Kunde nicht mit dem Endkunden identisch, zum Beispiel bei B2B2C (79) or B2B2B (78). Für eine erfolgreiche Einführung von Scrum ist ein regelmässiger und bewusster Austausch zwischen den Stakeholdern (einschliesslich, aber nicht beschränkt auf Kunden und Anwender) und dem Scrum Team unerlässlich.

Ein Anwender ist ein Stakeholder, der direkt mit dem Produkt interagiert, um bestimmte Ziele zu erreichen oder Probleme zu lösen. Die Nutzer erleben das Produkt aus erster Hand, egal ob es sich um eine Dienstleistung, eine Plattform oder ein Erlebnis handelt, und ihr Feedback und ihre Zufriedenheit sind entscheidend für die laufende Verbesserung des Produkts. Die Benutzer haben zwar kein Mitspracherecht bei Kaufentscheidungen, aber ihre Akzeptanz und ihr Engagement sind für den anhaltenden Erfolg des Produkts entscheidend. Manchmal ist der Benutzer nicht mit dem Endbenutzer identisch, z. B. bei B2B2C oder B2B2B. Für eine erfolgreiche Scrum-Einführung ist ein regelmässiger, bewusster Austausch zwischen Anwendern (und möglicherweise Endanwendern) und dem Scrum Team unerlässlich.

Ein Entscheidungsträger (von Jeff Patton als „Chooser“ bezeichnet) (82) ist ein Stakeholder mit der Autorität, die Einführung oder den Kauf des Produkts zu genehmigen, auszuwählen oder zu autorisieren. Der Entscheidungsträger ist für die Bewertung der Optionen und die endgültige Entscheidung verantwortlich, wobei er häufig die Bedürfnisse der Benutzer und der Organisation im Allgemeinen berücksichtigt. Die Entscheidungsträger können das Produkt selbst nutzen oder auch nicht, aber ihre Entscheidungen wirken sich direkt darauf aus, welche Produkte angenommen werden und wie der Wert für andere Stakeholder bereitgestellt wird. Für eine erfolgreiche Scrum-Einführung ist es oft besser, mit unvollkommenen Informationen zu arbeiten und das Feedback der entstehenden Ergebnisse zu erfassen.

Der Gesetzgeber (und für die Zwecke dieses Dokuments auch externe oder interne Entscheidungsträger) legt Regeln, Richtlinien und Grenzen für den Einsatz eines Produkts fest. Sie definieren rechtliche, regulatorische oder organisatorische Rahmenbedingungen, die die Wertschöpfung des Produkts für die Stakeholder und die Standards für Professionalität bestimmen. Sie stellen sicher, dass das Produkt mit externen oder internen Vorgaben übereinstimmt und steuern seine Entwicklung und Nachhaltigkeit. Für eine erfolgreiche Scrum-Einführung ist es entscheidend, die rechtlichen Anforderungen nicht zu übertreiben oder zu unterschätzen.

Finanzielle Sponsoren stellen Mittel und Ressourcen für die Entwicklung, Einführung und Verbesserung des Produkts bereit. Sie bewerten die Durchführbarkeit, den Wert und die Machbarkeit des Produkts, wobei sie sich an seinem Potenzial orientieren, den Stakeholdern einen kontinuierlichen Mehrwert zu liefern. Finanzielle Sponsoren nehmen Einfluss auf die Produktvision, -strategie und -ziele, um die Ausrichtung auf die Investitionsrendite und die langfristige Nachhaltigkeit sicherzustellen. Für eine erfolgreiche Einführung von Scrum sind eine flexible Einstellung und eine flexible Finanzierung entscheidend – für den Fall, dass neue Informationen ans Licht kommen.

Fachexperten bringen tiefgreifende Kenntnisse oder einzigartige Fähigkeiten mit, die für die Erstellung, Weiterentwicklung und Pflege von Produkten unerlässlich sind. Unabhängig davon, ob sie sich auf Technologie, Design, Compliance oder einen bestimmten Bereich konzentrieren, unterstützen Fachexpert:innen die Nutzbarkeit, Machbarkeit, Professionalität und Erweiterbarkeit des Produkts, stehen aber den selbstorganisierten Scrum Teams nicht im Weg (47).

Der Begriff Zufriedenheitslücke (satisfaction gap) bezeichnet die Differenz zwischen dem, was die Stakeholder jetzt erleben, und dem, was sie sich wünschen. Mit anderen Worten: Es ist die Lücke zwischen der Zufriedenheit der Stakeholder heute mit einem Produkt und der Zufriedenheit, die sie haben könnten.

Governance bezieht sich auf Strukturen, Standards, Vorschriften, Normen, Prozesse und Praktiken, die die Richtung, Entscheidungsfindung und Rechenschaftspflicht eines Produkts bewusst einschränken und steuern. Governance fördert die Transparenz und steuert die Einhaltung von Standards in Bezug auf Wert, Lebensfähigkeit und Professionalität. Sie bietet Mechanismen für das Risikomanagement und die Anpassung des Produkts an sich ändernde Bedürfnisse oder Umgebungen und unterstützt so seine Langlebigkeit und seinen evolutionären Charakter. Für eine erfolgreiche Einführung von Scrum ist es entscheidend, dass die Governance mit Scrum kohärent ist, z. B. ein einziger Ansprechpartner für jeden Governance-Bereich, der zielgerichtet mit dem Scrum Team in Bezug auf Qualität und Compliance interagiert. Ausserdem sollte die Governance regelmässig überprüft und angepasst werden, damit es keine Überraschungen gibt.

Unterstützer
Unterstützer sind ein spezieller Stakeholder-Typ. Unterstützer sind unterstützende Stakeholder und Change Agents. Supporter sind oft Teil einer starken Führungskoalition (83), die inspiriert und demotivierende Faktoren beseitigt. Supporter unterstützen das Scrum Team dabei, zu gedeihen und die Arbeitsabläufe, Prozesse, Systeme, Produkte, Dienstleistungen und das Arbeitsumfeld der Organisation so zu beeinflussen, dass sie mit der Einführung und dem Aufkommen von Scrum kohärent werden (71). Unterstützer sollten sich beteiligen, wenn und wo sie gebraucht werden oder wie gewünscht. Die Wertschöpfung erfordert oft eine effektive und konstruktive Zusammenarbeit mit anderen Stakeholdern.

Je nach Grösse der Organisation können Beispiele für Unterstützer Kollegen, Entscheidungsträgerinnen, Finanzsponsoren, die Governance-Aufsicht, Managerinnen, Fachexperten, das Marketing, die Personalabteilung, die Finanzabteilung, die Beschaffung und Early Adopters sein. Unterstützer, die Scrum Teams nicht dazu ermächtigen, das umzusetzen, was in diesem Dokument empfohlen wird, sind keine wirklichen Unterstützer. Führungskräfte und Vorstandsmitglieder spielen eine entscheidende Rolle bei der Förderung einer Kultur, in der Unterstützer ihre Rolle aktiv ausfüllen. Unterstützer sollten Führung demonstrieren, die das Scrum Team zu schätzen weiss.

Künstliche Intelligenz
Künstliche Intelligenz (KI) ist zunehmend Teil der Arbeitsumgebung und kann die Fähigkeiten eines Scrum Teams bei der Entdeckung, Entscheidungsfindung, Produktentwicklung und Wertrealisierung erheblich erweitern.

KI kann Scrum verbessern durch:
● Empirische Prozesskontrolle (64-66): KI-gesteuerte Analysen verbessern Transparenz, Überprüfung und Anpassung.
● Kognitive Erweiterung: KI ermöglicht es menschlichen Scrum Teammitgliedern, sich auf strategische, kreative und ethische Überlegungen zu konzentrieren.
● Kontinuierliche Wertanpassung: KI kann Product Backlog Items aktualisieren und neu priorisieren, basierend auf aktuellem Nutzerfeedback und Trends.
● Systems Insight: KI identifiziert versteckte Interdependenzen und verbessert die datengestützte Entscheidungsfindung.

Die Möglichkeiten sind unbegrenzt. Scrum Teams könnten KI nutzen, um:
● Mehrdeutigkeiten in Texten zu entdecken und die eigenen Empfehlungen und Ergebnisse kontinuierlich auf Verzerrungen, Fehler und unbeabsichtigte Folgen zu überprüfen.
● Modelle und Anwendungen regelmässig zu validieren und anzupassen.
● Transparenz in der Reihenfolge des Product Backlogs (Sequenzierung) zu fördern.
● Agenten als KI-Teammitglieder zu schaffen.
● KI kann hilfreich sein, um das bestehende Denken bewusst zu testen und in Frage zu stellen.

Die Gefahren sind aber auch unbegrenzt. Behalte eine klare menschliche Verantwortung für alle Ergebnisse bei (angelehnt an die Verantwortlichkeiten aus Scrum) und nutze KI als leistungsstarken, aber überwachten Entscheidungspartner. Dies wird als „den Menschen in der Schleife halten“ bezeichnet. KI kann zwar Innovation und Effektivität zu geringsten Kosten steigern, ersetzt aber nicht die menschliche Verantwortung. KI sollte die empirische Prozesskontrolle (64-66) und die ethische Entscheidungsfindung (57) von Scrum unterstützen und nicht ausser Kraft setzen. Das Scrum Team ist weiterhin dafür verantwortlich, wertvolle Ergebnisse zu liefern, Fakten zu evaluieren und Professionalität zu wahren.

KI kann ein unterstützendes Instrument sein, wenn sie mit guter Absicht eingesetzt wird. KI-Tools sollten wie jeder andere Beitrag zum psychologischen Flow (70) und zum Lernen bewertet werden: Verbessern sie die Feedback-Schleifen? Helfen sie, Annahmen schneller zu validieren? Handeln sie, und wenn sie es tun, ist das Handeln ethisch (57)?

Psychologischer Flow (70) ist ein Zustand der völligen Absorption und Freude an einer Tätigkeit, in dem Handlung und Bewusstsein verschmelzen und die Zeit anders zu vergehen scheint.

Wenn sie mit guter Absicht eingesetzt wird, kann KI ein unterstützendes Werkzeug sein. KI-Tools sollten wie jeder andere Faktor, der zum psychologischen Fluss und zum Lernen beiträgt, bewertet werden. Verbessern sie die Feedback-Schleifen? Helfen sie, Annahmen schneller zu überprüfen? Wenn sie agieren, ist ihr Handeln ethisch vertretbar?

Der Schwerpunkt sollte weiterhin auf der menschlichen Dynamik der Teamarbeit und der Zusammenarbeit liegen, wobei KI als potenzielles Hilfsmittel betrachtet wird.

Product Developer
‘Product Developer‘ ist eine Rolle und eine Verantwortlichkeit. Alle Product Developer zusammen sollten über alle Fähigkeiten verfügen, die für die Erstellung von Increments erforderlich sind. Die kombinierten Fähigkeiten werden oft als funktionsübergreifend bezeichnet.

Ein Product Developer kann ein Mensch oder ein Automat sein. Menschliche Product Developer engagieren sich in jedem Sprint für die Erstellung, Erforschung, Überprüfung und Anpassung aller Aspekte eines Increments, das released werden kann. Ihr Hauptaugenmerk liegt auf dem aktuellen Sprint. Ein Teil der Kapazität wird oft in die zukunftsorientierte Verfeinerung und die Untersuchung von Ergebnisrückmeldungen, Nebeneffekten oder anderen Erkenntnissen investiert.

Die Product Developer halten sich an die Definition von „Output Done“ und streben eine Nettoverbesserung an. Die Product Developer erzielen die besten Ergebnisse, wenn sie sich ausschliesslich auf ein Produkt konzentrieren. Wenn der Product Owner oder Scrum Master zu einem bestimmten Zeitpunkt aktiv an Elementen im Sprint Backlog arbeitet, führen sie diese Arbeit als Product Developer aus.

Die Product Developer sollten je nach Situation geeignete Verhaltensweisen annehmen; dazu gehören u.a. die Zusammenarbeit, die Erstellung und die Förderung von technischer Qualität, Entdeckung, Lieferung und Wertvalidierung.

Mindestens ein Product Developer sollte ein Mensch sein. Mehrere menschliche Product Developer verbessern oft die kognitive Vielfalt, was bei der Bewältigung von Komplexität hilfreich ist.

Product Developer sind immer gemeinsam verantwortlich für:
● die Erstellung eines sich entwickelnden Plans im Sprint Backlog zur Erreichung des Sprintziels;
● die Förderung der Qualität durch Einhaltung und Verbesserung der Definition of Output Done;
● die Erstellung von mindestens einem brauchbaren Increment in jedem Sprint;
● das Lernen, oft durch Daten, die sich an der Definition of Outcome Done orientieren;
● die tägliche Anpassung ihres Plans an das Sprintziel;
● sich gegenseitig zur Verantwortung ziehen als Fachleute; und,
● die Nettoverbesserung.

Es kommt auf den Kontext an, d. h. es ist wichtig, die spezifischen Umstände zu berücksichtigen. Als Faustregel gilt jedoch, dass ein Product Developer, der weder willens noch bereit oder in der Lage ist, professionell zu agieren, als Product Developer zurücktreten sollte.

Product Owner
Product Owner ist eine Rolle und eine Verantwortlichkeit. Der Product Owner muss ein Mensch sein. Um effektiv zu sein, sollte der Product Owner eine Führungspersönlichkeit für das Produkt sein. Der Product Owner maximiert den langfristigen Wert und muss wissen, wo der Wert liegt und wann er benötigt wird. Vom Product Owner wird erwartet, dass er auf allen Ebenen und in allen relevanten Geschäftsbereichen arbeitet. Der Product Owner arbeitet mit den Stakeholdern, dem Scrum Master und den Product Developers zusammen, um Werte zu schaffen.

Der Product Owner verwendet das Product Backlog, um festzulegen, was in welcher ungefähren Reihenfolge erstellt werden soll. Der Product Owner hat immer das Produktziel vor Augen; sein Hauptaugenmerk liegt darauf, bei jedem Schritt den langfristigen Wert zu maximieren.

Der Product Owner definiert sich nicht durch das Analysieren und Schreiben detaillierter Product Backlog Items. Jede Minute, die damit verbracht wird, den Product Developers nicht zu vertrauen, ist eine verpasste Chance, strategischer zu denken, mehr mit Stakeholdern zu arbeiten oder mehr Wert zu schaffen. Der Product Owner sollte je nach Situation angemessene Verhaltensweisen an den Tag legen. Dazu gehören unter anderem die Rolle des Visionärs, des Kundenvertreters, des Kollaborateurs, des Influencers, des Experimentators, des Entscheidungsträgers und des Verfechters von Stakeholder-Engagement, Klarheit, Produktqualität und Wertrealisierung.

Der Product Owner ist stets verantwortlich für:
● Stakeholder-Engagement, Verständnis der Stakeholder, ihrer Macht, Erwartungen, Bedürfnisse und Wünsche;
● Kontinuierliches Wahrnehmen, Zuhören, Lernen und Anpassen nach Bedarf;
● Kontinuierliches Abwägen von Kompromissen, einschliesslich aber nicht beschränkt auf:
- Qualität, Geschwindigkeit, Fähigkeit, Risikominderung, Wert, Einfachheit (149);
- Stakeholder und ihre vielfältigen, oft konkurrierenden Erwartungen und Grenzen;
- Wert, Arbeitsklima, potenzielle Kunden;
● Entwickeln und explizites Kommunizieren des Produktziels;
● Entwickeln und effektives Kommunizieren eines kohärenten Produkt-Narrativs;
● Erstellen und klares Kommunizieren von Product Backlog Items;
● Ordnen von Product Backlog Items;
● Sicherstellen, dass das Product Backlog transparent ist und verstanden wird;
● Effektives Kommunizieren von Ergebnissen, die durch Massnahmen in der Definition von „Outcome Done“ unterstützt werden;
● Das letzte Wort bei der Definition von „Outcome Done“ haben;
● Fördern der qualitativ hochwertigen Erstellung, Entdeckung, Lieferung und Validierung von Wert; und,
● Andere Produktmanagementaktivitäten nach Bedarf.

Der Product Owner kann die oben genannten Aufgaben übernehmen oder mit dem Scrum Team zusammenarbeiten, um gemeinsam die Verantwortlichkeiten für die oben genannten Aufgaben zu vereinbaren. Unabhängig davon bleibt der Product Owner ergebnisverantwortlich.

Damit der Product Owner erfolgreich sein kann, sollten alle Stakeholder und Unterstützer seine Entscheidungen respektieren. Diese Entscheidungen sind im Inhalt und in der Reihenfolge des Product Backlogs und durch das inspizierbare Increment beim Sprint Review sichtbar. Der Product Owner hat von der Organisation delegierte Befugnisse.

Product Ownership erfordert starke Fähigkeiten im Produktmanagement und Fachwissen. Ein Product Owner, dem diese Fähigkeiten fehlen, benötigt möglicherweise Unterstützung und Anleitung, bis er das erforderliche Fachwissen entwickelt hat. Der Kontext ist wichtig. Als Faustregel gilt jedoch, dass ein Product Owner, der weder willens, bereit noch in der Lage ist, sich Kenntnisse im Produktmanagement anzueignen, als Product Owner zurücktreten sollte. Ein Fachexperte ist nicht unbedingt die beste Wahl für einen Product Owner, da Produktmanagementfähigkeiten und Führungsqualitäten erforderlich sind; beispielsweise ist die Verantwortlichkeit des Product Developers oft besser geeignet.

Wenn das Scrum Team ungewollt an mehreren Produkten, Plattformen oder Projekten arbeitet, sollte jeder Produkt-, Plattform- oder Projektmanager ein Stakeholder (und Unterstützer) des Product Owners sein und zusammenarbeiten, um den langfristigen Wert zu maximieren. Scrum ermutigt das Scrum Team, fokussiert und engagiert zu bleiben, was ihm hilft, wertvolle Ergebnisse zu liefern und die Fallstricke zu vermeiden, die mit dem Betrieb als „Feature-Fabrik“ verbunden sind.

Der Product Owner ist eine Person, nicht ein Ausschuss oder eine Technologie. Wer das Product Backlog ändern möchte, muss den Product Owner überzeugen. Der Product Owner maximiert den langfristigen Wert und geht dabei oft Kompromisse ein.

Scrum Master
Der Scrum Master ist eine Rolle und eine Verantwortlichkeit. Der Scrum Master muss ein Mensch sein. Der Scrum Master ist ein Change Agent, der auf allen Organisationsebenen und in allen Geschäftsbereichen tätig ist. Der Scrum Master geht mit gutem Beispiel voran und fördert die Effektivität des Product Owners, des Scrum Teams, der Stakeholder und der Unterstützer bei der Einführung von Scrum. Der Scrum Master versteht die Komplexität (30-35) und ist geschickt darin, die nächste richtige Sache zu ermöglichen.

Der Scrum Master sollte je nach Situation angemessene Verhaltensweisen an den Tag legen; dazu gehören u.a. die Rolle des Anleiters, des Coaches, des Mentors, des Lehrers, des Beobachters, des Beseitigers von Hindernissen, des Change Agents, des Vermittlers von Effektivität und des Verfechters kontinuierlicher Verbesserung. Der Scrum Master ist weder ein Teamadministrator, Statusmanager, Taskmaster, Regeldiktator, Sitzungsraumbucher, Bericht-Dashboard-Verwalter, Vorsitzender, Held, Koordinator noch ein Scrum Master in Abwesenheit, der alles dem „Selbstmanagement“ überlässt.

Der Scrum Master ist verantwortlich für die Effektivität des Scrum Teams, der Stakeholder, der Unterstützer und der betroffenen Personen bei der Einführung von Empirie (67), Selbstmanagement und Scrum-Einführung, wie in diesem Dokument beschrieben. Der Scrum Master kümmert sich um alles, was den Fortschritt eines Scrum Teams behindert oder verlangsamt und nicht vom Scrum Team gelöst werden kann.

Der Scrum Master unterstützt das Scrum Team, den Product Owner und die Unterstützer auf verschiedene Weise, unter anderem indem:

● Er hilft allen, die Scrum-Theorie und -Praxis zu verstehen, indem er sie bei Bedarf schult oder coacht;
● Er ermöglicht es dem Scrum Team und den Unterstützern, sich auf vielfältige Weise kontinuierlich zu verbessern;
● Er fördert rechtzeitige, zielgerichtete und absichtliche Interaktionen;
● Er stellt sicher, dass das Scrum Team eine geeignete Definition von „Output Done“ hat;
● Er sorgt dafür, dass alle Scrum Events stattfinden und konstruktiv und produktiv sind und innerhalb der Timebox bleiben;
● Er beseitigt Hindernisse für die produktbezogene Arbeit und für die effektive Einführung von Scrum;
● Er coacht in Richtung Selbstmanagement (47) und funktionsübergreifend;
● Unterstützung des Scrum Teams, der Stakeholder und der Unterstützer beim Verständnis ihrer Bedeutung für die Unterstützung von hochwertigen Increments, die die Definition des „Output Done“ in Richtung des Produktziels und die Definition des „Outcome Done“ erfüllen;
● Verbesserung der Anpassungsfähigkeit (80) und Optimierung des Wertflusses;
● Förderung des Vertrauens auf der Grundlage von Fakten bei gleichzeitigem Bewusstsein und rechtzeitigem Handeln, um übermässiges Vertrauen zu vermeiden;
● Förderung der Veränderungsfähigkeit und der allgemeinen Handlungsfähigkeit des Scrum Teams und der Unterstützer;
● Ermutigung zu hilfreichen Verhaltensweisen innerhalb des Scrum Teams, die mit den Scrum-Werten übereinstimmen, um Vertrauen, Zusammenarbeit und hohe Leistung zu fördern; und,
● Förderung des Scrum Teams, um schnell und häufig wertvolle Arbeit zu liefern, Feedback zu erhalten und bei Bedarf Nacharbeit zu leisten.

Der Scrum Master unterstützt das Scrum Team auf verschiedene Weise, unter anderem:

● Unterstützung des Scrum Teams bei seiner Teambildung, Fortbildung und kontinuierlichen Verbesserung;
● Unterstützung des Scrum Teams beim Verständnis der Notwendigkeit klarer und prägnanter Product Backlog Items, die Wert liefern; und,
● Wachsam sein, dass das gesamte Scrum Team zielgerichtet und bewusst miteinander und mit den Stakeholdern zusammenarbeitet, die Definition von „Output Done“ beachtet und sich auf die Erstellung hochwertiger Increments gemäss der Definition von „Outcome Done“ konzentriert.

Der Scrum Master unterstützt den Product Owner auf verschiedene Weise, unter anderem:

● Hilfe bei der Entwicklung von Techniken zur effektiven Definition von Produktzielen und zur Verwaltung des Product Backlogs;
● Hilfe bei der Erstellung einer sich weiterentwickelnden Produktplanung für ein komplexes (30-35) Umfeld;
● Hilfe für den Product Owner, Ergebnisse als Massnahmen durch die Definition von „Outcome Done“ auszudrücken;
● Hilfe für den Product Owner, die Notwendigkeit klarer und prägnanter Product Backlog Items zu verstehen, die Wert liefern; und,
● Hilfe für den Product Owner, sich auf die Wertrealisierung zu konzentrieren.

Der Scrum Master unterstützt die Stakeholder auf verschiedene Weise, unter anderem:

● Wenn mehr als nur Fachwissen erforderlich ist, hilft er den Betroffenen und Stakeholdern, Folgendes zu verstehen und anzunehmen:
- Einen empirischen Ansatz für komplexe (30-35) Arbeiten, bei denen Ursache und Wirkung nur im Nachhinein kohärent sind,
- Über die empirische Prozesskontrolle hinausgehen, z. B. mehrere parallele Safe-to-Fail-Experimente durchführen, neues Denken, Exaptation (Ausweitung) oder Testen fundierter Vermutungen. Exaptation bedeutet, etwas, das für einen bestimmten Zweck hergestellt oder verwendet wurde, für einen anderen Zweck zu nutzen, insbesondere wenn man sich neuen oder unklaren Situationen gegenübersieht.
● Förderung von Aktionen, die das Mantra „Hör auf, Dinge anzufangen; fang an, Dinge fertig zu stellen“ unterstützen;
● Erleichterung der Zusammenarbeit mit den Stakeholdern, wenn dies gewünscht oder erforderlich ist;
● Unterstützung der Stakeholder beim Verständnis der Notwendigkeit klarer und prägnanter Product Backlog Items, die einen Wert liefern; und
● Unterstützung der Stakeholder, sich in erster Linie auf die Wertrealisierung zu konzentrieren.

Der Scrum Master arbeitet auf verschiedene Weise mit den Unterstützern zusammen, unter anderem:

● Führung, Schulung und Coaching der Unterstützer bei der Scrum-Einführung;
● Klärung, was einer effektiven Scrum-Einführung im Wege steht;
● Erleichterung einer disziplinierten emergenten Veränderung in eine Richtung, die die Scrum-Einführung unterstützt; und,
● Förderung organisatorischer Veränderungen in Richtung einer einfacheren Bereitstellung gegenüber einer einfacheren Verwaltung.

Der Scrum Master arbeitet auf verschiedene Weise mit der Organisation zusammen, darunter:

● Leitung, Schulung und Coaching der Organisation bei der Einführung von Scrum;
● Planung und Beratung bei der Einführung von Scrum in der Organisation;
● Zusammenarbeit mit verwandten Abteilungen zur Unterstützung der Einführung von Scrum; und,
● Beseitigung von Hindernissen für die Einführung von Scrum.

Scrum Master können sich mit anderen Scrum Mastern oder Supportern zusammenschliessen, um die gesamte Organisation zu unterstützen; sie können bei Bedarf auch mit anderen Change Agents oder Führungskräften zusammenarbeiten. Der Scrum Master ist als Change Agent für die Qualität der Scrum-Einführung verantwortlich und sollte mit anderen Change Agents zusammenarbeiten, um diese zu verbessern.

Der Scrum Master ist eine Person, kein Gremium oder eine Technologie, und dient dem Product Owner, dem Scrum Team, den Stakeholdern und der gesamten Organisation. Als Change Agent und Leader sollte der Scrum Master im Allgemeinen Menschen einladen, sich an der Veränderung zu beteiligen. Es ist hilfreich, wenn der Scrum Master den Wertfluss (68, 69), Lean (63), die Komplexitätstheorie (30-35) und andere unterstützende und ergänzende Theorien in diesem Dokument versteht und die Menschen beim Wie unterstützt.

Es ist auch hilfreich, wenn der Scrum Master hartnäckig ist und einen unersättlichen Appetit auf Lernen und Veränderung hat.

Scrum Master zu sein ist eine Berufung, bei der es Lohn genug ist, anderen zum Erfolg zu verhelfen. Ein Scrum Master sucht nicht das Rampenlicht. Wie jede gute Führungskraft zollt er anderen Anerkennung und übernimmt die Verantwortung, wenn etwas schief läuft. Ein längerer Verbleib in der Rolle hilft, das Scrum Team zu seinem vollen Potenzial zu führen, aber nur, wenn die Product Developers gemeinsam Selbstmanagement entwickeln. Ein Scrum Master, der sich wie ein Elternteil verhält, fördert nicht das Selbstmanagement eines Scrum Teams. Es kommt auf den Kontext an. Als Faustregel gilt jedoch, dass ein Scrum Master, der weder willens, bereit noch in der Lage ist, eine Veränderung herbeizuführen, als Scrum Master zurücktreten sollte.

Die Scrum Artefakte im Expansion Pack

Die Artefakte von Scrum sorgen für Transparenz darüber, was das Scrum Team und die Stakeholder glauben, dass es Wert schafft. So kann jeder die gleiche Grundlage für Überprüfung und Anpassung haben.

Jedes Artefakt enthält eine Verpflichtung:

● Für das Produkt, das den Stakeholdern dient, ist es die Definition von Outcome Done.
● Für das Increment, das ein Update-Kandidat für das Produkt ist, ist es die Definition von Output Done.
● Für das Product Backlog ist es das Produktziel.
● Für das Sprint Backlog ist es das Sprintziel.

Nach der Freigabe des Increments (Output) ist das Produkt das, was Wert schafft (Outcomes). Wert ist die messbare oder beobachtbare Erfüllung oder Schaffung von Erwartungen, Bedürfnissen oder Wünschen aus Sicht der Stakeholder.

Diese Verpflichtungen verstärken die Säulen Transparenz, Überprüfung und Anpassung und ermöglichen eine empirische Prozesskontrolle (64-66). Das Produktziel ist so lange festgelegt, wie keine gegenteiligen Beweise oder Beobachtungen in der Ergebnisdefinition des beobachteten Produkts auftauchen. Die Definition des Outputs Done wird während des Sprints nicht abgeschwächt. Was könnte also stattdessen abgeschwächt oder verändert werden? Es könnten die Akzeptanzkriterien für ein bestimmtes Product Backlog Item sein, die Implementierung oder Treue eines bestimmten Features oder sogar alternative Product Backlog Einträge zur Erreichung des Sprintziel, etc.

Wenn sich das Produktziel häufig verschiebt, könnte das ein Hinweis darauf sein, dass etwas nicht stimmt, vielleicht weil der Fokus auf das Wesentliche fehlt. Bei der Fokussierung geht es darum, professionell zu sein und zu entscheiden, woran gearbeitet werden soll, aber auch, woran nicht.

Produkt

Das Produkt ist ein Artefakt. Ein Produkt kann eine ganzheitliche Erfahrung oder eine Plattform sein. Es kann auch eine physische, digitale oder hybride Dienstleistung sein, die den Stakeholdern (und den Nutzern) einen kontinuierlichen Wert liefert.

Ein Erlebnis oder eine Erfahrung (“experience”) ist eine spezifische Lösung, die auf die Bedürfnisse der Stakeholder, inkl. der Nutzer, ausgerichtet ist, idealerweise ausserhalb der Organisation. Es bietet eine direkte Interaktion, die einen Wert schafft. Sie ist in der Regel darauf ausgerichtet, ein bestimmtes Problem oder eine bestimmte Gelegenheit oder eine Reihe von Problemen für Stakeholder zu lösen, einschliesslich, aber nicht beschränkt auf Kunden, Entscheidungsträger und Nutzer.

Eine Plattform ist eine architektonische Konstruktion, eine grundlegende Infrastruktur oder ein Tool-Set, das Entwicklern die Erstellung von Produkten ermöglicht, um eine Erlebnis zu bieten. Plattformen bieten eine Basis für die Entwicklung mehrerer Produkte. Der Schwerpunkt liegt dabei eher auf Skalierbarkeit, Zuverlässigkeit und Flexibilität für Ingenieure als auf direkter Benutzerinteraktion.

Das Scrum Team und die Stakeholder müssen zu jeder Zeit ein klares Verständnis davon haben, was das Produkt ist, wer die Kundinnen, Benutzer oder Entscheidungsträgerinnen sind und um welche Art von Produkt es sich handelt - wie z. B. ein Produkt für Endbenutzer, Mitarbeitende oder Scrum Teams - mit unterschiedlichen Stakeholdern und auf welche Weise es Wert schafft. Ein Produkt ist evolutionär und oft langlebig. Das Produkt benötigt ein einziges Product Backlog, um die Transparenz zu erhöhen und den Wert zu maximieren.

Der Kontext ist wichtig. Als Faustregel kann man jedoch sagen, dass folgende Aspekte für ein Produkt hilfreich ist, damit es sich längerfristig durchsetzt:

● Zufriedenheitslücken hinreichend adressiert;
● wertvoll, wünschenswert, realisierbar, nutzbar, machbar, sicher und geschützt ist;
● über eingebaute Expertise verfügt;
● eine überzeugende, klare und ergebnisorientierte Produktvision, Produktstrategie und ein Produktziel hat, oft einschliesslich Absicht, Begründung und Nichtzielen;
● sich anpasst und verbessert, um neue Entwicklungen zu erkennen, darzustellen oder zu messen (71); und,
● erweiterbar und wartbar ist.

Das Produkt ist die Manifestation dessen, warum wir tun, was wir tun.

Commitment: Definition von Outcome Done
Die Definition von Outcome Done ist eine Verpflichtung. Sie beschreibt die beobachtbaren (quantitativen oder qualitativen) Messgrössen, die erforderlich sind, um den realisierten Nutzen nachzuweisen, was häufig als Wertvalidierung bezeichnet wird. Sie kann sich auf das Gesamtprodukt oder ein bestimmtes Ziel beziehen. Es ist oft am besten, die Massnahmen zur Wertvalidierung vor Beginn der Realisierung zu definieren, da dies Verzerrungen und Fehlinterpretationen vermeidet.

Die Ergebnisse und die damit verbundenen Interpretationen dienen als Grundlage für künftige Anpassungen und bestätigen im Idealfall die beabsichtigten Auswirkungen auf die Stakeholder (einschliesslich, aber nicht beschränkt auf die Auswirkungen auf das Unternehmen oder den Benutzer). Dies könnte für ein bestimmtes Ziel gelten, z. B. für eine grössere Funktion oder mehrere Funktionen, und durch Produkttelemetrie validiert werden (das Produkt kann seine eigene Nutzung messen). Alternativ könnte es sich um das Gesamtprodukt handeln, bei dem es häufig um die strategischen Auswirkungen und die Validierung der Wirksamkeit des durchgeführten strategischen Einsatzes geht (120-123). Oder eine Kombination aus beidem.

Bevorzuge direkte Beweise gegenüber Zufallsfunden. Zum Beispiel:

● Kundenergebnisse könnten sich auf die Bereitstellung eines messbaren Werts für die Kunden konzentrieren, wie z. B. erhöhte Kundenzufriedenheit, langfristige Kostensenkung oder die Anzahl der erledigten Kundenaufträge.
● Benutzerergebnisse könnten sich auf spezifische Änderungen im Benutzerverhalten beziehen, die Probleme lösen und Erfahrungen verbessern, wie z. B. effizientere Erledigung von Aufgaben oder Nutzung neuer Funktionen.
● Ergebnisse für Produktstakeholder könnten diese Verhaltensänderungen mit Produktleistungskennzahlen in Verbindung bringen, z. B. Trends bei Kunden-, Entscheider-/Benutzerkennzahlen für das Produkt, Zeit bis zur Freigabe des Produkts, Zeit bis zum Lernen, Zeit bis zum Umschwenken, usw.
● Ergebnisse für Geschäftsinteressenten, z. B. Einhaltung von Vorschriften, langfristige Kostenreduzierung, Geschäftsergebnisse, Trends bei Marktanteilen, Kundenzufriedenheit über alle Produkte hinweg, organisatorische Zeit bis zur Freigabe, Zeit zum Lernen, Zeit bis zum Wechsel usw.
● Ergebnisse des Scrum Teams, wie z. B. verbesserte technische Fähigkeiten (psychologischer Flow (70), Release Häufigkeit , Werkzeuge, Fähigkeiten, technische Schulden, UX- oder CX-Schulden, Kapazität), Klima/Kultur für Nettoverbesserung und Innovation.

User eXperience (UX)- oder Customer eXperience (CX)-Schulden sind die Summe der Design- und Implementierungsentscheidungen - beabsichtigt oder unbeabsichtigt -, die ein Produkt oder eine Dienstleistung weniger nutzbar machen, weniger Spass machen und weniger Kosten verursachen. Das Erkennen, Verfolgen und Angehen dieser Schuld ist wesentlich für die Bereitstellung von Produkten, die wirklich den Bedürfnissen und Erwartungen der Nutzer entsprechen.

Massnahmen im Zeitverlauf machen Produkt-, Markt- und Stakeholder-Trends (einschliesslich, aber nicht beschränkt auf Kunden oder Nutzer) transparent; diese können jederzeit während des Sprints, inkl. während des Sprint-Reviews, überprüft werden.

Increment

Das Increment ist ein Artefakt. Es ist die Integration der abgeschlossenen Arbeit nach dem Standard der Definition von Output Done. Das Increment ist ein Output und ein Produktkandidat.

Innerhalb eines Sprints können mehrere Inkremente durch die Fertigstellung von Product Backlog Einträge erstellt werden. Jedes Increment wird gründlich verifiziert, nutzbar gemacht und mit allen vorherigen Incrementen integriert. Das resultierende aggregierte Increment wird so bald wie möglich, spätestens beim Sprint Review, geprüft. Das Increment muss brauchbar und nützlich sein, um Ergebnisrückmeldungen zu ermöglichen. Ein Increment ist zentral für Scrum, da es eine fortlaufende Wertvalidierung ermöglicht.

Ein Inkrement-Kandidat qualifiziert sich erst dann als Inkrement, wenn er den Qualitätsstandard der Definition of Output Done erfüllt. Nur ein Inkrement kann freigegeben werden. Ein Increment sollte ein konkreter Schritt in Richtung des Produktziels sein. Incremente können an die Stakeholder geliefert oder vor dem Sprint Review freigegeben werden. Die beste Wertvalidierung wird durch Ergebnis-Feedback erreicht.

Commitment: Definition von Output Done

Die Definition von Output Done ist eine Verpflichtung. Sie beschreibt formal die Qualitätsmassnahmen, die die Sorgfaltspflicht für das Increment zum Ausdruck bringen, damit es an die Stakeholder ausgeliefert werden kann.

Die Definition of Output Done umfasst typischerweise (aber nicht nur) sowohl technische Standards als auch Produktqualitäten. Das Scrum Team ist für die Erstellung verantwortlich, es sei denn, die Organisation stellt sie zur Verfügung. Wenn mehrere Scrum Teams an demselben Produkt arbeiten, haben sie dieselbe Definition.

Das Scrum Team ist verpflichtet, sich an die Definition des Outputs Done zu halten und diesen kontinuierlich zu verbessern. Das Increment ist kumulativ. Die Definition of Output Done dient dem Wohl des Produkts und seiner Stakeholder. Die Definition des erreichten Outputs ist der allgemeine Qualitätsstandard für das gesamte Increment, nicht der spezifische Standard für jedes Element (z. B. die Abnahmekriterien).

Ein freigegebenes Increment ermöglicht ein Ergebnisfeedback zur Validierung von Definition of Outcome Done.

Product Backlog

Das Product Backlog ist ein Artefakt. Es ist die entstehende, geordnete (sequenzierte) Liste von Product Backlog Einträge, die zum Erreichen des Produktziels benötigt werden. Das Product Backlog sorgt für Transparenz (Arbeitsklarheit) und ist die einzige Arbeitsquelle für das Scrum Team, um das Produktziel zu erreichen. Der Product Owner, der immer den Wert im Auge behält, leitet die Anordnung der Product Backlog Einträge im Product Backlog. Ein kleineres Product Backlog bietet oft mehr Transparenz.

Product Backlog Eintrag (Item)
Ein Product Backlog Eintrag ist ein potenziell wertvolles Element im Product Backlog. Es hat nicht unbedingt ein bestimmtes Format. Es soll sich mit einem Problem oder einer Gelegenheit befassen. Es kann neben der Definition des Outputs auch Abnahmekriterien enthalten, die angeben, wann die Arbeit abgeschlossen ist. Es kann sein, dass man genau das liefert, was angefordert wurde, aber trotzdem nicht genügend Ergebnisse liefert. Ein Product Backlog Eintrag kann also auch klar definierte Ergebniskriterien enthalten, die Auskunft darüber geben, wann ein ausreichender Wert geliefert wurde, zusätzlich zu dem, was bereits in der Definition von Outcome Done steht.

Ein Product Backlog Eintrag ist ein einzelnes Stück Arbeit, das einen Wert entdeckt oder liefert. Ein Product Backlog Eintrag kann sich jederzeit weiterentwickeln, auch während die Produktentwickler daran arbeiten. Während dem Refinement wird es in kleinere, verständlichere (meist für das Scrum Team) Product Backlog Einträge unterteilt, die einen Wert liefern könnten. Gelegentlich kann es vorkommen, dass ein Eintrag im Product Backlog nicht mit dem Produktziel in Verbindung steht; wenn dies häufig vorkommt, lohnt es sich zu prüfen, ob die Fokusebene nicht dort ist, wo sie sein sollte. Das Scrum Team und die Stakeholder sollten sich auf die Ergebnisse konzentrieren und nicht auf die Ergebnisse, und das Scrum Team sollte nicht zu einer „Feature-Fabrik“ oder „Discovery-Fabrik“ werden.

Akzeptanzkriterien
Akzeptanzkriterien, falls vorhanden, beschreiben, wann ein Output für ein bestimmtes Product Backlog Eintrag vollständig ist, zusätzlich zur Definition von Output Done. Akzeptanzkriterien in verfeinerten Elementen sollten eindeutige Klarheit darüber schaffen, was verlangt wird. Akzeptanzkriterien umfassen Kriterien, die für ein Product Backlog Eintrag spezifisch sind und nicht bereits in der Definition von Output Done behandelt werden; sie können funktional oder nicht-funktional sein. Akzeptanzkriterien können sich jederzeit weiterentwickeln, auch während die Product Developer an ihnen arbeiten.

Ergebniskriterien (Outcome Criteria)
Ergebniskriterien, sofern vorhanden, beschreiben die Absicht des Product Backlog Einträge; es ist das Warum hinter dem Was. Die Erfüllung der Ergebniskriterien ergänzt häufig die Definition des Ergebnisses „erledigt“ für das Produkt. Sie können Kriterien enthalten, die für einen Product Backlog Eintrag spezifisch sind und nicht bereits in der Definition von „Outcome Done“ angesprochen werden. Wenn Fragen auftauchen, geben die Ergebniskriterien eine Richtung vor; sie können in Form einer Erzählung oder von Massnahmen sein, idealerweise letzteres. Ergebniskriterien können jederzeit weiterentwickelt werden, auch während die Product Developer daran arbeiten.

Refinement
Das Refinement ist eine Aktivität. Sie kann formell (ein zusätzliches Ereignis) oder informell sein. Refinement ist ein fortlaufender, sich weiterentwickelnder Prozess, der die Klarheit fördert und das Risiko reduziert; er schafft ein ausreichendes Verständnis und Vertrauen, dass die ausgewählten oder anstehenden Product Backlog Items fertig sind (sie können gemäss der Definition von Output Done innerhalb weniger Tage oder kürzer abgeschlossen werden). Es werden verschiedene Arten von Abhängigkeiten berücksichtigt.

Beim Refinement werden die Product Backlog Items in kleinere, besser verständliche (vor allem für das Scrum Team) Product Backlog Items zerlegt. Dabei können weitere Details wie Beschreibung, Annahmekriterien, Ergebniskriterien, Reihenfolge und Grösse hinzugefügt werden. Die Attribute variieren, sollten aber für das Scrum Team sinnvoll sein. Die Verfeinerung kann Recherchen beinhalten, einschliesslich, aber nicht beschränkt auf, Problem- oder Chancenvalidierung, Benutzer- oder Kundenerfahrung, Lösungsvalidierung. Die Product Developer und niemand sonst sind für die Dimensionierung der Product Backlog Items verantwortlich. Der Product Owner kann die Product Developers beeinflussen, indem er ihnen hilft, mögliche Kompromisse zu verstehen und auszuwählen.

Zu den Teilnehmenden gehören häufig Stakeholder und Mitglieder des Scrum Teams; es ist nicht ungewöhnlich, dass dir Product Developers direkt mit den Stakeholdern zusammenarbeiten. Das Refinement wird häufig durch den Product Owner unterstützt oder erleichtert. Der Product Owner kann sich mehr auf die Produktverantwortung konzentrieren, wenn die Product Developer ein umfassendes Verständnis für das Produkt haben.

Im Allgemeinen handelt es sich um eine vorausschauende Aktivität, die Klarheit, Richtung und potenziellen Fokus für kommende Sprints bietet.

Commitment: Produktziel
Das Produktziel ist eine Verpflichtung. Es wird durch das Product Backlog dargestellt, dessen Eigentümer der Product Owner ist. Es ist das derzeitige einzige, strategischere, ehrgeizige Ziel (das Warum). Es gibt die Richtung für das Produkt vor und ermöglicht den Product Developers, die an dem Produkt arbeiten, den Fokus. Es verbessert die Transparenz, indem es den Product Developers eine klare, wertvolle Richtung vorgibt, auf die sie mit Hilfe eines eher taktischen Sprintziels (das Warum für den Sprint) hinarbeiten können.

Ein Produktziel ist das mittelfristige Ziel für das Scrum Team und die Stakeholder (und Supporter). Das Scrum Team sollte ein Produktziel erfüllen (oder verwerfen), bevor es das nächste in Angriff nimmt.

Ein Produktziel ist in der Regel eine noch unbewiesene Behauptung über den Wert. Es kann als eines von vielen Dingen ausgedrückt werden, einschliesslich einer Reihe von Hypothesen über das Schliessen oder Verringern von Zufriedenheitslücken. Sie sorgt für das richtige Gleichgewicht, indem sie sich auf eine Teilmenge der vielfältigen Erwartungen und Grenzen der Stakeholder (einschliesslich, aber nicht beschränkt auf die Kunden oder Nutzer) konzentriert. Durch Überprüfung und Anpassung ist es wichtig, Unsicherheit (72), Ergebnis-Feedback, Nebenwirkungen und andere Erkenntnisse zu berücksichtigen.

Wie stehts um das Produktziel?
Viele Unternehmen arbeiten mit einer Produktvision, die hilft, eine mögliche Zukunft zu visualisieren. Das Scrum Team kann eine Vision als Input für die Überlegung eines Produktziels verwenden. Eine Produktvision ist eine sinnvolle, langfristige Reihe von wertvollen gewünschten Ergebnissen. Das mittelfristige Produktziel ist oft ein Sprungbrett zu einer langfristigen Produktvision.

Während das Scrum Team und die Stakeholder das Produktziel überprüfen und anpassen, müssen sie offen für die Idee sein, dass auch die Produktvision oder das Produktziel angepasst werden müssen. Oft werden mehrere Produktziele nacheinander erreicht, während man auf eine Vision hinarbeitet.

Der wichtigste Punkt ist, dass eine Produktvision oft frei erfunden ist und nichts davon wahr sein kann. Das Bilden von Hypothesen und das Durchführen von Experimenten in eine bestimmte Richtung ist von wesentlicher Bedeutung und ist der Bereich, in dem Scrum den grössten Wert generieren kann.

Eine Produktvision kann inspirierend sein, aber auch überwältigend wirken. Das Produktziel reduziert diese Überforderung, indem es als konkreter, vertikaler Ausschnitt der Produktvision oder als Wegbereiter für diese fungiert.

Sprint Backlog
Das Sprint Backlog ist ein Artefakt. Es setzt sich zusammen aus dem Sprintziel (dem Warum für den Sprint), dem Satz ausgewählter Product Backlog Items (dem Was, auch bekannt als Vorhersage) für den Sprint und enthält oft einen umsetzbaren Plan für die Lieferung des Increments (das Wie). Es sorgt für Transparenz (Arbeitsklarheit) während des gesamten Sprints.

Das Sprint Backlog ist ein Plan von und für die Product Developer. Es ist die Sichtweise der Product Developer auf die zu verstehende Arbeit, um das Sprint Goal (das Warum für den Sprint) zu erreichen. Nehmen wir ein suboptimales Szenario an, in dem die meisten Elemente im Sprint Backlog ständig in keinem Zusammenhang mit dem Produktziel stehen. In diesem Fall werden die Scrum-Werte Focus und Commitment nicht eingehalten.

Im Zusammenhang mit dem Sprintziel aktualisieren die Product Developer ihren Plan, sogar die Prognose, während des Sprints, wenn sie mehr erfahren. Das Sprint Backlog sollte genug Arbeit enthalten, um anzufangen, z.B. mit einem oder zwei Product Backlog Items in Richtung Sprintziel. Die Product Developer überprüfen ihren Fortschritt auf dem Weg zum Sprintziel im Daily Scrum oder öfters. Die Product Developer lernen, sich anzupassen und auf Unsicherheiten zu reagieren (72).

Commitment: Sprintziel
Das Sprintziel ist eine Verpflichtung, die vom Scrum Team erstellt wird und ihm gehört. Das Sprintziel ist das einzige vereinheitlichende Ziel des Sprints (das Warum) für die Product Developer, das im Sprint Planning erstellt wird. Die Lieferung des Sprint Ziel ist eine Verpflichtung der Product Developer. Das Sprint Backlog (einschliesslich des „Warum“, des ‚Was‘ und oft auch des „Wie“) bietet Fokus und Flexibilität in Bezug auf die sich entwickelnde Arbeit und verbessert so die Transparenz.

Das Sprintziel ermutigt das Scrum Team, zusammen zu arbeiten und nicht an getrennten Initiativen. Wenn sich die Arbeit als anders herausstellt als von den Product Developer erwartet, arbeiten die Product Developer mit dem Product Owner zusammen, um Möglichkeiten innerhalb des Sprints auszuhandeln, ohne das Sprintziel zu beeinträchtigen. Niemand schreibt den Product Developer vor, wie sie ihre Arbeit dimensionieren oder durchführen sollen.

Die Scrum Events im Expansion Pack

Scrum kombiniert vier zeitlich begrenzte Events zur Überprüfung und Anpassung innerhalb eines übergeordneten, ebenfalls zeitlich bestimmten Events: dem Sprint. Diese Events stützen die drei Scrum-Säulen Transparenz, Überprüfung und Anpassung. Releases ermöglichen Wertschöpfung – idealerweise kontinuierlich. Seltene Releases führen zu verzögertem Feedback zu den Ergebnissen.

Eine Timebox ist eine festgelegte maximale Zeitspanne von Anfang bis Ende eines bestimmten Events – sie darf nicht mit der Erwartung verwechselt werden, dass diese Zeit vollständig ausgeschöpft wird. Der Zweck einer Timebox in Scrum ist es, die Auswahl von wirklich wichtigem Arbeitspensum zu fördern und damit Fokus zu schaffen, um rasch Resultate zu erzielen. In Scrum ist die Sprintdauer für ein bestimmtes Scrum Team konstant, sie stellt daher keine Timebox im eigentlichen Sinne dar.

Die Scrum-Events schaffen Rhythmus (Kadenz) und reduzieren den Bedarf an weiteren Meetings, die nicht Teil von Scrum sind. Idealerweise finden die Events am selben Ort und zur selben Zeit statt, um Komplexität zu verringern (30–35) und die Bildung von Gewohnheiten zu fördern. Gute Moderation steigert die Wirksamkeit. Schlechte Moderation hingegen gefährdet die Ausrichtung auf das Sprintziel, das Produktziel, die drei Scrum-Säulen sowie die Scrum-Werte.

Jedes Event hat einen eigenen Zweck und sollte tiefgehende, sinnvolle Arbeit beinhalten. In ihrer Gesamtheit bilden die Scrum-Events ein Gerüst aus Transparenz, um zu überprüfen, sich anzupassen, innezuhalten und zu reflektieren. Sie unterstützen strukturiertes Denken und Arbeiten, Wirksamkeit und eine ausgewogene Arbeitslast.

Kommunikation ist entscheidend, damit das Scrum Team und seine Unterstützenden sich auf das Wesentliche fokussieren. Mit Ausnahme des Sprints dürfen die anderen Events auch kürzer ausfallen – sofern dabei keine Kohärenz verloren geht.

Der Sprint
Der Sprint ist ein Event, bei dem Ideen in Wert umgewandelt werden. Der Sprint ist das Container-Ereignis. Er ist eine Iteration mit einer bestimmten Zeitspanne, in der die Arbeit durchgeführt wird. Er bietet Fokus und Stabilität. Ein Sprint ist nicht länger als vier Wochen. Ein neuer Sprint beginnt unmittelbar nach dem Abschluss des vorherigen Sprints. Alle Arbeiten, die zur Erreichung des Produktziels notwendig sind, finden innerhalb von Sprints statt.

Sprints sind der Herzschlag von Scrum, in dem das Scrum Team Ideen in brauchbare, nützliche und potenziell wertvolle Increments umwandelt. Das Increment wird so schnell wie praktisch möglich freigegeben, wobei die Notwendigkeit eines frühen Feedbacks zum Ergebnis berücksichtigt wird. Eine fehlende Freigabe an eine Teilmenge von Stakeholdern (einschliesslich, aber nicht beschränkt auf echte Kunden, Entscheidungsträger und Benutzer) kann zu einem Mangel an rechtzeitigem Feedback zum Ergebnis führen. In einem Sprint können mehrere Incremente erstellt werden; das Scrum Team sollte sich bemühen, den Wert durch frühzeitige und häufige Freigaben zu validieren, wo dies möglich ist.

Während des Sprints:
● Keine Änderungen die das Sprintziel gefährden;
● Die Increment(s) sollen in ihrer Qualität nicht abnehmen
● Das Product Backlog wird nach Bedarf verfeinert; und,
● Wenn weitere Erkenntnisse vorliegen, können die laufenden Arbeiten geklärt und mit dem Product Owner neu verhandelt werden, ohne das Sprintziel zu beeinflussen.

Sprints ermöglichen Ergebnisse, indem sie mindestens alle vier Wochen eine Überprüfung und Anpassung des Fortschritts zum Sprintziel sicherstellen. Ist ein Sprint zu lang, kann das Sprintziel seine Gültigkeit verlieren – Komplexität und Risiko steigen (30–35). Kürzere Sprints generieren oft mehr Lernzyklen und begrenzen Risiken.

Kürzere Sprints setzen meist verbesserte Fähigkeiten voraus (z. B. Refinement, vertikale Zerteilung, technisches und fachliches Know-how). Der Kontext ist entscheidend – das Scrum Team strebt nach der richtigen Balance.

Es gibt ergänzende Praktiken zur Einschätzung oder Prognose des Fortschritts, wie Burndown-, Burn‑up-Diagramme, Flow‑Analysen, Monte‑Carlo‑Vorhersagen, Schätzung grosser Aufwände, Fuzzy‑Sets (110) usw. Zwar hilfreich, ersetzen sie nicht die Bedeutung von Empirie (67). In komplexen Umgebungen (30–35) kann Vergangenes für zukunftsgerichtete Entscheidungen genutzt werden, aber die Zukunft bleibt ungewiss.

Man kann einen Sprint als Mini-Projekt sehen: klar definiertes Ergebnis, bestimmte Dauer und kalkulierbare Kosten – allerdings laufen viele Aktivitäten parallel und nicht sequenziell.

Ein Sprint kann abgebrochen werden, wenn das Sprintziel obsolet wird – nur der Product Owner ist dazu befugt. Kürzere Sprints senken die Wahrscheinlichkeit eines Abbruchs.

Sprint Planning
Sprint Planning ist ein Event – das erste im Sprint, in dem das Scrum Team Fokus setzt und Engagement erzeugt. Dabei wird das strategischere Produktziel betrachtet und gibt die Richtung vor. Die Product Developers erstellen das Sprint Backlog: Sprintziel, ausgewählte Backlog-Items und der Plan zu deren Umsetzung.

Themen im Sprint Planning:

• Das Warum des Sprints: Der Product Owner schlägt Ideen vor, wie der Wert im Sprint gesteigert werden kann. Das Team definiert daraus ein Sprintziel, das bis zum Ende des Events formuliert sein muss.

• Das Was zum Warum: Gemeinsam mit dem Product Owner wählen die Product Developers Elemente aus dem Product Backlog aus. Refinement vertieft das Verständnis. Die Items müssen nach Definition of Output Done umsetzbar sein.
  Die Auswahl hängt von Erfahrung, vertikaler Zerteilung, Kapazität und Definition ab – so steigt die Zuversicht in die Prognose des Sprint-Ergebnisses.

Erfolgreiche Teams überladen sich nicht, planen Fertigstellung oft früher und nutzen Puffer für Unerwartetes (85). So bleiben Fokus und Qualität erhalten – Stakeholder erhalten Wert früher. Dauerhafte Überlastung oder plötzliche Veränderungen verursachen Stress – Jeff Sutherland nennt es „Bayesian surprise“. Gute Kommunikation, professioneller Umgang mit Unvorhergesehenem (71) und kleine, regelmässige Veränderungen fördern das frühzeitige Liefern.

Das Wie des Was bestimmen ausschliesslich die Product Developers – niemand weist ihnen ihre Arbeit zu, auch nicht der Product Owner.

Sprint Planning ist auf maximal acht Stunden für einen Vier-Wochen-Sprint begrenzt – kürzer bei kürzeren Sprints. Der Kontext entscheidet, doch mindestens so viel planen, dass man loslegen kann.

Daily Scrum
Das Daily Scrum ist ein Event. Die Product Developers arbeiten täglich zusammen am Fortschritt zum Sprintziel, aktualisieren den aktionsfähigen Plan – das Sprint Backlog – bis zum nächsten Daily. Wenn das Sprintziel erreicht ist, fokussieren sie sich auf Fortschritte hinsichtlich des Produktziels.

Das Daily Scrum fördert Fokus, Kohäsion und Dringlichkeit und unterstützt Selbstorganisation (47). Meist nehmen nur die Product Developers teil, idealerweise am gleichen Ort, zur gleichen Zeit, mit hoher Regelmässigkeit.

Struktur und Methodik sind frei wählbar. Daily Scrums optimieren Kommunikation, helfen Risiken und Hindernisse zu erkennen und schnelle Entscheidungen zu treffen – so entfällt oft der Bedarf an weiteren Meetings. Das Daily ist auf maximal fünfzehn Minuten begrenzt, es kann kürzer sein.

Sprint Review
Das Sprint Review ist ein interaktives, kollaboratives Event. Meist präsentieren Scrum Team und Stakeholder: Produktziel, Definition of Output Done, Definition of Outcome Done, was erreicht wurde, gemachte Kompromisse und der Fortschritt zum Produktziel. Wenn vorhanden, werden aktuelle Metriken zur Outcome-Erfüllung gezeigt.

Das Review überprüft viele Aspekte: Produktziel, Product Backlog, Sprintziel, Erkenntnisse, Increment, Stakeholder-Erwartungen, Nebenwirkungen, Markt, neue Ideen, nächstmögliche Schritte.
Aus dem Gelernten entstehen:

1. Wahrnehmung, Lernen und Zusammenarbeit zu potenziellen nächsten Schritten

2. Anpassung von Product Backlog und evtl. Produktziel – gestützt durch Beweise

3. Anpassung der Definition of Outcome Done

Stakeholder‑Werte sind entscheidend, auch „nicht‑menschliche“ wie gesetzliche Vorgaben.
Unvollständige Backlog-Items kehren ins Product Backlog zurück oder gehen in den nächsten Sprint.
Das Review findet gegen Ende des Sprints statt und ist auf maximal vier Stunden für vier Wochen begrenzt (kürzer für kürzere Sprints).

Sprint Retrospective
Die Sprint Retrospective ist das letzte Event im Sprint. Das Scrum Team einigt sich darauf, wie es sich verbessern kann. Auch fehlerhafte Annahmen werden beleuchtet – ebenso positive Aspekte wie Technologien, Prozesse, Muster. Geprüfte Bereiche hängen vom Arbeitskontext ab. Reflektion wirkt nur in einem psychologisch sicheren Umfeld.

Im Fokus stehen hilfreiche Verbesserungen, z. B.: Increment, Resultate, Professionalität, Value-Flow, Effektivität, Zusammenarbeit, Informationstransparenz, Definitionen für „Done“, Messbarkeit, und mehr.
Die wichtigsten Verbesserungen sollten möglichst bald umgesetzt werden – Scrum lebt von kontinuierlicher, nachweisbarer Weiterentwicklung. Manche Massnahmen brauchen Unterstützung von Stakeholdern, trotzdem bleibt das Team für den Fortschritt verantwortlich („continual marginal gains“).

Die Retrospective schliesst den Sprint ab und ist auf maximal drei Stunden für Vier-Wochen-Sprints begrenzt (kürzer bei kürzeren Sprints).

Mehrere Scrum Teams arbeiten am gleichen Produkt

Wenn ein Team zu gross ist, sollte es in mehrere kohäsive Scrum Teams aufgeteilt werden, die am selben Produkt arbeiten. Sie teilen: Produktziel, Product Backlog, Product Owner, Definition of Outcome Done und Output Done.

Mehr Teams bedeuten nicht zwangsläufig höheren Wert – skalieren nur, wenn der Mehrwert den Aufwand rechtfertigt. Ein einzelnes Team muss zuerst zuverlässig ein Increment liefern können. Falls skaliert wird, nutze einen kohärenten Ansatz – oft erzeugen weniger Teams mehr Resultate.

Bei mehreren Teams reduzieren cross‑funktionale Zusammenarbeit, Wissenstransfer und gezielte Interaktionen Abhängigkeiten. Die benötigten Fähigkeiten sind domänenspezifisch und vielfältig. In diesem Kontext sind bewusste Interaktion und Professionalität (v. a. Continuous Integration) besonders wichtig.

In einem Setup mit einem Product Owner und einem Scrum Team kann dieser z. B. Product Manager oder Marketing‑ oder Technik‑Leiter sein. Beim Multi-Team‑Setup bleibt nur ein Product Owner, der strategischer wird und Probleme und Chancen an die Product Developers delegieren darf, etwa in Produktdesign oder -management.

Product Backlog
Das Product Backlog erhöht Transparenz. Weniger Backlog Einträge pro Produkt sind besser – implizit oder explizit:

• Weniger Silo-Denken, mehr Transparenz

• Besseres Verständnis für den Gesamtfortschritt

• Klarerer Überblick über den Wert des Produkts

• Früheres Erkennen von Low-Value-Arbeit

• Grössere Wahrscheinlichkeit, Wert zu realisieren

• Mit delegierbaren, produktübergreifenden Tasks wir die Rolle des Product Owners strategischer

Weniger Backlog Einträge fördern Anpassungsfähigkeit (80), doch ohne klare Ownership, passenden Kontrollbereich und direkte Stakeholder-Kommunikation entstehen Lücken. Scrum schafft einen Rahmen für Zufallsentdeckungen und Lernprozesse – gemeinsame Arbeit führt zu neuen Ideen.
Multi-learning heisst Lernen auf vielen Ebenen gleichzeitig – fachlich, methodisch, persönlich und organisational – was Teams flexibler macht und problemlösungsfähiger.

Organisationaler Wissenstransfer, wie im «New New Product Development Game» (29) beschrieben, bedeutet, Erkenntnisse aus einem Bereich systematisch im ganzen Unternehmen zu teilen.

Organisationsstrukturen sind oft auf Steuerbarkeit statt Ergebnisse ausgerichtet – frage dich: Wie viele Teams sind nötig, um Wert zu liefern? Weniger sind meist besser.

Freiheit statt Kontrolle. Gib den Teams Autonomie. Bevorzuge ausgerichtete Selbstständigkeit. Fördere bewusste, gezielte Interaktionen innerhalb und zwischen selbststeuernden Scrum Teams (47). Erschaffe ein Arbeitsklima mit minimalem, aber ausreichendem Management‑Rahmen, Gerüsten und Grenzen. Balanciere und pflege Stakeholder‑Erwartungen und -Grenzen. Baue Veränderungsfähigkeit und kontinuierlichen Wandel nicht nur in die Lieferung, sondern in den Rhythmus selbst ein.

Wenn du unsicher bist: Sieh das «New New Product Development Game» (29) an, nutze das Gute im Jetzt und verzichte auf industrialisierte Komplexität (30–35), in der nur die Mutigen etwas bewirken.

Schlussbemerkung

Jeff Sutherlands Einführung von Scrum bei Easel im Jahr 1993 wurde durch die Arbeiten von Christopher Langton (36, 37) zur Theorie komplexer adaptiver Systeme (CAS) (74–77) am Los Alamos Laboratory inspiriert. Diese zeigen, dass sich Systeme am Rand des Chaos schneller weiterentwickeln.

Scrum wird im Scrum Guide von 2020 (40) beschrieben. Tobias Mayers A Simple Guide to Scrum (58) ist eine gekürzte, bearbeitete Version des offiziellen Scrum Guides von Ken Schwaber und Jeff Sutherland. Die Scrum Hexis (52) baut aus Sicht des Jahres 2025 auf dem Scrum Guide 2020 auf, aber dieser bleibt die zentrale Referenz für Scrum.

Scrum ist wie ein Spiegel. Wenn das Bild im Spiegel nicht den Erwartungen entspricht – soll man dann den Spiegel verstecken?

Gewöhne dir an, in jedem Sprint mindestens ein Increment zu erreichen, bevor du Scrum anpasst. Jeder Teil von Scrum hat einen Zweck; das Verstehen des „Warum“ hinter jedem Element ist entscheidend. Der Kontext zählt: Kurzfristig geht es um Lieferung. Langfristig um erfolgreiche, emergente Veränderung in eine Richtung sowie um nachhaltige Wertschöpfung. Der Erfolg bei der Einführung von Scrum hängt davon ab, das Gleichgewicht zwischen kurz- und langfristigen Zielen richtig zu finden.

Sei vorsichtig damit, Ansätze anderer Organisationen zu kopieren, ohne auch ihre Kultur mitzuentwickeln. Emergent sich entwickelnde Veränderung in eine bestimmte Richtung ist die Veränderung – sie betrifft unter anderem Führung, Abläufe, Prozesse und Systeme wie HR, Finanzen, Beschaffung usw. Scrum ist Teil einer unendlichen Reise stetiger Verbesserung und Entwicklung in eine Richtung, nicht zu einem festen Ziel.

Quellen:
– Scrum Guide 2020: https://scrumguides.org
– Langton, C. A. (1980er/1990er), Complex Adaptive Systems
– Tobias Mayer: A Simple Guide to Scrum
– The Scrum Hexis (2025-Perspektive)

Danksagungen

Scrum wurde durch Lean (63), das Toyota-Produktionssystem (59-60), den Artikel „The New New Product Development Game“ der Harvard Business Review von Hirotaka Takeuchi und Ikujiro Nonaka (29) und den Empirismus bei Dupont (61) inspiriert.

Scrum wurde in den frühen 1990er Jahren entwickelt. Ken Schwaber und Jeff Sutherland präsentierten Scrum erstmals gemeinsam auf der OOPSLA-Konferenz im Jahr 1995 (62). Die erste Version des Scrum Guide (40) erschien 2009. Scrum entwickelt sich weiter.

Wir danken auch den Gutachtern, die uns Feedback zu früheren Entwürfen gegeben haben, einschliesslich, aber nicht beschränkt auf, Daryn Basson, Alex Benes, Deb Bhattacharya, Magdalena Firlit, Nichervan Fazel, Peter Fischbach, Michael Forni, Tom Gilb, Martin Hinshelwood, Jesse Houwing, Michael Huynh, Matthew Ijogi, Marc Kaufmann, Christian Neverdal, Stas Pavlov, Ian Sharp, Alisa Stolze, Mark Summers, und Nader Talai.

Scrum Guide Erweiterung auf einer Seite zusammengefasst

Scrum wird im Scrum Guide (2020) (40) beschrieben. Scrum ist ein leichtgewichtiges Rahmenwerk für die Bewältigung komplexer (30-35) Aufgaben, insbesondere in den Bereichen Produkterfindung, Entwicklung, Lieferung und Wertrealisierung. Scrum basiert auf empirischer Prozesskontrolle (Entscheidungen auf der Grundlage von Fakten) und Lean Thinking (Reduktion der Verschwendung und Konzentration auf den Wertfluss) (63). Scrum ist absichtlich unvollständig, da es die Interaktionen anleitet, anstatt detaillierte Rezepte vorzuschreiben.

Warum Scrum nutzen?
Scrum ermöglicht es Scrum Teams, Emergenz zu identifizieren, darzustellen oder zu messen (71), Ungewissheit anzunehmen, auf Veränderungen zu reagieren, häufig Werte zu liefern und zu validieren und sich kontinuierlich zu verbessern. Scrum fördert die Zusammenarbeit, die Verantwortlichkeit und die evidenzbasierte Entscheidungsfindung, wodurch die bestmöglichen Ergebnisse in einem sich schnell verändernden Umfeld erzielt werden. Selbstverwaltende Scrum Teams, die um den Wert herum organisiert sind, sind entscheidend für kreative Problemlösungen und das Ergreifen von Chancen; nicht selbstverwaltende Scrum Teams behindern die Fähigkeit, mit Komplexität umzugehen (30-35). Selbstverwaltende Scrum Teams sind nicht zu verwechseln mit individuellem Selbstmanagement.

Elemente von Scrum
1. Scrum-Theorie: Aufbauend auf drei Säulen:
● Transparenz - Arbeit und Wert für die Inspektion sichtbar machen.
● Überprüfung - Regelmässige Bewertung von Fortschritt und Ergebnissen für die Adaption.
● Anpassung - Anpassung der Pläne auf der Grundlage von Erkenntnissen und Rückmeldungen.

2. Scrum-Werte:
● Fokus, Offenheit, Mut, Engagement und Respekt ermöglichen effektive Teamarbeit; sie unterstützen Vertrauen.3. Rollen / Verantwortlichkeiten:

3. Rollen / Verantwortlichkeiten:
Scrum Team
- Ein kleines, selbstverwaltetes, funktionsübergreifendes, kognitiv vielfältiges Team bestehend aus:
○ Product Owner
- Maximiert den langfristigen Wert, bindet die Stakeholder ein und verwaltet das Product Backlog.
○ Scrum Master - Leitet die Einführung von Scrum, beseitigt Hindernisse und fördert die kontinuierliche Verbesserung.
○ Produktentwickler - Liefern in jedem Sprint durch ihre funktionsübergreifenden Fähigkeiten Inkremente.

Stakeholder - eine Einheit, Einzelperson oder Gruppe, die sich für Inputs, Aktivitäten und Ergebnisse interessiert, davon betroffen ist oder diese beeinflusst, mit einem direkten oder indirekten Interesse innerhalb oder außerhalb der Organisation, ihrer Produkte oder Dienstleistungen.○ Unterstützer, ein Stakeholder-Typ - fördert das Klima und die Umwelt und beteiligt sich wie gewünscht.○ KI - als Werkzeug oder auch als möglicher Produktentwickler, dem man aber noch nicht ganz trauen kann.

4. Scrum Events & Aktivitäten
● Scrum arbeitet in Sprints (Iterationen von bestimmter Länge bis zu vier Wochen) mit vier zeitlich begrenzten Ereignissen:
● Sprint Planning - Definieren des Sprintziel und Planen der Arbeit.
● Daily Scrum - Product Developer stimmen sich täglich über den Fortschritt zum Sprintziel oder Produktziel ab.
● Sprint Review - Überprüfe das Increment, den Wert und den Markt und passe das Product Backlog an.
● Sprint Retrospective - Reflektiere und verbessere das Scrum Team.
● Refinement - Kläre anstehende oder ausgewählte Arbeiten, formell (als optionales Event) oder informell.

5. Scrum Artefakte & Commitments
● Product & Definition of Outcome Done - Produkt und wertvolle Ergebnisse, die den realisierten Nutzen belegen.
● Increment & Definition of Output Done - Ein potenziell wertvolles, releasefähiges Kandidaten-Update für das Produkt.
● Product Backlog & Produktziel - die geordnete (sequenzierte) Liste von Arbeiten, um ein mittelfristiges, eher strategisches Ziel zu erreichen.
● Sprint Backlog & Sprintziel - ausgewählte Product Backlog Items und ein Plan für den Sprint, kurzfristiges Ziel.

Erweiterungsprotokoll

Erweiterungen

● KI-Abschnitt
● Abschnitte über selbstorganisierendes Scrum Team, Kadenz, Professionalität
● Abschnitt über die Entstehung, offen für die Idee, dass Risiko oder Abweichungen von Erwartungen nicht zwangsläufig mit der Zeit abnehmen
● Komplexität (30–35) – Der Fall für Scrum
● Abschnitt über Leadership und System Thinking
● Abschnitte über Produktdenken und Entdeckung
● Abschnitte über erste Prinzipien, Menschen und Veränderung
● Abschnitt über Produkte mit mehreren Scrum Teams
● Stakeholder-Rolle (einschliesslich Kundinnen und Kunden, Entscheidungsträger und Nutzende), Unterstützer als Stakeholder-Typ
● Abschnitte über Verfeinerung und Product Backlog Items
● Optional: Produktvision, Akzeptanzkriterien, Ergebniskriterien
● Definition of Outcome Done, verstärkte Betonung der Anpassung basierend auf Ergebnisbelegen
● Stakeholder, Wert, Ergebnisfeedback, Release, Ergebnisse, Risiko, Hindernis und Führungskraft sind definiert
● Flow-Analysen, Monte-Carlo-Wahrscheinlichkeitsprognosen, grobe Aufwandsschätzungen, Fuzzy Sets (alle optional)
● Scrum Expanded auf einer Seite
● Die Notwendigkeit, Arbeitsabläufe, Designs, Prozesse, Systeme und das Arbeitsumfeld mit Emergenz in Einklang zu bringen
● „Product Ownership erfordert starke Fähigkeiten im Produktmanagement und Fachkenntnisse ... Ein Product Owner, der nicht willens, bereit oder in der Lage ist, sich Produktmanagement-Fähigkeiten anzueignen, sollte als Product Owner zurücktreten.“
● „Ein Product Developer, der weder willens, noch bereit, noch in der Lage ist, professionell zu sein, sollte zurücktreten.“
● „Ein Scrum Master, der weder willens, bereit noch in der Lage ist, ein Veränderungsagent zu sein, sollte zurücktreten.“
● Anhänge: Cynefin®-ähnliche Erklärung – inoffiziell und nicht autorisiert, Emergent Strategy, Adaptive (80) Enterprise, Adaptive Executive oder Vorstandsmitglied

Empfehlungen

● Klärung und Änderung der Verantwortlichkeiten bei gleichzeitiger „Umarmung der Unschärfe“ (73)
● Von Scrum ist unveränderlich oder einfach zu Scrum entwickelt sich, in einigen Fällen aufgeweichte Formulierung von ‚muss‘ zu „sollte“
● Verantwortlichkeit des Product Owner zu Product Owner Rolle mit Verantwortlichkeit; Maximierung des langfristigen Wertes
● Verantwortlichkeit der Developers gegenüber der Rolle des Product Developer mit Rechenschaftspflicht
● Verantwortlichkeit des Scrum Masters gegenüber der Rolle des Scrum Masters mit Rechenschaftspflicht; Scrum Master ist eine Person, keine KI
● Product Developer können menschlich oder KI sein oder von KI unterstützt werden, mindestens ein Mensch; mehr menschliche Product Developer sind besser für die kognitive Vielfalt und die Bewältigung von Komplexität
● Scrum Team verpflichtet sich auf das Sprint Goal, nicht die ehemaligen Developers wichtig, dass Product Owner fokussiert ist
● Sprint Backlog in Richtung Sprintziel oder Produktziel, nicht nur Sprintziel
● Produktdefinition, Erwähnung der Produktstrategie, Roadmaps, Produktmodelle, Skalierung, zielorientierte Ansätze
● Betonung auf Lernen, Ergebnis-Feedback, Nebeneffekte, Outcomes statt Outputs
● Um den Wertfluss zu erhalten, müssen unvollständige Product Backlog Elemente nicht in das Product Backlog zurückkehren
● Definition von Done umbenannt in Definition of Output Done
● Betonung des vollständigen Produktlebenszyklus, des vollständigen Funktionslebenszyklus und der Wertrealisierung
● Sprint Planning Themen 1-3 umbenannt in Wieso, Was und Wie; Sprint bis zu 4 Wochen statt bis zu 1 Monat
● Mögliche zusätzliche Überprüfung des Increments und der Ergebnisse in einer psychologisch sichereren Umgebung bei der Sprint-Retrospektive
● Stärkere Betonung, dass das Increment immer fertig ist, daher ist „Done Increment“ überflüssig
● Explizite Annahme über die Formbarkeit des Produktziels (im Rahmen der Vernunft)
● Von der optimistischen Annahme der Wertlieferung zu einem bewussten Fokus auf Wertrealisierung
● Die folgenden Qualitäten sind der Schlüssel zu unserem Ethos: eingebaute Qualität, Klarheit, datengestützte Entscheidungen, absichtliche Interaktionen, Emergenz (71), Ergebnisse statt Outputs, Innehalten und Nachdenken, Wertrealisierung, Verständnis des Problems oder der Gelegenheit, Förderung des Klimas/Umfelds für eine kohärente Scrum-Annahme und kontinuierliche Verbesserung in einer kohärenten Richtung.
● Abkehr von der nebulösen Organisation, um den Wandel an Rollen festzumachen
● Bewusstere Beachtung der Scrum-Werte unter Berücksichtigung des Kontextes

Anhang

Abschnitt 2: MORE executive SUCCESS
Auszug Titel: MORE executive SUCCESS AuszugAutor: John ColemanQuelle: (6)Lizenz/Copyright: CC BY-NC-ND 4.0, © 2017-2025 Orderly Disruption Limited

Hinweis: Dieser Abschnitt wird in seiner ursprünglichen, unveränderten Form mit Genehmigung unter den Bedingungen der CC BY-NC-ND 4.0-Lizenz veröffentlicht. Es wurden keine Änderungen vorgenommen.

The Adaptive Enterprise
Es ist schwierig für ein Unternehmen, adaptiv (80) zu sein, wenn nicht ein Klima herrscht, in dem Worte und Taten übereinstimmen. Es wurden über achtzig Engagementmodelle untersucht. Darunter waren Skalierungs- oder Dekalierungsmodelle und Produktbetriebsmodelle, die für Produkte mit mehreren Scrum Teams nützlich sein können. Die Modelle reichen von zu weit gehend bis zu nicht ausreichend, um der Produktorganisation zu mehr Anpassungsfähigkeit zu verhelfen. Es gibt keine grosse, allgemeingültige Wahrheit oder kontextfreie „Goldlöckchen-Zone“.

Unter den untersuchten Engagement-Modellen gibt es eine Reihe bemerkenswerter Anwärter, einschliesslich, aber nicht beschränkt auf Beyond Budgeting, Humanokratie und Soziokratie, die je nach Kontext erkundet werden sollten. Es gilt eine Kombination miteinander und mit anderen Ansätzen zu erwägen.

Beyond Budgeting
Beyond Budgeting (15-28, 90-98, 103) ist eine Managementphilosophie, die die traditionelle, starre jährliche Budgetierung zugunsten eines dezentralisierten und anpassungsfähigen Ansatzes für Organisationssteuerung und Qualitätsmanagement ablehnt. Sie basiert auf 12 Leitprinzipien - sechs davon sind auf die Führung und sechs auf die Managementprozesse ausgerichtet -, die dezentrale Entscheidungsfindung, Transparenz, Teamautonomie und eine starke Ausrichtung auf den Kundennutzen fördern.

Anstelle von festen Zielvorgaben und detaillierten Jahresplänen fördert Beyond Budgeting die dynamische Zielsetzung, die kontinuierliche Planung und die Zuweisung von Mitteln auf der Grundlage von Echtzeitbedürfnissen, um die Anpassungsfähigkeit und Reaktionsfähigkeit in einem sich schnell verändernden Geschäftsumfeld zu fördern. Dieser Ansatz zielt darauf ab, Teams zu befähigen, Innovationen zu fördern und sicherzustellen, dass Organisationen besser gerüstet sind, um Unsicherheit (72) und Komplexität (30-35) zu bewältigen. Beyond Budgeting hat einen schlechten Namen (falsche Annahme, dass es nur um Finanzen geht) und gleichzeitig einen guten Namen (es geht tatsächlich über die Budgetierung hinaus).

Humanokratie
Die Humanokratie (2), wie sie von Gary Hamel definiert wurde, ist ein Managementmodell, das starre Hierarchien und zentralisierte Kontrolle durch Systeme ersetzt, die den Beitrag und die Kreativität jedes Einzelnen maximieren. In einer Humanokratie sind Organisationen dazu da, den Menschen zu dienen und sie zu befähigen, und behandeln Mitarbeitende nicht nur als Ressourcen für die Unternehmensziele.

Sie beruht auf Prinzipien wie verteiltem Eigentum, Leistungsgesellschaft, Offenheit, Experimentierfreude und Gemeinschaft und fördert Autonomie und Innovation. Autorität basiert auf Kompetenz, und die Entscheidungsfindung wird dezentralisiert auf diejenigen, die der Arbeit am nächsten sind. Die Humanokratie stellt Vertrauen, Engagement und die Entfaltung des menschlichen Potenzials über die Einhaltung von Vorschriften und die Kontrolle und zielt darauf ab, widerstandsfähige, innovative Arbeitsplätze zu schaffen, an denen die Mitarbeiter sinnvolle Veränderungen vorantreiben.

Während Modelle wie Rendanheyi von Haier (56, 101) die Werte der Dezentralisierung und Ermächtigung teilen, ist die Humanokratie eine umfassendere Philosophie, die sich darauf konzentriert, Bürokratie durch menschenzentrierte Prinzipien zu ersetzen, die kollektive Fähigkeiten und Werte freisetzen.

Soziokratie
Die Soziokratie (11-14) ist ein Regierungssystem, bei dem die Menschen in selbstverwalteten (47) Kreisen organisiert sind und Entscheidungen durch Zustimmung und nicht durch Mehrheitsentscheidungen getroffen werden. Sie wurde in den 1970er Jahren von Gerard Endenburg (81) in den Niederlanden entwickelt und stellt sicher, dass jeder, der von einer Entscheidung betroffen ist, ein Mitspracherecht hat, wobei Vorschläge nur dann angenommen werden, wenn ein begründeter Einwand erhoben wird. Geleitet von dem Grundsatz „gut genug für den Moment, sicher genug, um es zu versuchen“, verteilt die Soziokratie Autorität, fördert Transparenz, Verantwortlichkeit und kontinuierliche Verbesserung und unterstützt Zusammenarbeit und gemeinsame Verantwortung. Ihre Grundsätze haben Modelle wie Holacracy und selbstverwaltete Teams beeinflusst.

Die bekannteste Variante ist die soziokratische Kreis-Organisations-Methode (SCM), die ursprüngliche, formalisierte Methode. Die SCM verwendet halbautonome Kreise, doppelte Verbindungen (bei denen zwei Personen an zwei direkt miteinander verbundenen Kreisen teilnehmen, um diese Kreise zu verbinden), auf Zustimmung basierende Entscheidungsfindung und offene Wahlen für Rollen. Diese Struktur erhält sowohl die organisatorische Effizienz als auch die Gleichwertigkeit der Mitglieder und hat sich in Unternehmen, Genossenschaften und Schulen in den Niederlanden bewährt.

Während neuere Varianten wie die Soziokratie 3.0 (S3) mehr Flexibilität bieten, bleibt die SKM die historisch am besten belegte und am besten dokumentierte Form der Soziokratie.

The Adaptive Executive or Board Member

Die adaptive Führungskraft oder das Vorstandsmitglied (The Adaptive Executive or Board Member)
MORE Executive SUCCESS zeigt eine Reihe von Möglichkeiten für Führungskräfte und Vorstandsmitglieder auf:

● Aneignung von Wissen über die Stakeholder (einschliesslich der Kunden) und ihre Bedürfnisse und Grenzen, die Arbeit, die Art und Weise, wie die Arbeit funktioniert, die Verschwendung, die Anti-Muster, den Problembereich, die Möglichkeiten, die Beweise dafür, dass Wert geerntet werden kann, Verhaltensweisen und Gewohnheiten
● Förderung eines menschlichen Leistungsklimas und Ermöglichung einer Nachfolgeplanung, die dieses schützt und verbessert
● Entwicklung der Reaktionsfreudigkeit und des Werteflusses (68,69) in den verschiedenen Wertschöpfungsnetzen
● Emergenz (71) und Anpassungsfähigkeit (80) mit Klarheit ausrichten
● Einbindung von Menschen, einschliesslich Kunden und Kolleg:innen
● Förderung einer effektiven und rechtzeitigen Nachfolgeplanung

Die Mitarbeitenden zuunterst, in der Mitte oder auf der Seite der hierarchischen Organisationsstruktur erhalten reichlich Anleitung zur Verbesserung der Anpassungsfähigkeit (80). Die Führungsebene erhält jedoch nur unzureichend Anleitung zur menschlichen Effektivität, zu Kundeninteraktionen und dazu,„wie die Arbeit funktioniert“. Es ist unrealistisch zu erwarten, dass angeheuerte Change Agents diese Lücke allein füllen, da die Organisation die Verantwortung für den Wandel trägt.

Eine zeitnahe, humane Effektivität sollte die gesamte Unternehmensstruktur durchdringen, um ihre zahlreichen Vorteile zu nutzen. Selbst Organisationen, die „erfolgreich Veränderungen eingeführt“ haben, sind mit Risiken konfrontiert. Mitarbeitende verlassen das Unternehmen, andere Sichtweisen setzen sich durch, und Modeerscheinungen können Anpassungserfolge zunichte machen. Ein negatives Chaos kann entstehen.

Viele Akteure und Engagementmodelle unterstützen angeblich die Anpassungsfähigkeit von Führungskräften, was grossartig ist, da unterschiedliche organisatorische Kontexte unterschiedliche Ansätze erfordern. Aber trotz aller verfügbaren Ressourcen hat sich die Gesamtlandschaft der Anpassungsfähigkeit von Führungskräften in den letzten 25 Jahren nicht wesentlich verändert.

Unabhängig von den eingesetzten Taktiken, Strategien, Methoden und Rahmenwerke, sollten Organisationen zunächst das Werteverständnis verinnerlichen, das Ambidextrie, menschliche Effektivität, Anpassungsfähigkeit und Aktualität an der Spitze untermauert. Andernfalls werden Führungskräfte und Vorstandsmitglieder weiterhin ein „Veränderungstheater“ und einen unvollständigen Flickenteppich von zeitgemässen, humanen und effektiven Massnahmen in Organisationen beaufsichtigen.

Das Verhalten von Führungskräften unter die Lupe nehmen
Die Haltung und die Verhaltensweisen von Führungskräften und Vorstandsmitgliedern beeinflussen das zukünftige Verhalten der anderen mehr als ihre Worte oder Anweisungen. Dennoch wäre es am besten, die gestellten Fragen zu überarbeiten, um Geschicklichkeit, menschliche Wirksamkeit, Anpassungsfähigkeit und Termintreue zu verbessern.

Geschicklichkeit, menschliche Wirksamkeit, Anpassungsfähigkeit und Termintreue setzen voraus, dass inkonsequentes Führungsverhalten endgültig beseitigt wird. Beispiele für eher förderliches Verhalten sind das Akzeptieren von Misserfolgen, das Erfragen von Informationen, bevor man urteilt, das Schaffen von Lernmöglichkeiten, das Zulassen von Nichtwissen und die Unterstützung bei der Fokussierung. Es gibt einige interessante Optionen für den bewussten Umgang mit Führungsverhalten.

Immunity To Change®
Lisa Laskow Lahey und Robert Kegan (Leiter des The Developmental Edge) haben einen Veränderungsansatz entwickelt, der als Immunity to Change® bekannt ist (3,4). Menschen wissen oft, was zu tun ist, aber sie tun es nicht, weil sie sich in einem inneren Konflikt befinden. Metaphorisch ausgedrückt: Die Menschen haben einen Fuss auf dem Gas und einen Fuss auf der Bremse".

Immunity to Change® ist ein Konzept, mit dem sich die „versteckten Verpflichtungen“ und „einschränkenden Annahmen“ definieren lassen, die Menschen daran hindern, sich zu verändern und ihre Ziele zu verwirklichen. Die Immunity to Change®-Theorie und -Landkarte haben zahllosen Fachleuten und Organisationen dabei geholfen, die Verpflichtungen, die ihr berufliches und organisatorisches Wachstum behindern, aufzudecken und zu überwinden.

Intent-Based Leadership®
Intent-Based Leadership® (IBL) (7, 8, 9) ist eine Sprache, die Teams für Höchstleistungen verwenden und die programmierte Sprache des Industriezeitalters ersetzt. IBL unterstreicht das Konzept der Absicht von Führungskräften und dem Team. Es basiert auf den Büchern Turn The Ship Around und Leadership is Language von L. David Marquet.

Eine der Kernüberzeugungen ist, dass Führung nicht nur für einige wenige an der Spitze gilt. In hocheffektiven Organisationen gibt es Führungskräfte auf jeder Ebene. L. David Marquet hat das Führungskonzept, das er auf dem Atom-U-Boot USS Santa Fe entwickelt hat, in ein System namens Intent-Based Leadership (Absichtsorientierte Führung) umgewandelt, das Sie in Ihrem Unternehmen einsetzen können, um das Denken und die Führung auf allen Ebenen zu fördern.

Intent-Based Leadership hilft Führungskräften, Organisationen aufzubauen, in denen die Mitarbeitende ihr Bestes geben, weil sie ein Gefühl der Autonomie haben, ihre intrinsische Motivation nutzen, sich angehört fühlen und nach Spitzenleistungen streben. Sie haben das Gefühl, dass sie ein hohes Mass an Eigenverantwortung und Kontrolle haben, so dass sie ihr Herz und ihren Kopf einschalten. Sie erhalten psychologische Belohnungen, da sie die Früchte ihrer Entscheidungen und ihrer Arbeit sehen. Die Teams sind agiler und widerstandsfähiger, weil weniger Fehler entstehen und sich weniger ausbreiten.

Die Praxis der Absichtserklärung ermöglicht Teams eine verteilte Entscheidungsfindung bei gleichzeitiger Wahrung der Einheitlichkeit der Bemühungen. Die Intent-Based Leadership International (IBLI-Website) bietet Beratung, Coaching, Online-Kurse und Bücher für Führungskräfte an.

Abschnitt 3: Cynefin Framework Art der Erläuterung inoffiziell & unautorisiert
Titel: Cynefin Framework Art der Erläuterung inoffiziell & nicht autorisiert
Quelle: [Link zum ursprünglichen Cynefin-Wiki], [Link zu dieser Anpassung]
Lizenz: Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) . © 2017-2025 Cynefin.io.
Haftungsausschluss: Es werden keine Garantien gegeben. Nutzung auf eigene Gefahr.
Dieser Abschnitt wird unter der Lizenz Attribution-ShareAlike 4.0 International von Creative Commons angeboten.
Durch die Nutzung dieser Cynefin Framework Art der Erklärung inoffiziell & nicht autorisiert, stimmen Sie den Bedingungen der CC BY-SA 4.0 Lizenz zu.

Cynefin®
Cynefin® (30-35) bietet einen Kompass für die Entscheidungsfindung von Führungskräften. Es wurde durch den HBR-Artikel „A Leader's Framework for Decision Making“ von Dave Snowden und Mary Boone im Jahr 2007 einer breiten Öffentlichkeit bekannt und in „Managing complexity (and chaos) in a crisis - a field guide for decision makers inspired by the Cynefin framework“, auch bekannt als „EU Field Guide“, wieder aufgegriffen. Seine Prämisse ist, dass man je nach der Dynamik des Raums unterschiedlich handeln sollte. Die These wird oft zu stark vereinfacht. Ein bestimmtes Problem kann in allen Bereichen gleichzeitig bestehen, wobei jeder Bereich unterschiedliche Aspekte aufweist.

Eine Phasenverschiebung bezieht sich auf einen oft abrupten Übergang zwischen den Bereichen, insbesondere von der Ordnung zum Chaos, der ausgelöst wird, wenn die Beschränkungen eines Systems (Regeln, Gewohnheiten, Grenzen und Rückkopplungen) falsch ausgerichtet sind oder zusammenbrechen. Es handelt sich um eine grundlegende Veränderung des Systemverhaltens, bei der die bisherigen Methoden der Kontrolle oder des Verständnisses nicht mehr funktionieren.

Nicht alle Aspekte der Produktentwicklung sind komplex. Das Scrum Team muss in einer gegebenen Situation möglicherweise eine Vielzahl von Phasenverschiebungen zwischen berücksichtigen:

● Geordnet: Kerngedanke: Stabilität, Routine, beste/bewährte Verfahren, Fachwissen
- Fachwissen ist ausreichend, und Ursache und Wirkung sind vorhersehbar oder bekannt
- Antwortmöglichkeiten sind nicht beschränkt auf: Beste/bewährte Praktiken anwenden, Regeln befolgen, Expertenanalyse verwenden, individuelle Forschung betreiben
- Metaphern: Schwer bis kaum gefrorener Eiswürfel, angenehmes Wetter oder Schach/Sudoku
- Beispiel aus der Natur: Ein modernes, klimatisiertes Gewächshaus - vorhersehbares, kontrolliertes, geplantes Wachstum
- Produktbeispiel: Lösung eines kniffligen technischen Problems durch Konsultation von Experten und Analyse von Protokollen

● Komplex (30-35), wo Fachwissen wertvoll ist, aber nicht ausreicht, und man nur im Nachhinein verstehen kann, warum etwas passiert ist. Kerngedanke: Emergenz, „Safe-to-fail“-Experimente○ Antworten nicht beschränkt auf:
- Ermutigung zum Lernen und zur Anpassung○ Ausprobieren mehrerer kleiner, paralleler Experimente, bei denen nichts schiefgehen kann
- Förderung frischen Denkens durch kognitive Vielfalt und Zusammenarbeit
- Ausleihen von Lösungen aus anderen Bereichen, wenn sie hilfreich sein könnten
- Ausprobieren von klugen Vermutungen oder fundierten Ahnungen, um zu sehen, was funktionier
- Dies alles unter Beachtung hilfreicher Leitlinien, die dazu beitragen, dass sich gute Ergebnisse auf natürliche Weise entwickeln
- Metaphern: Fliessendes Wasser, regnerisches Wetter oder Poker
- Beispiel Natur: Brombeerdickicht - alles ist verwoben, Verbindungen sind unvorhersehbar
- Produktbeispiel: Experimentieren mit verschiedenen Funktionen oder Lösungen auf der Grundlage von Nutzerfeedback, z. B. A/B-Tests neuer Produktideen

● Chaotisch:
- Negativ: Kerngedanke: Zerstörerische Krise, Zusammenbruch, dringende Massnahmen○ Antworten nicht beschränkt auf: Sofortige Massnahmen ergreifen, um die Ordnung wiederherzustellen, der Sicherheit Vorrang einräumen, schnell etwas tun, ohne die Situation zu verschlimmern
- Metaphern: Zerbrechendes Eis oder unkontrollierte Explosion, giftiges Gas, Tornado, Erdbeben, Flächenbrand oder Aufruhr in einem Stadion
- Beispiel Natur: Naturkatastrophe (z. B. Tsunami) - plötzlich, zerstörerisch, unvorhersehbar
- Produktbeispiel: Reaktion auf eine kritische Sicherheitsverletzung durch Isolierung von Systemen und Bereitstellung von Notfallkorrekturen

- Positiv: Kerngedanke: Generative Unterbrechung, schnelle Innovation
- Reaktionsmöglichkeiten sind nicht beschränkt auf: Absichtlich stören, Kreativität fördern, Energie nutzen, z. B. Hackathon, Inkubator, „Innovation Friday“
- Metaphern: Kontrollierte Explosion (Dampfmaschine), Feuerwerk oder Freudenfeuer
- Beispiel Natur: Waldbrand, bei dem alter Bewuchs für neue Pflanzen gerodet wird - Erneuerung des Ökosystems
- Beispiel für ein Produkt: Schnelle Umstellung eines Produkts während einer Marktstörung, um neue Chancen zu nutzen (z. B. Einführung einer neuen Funktion als Reaktion auf den Schritt eines Konkurrenten)

Die Liminalität ist ein Zwischenstadium, wie eine Schwelle. Im liminalen Zustand finden Phasenverschiebungen statt, die oft weniger abrupt sind.

Im Grenzbereich zwischen Komplexität und Ordnung liegt der optimale Sweetspot von Scrum:

○ Geordnet-komplex:
■ Von der Expertenanalyse zur adaptiven Exploration
■ Die Antwortmöglichkeiten sind nicht beschränkt auf: Einige Regeln lockern, Experimentieren einführen, sich auf Emergenz vorbereiten
■ Metaphern: Ein schmelzender Eiswürfel, trübes Wetter, Wechsel von Schach zu Poker
■ Beispiel aus der Natur: Saisonales Tauwetter - starres Eis weicht fliessenden Strömen und neuem Wachstum
■ Produktbeispiel: Wenn ein Routineprozess nicht mehr funktioniert, ermutigen Sie das Team, andere Ansätze auszuprobieren

○ Komplex geordnet:
■ Die Antwortmöglichkeiten sind nicht beschränkt auf: Kreative Entdeckungen in Expertenroutinen umwandeln; Innovation stabilisieren, erfolgreiche Muster beobachten und kodifizieren; Übergang zur Standardisierung
■ Metaphern: Schneematsch (zwischen Eis und Wasser), sich auflösender Nebel nach Regen, Wechsel von Poker zu Schach
■ Beispiel Natur: Flussdelta, das Kanäle bildet - von unvorhersehbaren zu stabilen Strömungen
■ Produktbeispiel: Eine erfolgreiche experimentelle Funktion wird in einen dokumentierten, wiederholbaren Prozess umgewandelt.

Im Grenzbereich zwischen komplex und chaotisch:

○ Komplex-chaotisch (positiv):
■ Eine Situation, in der Zwänge gelockert werden müssen, um Zeit und Raum für Innovation oder Erfindung zu schaffen. Kerngedanke: Die Grenzen der Kreativität, des Risikos und der Innovation
■ Antworten nicht beschränkt auf: Beschränkungen lockern, Experimentieren fördern, bahnbrechende Ideen suchen
■ Metaphern: Kochendes Wasser (am Rande des Dampfes), ein ausbrechendes Gewitter, Improvisationstheater oder eine Jazz-Jam-Session
■ Beispiel Natur: Vulkan, der neues Land schafft - schöpferische Transformation am Rande des Chaos
■ Produktbeispiel: Durchführung eines risikoreichen Innovations-Hackathons, um disruptive Ideen zu entwickeln

○ Komplex-chaotisch (negativ):
■ Kerngedanke: Eine zerstörerische Bewegung in die Krise
■ Nicht nur Reaktionen: Rasche Wiedereinführung von Beschränkungen, Stabilisierung der Situation, Verhinderung eines weiteren Zusammenbruchs
■ Metaphern: Explodierender Dampfkochtopf, plötzlicher Tornado oder Sturzflut, in Wut geworfene Spielsteine, umgeworfenes Spielbrett
■ Beispiel Natur: Plötzlicher Erdrutsch - Verlust der Struktur, zerstörerischer Übergang
■ Produktbeispiel: Misslungene Produkteinführung, Verwirrung und dringende Notwendigkeit, die Kontrolle wiederzuerlangen

○ Chaotisch-Komplex: Raus aus dem Chaotischen - Umgruppieren
■ Nicht nur Reaktionsmöglichkeiten: Aufkommende Ordnung wahrnehmen, Sondierung starten, Zusammenarbeit fördern und Muster erkennen
■ Metaphern: Dampf, der zu Wasser kondensiert, Ruhe nach einem Wirbelsturm, Neustart eines Sportspiels nach einem Sturm
■ Beispiel Natur: Pionierarten, die sich nach einem Feuer ansiedeln - neues Wachstum nach einer Störung
■ Produktbeispiel: Nach einer Krise das Team neu gruppieren, um mit neuen Arbeitsweisen oder neuen Produktrichtungen zu experimentieren

Aporie (paradoxe Grenze):
sich mit dem Paradoxon auseinandersetzen, um neue Erkenntnisse zu gewinnen, vielleicht nachdem man erkannt hat, dass die Situation nicht so ist, wie sie zu sein scheint

○ Reaktionsmöglichkeiten: Mehrdeutigkeit aushalten, zum Nachdenken anregen, neues Verständnis entstehen lassen○ Metaphern: Dreifacher Punkt (fest, flüssig, gasförmig), im Auge des Sturms stehen, ein Rätsel lösen
○ Beispiel Natur: Mündung, wo Fluss, Meer und Land aufeinandertreffen - alle Zustände und Möglichkeiten koexistieren○ Produktbeispiel: Das Team steckt zwischen widersprüchlichen Strategien oder Visionen fest und sollte kurz innehalten, um nachzudenken und sich neu auszurichten.

Eine aufgrund des Schwierigkeitsgrads selten in Betracht gezogene Phasenverschiebung:

Chaotisch-Ordentlich liminal

○ Reaktionsmöglichkeiten: Starke Zwänge auferlegen, Regeln und Struktur wiederherstellen
○ Metaphern: Eis, das schnell wieder gefriert, Kälteeinbruch nach einem Sturm, Schiedsrichter ist erfolgreich streng nach Chaos
○ Beispiel Natur: Ein Damm wird nach einer Überschwemmung erfolgreich gebaut - ein wilder Fluss wird plötzlich eingedämmt und kontrolliert
○ Beispiel Produkt:
■ Nach einem grösseren Produktionsausfall oder einer Produktkrise stabilisiert ein funktionsübergreifendes Krisenteam die Situation rasch mit klaren, minimalen Regeln und vorübergehenden Protokollen
■ Sobald die unmittelbare Gefahr vorüber ist, werden diese iterativ verfeinert und zu nachhaltigen, ausgewogenen Prozessen formalisiert, wobei Überkorrekturen oder übermässige Bürokratie vermieden werden

Eine Phasenverschiebung ist besonders plötzlich und negativ, nämlich der geordnet-chaotische Grenzbereich:

● Reaktionsmöglichkeiten: Zerbrechlichkeit und Übervertrauen erkennen, schnell handeln, um Grenzen und Sicherheit wiederherzustellen
● Metaphern: Eis, das in Scherben bricht, plötzlicher und heftiger Hagelsturm, Spielregeln, die plötzlich ausser Kraft gesetzt werden
● Beispiel Natur: Gefrorener See, der im Frühjahr aufbricht - stabile Oberfläche zerbricht plötzlich
● Produktbeispiel: Ein stabiler Produktprozess bricht aufgrund eines unerwarteten Ereignisses (z. B. eines größeren Ausfalls) plötzlich zusammen

Section 4: Emergent Strategy
Author: Roger L. Martin, Tom Gilb
Source: (41), (43-48)
Copyright: All rights reserved. Adapted

Emergent Strategy
Wenn es eine Strategie gibt, sollte sie auf Unternehmens-, Geschäftseinheits- oder Produktebene klar formuliert sein und über diese Ebenen hinweg kohärent und integriert bleiben. Entscheidend ist, dass die Strategie zwischen Zielen (quantifizierte, von den Stakeholdern bewertete Ergebnisse) und Mitteln (Initiativen oder Aktivitäten) unterscheidet.

In Anlehnung an die Arbeiten von Roger L. Martin (41) und Tom Gilb (43-48) geht es bei der Strategie darum, integrierte, explizite Entscheidungen zu treffen, d. h. zu entscheiden, was ausgehend von einem klar definierten, messbaren Ziel verfolgt werden soll und was nicht, und nicht nur von einer allgemeinen Mission oder Vision. Eine wirksame Strategie gibt Antworten:

● Wo werden wir spielen?
● Wie werden wir ethisch (57) und nachhaltig gewinnen und dabei eine Vielzahl von Erwartungen und Grenzen ausgleichen?
● Welche Fähigkeiten und Systeme müssen vorhanden sein?
● Was muss sonst noch stimmen, damit diese Strategie erfolgreich ist?

In Situationen, in denen Fachwissen allein ausreicht (oder vielleicht an der Grenze des Ausreichenden liegt), um sicherzustellen, dass die Strategie iterativ, umsetzbar und wertorientiert ist:
● Quantifiziere und manage iterativ den Wert für die Stakeholder, mehrere Auswirkungen oder Nebeneffekte, Risiken und Kompromisse:
- Identifiziere alle kritischen Stakeholder (einschließlich, aber nicht beschränkt auf Kunden) und definieren Sie ihre Wertziele in messbaren Begriffen (z. B., Verringerung der Einarbeitungszeit für neue Benutzer von 5-10 auf 2-4 Tage").
- Quantifiziere explizit Kompromisse und Einschränkungen und überprüfe diese, wenn neue Informationen auftauchen.
- Nutze integratives Denken, um Spannungen kreativ zu lösen.

● Mitgestalten und gemeinsam Prioritäten setzen:
- Entwickle die Strategie, indem du Top-Down- und Bottom-Up-Einsichten und laterale Zusammenarbeit kombinierst.
- Nutze strukturierte Workshops und Feedback-Schleifen, um die Abstimmung und Anpassungsfähigkeit zu fördern, und setze kontinuierlich neue Prioritäten für nicht begonnene Arbeiten.

● Wert schrittweise liefern und Ergebnisse messen:
- Strategische Bestrebungen iterativ in kleine, priorisierte, messbare Schritte aufschlüsseln.
Wert in kurzen Zyklen (z. B. Sprints oder Wochen) liefern, tatsächliche Ergebnisse und Nebeneffekte anhand der ursprünglichen quantifizierten Ziele messen.
- Regelmässige Überprüfungen nutzen, um auf der Grundlage von Feedback aus der Praxis Anpassungen vorzunehmen.

● Entwicklung ermöglichen:
- Erlauben der Strategie, sich als Reaktion auf neue Daten und das Feedback der Stakeholder (einschliesslich, aber nicht beschränkt auf die Nutzer) innerhalb eines Rahmens klarer, quantifizierter Ziele, messbarer Trends und regelmässiger Risiko-/Nutzen-Neubewertungen weiterzuentwickeln.
- Nimm Kurskorrekturen schnell und transparent vor, wenn sich die Realität entwickelt.

● Sicherstellen, dass Strategie und Strategieeinsatz ergebnisorientiert und fokussiert sind (entscheiden, woran gearbeitet werden soll und woran nicht). Unterscheide zwischen:
- Strategie, einschließlich Absicht, Begründung, Ziele und Gegenziele (das Was und Warum),
- Strategieumsetzung: die Operationalisierung der Strategie, iterative Abfolge oder Zerlegung integrierter Entscheidungen für die Strategie, in der Regel in kleinen ergebnisorientierten Abschnitten des Was und Warum,
- ergebnisorientierte, fokussierte Product Backlog Einträge (kleinere Abschnitte für wen) und
- Listen von Aktivitäten oder Initiativen (das „Was werden wir tun“ oder Wie).

● Verwechsle eine Ansammlung von Projekten nicht mit einer kohärenten, wertorientierten Strategie.

In Situationen, in denen Fachwissen wertvoll, aber unzureichend ist, Ursache und Wirkung nur im Nachhinein kohärent sind und Ungewissheit in Kauf genommen werden muss, müssen Scrum Teams und Stakeholder:
● die Unordnung einer weniger strukturierten und emergenten ergebnisorientierten Arbeit in einer bestimmten Richtung akzeptieren.
● berücksichtige, dass detaillierte, langfristige Pläne unwirksam sind. Stattdessen sollten sich Organisationen darauf konzentrieren, Bedingungen zu schaffen, unter denen nützliche Muster und Innovationen aus den Interaktionen innerhalb des Systems entstehen können.
● Anstatt eine Idee nach der anderen auszuprobieren und an dem festzuhalten, was zuvor funktioniert hat, sollten Scrum Teams mehrere kleine, parallele Experimente in Erwägung ziehen, bei denen es sicher ist, dass sie nicht scheitern, um zu sehen, was passiert, und aus dem zu lernen, was sich ergibt.
● Ein Klima für kreative Erkundung, Innovation und Evolution aus der Gegenwart heraus fördern. Schaffe Prozesse und Umgebungen, in denen die Mitarbeitenden neue Ideen, Erkenntnisse, fundierte Vermutungen miteinander verbinden und voneinander lernen können, anstatt Uniformität oder starre KPIs aufzuerlegen.

● Die Reaktionsmöglichkeiten sind nicht beschränkt auf:
- Zeichne auf, was bereits bekannt ist, und verstehe das evolutionäre Potenzial des Systems, bevor du versuchst, es zu verändern○ Förder die Selbstorganisation
- Führe „Safe-to-fail“-Experimente (Tests) durch - die Test sollten klein, parallel und so konzipiert sein, dass deine Organisation ein Scheitern überlebt und daraus lernt
- Suche nach neuen Denkansätzen
- Probiere Lösungen für verschiedene Probleme in der aktuellen Situation aus
- Teste fundierte Vermutungen
- Beobachte, was sich ergibt, und verstärken Sie erfolgreiche Muster, während du diejenigen, die nicht funktionieren, abschwächen oder stoppst
- Innovation ist wichtig, aber bewährte Lösungen sollten für wiederkehrende Probleme wiederverwendet werden
- Schaffe kontinuierlich Sinnhaftes
- Halte das Geschehen narrativ fest

● Metapher: Die Rolle der Führungskräfte besteht darin, den Boden, die Grenzen und die Bedingungen (das „Substrat“) aktiv vorzubereiten und zu verwalten, um das Wachstum gesunder Pflanzen (sich weiterentwickelnde Lösungen) zu fördern. Dazu gehört metaphorisch gesehen das Jäten, Beschneiden und Gestalten des Umfelds und nicht nur das passive Warten auf Ergebnisse.

Im Allgemeinen sollten extrinsische motivierende Belohnungen aufgrund des „Kobra-Effekts“ (104) vermieden werden, es sei denn, sie stehen im Einklang mit den Grundsätzen von Beyond Budgeting. Ebenso sollte die Leistung des Einzelnen oder des Teams nicht mit den Ergebnissen abgekoppelt werden, denn die Ergebnisse mögen zwar erreicht worden sein, aber wie wurden sie erreicht? Welche Nebeneffekte hatte das Erreichte und welche Auswirkungen hatte der Prozess auf die Moral des Teams?

Dennoch:
● In von Fachleuten rezensierten Arbeiten (105-108) und einer grundlegenden, nicht von Fachleuten kommentierten Arbeit (109) herrscht Uneinigkeit darüber, ob die Quantifizierung von Stakeholder-Erwartungen, Stakeholder-Grenzen oder Zielen hilfreich oder nicht hilfreich ist und ob sie die intrinsische Motivation verringert.
● Berücksichtige den Kontext. Berücksichtige auch, ob Quantifizierung Autonomie und Bedeutung unterstützt oder kontrollierende Zwänge auferlegt.
● Dieses Dokument konzentriert sich im Moment auf die Klärung und das gemeinsame Verständnis einer Idee, die Quantifizierung der Erwartungen der Stakeholder, Auslotung der Grenzen der Stakeholder und der Richtung der Reise, unterstützt durch qualitativ hochwertige und genaue Berichte über Geschichten (mehr Geschichten wie diese, weniger Geschichten wie jene).

Eine emergente Strategie wird durch eine emergente ergebnisorientierte Roadmap unterstützt, die vom Sprintziel bis zur Produktvision und darüber hinaus reichen kann. Emergent Strategy Deployment (120-123) sollte nicht mit Emergent Strategy verwechselt werden. Vektorielle Veränderungsmodelle (30-35, 54), Produktbetriebsmodelle (113-119), Skalierungs- und Deklinationsmodelle (134-147) und aufstrebende zielorientierte Modelle (120-133) können für die Entwicklung einer aufstrebenden Strategie von grossem Nutzen sein. Entscheide dich für Modelle, die mit Vektoränderungen kohärent sind, z. B. mit der Richtung des Wegs und nicht mit festen Zielen.

Emergent Strategy Deployment bedeutet, dass Pläne und Aktionen sich auf natürliche Weise entwickeln, wenn das Scrum Team und die Stakeholder auf Veränderungen in der realen Welt reagieren. Anstatt einem festen Weg zu folgen, achten sie auf das, was um sie herum geschieht, und nehmen nach und nach Anpassungen vor. Im Laufe der Zeit bilden die unternommenen Schritte ein Muster, das zur eigentlichen Strategie wird, auch wenn sie sich von den ursprünglichen Plänen unterscheidet.

Namensnennung für die Scrum Guide Expansion Pack Collection

Diese Sammlung wurde von Ralph Jocham, John Coleman und Jeff Sutherland verfasst und zusammengestellt. Jeder Abschnitt ist oben einzeln aufgeführt und behält seine ursprüngliche Lizenz. Die Sammlung als Ganzes dient zu Informationszwecken; bitte beachten Sie die Lizenzbedingungen der einzelnen Abschnitte.

Literaturverzeichnis

1.Rau, T. (2022) Sociocracy - Basic Concepts and principles, Sociocracy For All. At: https://www.sociocracyforall.org/sociocracy/ (April 5, 2023).

2. Hamel, G. and Zanini, M. (2023) Humanocracy. At: https://www.humanocracy.com/ (April 5, 2023).

3. Kegan, R. and Laskow Lahey, L. (2019) An everyone culture, The Developmental Edge. At: https://developmentaledge.com/an-everyone-culture/ (April 4, 2023).

4. Laskow Lahey, L. and Kegan, R. (2023) News & thinking, The Developmental Edge. At: https://developmentaledge.com/newsthinking/#methodologies (April 3, 2023).

5. Moore, G.A., 1991. Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customers. New York: Harper Business.

6. Coleman, J., (2025) MORE executive SUCCESS. Unpublished.

7. Marquet, L. D. (2013) Turn the Ship Around! A True Story of Turning Followers into Leaders. Portfolio.

8. Marquet, L.D. (2021) Leadership is language: The hidden power of what you say and what you don't. Nakskov, Denmark: Nota.

9. Marquet, L. D. (2021) Based Leadership® International with L. David Marquet - IBLI. At:https://davidmarquet.com/ (April 5, 2023).

10. Rau, T.J. and Koch-Gonzalez, J. (2018) Many voices one song: Shared power with sociocracy. Amherst, MA: Sociocracy for All.

11. Buck, J. & Endenburg, G. (2012) The creative forces of self-organization. Sociocratic Center.

12. Buck, J. & Villines, S. (2017) We the people: Consenting to a deeper democracy. 2nd edn. Sociocracy.info Press.

13. Endenburg, G. (1998) Sociocracy: The organization of decision-making. Delft: Eburon Publishers.

14. Priest, J. & Bockelbrink, B. (2018) Sociocracy 3.0 – The practical guide. Available at: https://sociocracy30.org/ (Accessed: 17 May 2025).

15. Bogsnes, B. (2023) This is beyond budgeting: A guide to more adaptive and human organizations. Hoboken, NJ: John Wiley & Sons, Inc.

16. Bogsnes, B. (2023) Beyond budgeting at 25 - bbrt.org, Beyond Budgeting Round Table. At: https://bbrt.org/wp-content/uploads/bb-white-paper_a.pdf (April 7, 2023).

17. Olesen, A. (2016) Beyond budgeting: Principle 1 - purpose, YouTube. At: https://youtu.be/_9ZW2NjyFxE (April 7, 2023).

18. Larsson, D. (2016) Beyond budgeting: Principle 2 - values, YouTube. At: https://youtu.be/pl1BPrITbm4 (April 7, 2023).

19. Player, S. (2016) Beyond budgeting: Principle 3 - transparency, YouTube. At: https://youtu.be/Mb7K8App2vw (April 7, 2023).

20. Röösli, F. (2016) Beyond budgeting: Principle 4 - Organization, YouTube. At: https://youtu.be/i8HIgc8OZYM (April 7, 2023).

21. Larsson, D. (2016) Beyond budgeting: Principle 5 - autonomy, YouTube. At: https://youtu.be/ipnjHtXYi-g (April 7, 2023).

22. Player, S. (2016) Beyond budgeting: Principle 6 - customers, YouTube. At: https://youtu.be/_6fut4R_wVw (April 7, 2023).

23. Bogsnes, B. (2016) Beyond budgeting: Principle 7 - rhythm, YouTube. At: https://youtu.be/rb_NsnPNIQQ (April 7, 2023).

24. Röösli, F. (2016) Beyond budgeting: Principle 8 - targets, YouTube. At: https://youtu.be/up3mp7jN6XU (April 7, 2023).

25. Player, S. (2016) Beyond budgeting: Principle 9 - plans and forecasts, YouTube. At: https://youtu.be/OWM7FUuXejI (April 7, 2023).

26. Olesen, A. (2016) Beyond budgeting: Principle 10 - resource allocation, YouTube. At: https://youtu.be/mPCYHmvi_b8 (April 7, 2023).

27. Bogsnes, B. (2016) Beyond budgeting: Principle 11 - performance evaluation, YouTube. At: https://youtu.be/RfPVtG2B27E (April 7, 2023).

28. Röösli, F. (2016) Beyond budgeting: Principle 12 - rewards, YouTube. At: https://youtu.be/ETU5TzNYiC0 (April 7, 2023).

29. Takeuchi, H. and Nonaka, I. (2014) The new new product development game, Harvard Business Review. At: https://hbr.org/1986/01/the-new-new-product-development-game (21 January 2024).

30. Cynefin.io, V. (2022) Cynefin wiki, Cynefin.io. Cynefin.io. At: https://cynefin.io/ (April 4, 2023).

31. Rancati, A. and Snowden, D. (2021) Managing complexity (and chaos) in a crisis - a field guide for decision makers inspired by the Cynefin framework. Luxembourg, Belgium: Publications Office of the European Union.

32. Snowden, D. et al. (2022) Cynefin® weaving sense-making into the fabric of our world. 2nd edn. Edited by R. Greenberg and B. Bertsch. Singapore, Singapore: Cognitive Edge - The Cynefin Co.

33. Snowden, D. (2023) Cynefin St David's 2023 1 of 2, Cynefin Co. https://thecynefin.co/cynefin-st-davids-2023-1-of-2/ (April 20, 2023).

34. Snowden, D. (2023) Managing for emergence through abduction, The Cynefin Co. At: https://thecynefin.co/managing-for-emergence/ (June 24, 2023).

35. Snowden, D. and Smith, N. (2023) Leadership discussion: Dave and Natalie - the Cynefin co, YouTube. At: https://youtu.be/WcPZ8ybDF0w (April 7, 2023).

36. Langton, C.G. (ed.) (1989) Artificial Life: Proceedings of an Interdisciplinary Workshop on the Synthesis and Simulation of Living Systems, Los Alamos, New Mexico, September 1987. Santa Fe Institute Studies in the Sciences of Complexity, vol. VI. Redwood City, CA: Addison-Wesley.

37. Langton, C.G. (1989) ‘Life at the edge of chaos’, in Langton, C.G. (ed.) Artificial Life: Proceedings of an Interdisciplinary Workshop on the Synthesis and Simulation of Living Systems. Santa Fe Institute Studies in the Sciences of Complexity, vol. VI. Redwood City, CA: Addison-Wesley, pp. 41–91.

38. Wolfram, S. (2002) A new kind of science. Champaign, IL: Wolfram Media.

39. Alexander, C. (1979) The timeless way of building. New York: Oxford University Press.

40. Schwaber, K. & Sutherland, J. (2020) The Scrum Guide: The definitive guide to Scrum: The rules of the game. Available at: https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf (Accessed: 17 May 2025)

41. Martin, R.L. (2022) A new way to think your guide to Superior Management Effectiveness. Boston, MA, MA, USA: Harvard Business Review Press.

42. Gilb, T. & Graham, D. (1993) Software Inspection. Harlow: Addison-Wesley.

43. Gilb, T. (1993) ‘Practical purposeful creativity constructs’, AI & Society, 7(1), pp. 90–100. Available at: https://www.researchgate.net/publication/220619825_Practical_Purposeful_Creativity_Constructs [Accessed 17 May 2025].

44. Gilb, T. (2015) Planguage and innovation: How metrics drive ideas. Presentation, Gilb Seminar, London, 26 June. Available at: https://www.researchgate.net/publication/279535067_Planguage_and_Innovation_How_Metrics_Drive_Ideas [Accessed 17 May 2025].

45. Gilb, T. (1988) ‘Deeper perspectives on evolutionary delivery’, in Principles of Software Engineering Management. Wokingham: Addison-Wesley, pp. [chapter 15].

46. Gilb, T. (2005) Competitive Engineering: A Handbook for Systems Engineering, Requirements Engineering, and Software Engineering Using Planguage. Oxford: Elsevier Butterworth-Heinemann.

47. Gilb, T. (2009) ‘Agile specification quality control: Shifting emphasis from cleanup to sampling defects’, Testing Experience, March. Available at: https://www.researchgate.net/publication/269995470_Agile_Specification_Quality_Control_Shifting_Emphasis_from_Cleanup_to_Sampling_Defects [Accessed 17 May 2025].

48. Gilb, T. & Gilb, K. (1989) ‘The McDonnell-Douglas case study of SQC and engineering improvement: Case DAC Inspection 1988–89’. Available at: https://www.researchgate.net/publication/279535134_The_McDonnell-Douglas_Case_Study_of_SQC_and_Engineering_Improvement_Case_DAC_Inspection_1988-89 [Accessed 17 May 2025].

49. LeSS.works (n.d.) Self-managing teams. Available at: https://less.works/less/management/self-managing-teams (Accessed: 17 May 2025).

50. Gothelf, J. & Seiden, J. (2021) Lean UX: Designing great products with agile teams. 3rd edn. Sebastopol, CA: O’Reilly Media

51. Torres, T. (2021) Continuous discovery habits: Discover products that create customer value and business value. North Charleston, SC: Product Talk

52. Scrum.org (2025) Scrum Hexis. Available at: https://thecynefin.co/product/hexi-scrumorg/?srsltid=AfmBOorcohLYeVy0qBsQFI6mK_bZtJA_uGC6hPL2BdptiTwNmMwpKTQv (Accessed: 17 May 2025).

53. Sutherland, J., Coplien, J.O., Heasman, L., den Hollander, M., Ramos, C. and The Scrum Patterns Group (2019) A Scrum Book: The Spirit of the Game. Raleigh, NC: Pragmatic Press.

Members of The Scrum Patterns Group: Vervloed, E., Harrison, N., Harada, K., Yoder, J., Kim, J., O’Callaghan, A., Beedle, M., Bjørnvig, G., Friis, D., Reijonen, V., Benefield, G., Østergaard, J., Eloranta, V.-P., Leonard, E. & Aguiar, A.

54. Snowden, D. (2025) ‘Estuarine mapping first edition’, The Cynefin Co, 22 April. Available at: https://thecynefin.co/estuarine-mapping/ (Accessed: 8 June 2025)

55. Ackoff, R.L. (1999) Ackoff’s Best: His Classic Writings on Management. New York: John Wiley & Sons.

56. Fischer, B., Minnaar, J., Moehrle, M., & Cornuel, E. (2020) RenDanHeYi: Pioneering the Quantum Organisation. EFMD Global Focus, Special Supplement. Available at: https://www.globalfocusmagazine.com/wp-content/uploads/2020/10/GF_RenDanHeYi_Supplement_WEB-new-3.pdf [Accessed 27 May 2025]

57. Blackburn, S. (2003) Ethics: A Very Short Introduction. Oxford: Oxford University Press.

58. Mayer, T. (2025) A Simple Guide to Scrum. [Online]. Available at: https://scrum.academy/guide/ (Accessed: 17 May 2025)

59. Ohno, T. (1988) Toyota Production System: Beyond Large-Scale Production. Portland, OR: Productivity Press.

60. Toyota Motor Corporation (2024) Toyota Production System. Available at: https://global.toyota/en/company/vision-and-philosophy/production-system/index.html (Accessed: 17 May 2025).

61. Hounshell, D.A. & Smith, J.K. (1988) Science and Corporate Strategy: DuPont R&D, 1902–1980. Cambridge: Cambridge University Press.

62. Schwaber, K. and Sutherland, J. (1995) 'SCRUM Development Process', OOPSLA Business Object Design and Implementation Workshop. Austin, Texas, October 1995. Available at: http://jeffsutherland.org/oopsla/schwapub.pdf (Accessed: 17 May 2025).

63. Womack, J.P. and Jones, D.T. (1996) Lean Thinking: Banish Waste and Create Wealth in Your Corporation. New York: Simon & Schuster.

64. Thurlow, N., Turner, J.R. and Podder, A. (2020) The Flow System: The Evolution of Agile and Lean Thinking in an Age of Complexity. Flow Consortium. Available at: https://flowguides.org/Flow_Guide.pdf (Accessed: 17 May 2025).

65. Felderer, M. and Travassos, G.H. (2020) ‘The Evolution of Empirical Methods in Software Engineering’. Available at: https://arxiv.org/pdf/1912.11512.pdf (Accessed: 17 May 2025).

66. Creative Wisdom (n.d.) ‘Abduction, Deduction and Induction’. Available at: https://www.creative-wisdom.com/teaching/WBI/abduction5.pdf (Accessed: 17 May 2025).

67. Campbell, J. (2025) ‘Empiricism’, EBSCO Research Starters. Available at: https://www.ebsco.com/research-starters/religion-and-philosophy/empiricism (Accessed: 17 May 2025)

68. Kanban Guides (2025) Available at: https://kanbanguides.org (Accessed: 17 May 2025)

69. Scrum.org et al. (2021) The Kanban Guide for Scrum Teams. Available at: https://www.scrum.org/resources/kanban-guide-scrum-teams (Accessed: 17 May 2025)

70. Csíkszentmihályi, M. (1990) Flow: The Psychology of Optimal Experience. New York: Harper & Row

71. Templeton Foundation (2023) ‘What Is Emergence?’ John Templeton Foundation. Available at: https://www.templeton.org/news/what-is-emergence (Accessed: 17 May 2025).

72. van der Bles, A.M., van der Linden, S., Freeman, A.L.J. and Spiegelhalter, D.J. (2019) ‘Communicating uncertainty about facts, numbers and science’, Royal Society Open Science, 6(5), 181870. Available at: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6549952/ (Accessed: 17 May 2025).

73. Morieux, Y. (2015) How too many rules at work keep you from getting things done: Yves Morieux: Ted Talks, YouTube. At: https://youtu.be/t NoFstCmQ (April 3, 2023).

74. Holland, J.H. (1992) Complex Adaptive Systems. Daedalus, 121(1), pp. 17–30. Available at: https://www.jstor.org/stable/20025416 (Accessed: 17 May 2025).

75. Axelrod, R. and Cohen, M.D. (2000) Harnessing Complexity: Organizational Implications of a Scientific Frontier. New York: Free Press.

76. Juarrero, A. (1999) Dynamics in Action: Intentional Behavior as a Complex System. Cambridge, MA: MIT Press.

77. Snowden, D.J. and Boone, M.E. (2007) ‘A leader’s framework for decision making’, Harvard Business Review, 85(11), pp. 68–76. Available at: https://hbr.org/2007/11/a-leaders-framework-for-decision-making (Accessed: 17 May 2025)

78. Dictionary Marketing (2024) ‘B2B2B’. Available at: https://dictionarymarketing.com/definition/b2b2b/ (Accessed: 17 May 2025).

79. NetSuite (2023) ‘What Is Business to Business to Consumer (B2B2C)?’ Available at: https://www.netsuite.com/portal/resource/articles/ecommerce/b2b2c.shtml (Accessed: 17 May 2025).

80. LeSS (n.d.) ‘Why LeSS? Achieving adaptiveness’. Available at: https://less.works/less/framework/why-less (Accessed: 17 May 2025).

81. Sociocracy For All (n.d.) ‘Gerard Endenburg: founder of Sociocratic Circle Method and pioneer of self-management’. Available at: https://www.sociocracyforall.org/gerard-endenburg-founder-of-sociocratic-circle-method-and-pioneer-of-self-management/ (Accessed: 18 May 2025).

82. Patton, J. and Economy, P. (2014) User Story Mapping: Discover the Whole Story, Build the Right Product. Sebastopol, CA: O’Reilly Media.

83. Kotter, J.P., 1996. Leading Change. Boston: Harvard Business School Press.

84. ‘Genchi Genbutsu’ (2024) Wikipedia. Available at: https://en.wikipedia.org/wiki/Genchi_genbutsu (Accessed: 18 May 2025).

85. ScrumPlop, n.d. Illigitimus Non Interruptis. The Scrum Book: The Spirit of the Game. Available at: https://sites.google.com/a/scrumplop.org/published-patterns/product-organization-pattern-language/illegitimus-non-interruptus [Accessed 18 May 2025].

86. Cagan, M., 2018. Inspired: How to Create Tech Products Customers Love. 2nd ed. Hoboken, NJ: Wiley.

87. Cagan, M. & Jones, C., 2020. Empowered: Ordinary People, Extraordinary Products. Hoboken, NJ: Wiley.

88. Cagan, M., 2024. Transformed: Moving to the Product Operating Model. Hoboken, NJ: Wiley.

89. Schwaber, K. (2023) ‘Scrum Guide’, Ken Schwaber’s Blog, 25 September. Available at: https://kenschwaber.wordpress.com/2023/09/25/scrum-guide/ (Accessed: 20 May 2025).

90. Future Ready: How to Master Business Forecasting Morlidge, S. & Player, S., 2010. Future Ready: How to Master Business Forecasting. Chichester: John Wiley & Sons.

91. The Little Book of Beyond Budgeting Morlidge, S., 2024. The Little Book of Beyond Budgeting: A New Management Model for Organisations (Second Edition) [Beyond Books Press]

92. The Little (Illustrated) Book of Operational Forecasting Morlidge, S., 2019. The Little (Illustrated) Book of Operational Forecasting. [Troubador].

93. Present Sense Morlidge, S., 2019. Present Sense. [Troubador].

94. Zen and the Art of Organising Work Morlidge, S., 2021. Zen and the Art of Organising Work. [Troubador].

95. Cost Matters Morlidge, S., 2023. Cost Matters. [Beyond Books Press].

96. Beyond Budgeting i praktiken Fahlén, K., 2016. Beyond Budgeting i praktiken. Stockholm: Liber.

97. Fahlén, K., 2018. Dynamic Management Strategy: A guide to management innovation and competitive advantage. Gothenburg: BAS

98. Bogsnes, B., 2016. Implementing Beyond Budgeting: Unlocking the Performance Potential. 2nd ed. Chichester: John Wiley & Sons.

99. Boyd, J.R. (1995–1996) The Essence of Winning and Losing. Unpublished briefing slides. Note: Boyd’s OODA was primarily disseminated through military briefings and unpublished manuscripts. His final conceptualization appears in The Essence of Winning and Losing, which emphasizes nonlinear decision-making and adaptation in complex environments.

100. Turner, J.R., Thurlow, N. and Rivera, B. (2019) The Flow System Guide. Available at: https://flowguides.org/Flow_Guide.pdf (Accessed: 24 May 2025). Summary: This guide integrates Boyd’s OODA with complexity theory and agile practices, framing it as a dynamic, non-linear decision-making process for organizational flow.

101. Williamson, P.J. & Yin, E. (2018) 'Management Innovation Made in China: Haier's Rendanheyi', California Management Review, 61(1), pp. 71-93.

102. Richards, C. (2004) Certain to Win: The Strategy of John Boyd, Applied to Business. Bloomington, IN: Xlibris

103. Becker, S et al (co-author) The Viable Map Workbook 2023 [Beyond Books Press]

104. Frey, B.S. and Jegen, R. (2001) ‘Motivation crowding theory’, Journal of Economic Surveys, 15(5), pp. 589–611.

105. Cameron, J., Banko, K.M. and Pierce, W.D. (2001) ‘Pervasive negative effects of rewards on intrinsic motivation: The myth continues’, The Behavior Analyst, 24(1), pp. 1–44.

106. Deci, E.L., Koestner, R. and Ryan, R.M. (1999) ‘A meta-analytic review of experiments examining the effects of extrinsic rewards on intrinsic motivation’, Psychological Bulletin, 125(6), pp. 627–668.

107. Ryan, R.M. and Deci, E.L. (2000) ‘Intrinsic and extrinsic motivations: Classic definitions and new directions’, Contemporary Educational Psychology, 25(1), pp. 54–67.

108. Sandel, M.J. (2012) What money can’t buy: The moral limits of markets. London: Allen Lane.

109. Kohn, A. (1993) ‘Why incentive plans cannot work’, Harvard Business Review, 71(5), pp. 54–63.

110. Fuzzy Business: How to be roughly right rather than precisely wrong (unpublished).

111. Lewis, R. (2023) An operating model for business agility: Agile for managers of the digital age. Independently published.

112. less.works (n.d.) Technical Excellence. Available at: https://less.works/less/technical-excellence (Accessed: 7 June 2025)

113. Cagan, M. (2024) Transformed: Moving to the Product Operating Model. Hoboken, NJ: Wiley.

114. Cagan, M. (2025) ‘The Product Operating Model’, Silicon Valley Product Group, 17 March. Available at: https://www.svpg.com/the-product-operating-model/ (Accessed: 8 June 2025).

115. Cagan, M. (n.d.) ‘The Product Operating Model: An Introduction’, Silicon Valley Product Group. Available at: https://www.svpg.com/the-product-operating-model-an-introduction/ (Accessed: 8 June 2025)

116. Scrum.org (2025) ‘The Agile Product Operating Model’, Scrum.org, 1 May. Available at: https://www.scrum.org/resources/agile-product-operating-model (Accessed: 8 June 2025).

117. Scrum.org (2025) ‘Agile Product Operating Model State of Play - Part 1 - Fundamentals’, Scrum.org, 12 May. Available at: https://www.scrum.org/resources/blog/agile-product-operating-model-state-play-part-1-fundamentals (Accessed: 8 June 2025).

118. Scrum.org (2024) ‘Project to Product and the Agile Product Operating Model’, Scrum.org, 7 November. Available at: https://www.scrum.org/resources/blog/project-product-and-agile-product-operating-model (Accessed: 8 June 2025).

119. Scrum.org (2024) Moving to an Agile Product Operating Model [PDF]. Available at: https://s3.amazonaws.com/static.scrum.org/Webinar+Slides/Moving+to+an+agile+product+operating+model+2024+.pdf. (Accessed: 8 June 2025)

120. Scotland, K. (2023) Why strategy deployment? Here are three great reasons, AvailAgility. At: https://availagility.co.uk/2023/02/16/why-strategy-deployment-here-are-three-great-reasons/ (April 3, 2023).

121. Scotland, K. (2019) Deploying strategies as choices, AvailAgility. At: https://availagility.co.uk/2019/02/08/deploying-strategies-as-choices/ (April 3, 2023).

122. Scotland, K. (2017) Strategy deployment and playing to win, AvailAgility. At: https://availagility.co.uk/2017/07/14/strategy-deployment-and-playing-to-win/ (April 3, 2023).

123. Scotland, K. (2017) A strategy deployment cadence, AvailAgility. At: https://availagility.co.uk/2017/09/06/a-strategy-deployment-cadence/ (April 3, 2023).

124. Scotland, K. (2022) The ultimate X-matrix for your agile transformation is here, AvailAgility. At: https://availagility.co.uk/2022/11/03/the-ultimate-x-matrix-for-youragile-transformation-is-here/ (April 5, 2023).

125. Krebs, J. (2023) Agile kata pro, Agile Kata Pro. At: https://agilekata.pro/ (April 4, 2023).

126. Doerr, J. (2023) OKRs 101, What Matters. At: https://www.whatmatters.com/get-started/ (April 4, 2023).

127. Wodtke, C. (2021) Radical focus achieving your most important goals with objectives and key results--. Palo Alto, CA: Cucina Media.

128. Gothelf, J. & Seiden, J. (2024) Who Does What By How Much?: A Practical Guide to Customer-Centric OKRs. New York: Sense & Respond Press.

129. Appelo, J. (2023) Sometimes, you *don’t* want focus, unFIX. At: https://unfix.com/blog/sometimes-you-dont-want-focus (14 January 2024).

130. Appelo, J. (2023) Bets and objectives, unFIX. At: https://unfix.com/bets-and-objectives (14 January 2024).

131. McChesney, C. (2023) The 4 disciplines of execution (new), FranklinCovey. At: https://www.franklincovey.com/the-4-disciplines/ (April 4, 2023).

132. Scrum.org (2024) Evidence-Based Management (EBM) Framework, Scrum.org. Available at: https://www.scrum.org/resources/evidence-based-management. (Accessed: 8 June 2025).

133. Burrows, M. (2023) Home: Agendashift™, Agendashift. At: https://www.agendashift.com/ (April 4, 2023).

134. Kniberg, H. and Ivarsson, A. (2012) Scaling at Spotify, Crisp. At: https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf (April 5, 2023).

135. Ambler, S.W. and Lines, M. (2023) Disciplined Agile® Toolkit - Project Management Institute, PMI. At: https://www.pmi.org/disciplined-agile/ (April 5, 2023).

136. Leffingwell, D. and Knaster, R. (2023) Safe 6.0 framework, Scaled Agile Framework. At: https://www.scaledagileframework.com/ (April 5, 2023).

137. Sutherland, J. (2021) Scrum@Scale - the scaling framework created by dr. Jeff Sutherland, Scrum@Scale Framework. At: https://www.scrumatscale.com/ (April 5, 2023).

138. Skelton, M. and Pais, M. (2023) Team topologies, Team Topologies. At: https://teamtopologies.com/ (April 5, 2023).

139. Appelo, J. (2023) Versatile Organization Design, unFIX. At: https://unfix.com/ (April 5, 2023).

140. Merel, P. (2023) Xscale Alliance, XSCALE Alliance. At: https://xscalealliance.org/#manifesto (April 5, 2023).

141. Schwaber, K. et al. (2021) Online nexus guide, Scrum.org. At: https://www.scrum.org/resources/online-nexus-guide (April 5, 2023).

142. Quartel, R. et al. (2024) FaST guide, Fluid Scaling Technology. At: https://www.fastagile.io/ (December 6, 2023).

143. Ramos, C. and Pavlichenko, I. (2023) Creating agile organizations, Creating Agile Organizations. At: https://creatingagileorganizations.com/ (April 15, 2023).

144. Larman, C. & Vodde, B. (2025) LeSS (Large-Scale Scrum) Framework. Available at: https://less.works/less/framework (Accessed: 8 June 2025)

145. Flight Levels GmbH (2025) Flight Levels Framework. Available at: https://www.flightlevels.io/what-is-flight-levels/ (Accessed: 8 June 2025).

146. Krivitsky, A. and Flemm, R. (2022) Org topologies, Org Topologies. At: https://www.orgtopologies.com/ (April 4, 2023).

147. Singh, P. (2023) Scaling Simplified: A Practitioner’s Guide to Scaling Flow. Florida: Self-published. Available at: https://leanpub.com/scalingsimplified (Accessed: 8 June 2025)

148. Davies, Dan. (2025) The Unaccountability Machine: Why Big Systems Make Terrible Decisions—and How the World Lost Its Mind. London: Profile Books Ltd. (Paperback edition).

149. Stripe (2025) ‘Sir Jony Ive and Patrick Collison Fireside Chat | Stripe Sessions 2025’, YouTube video, 8 May. Available at: https://youtu.be/wLb9g_8r-mE?si=1rEJxU0sxixvblQ3&t=1390 (Accessed: 8 June 2025)

Scrum Guides im Überblick

Das Extension Pack basiert auf dem Scrum Guide. Dieser ist weiterhin die Grundlage der Scrum Praktiken und enthält alle zentralen Elemente für die Arbeit nach Scrum.

Der Scrum Guide - deutsch - Version November 2020 als PDF - Gender neutral

Der Scrum Guide - deutsch - Version November 2020 als PDF - männliche Version

Der Scrum Guide - deutsch - Version November 2020 als PDF - weibliche Version

Scrum Guide Extension Pack - English - Version June 2025 - PDF

Scrum@Scale Guide - als PDF in Deutsch

Kennst du schon unsere Blogs und Podcasts über Scrum und weitere agile Themen? Jetzt reinhören und lesen.