Happy Birthday, Scrum!

Ein Blick auf die Anfänge, die Zwischenstände und die Gegenwart von Scrum

Am 15. Oktober 1995 startete die Tagesschau mit der Meldung, dass die Islamwissenschaftlerin Annemarie Schimmel in Frankfurt den Friedenspreis des Deutschen Buchhandels verliehen bekam. [1] In den USA lief die Simpsons-Episode „Lisa the Vegetarian” mit Linda und Paul McCartney, in der sich Lisa für eine vegetarische Ernährung entscheidet. [2] Und ich? Ich hatte meine ersten beiden Berufswochen in einem Telekommunikationskonzern hinter mir und lernte, wie Vertrieb jenseits der BWL-Lehrbücher funktioniert. Ach ja, und dann war da noch eine Veranstaltung in Austin, Texas: die „Conference on Object Oriented Programming Systems, Languages, and Applications”, kurz OOPSLA ’95, auf der Ken Schwaber den SCRUM Development Process vorstellte. [3] Ein Prozess, der die Welt der Softwareentwicklung nachhaltig veränderte.

30 Jahre ist das her. Trotz der Tatsache, dass die beiden Japaner Ikujirō Nonaka [4] und Hirotaka Takeuchi [5] Scrum als Ausdruck bereits 1986 in einer Abhandlung erwähnt hatten (nach ihrer Beobachtung erzielten kleine, sich selbst organisierende Teams mit selbst gesteckten Zielen die besten Ergebnisse bei der Entwicklung von komplexen Produkten), gilt bei vielen Agilisten die OOPSLA ’95 als Geburtsstunde von Scrum.

Happy Birthday, Scrum! Du bist nun stolze 30 Jahre alt!

Der SCRUM Development Process

Ken Schwaber beginnt mit einer unbequemen Beobachtung: In vielen Unternehmen wird so getan, als ließe sich Softwareentwicklung vollständig planen und linear steuern. In der Praxis ändert sich jedoch vieles gleichzeitig: Technologien reifen, Anforderungen verschieben sich, Markt und Wettbewerb setzen neue Impulse. Wer diesen kreativen und teils undurchsichtigen Prozess wie eine exakt berechenbare Maschine behandelt, produziert Fehlprognosen und Frust. Seine Antwort lautet: SCRUM. Kein Wunsch nach mehr Kontrolle, sondern der Entwurf eines Prozesses, der Unvorhersehbarkeit ernst nimmt und aktiv steuert.

Die Grundlage von SCRUM ist empirische Prozesskontrolle. Im Mittelpunkt stehen häufige Inspektion, bewusste Anpassung und sichtbares Risikomanagement. Methodisch knüpft SCRUM an iterative und inkrementelle Vorgehensweisen in der objektorientierten Entwicklung an. An die Stelle der Illusion vollständiger Planbarkeit treten ein klarer Takt, kurze Zyklen und wenige robuste Kontrollen.

Wie funktioniert das konkret? SCRUM organisiert die Arbeit in drei Phasen:

Pregame: Im Pregame werden Backlog und grobes Releaseziel geklärt, kleine Teams benannt, Risiken beurteilt und die Architektur so gespannt, dass Änderungen möglich bleiben. Die Gestaltung erfolgt auf hoher Ebene und bereitet die Umsetzung vor.

Game: In kurzen Sprints von ein bis vier Wochen liefern Teams mit drei bis sechs Personen lauffähige Stände. Jede Schleife folgt demselben Ablauf: Develop für die Umsetzung, Wrap für das Integrieren zu einem ausführbaren Stand, Review mit allen relevanten Beteiligten, Adjust für Kurs und Inhalt. Der geplante Release kann währenddessen angepasst werden. Die Anpassung erfolgt gesteuert und auf Basis der gemachten Beobachtungen.

Postgame: Im Postgame schließen Integration, Systemtests, Dokumentation, Training und die Vorbereitung der Auslieferung die Arbeit ab. Das Produkt wird für die Veröffentlichung bereitgestellt.

Gesteuert wird mit wenigen klaren Größen: Backlog und geplante Releases, zu ändernde Komponenten als Packets, konkrete Changes, aufkommende Problems, kontinuierlich bewertete Risks sowie Solutions und Issues. In jedem Review werden diese Punkte transparent gemacht und nachgeschärft.

Kurz gesagt: SCRUM ersetzt trügerische Vorhersage durch kurze Feedbackschleifen, kleine fokussierte Teams und sichtbare Entscheidungen. So entsteht Verlässlichkeit in einem Umfeld, das sich ständig bewegt. Zumindest klingt diese Zusammenfassung schon erstaunlich nach dem Ansatz, den wir heute kennen, oder?

Prozess, Methode, Vorgehen oder Framework?

• “In this paper we introduce a development process, SCRUM, that treats major portions of systems development as a controlled black box.”
• “SCRUM is a management, enhancement and maintenance methodology for an existing system or production prototype.”
• “Our new approach to systems development is based on both defined and black box process management. We call the approach the SCRUM methodology…”

Diese drei Sätze finden sich in Ken Schwabers Dokument. SCRUM wird als Entwicklungsprozess beschrieben, als Methodologie zum Managen, Erweitern und Pflegen von Systemen und Prototypen positioniert und als Vorgehen deklariert. Offensichtlich verwendet Schwaber die Begriffe überlappend: Ein Prozess beschreibt eine Abfolge von Aktivitäten mit Ein- und Ausgaben. Eine Methode ist ein übergeordneter Handlungsrahmen mit Regeln und dem Wie des Arbeitens. Ein Approach bzw. Vorgehen ist die pragmatische Ausprägung im Kontext, also die konkrete Organisation und Anwendung des Handlungsrahmens.

Interessanterweise taucht der Begriff Framework nicht im Sinne des heutigen Scrum Guide auf. Schwaber verwendet Framework lediglich definitorisch im Methodenkapitel:

“The approach used to develop a system is known as a method. A method describes the activities involved in defining, building, and implementing a system; a method is a framework. Since a method is a logical process for constructing systems (process), it is known as a metaprocess (a process for modeling processes).”

Hätte ich das vor zehn Jahren gewusst, hätte ich mir manche Diskussion über Methode oder Framework sparen können. Heute würde ich beim Referenzieren des Originals konsistent von Prozess, Methode und Vorgehen sprechen. Und beim Diskutieren über das heutige gelebte Scrum den Begriff Framework verwenden und bei Bedarf auf den Begriffswechsel sowie die geänderte Schreibweise mit nur noch einem Großbuchstaben hinweisen. [6]

Abbildung 1: SCRUM Methodology – Auszug aus Ken Schwabers Development Process von 1995 [3]

Eine Zeitreise vom SCRUM Development Prozess zum heutigen Scrum Guide

Springen wir in das Jahr 2010. Fünfzehn Jahre dauert der Siegeszug von SCRUM bereits an, doch inzwischen vermischen Unternehmen Praktiken, Beratungen liefern Checklisten und Teams streiten über Begriffe. Aus einem empirischen Rahmen ist vielerorts ein Methodencocktail geworden. Genau hier setzen Ken Schwaber und Jeff Sutherland an: Der Scrum Guide soll ein gemeinsames Minimum schaffen. Ein schlankes Framework, klare Sprache, wenige Regeln, viel Freiraum. Kein Rezeptbuch, sondern Referenz.

Die Erstausgabe 2010 zieht die Leitplanken. [7] Scrum (jetzt nur noch in Überschriften groß geschrieben) wird als Framework für die Entwicklung komplexer Produkte und Systeme auf Basis empirischer Prozesskontrolle beschrieben. Transparenz, Inspektion und Anpassung bilden das Fundament. Der Takt ist der Sprint. Am Ende steht ein potenziell auslieferbares Increment. Rollen und Ereignisse werden benannt, Timeboxes klar begrenzt, der Ton ist pragmatisch. Ziel ist ein gemeinsames Vokabular, das Orientierung gibt, ohne Teams zu fesseln. [8]

Kurz danach zeigt sich ein neues Risiko. Wo Regeln Orientierung bieten, drohen sie zum Abhaken zu verkommen. Die 2011er Fassungen entschlackt bewusst. Teams geben keinen heiligen Schwur auf Umfang mehr, sondern liefern eine Prognose. Burn-downs und Release-Pläne mögen helfen, sind aber nicht vorgeschrieben. Das Product Backlog wird geordnet statt starr priorisiert. Der Guide trennt deutlicher zwischen Regeln und hilfreichen Praktiken. Denken statt Rezept folgen. [9] [10]

2013 rückt die Stelle in den Fokus, an der viele Entscheidungen kippen: mangelnde Transparenz. Ein eigener Abschnitt macht deutlich, dass schlechte Einsichten aus schlechten Artefakten entstehen. Sprint Planning wird als ein Ereignis mit zwei Themen beschrieben, das Sprintziel ausdrücklich gestärkt. Grooming wird zu Refinement. Das Daily wird als Planungsereignis geschärft, Timeboxes werden sprachlich präzisiert. Der Rahmen bleibt schlank, die Inspektionspunkte werden belastbarer. [11]

2016 ergänzt, was Empirie erst tragfähig macht. Die fünf Werte Commitment, Courage, Focus, Openness und Respect werden verankert. Sie adressieren Verhalten, nicht Technik. Die Botschaft lautet: Ohne gelebte Werte bleibt Transparenz Fassade und Adaption Zufall. Der Guide benennt damit die soziale Statik hinter der Methode. [12]

2017 folgt Feinarbeit aus der Praxis. Scrum wird jenseits von Software eingeordnet. Das Daily wird noch klarer als Planungsereignis formuliert. In das Sprint Backlog wandert mindestens eine priorisierte Verbesserung aus der Retrospektive. Das Increment wird als inspizierbare Done Arbeit konkretisiert. Es geht um Kontur, nicht um Ausbau. [13]

2020 strafft den Text deutlich und beseitigt ein verbreitetes Organisationsmuster. Statt eines Development Teams im Scrum Team gibt es ein Team mit drei Verantwortlichkeiten. Product Owner, Scrum Master und Developers arbeiten auf ein gemeinsames Ziel. Neu ist das Product Goal als langfristiger Orientierungspunkt. Jedes Artefakt erhält ein Commitment: Product Goal am Product Backlog, Sprint Goal am Sprint Backlog, Definition of Done am Increment. Die Sprache wird einfacher, der Produktfokus klarer. [14] [15]

So entsteht über die Jahre eine konsistente Linie. Zuerst ein gemeinsamer Kern, dann die Korrektur gegen Rezeptdenken, danach Transparenz, Werte und Feinschliff, schließlich ein sehr schlanker Referenztext mit klaren Verantwortlichkeiten und Commitments. Wer heute über Daily, Definition of Done, Increment oder Product Goal spricht, kann hier verorten, welches Problem diese Elemente lösen und wann sie im Guide ihren Platz fanden. [16]

Die Gegenwart von Scrum

Wie empfinden Sie Scrum heute? Mehr Meetings als Wirkung? Funktionierendes Miteinander, aber wenig Resultate? Oder erleben Sie kurze Zyklen, klare Entscheidungen und regelmäßiges Lernen?

Die Gegenwart von Scrum wirkt oft ambivalent. Im Netz kursieren viele Berichte über ausbleibende Erfolge. Gleichzeitig entstehen Erweiterungen wie das Scrum Expansion Pack, die mehr Tiefe und Kontext liefern sollen, oder Frameworks zur Skalierung, um die Elemente konzerntauglich zu gestalten. Hat Scrum also ein Problem? Ringen Organisationen mit falsch verstandener oder halbherziger Agilität? Oder liegen praktische Herausforderungen außerhalb des Scopes von Scrum?

Bei der Beantwortung helfen verschiedene Perspektiven. Die erste fokussiert das Warum. Scrum richtet sich an Situationen mit hoher Dynamik und Ungewissheit. Wer vor allem Effizienz erwartet, startet mit einer falschen Hoffnung. Unter Komplexität zählt zuerst Wirkung, dann Geschwindigkeit. Effektivität schlägt Effizienz, weil ein perfekt optimierter Prozess am falschen Produkt elegant scheitert. Genau das ist das agile Versprechen: schneller herausfinden, was wirklich Nutzen stiftet, und darauf fokussieren.

Danach folgt die Empirie. Scrum funktioniert nur, wenn Teams sichtbar planen, messen und lernen. Messung ist dabei Feedback für das Team, nicht Fernsteuerung für die Hierarchie. Wird Velocity nach oben gemanagt, entsteht Metrik-Theater: Punkte steigen, Erkenntnis sinkt, Motivation bröckelt. Besser ist, Kennzahlen dort zu interpretieren, wo Kontext vorhanden ist, und sie als Ausgangspunkt für Entscheidungen und Verbesserungen zu nutzen.

Der dritte Hebel ist Kundennähe. Sprint Reviews ohne echte Nutzer sind verbreitet. Dann bleibt Produktentwicklung ein Ratespiel. Der Review dient dazu, das Increment zu prüfen und das Backlog anzupassen. Ohne die wichtigsten Stakeholder fehlt das Markt-Echo, das Prioritäten schärft und Lernen beschleunigt.

Es braucht außerdem Disziplin im Kleinen. Viele Retrospektiven produzieren lange Wunschlisten, aber wenig Umsetzung. Wirksam wird die Retro, wenn konkrete Verbesserungen in den nächsten Sprint übernommen und im Sprint Backlog sichtbar werden. Jede Maßnahme braucht Ursachenanalyse und Verantwortungsübernahme, ein erwartetes Ergebnis und ein Kriterium, woran man den Erfolg erkennt.

Ein weiteres Spannungsfeld ist Skalierung. Wachsen Produkt und Organisation, häufen sich Abhängigkeiten. Häufige Reaktion: zusätzliche Gremien und Statuspräsentationen. Wirksamer ist es, solche Abhängigkeiten aktiv zu reduzieren, echte Entscheider in den Lernzyklus zu holen und Formate zu wählen, die Hilfe schnell ermöglichen statt Kontrolle zu inszenieren. [17]

Schließlich entscheidet Kontextpassung. Scrum ist kein Allheilmittel. In stabilen, gut vorhersagbaren Märkten stiftet ein schlanker, planbarer Prozess oft mehr Nutzen. Viele Organisationen brauchen beides: in einigen Bereichen explorativ, in anderen effizient. Das erfordert regelmäßige Gespräche über Marktlogik, Risiken und den echten Bedarf an Agilität, statt Agilität zum Selbstzweck einzuführen.

Diese typischen Ernüchterungen deuten selten auf einen Mangel im Framework. Sie verweisen auf fehlendes Warum, falsch eingesetzte Messung, zu wenig Kundenecho, zu viele Abhängigkeiten und zu wenig Fokus in der Verbesserung. Wenn das Fundament stimmt, zeigt sich Scrum als leichtes Betriebssystem für Lernen unter Unsicherheit: kurze Zyklen, klare Entscheidungen, sichtbare Ergebnisse. Erweiterungen haben dann ihren Platz, aber nicht als Ersatz für das, was zuerst sitzen muss.

Hoch sollst du leben, dreimal hoch!

Scrum hat Arbeit neu verdrahtet. Nicht als Trend, sondern als Taktik für das Wesentliche: Wirkung vor Geschwindigkeit, Lernen vor Linearisierung, Produkt vor Projekt. Aus einer Idee wurde ein Siegeszug durch Entwicklungsabteilungen, Produktteams und ganze Organisationen. Weil kurze Zyklen, klare Ziele und sichtbare Increments Ergebnisse liefern. Punkt.

Scrum gewinnt dort, wo andere Verfahren ins Raten kippen: bei Unsicherheit, bei wechselnden Annahmen, bei echter Komplexität. Transparenz, Inspektion, Anpassung sind keine Poster. Sie sind der Motor. Der Sprint fixiert die Zeit. Das Ziel bestimmt den Umfang. Das Increment macht Fortschritt verhandelbar. So wird Bewegung messbar und Entscheidungen werden besser.

Die Stärke des Frameworks liegt in seiner Knappheit. Wenige Seiten, enorme Wirkung. Wer die Entwicklung der Guides kennt, liest zwischen den Zeilen die Absicht: keine Rezeptküche, sondern ein Minimum an Regeln, das Fokus erzwingt und Verantwortung sichtbar macht. Product Goal, Sprint Goal, Definition of Done. Drei Commitments, ein Kompass.

Und ja, Scrum verlangt Haltung. Mut, Klartext, Konsequenz. Rollen, die entscheiden. Kennzahlen, die dem Team gehören. Reviews mit echten Nutzern. Retrospektiven mit greifbaren Maßnahmen. Wer das liefert, erlebt Wirkung. Wer stattdessen Theater spielt, bekommt Theaterergebnisse. Nicht das Framework scheitert. Die Anwendung tut es hin und wieder.

Darum: Happy Birthday, Scrum! 30 Jahre und kein bisschen müde. Hoch sollst du leben, du beeindruckendes Framework. Danke, dass du aus Unsicherheit Fortschritt machst und aus Komplexität Klarheit. Auf die nächsten Jahre voller klarer Ziele und Produkte, die zählen. 

Hinweise:

[1] Tagesschau, 15. Oktober 1995
[2] Lisa als Vegetarierin. Linda und Paul McCartney waren übrigens erst einverstanden in der Episode aufzutreten, als die Produzenten ihnen versprachen, dass Lisa auch in späteren Folgen Vegetarierin bleibt.
[3] Ken Schwaber: SCRUM Development Process
[4] Ikujirō Nonaka war Ökonom und Organisationstheoretiker und legte ein besonderes Augenmerk auf die Beschleunigung von Produktentwicklungszyklen
[5] Hirotaka Takeuchi entwickelte die sogenannte Wissensspirale und gilt wie Ikujirō Nonaka als bedeutender Experte des Wissensmanagements
[6] Im Originaltext „fehlen“ einige Bezeichnungen, ohne die man sich das Vorgehen heutzutage kaum vorstellen kann: Product Owner, Scrum Master, Retrospektive, Daily, Definition of Done oder auch Increment.
[7] Vor der ersten offiziellen Version, die im Februar 2010 veröffentlicht wurde, gab es bereits zwei ältere, nicht offizielle Versionen: Ken Schwabers SCRUMGUIDE von Mai 2009 bzw. Ken Schwabers und Jeff Sutherlands SCRUMGUIDE von November 2009.
[8] Scrum Guide, (Version 1,) Februar 2010, veröffentlicht von Scrum Alliance
[9] The Scrum Guide (Version 2,) Juli 2011, veröffentlicht von Ken Schwaber und Jeff Sutherland
[10] The Scrum Guide(Version 3,) Oktober 2011, veröffentlicht von Ken Schwaber und Jeff Sutherland
[11] The Scrum Guide, (Version 4,) Juli 2013, veröffentlicht von Ken Schwaber und Jeff Sutherland
[12] The Scrum Guide, (Version 5,) Juli 2016, veröffentlicht von Ken Schwaber und Jeff Sutherland
[13] The Scrum Guide, (Version 6,) November 2017, veröffentlicht von Ken Schwaber und Jeff Sutherland
[14] The Scrum Guide (Version 7,) November 2020, veröffentlicht von Ken Schwaber und Jeff Sutherland
[15] Interessanterweise „fehlen“ auch in der Version aus dem Jahr 2020 zahlreiche Begriffe, die im agilen Kontext etabliert sind: Velocity, Standup-Meeting, Definition of Ready, Story Points, Traceability, Vegas Regel…
[16] Wie verändern sich die Inhalte der verschiedenen Versionen im Laufe der Zeit? Hier finden Sie eine Übersicht mit Änderungen.
[17] Robert Briese hat einen Beitrag veröffentlicht, in dem er ein anderes Vorgehen mit synchronen Abhängigkeiten für Teams empfiehlt.

Im kostenlosen Blogpaper Scrum finden Sie sieben Perspektiven auf die heute gelebte Praxis von Scrum.

Sehr zu empfehlen ist auch die Beitragsreihe von Heiko Bartlog: Agilität? Haben wir probiert! Funktioniert nicht!

Wollen Sie als Multiplikatorin oder Meinungsführer über die Vergangenheit und den Status quo von Scrum diskutieren? Dann teilen Sie diesen Beitrag in Ihrem Netzwerk.

Michael Schenkel hat weitere Beiträge im t2informatik Blog veröffentlicht, u. a.: