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