Was ist Scrum 3.0?  

Scrum ist mittlerweile rund 40 Jahre alt. 1986 erklärten bereits Nonaka und Takeuchi, wie selbstorganisierte Teams schnell gute Produkte bauen können. Wie hat sich Scrum im Laufe der Zeit entwickelt? Wie sollte „state of the art Scrum“ eigentlich aussehen? Ein Überblick:

Scrum 1.0 

Jeff Sutherland und Ken Schwaber formalisierten ihre Erkenntnisse zur erfolgreichen Softwareentwicklung auf der OOPSLA Konferenz 1995. Einige Jahre später entstand das Agile Manifesto, welches bis heute die Basis für agile Prozesse in vielen Unternehmen ist. In der ersten Iteration von Scrum lautete das Paradigma: Es gibt ein Team, dass das Backlog abarbeitet. Der Product Owner wurde nicht wirklich als Teil des Teams gesehen: Seine Aufgaben umschlossen das Schreiben von Anforderungen (also die Befüllung des Backlogs). Die Priorisierung und das Review wurde für ihn gemacht. 

Das Team arbeitete die Anforderungen ab, schätzte die Aufwände und Tasks. Zu Beginn der 30 Tage dauernden Sprints gab es ein vierstündiges Sprint Planning. Der ScrumMaster sorgte dafür, dass das Team in die Lieferung kam – aus heutiger Sicht allerdings eher in einer moderierenden als einer führenden Rolle. Das Daily Scrum (oder „Daily Stand-up“) bestand aus drei Fragen: Was habe ich gestern getan? Was habe ich heute zu tun? Was ist mir im Weg? 

Fun Fact: Die Agile Community hat sich lange darüber gestritten, ob Sutherland bei seinen „Monatssprints“ 30 oder 31 Tage gemeint hat.  

Scrum 2.0 

So klar Scrum von Sutherland beschrieben schien, so viele Fragen stellten sich in der Praxis – wie geht das eigentlich? Wie setze ich die Ideen um?  

Seit ca. 2000 entstanden zunehmend „Agile Communities“, z. B. die XP Belgium, welche mehr und mehr Umsetzungshilfen entwickelten, um Scrum zum Leben zu erwecken und damit schneller Produkte und/oder Software zu liefern.  

Zwei-Wochen-Sprints und User Storys

Die fundamentalste Änderung von Scrum 1.0 zu 2.0 war die Verkürzung von Sprints auf zwei Wochen und die Entwicklung von User Storys (Mike Cohn, 2005), damit die Teams die Anforderungen der Nutzer:innen verstehen konnten. Diese wurden nun in einer vorgegebenen Syntax formuliert:

„Als User möchte ich …[Funktion], um zu … [Problemlösung]“.

Die Teams fingen also an, wirklich darüber zu sprechen, was die Nutzer:innen tatsächlich brauchten (was nicht immer einherging mit dem, was sich die Nutzer:innen gewünscht haben). 

Bessere Planung und Fokus aufs Liefern

Weitere Verbesserungen bzw. Weiterentwicklungen waren zusätzliche Meetings wie das Release Planning (wann liefert das Scrum-Team?), das Backlog Refinement (User Storys so vorbereiten, dass sie im nächsten Sprint in das Sprint Backlog wandern können) oder das Estimation Meeting (Schätzen von User Storys) und hilfreiche Tools wie Planning Poker oder das von Boris Gloger erfundene Magic Estimation, um verlässlich die Größe von Backlog Items zu schätzen.  

Den Fokus der Veränderung konnte man wieder gut am kürzesten Meeting (Daily) erkennen: Die drei Fragen waren nun:
1. Was ist mir gestern gelungen?
2. Was habe ich heute vor zu erreichen?
3. Was ist mir im Weg? / Wo brauche ich Unterstützung?

Auch wenn die Fragen auf den ersten Blick gleich klingen: Der Fokus lag nun auf der Lieferung. Wenn ein Teammitglied darüber berichtet, was es getan hat (1. Iteration), stehen Aktivitäten im Vordergrund (z. B. E-Mails beantwortet, Code geschrieben etc.) und nicht die Lieferung (Code ist fertig).   

Der erste Scrum Guide

Zwischen 2005 und 2014 fand eine weitere tiefgreifende Veränderung statt: Der erste Scrum Guide wurde von Ken Schwaber und Jeff Sutherland entwickelt.  

Der Fokus im Sprint Planning lag nun auf dem, woran die nächsten zwei Wochen gearbeitet werden sollte (Requirements in Form von User Storys). Auf den Taskboards der Teams wurden die User Storys festgehalten (Folge: Task Burndowns wurden zu Story Burndowns), Tasks mussten innerhalb eines Tages erledigt werden. Wenn ein Task länger als einen Tag in der „In Arbeit“-Spalte festhing, wurde er markiert, um schneller zu erkennen, welche Aufgaben länger dauern.  

Ebenso wie die Meetings änderte sich die Rolle des Product Owners: Das Review war nicht mehr für ihn, sondern für den User, auch wenn der Product Owner sich die Lieferungen vor dem Review anschaute (um festzustellen, ob dem User überhaupt etwas gezeigt werden konnte): Team und Product Owner zeigten am Ende eines Sprints gemeinsam ihre Lieferungen. Im Review fingen DevTeams an, die Nutzer:innen ihrer Produkte wirklich zu beobachten, um aus diesen Beobachtungen wieder neue User Storys zu schreiben. 

Es wurde außerdem ein neues Meeting eingeführt: Die Retrospektive, also die Reflexion im Team, um die Zusammenarbeit zu verbessern. In den folgenden Jahren wurde die Retro jedoch „verschönert“: Es entstanden Segelboot-, Seestern- oder andere kreative Retrospektiven.   

Diese Veränderungen spiegelten sich auch in den Iterationen des Scrum Guides wider: 2013 wurde vor allem das Review verändert, 2016 die Scrum-Werte erstmals angeführt, ein Jahr später die ScrumMaster-Rolle detaillierter beschrieben. 

Auch das Daily wurde wieder anders: Das Team versammelte sich von nun an gemeinsam am Board, um die User Storys zu aktualisieren, während der ScrumMaster dafür sorgte, dass die Teammitglieder miteinander redeten. Aus dem von Sutherland beschriebenen ScrumMaster wurde eine wirkliche Führungskraft, die die Rollen „Manager“, „Facilitator“ und „Change Agent“ vereinte.  

Scrum 3.0  

2020: Scrum 3.0 hält Einzug in den Unternehmen (siehe auch die Scrum Checklist 3.0 und den neuesten Scrum Guide), und es hat ein weiterer Paradigmenwechsel stattgefunden: Die Rolle des Product Owners hat sich grundlegend geändert.  

Der Product Owner

Der Product Owner ist nicht mehr das Bottleneck, das Anforderungen für das Team filtert und priorisiert. Das Team beobachtet den User und dessen Bedürfnisse, findet die Lösung und schreibt die User Storys. So macht es dem User ein Angebot, wie sein Problem gelöst werden kann – der Product Owner entscheidet, was davon gebaut wird. Ergo: Er entfernt User Storys aus dem Backlog, anstatt neue hineinzugeben. Das wichtigste Wort des Product Owners ist also „Nein“ – gegenüber Stakeholdern, aber auch seinem Team. Sein Job ist es, die nicht getane (weil nicht notwenige) Arbeit zu maximieren – also wieder ein wenig zurück zu den Grundideen des agilen Manifests: Dort wurde der Kundenfokus von Anfang an benannt, geriet im Laufe der Zeit aber ein wenig in Vergessenheit bzw. stach nicht mehr so heraus neben den Meetings und Rollen.

User im Fokus

Eine weitere Neuerung ist die Ersetzung von Kundenfokus durch User-Fokus. Um es deutlich zu machen: Im Zentrum steht die Person, die das Produkt wirklich nutzt – es ist aber möglich, dass eine andere Person (Kunde) das Produkt beauftragt und/oder dafür bezahlt.  

Im Idealfall sitzt das Team bei Scrum 3.0 die ganze Zeit zusammen und arbeitet mit Mob-Programming. So fallen die meisten Meetings (wie z. B. das Daily) weg, weil das ganze Team alles voneinander mitbekommt und Unsicherheiten sofort geklärt werden können.  

Auch die Retrospektive darf kürzer ausfallen, denn: Für eine wirklich gute Retrospektive genügt eine Frage: „Was würde uns im nächsten Sprint glücklicher machen?“ 

Was nun mit dem gewonnen Wissen tun?  

Nehmen Sie Ihre Scrum-Meetings genauer unter die Lupe: Welche Fragen werden im Daily gestellt? Sind Ihre Retrospektiven "verschönert" oder haben sie wirklich einen positiven Effekt auf die Zusammenarbeit Ihres Teams? Welche Beobachtungen haben Sie bei der Weiterentwicklung von Scrum gemacht? Welchen Einfluss hatte das auf Ihre Teams, Produkte und Services?  

Ich bin gespannt auf Ihre Erfahrungen und freue mich über Kommentare unter diesem Beitrag.  

Titelbild: Olga Guryanova, Unsplash

Agile Toolbox
Scrum
Paulina Heins
June 27, 2022

Table of content

Diesen Beitrag teilen

Das könnte auch interessant sein:

Agile Coach
Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox

FRAGE: Warum macht ihr eigentlich kein SAFe?

Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox
Transformation

FRAGE: Was kostet eine agile Transformation?

Agile Management
Agile Organization
Agile Toolbox
Leadership
Agiles Lernen

FRAGE: Welche Rolle spielt Training?

Agile Coach
Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox

FRAGE: Wer sind die Top 10 agilen Unternehmensberatungen?

Agile Management
Agile Organization
Agile Tools
Agiles Management
Leadership

FRAGE: Wie viel bringt die Investition? Was ist der Business Case dahinter?

Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox
Führung

FRAGE: Welche sind häufige Herausforderungen, die ihr beim Kunden löst?

Agile Management
Agile Organization

FRAGE: Warum sollten wir mit borisgloger arbeiten?

Agile Management
Agile Organization
Agiles Management
Transformation

FRAGE: Wie viel kostet eine Beratung und ist es wirklich rentabel bei borisgloger?

Agile Prinzipien
Agile Toolbox
Projektmanagement

The Lie Behind the Parable of the Golf Balls and the Jar

Video
Change
Digitale Transformation
Hardware
Agile Organization

Agile in Industrial Automation: The Digital Transformation of Yokogawa

Versicherung
Neues Arbeiten
Führung
Agile Prinzipien
Kundenfokus

Kundenzentrierte Versicherung: Kann ein agiles Projekt die Organisation retten?

Versicherung
Change
Digitale Transformation
Agile Prinzipien
Kundenfokus

Agilität in den Vertrieb bringen – für Versicherer sinnvoll

Versicherung
Agile Prinzipien
Kundenfokus
Agile Toolbox
Produktentwicklung

BizDevOps in der Versicherungsbranche – Wie multidisziplinäre Teams wirklich besetzt sein sollten

Versicherung
Agile Prinzipien
Kundenfokus
Neues Arbeiten
Meetings

Undercover Agile für Versicherer: 5 agile Praktiken für Ihr klassisches IT-Projekt

Versicherung
Change
Digitale Transformation
Agile Prinzipien
Kundenfokus

IT-Projekte in der Versicherungsbranche – Das Rennen um die Time-to-Market

Team
Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills

Umgang mit Fehlern & Diversität – Erfolgreiche agile Teams #2

Team
Neues Arbeiten
Agile Toolbox
Produktentwicklung

Das Geheimrezept von High-Performance-Teams

Team
Arbeiten bei borisgloger consulting
Agile Prinzipien
Freiwilligkeit
Selbstorganisation

Konsent und offene Wahl: 2 Prinzipien aus der Soziokratie, die jedes agile Team gebrauchen kann

Team
Neues Arbeiten
Meetings
Social Skills

Der agile Adventkalender

Team
Agile Toolbox
Scrum
ScrumMaster-Praxistipps
Agile Prinzipien

Selbstorganisation der Teams fördern: Ask the team!

Team
Agile Toolbox
Design Thinking

Who Recognizes the Truly Good Ideas?

Team
Agile Organization
Transformation

Pizza Is Not Dead, and Neither Is Agility

Scrum4Schools
Neues Arbeiten
Führung
Life
Social Skills

Trauen wir unseren Kindern mehr zu – auch in der Schule!

Scrum4Schools
Change
Agiles Lernen
Neues Arbeiten
Remote Arbeiten

Eine Scrum4Schools-Projekt-Rückschau mit Physiklehrer Ivan Topic

Scrum4Schools
Mehr Formate
Interview
Nachhaltigkeit

Mit Scrum4Schools dem Weltraum auf der Spur

Scrum4Schools
Change
Agiles Lernen

Scrum4Schools - ein Projekt nimmt Fahrt auf

Scrum4Schools
Agile Schulentwicklung
Agile Toolbox

Technik im Alltag - Scrum4Schools zu Gast in Langenzersdorf

Projektmanagement
Agile Toolbox
Scrum
Scrum-Begriffe
ScrumMaster-Praxistipps

Sprechen Sie Agile? Den klassischen Projektplan in die agile Welt überführen

Projektmanagement
Agiles Management
Agile Toolbox
Scrum
Enterprise Scrum

Das Management in Scrum

Projektmanagement
Change
Digitale Transformation

Agilität in der Logistik oder: Liefern wie Amazon

Projektmanagement
Agile Toolbox
Scrum

Meilensteine und Scrum

Portfoliomanagement
Project management

Too many projects? Portfolio management simplified

Neues Arbeiten
Mehr Formate
Agile Toolbox
Scrum
Scrum Values

Wie agiles Arbeiten die Kommunikation aus der Selbstverständlichkeit holt

Neues Arbeiten
Change
Agiles Lernen
Mehr Formate
Audio

New Learning heute für das New Work von morgen – mit Angelika Weis

Neues Arbeiten
Change
Soziale Innovation

New Work Experience 2019 – ein Erfahrungsbericht

Neues Arbeiten
Audit
Change

Agil im Audit: das Starter-Kit

Neues Arbeiten
Agile Toolbox
Scrum
Scrum4Schools
Agile Prinzipien

Scrum4Schools: Lernen für die Zukunft

Neues Arbeiten
Agile Toolbox
Scrum
Scrum Meetings
Retrospektive

Arbeiten wir uns gesund!

Neues Arbeiten
Agile Toolbox
Scrum
ScrumMaster-Praxistipps

Who should be in (agile) HR?

Neues Arbeiten
Agile Toolbox
Scrum
Scrum Values

Glauben Sie an die Seele Ihrer Firma?

Neues Arbeiten
Agile Toolbox
Scrum
Product Owner
ScrumMaster-Praxistipps

Produktivität auf Irrwegen: "Führen wir schnell mal Scrum ein!"

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Freiwilliges Teilen von Wissen – Erfolgreiche agile Teams #5

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Doing vs. Being Agile – Erfolgreiche agile Teams #1

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Freude bei der Arbeit & Sustainable Pace – Erfolgreiche agile Teams #3

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Anpassungsfähigkeit & schonungslose Offenheit – Erfolgreiche agile Teams #4