SCRUM

Ein Rahmenwerk für die agile Produktentwicklung

Autor: Steffen Griesel, Business Trainer 


Die Anfänge von Scrum

Scrum ist eine der bekanntesten agilen Methoden und wird vor allem in der Softwareentwicklung angewendet. Der Ursprung des Begriffs und die damit verbundene Vorgehensweise haben aber mit der Softwareentwicklung zunächst gar nichts zu tun.

Der Begriff und die Idee tauchen zum ersten Mal 1986 in einem von Hirotaka Takeuchi und Ikujiro Nonaka verfassten Artikel für die Harvard Business Review auf: https://hbr.org/1986/01/the-new-new-product-development-game

Die beiden Wissenschaftler stellen darin einen Ansatz vor, wie die Entwicklung neuer Produkte unter verschärften Wettbewerbsbedingungen schneller und flexibler verlaufen kann. 

Gegen die aus ihrer Sicht veraltete sequentielle Produktentwicklung, bei der ein Entwicklungsschritt nach dem anderen erfolgt, propagieren die beiden Autoren einen ganzheitlichen Ansatz, bei dem das Entwicklungsteam ständig zusammenarbeitet und sich gegenseitig inspiriert.

Takeuchi und Nonaka vergleichen die beiden unterschiedlichen Produktentwicklungsansätze mit zwei verschiedenen Sportarten: 

Die sequentielle Methode gleicht einem Staffellauf, bei dem ein Spezialistenteam den Staffelstab an das nächste Spezialistenteam weiterreicht. So durchläuft die Produktentwicklung nach und nach die vorgegebenen Phasen.

Die ganzheitliche Methode gleicht dagegen einem Rugby-Spiel, bei dem sich das gesamte Team einheitlich auf dem Spielfeld nach vorn bewegt und sich dabei den Ball gegenseitig zuspielt. 

„Moving the Scrum Downfield“ ist die entsprechende Formulierung im Artikel, bei dem der Begriff zum ersten Mal im Kontext der Produktentwicklung vorkommt. Damit ist die Bewegung des angreifenden Rugby-Teams auf die Torlinie des Defensivteams gemeint. 

Eine solche Vorwärtsbewegung kann ihren Ausgangspunkt in einem „Scrum“ haben. Das ist die Abkürzung für „Scrummage“ und bedeutet „angeordnetes Gedränge“. Ein solches Gedränge, bei dem sich Spieler*innen beider Teams in drei Reihen dicht an dicht gegenüberstehen ist eine Standardsituation im Rugby, um das Spiel nach einem kleineren Regelverstoß neu zu starten.  

Takeuchi und Nonaka sahen 1986 in dieser Rugby-Spielweise das neue Vorbild für die Zusammenarbeit zukünftiger Entwicklungsteams. 

Die Basis für eine schnellere und flexiblere Produktentwicklung ist das permanente Zusammenspiel eines sorgfältig zusammengestellten interdisziplinären Teams, das von Beginn an zusammenarbeitet. 

Der Entwicklungsprozess orientiert sich dabei nicht mehr an einer vorgegebenen Phasenstruktur, sondern entsteht aus dem Zusammenspiel des Teams.

Takeuchi und Nonaka fanden bei der Analyse des Prozessmanagements solcher Unternehmen, die sich den neuen Scrum-Ansatz bei der Produktentwicklung auf die Fahne geschrieben hatten, folgende sechs hervorstechende Merkmale: 

  • Die Entwicklungsteams werden einerseits mit einem hohen Maß an Gestaltungsfreiheit ausgestattet, andererseits aber auch vor eine sehr große Herausforderung gestellt, wie z.B. die Entwicklung eines Produkts mit enormer strategischer Bedeutung für das ganze Unternehmen. 

  • Die Entwicklungsteams fangen ganz von vorn an und agieren im Lauf der Zeit wie Startups, die ihre eigene Agenda entwickeln und sich selbst organisieren.


  • Die Entwicklungsteams arbeiten von Anfang bis Ende zusammen. Dadurch überlappen sich die einzelnen Entwicklungsphasen und erzeugen einen ganz eigenen Arbeitsrhythmus.


  • Die Entwicklungsteams eignen sich durch beharrliches Lernen das nötige Wissen und die erforderlichen Fähigkeiten an, um der jeweiligen Aufgabenstellung zu begegnen. Die Teams arbeiten nach einem Versuch-und-Irrtum-Verfahren und grenzen die Optionen sukzessive ein.


  • Die Entwicklungsteams haben zwar große Freiheiten, werden aber dennoch vom Management beeinflusst, z.B. durch die Auswahl der Teammitglieder, die Zusammensetzung des Teams oder die Ausnutzung sozialer Dynamiken im Team.


  • Die Entwicklungsteams haben starkes Interesse daran, ihre Erfahrungen über die Teamgrenzen hinaus in der jeweiligen Organisation weiterzugeben. Mitglieder übernehmen beispielsweise nach dem Ende des Projekts Schlüsselpositionen in neuen Entwicklungsteams. Eine andere Form des Wissenstransfers ist die Standardisierung bestimmter erfolgreicher Projektaktivitäten im gesamten Unternehmen.  



Scrum in der Softwareentwicklung

Seinen Weg in die Softwareentwicklung fand der Scrum-Ansatz 1993 über Jeff Sutherland. Er kannte die Forschungsergebnisse von Takeuchi und Nonaka und probierte den Ansatz in einem Softwareprojekt aus. Auch Ken Schwaber testete damals ähnliche methodische Ansätze. Gemeinsam stellten beide 1997 Scrum für die Softwareentwicklung in einem Fachartikel vor.

In den darauffolgenden Jahren folgten weitere Publikationen und Scrum erfreute sich immer größerer Beliebtheit unter Softwareentwickler*innen. Heute ist Scrum quasi Standard in der agilen Softwareentwicklung.

Sutherland und Schwaber geben seit 2010 den „Scrum Guide“ heraus und aktualisieren ihn regelmäßig: https://scrumguides.org/ 

Der Scrum Guide gilt als die offizielle Richtlinie, wie Scrum anzuwenden ist. Scrum wird darin als „ein Rahmenwerk“ definiert, „innerhalb dessen Menschen komplexe adaptive Aufgabenstellungen angehen können, und durch das sie in die Lage versetzt werden, produktiv und kreativ Produkte mit höchstmöglichem Wert auszuliefern.“

Mit der Definition als „Rahmenwerk“ machen Sutherland und Schwaber klar, dass es sich bei Scrum keinesfalls um eine bestimmte Methode, Technik oder einen Prozess handelt, sondern im Rahmen von Scrum, verschiedene Methoden, Techniken und Prozesse realisiert werden können.

Mittlerweile wird Scrum über die Softwareentwicklung hinaus als Rahmenwerk bei den unterschiedlichsten Entwicklungsprojekten eingesetzt, insbesondere solchen, die sich durch komplexe Anforderungen auszeichnen.

Scrum favorisiert eine iterative und inkrementelle Vorgehensweise, die sich auf Erfahrungswissen stützt. Erfahrungswissen wird durch Learning by Doing und den daraus resultierenden Erkenntnissen gewonnen. Dieser empirische Ansatz der Prozessteuerung basiert auf einem Dreischritt: Transparenz, Überprüfung und Anpassung. 

Mit Hilfe dieses Dreischritts soll die Vorhersage künftiger Entwicklungsergebnisse verbessert und die Wahrscheinlichkeit, dass ein Entwicklungsprojekt scheitert, minimiert werden.

Aus diesem Grund wird der Entwicklungsprozess bei Scrum nach transparenten Standards implementiert. Die Fortschritte in Richtung des Projektziels werden regelmäßig überprüft. Zeichnen sich Defizite ab, wird umgehend eine Anpassung vorgenommen, um den Schaden so klein wie möglich zu halten. 

Scrum kennt vier immer wiederkehrende Ereignisse, bei denen eine Überprüfung und Anpassung stattfinden kann:

  • Sprint Planning
  • Daily Scrum
  • Sprint Review
  • Sprint Retrospektive


Es gibt fünf Werte, an denen sich die Mitglieder eines Scrum Teams bei der Zusammenarbeit orientieren: 

  • Selbstverpflichtung
  • Mut
  • Fokus
  • Offenheit
  • Respekt


Das Team

Scrum Teams organisieren sich selbst und sind interdisziplinär zusammengesetzt. Das fördert erfahrungsgemäß die flexible, kreative und produktive Zusammenarbeit.

Scrum Teams gehen bei der Produktentwicklung iterativ und inkrementell vor, d.h. die ausgelieferten Zwischenergebnisse sind bereits anwendbar und das daraus resultierende Anwenderfeedback fließt direkt in die nächste Entwicklungsschleife  ein.

Neben dem eigentlichen Entwicklungsteam gibt es bei Scrum noch die Rollen des Scrum Masters und Product Owners. Die Aufgabenverteilung ist sehr klar: Das Entwicklungsteam kümmert sich um die Entwicklung des Produkts und stellt nach jeder Entwicklungsschleife ein Produktinkrement vor.

Der Product Owner managt das Product Backlog. Das ist ein Katalog aller Anforderungen, die für eine erfolgreiche Produktentwicklung erforderlich sind.

Der Product Owner aktualisiert und priorisiert die einzelnen Anforderungen regelmäßig im Laufe des Entwicklungsprozesses.

Er bringt dem Entwicklungsteam die Hintergründe, Zusammenhänge und Abhängigkeiten zwischen den einzelnen Produktanforderungen näher, damit es seine Entwicklungsarbeit bestmöglich erledigen und ein Produkt mit höchstmöglichem Wert entwickeln kann.

Der Scrum Master hat die Aufgabe, darauf zu achten, dass Scrum nach allen Regeln der Kunst umgesetzt wird. Er steht dem Entwicklungsteam zu diesem Zweck als Coach zur Seite fördert die Zusammenarbeit. 

Der Scrum Master unterstützt ebenfalls die Arbeit des Product Owners, indem er das nötige Wissen für einen erfolgreichen Entwicklungsprozess nach Scrum an das Entwicklungsteam vermittelt.

Innerhalb der Organisation ist der Scrum Master dafür verantwortlich, dass Scrum als Rahmenwerk der Produktentwicklung eingeführt und implementiert wird. Als Ansprechpartner gibt er Auskunft über alle anfallenden Fragen zu Scrum.
 

Die Ereignisse

Scrum ist durch mehrere Ereignisse charakterisiert, die sich in einem regelmäßigen Rhythmus wiederholen. Die Ereignisse selbst sind jeweils befristet und in ihrer Dauer begrenzt.

Das Herzstück von Scrum ist der Sprint. Ein Sprint dauert nicht länger als einen Monat. Er kann aber auch in einem kürzeren Turnus absolviert werden. Am Ende eines jeden Sprints liegt ein anwendbares Produktinkrement zur Auslieferung bereit. Ein Sprint folgt auf den anderen, bis das Produkt fertig ist.

Alle weiteren Ereignisse finden innerhalb eines Sprints statt. Jeder Sprint startet mit einem Sprint Planning, das höchstens acht Stunden dauert und an dem das komplette Scrum Team teilnimmt.

Im Sprint Planning wird geklärt, welche Funktionalitäten das zu entwickelnde Produktinkrement des aktuellen Sprints beinhalten soll und welche konkreten Arbeitsschritte dafür erforderlich sind.

Der Product Owner erläutert mit Blick auf das zu erreichende Sprint-Ziel die dafür im Product Backlog vorgesehenen Anforderungen und stimmt sich darüber mit dem Scrum Master und dem Entwicklungsteam ab.

Alle Anforderungen, die für das Sprint-Ziel relevant sind und entwickelt werden müssen, damit am Ende des Sprints ein anwendbares und auslieferungsfähiges Produktinkrement vorliegt, werden daraufhin in das Sprint Backlog übertragen.

Im Laufe des Meetings arbeitet das Entwicklungsteam einen Umsetzungsplan aus und definiert darin die einzelnen Arbeitsschritte. Das Entwicklungsteam erläutert den  Umsetzungsplan gegenüber dem Product Owner und dem Scrum Master. Der Umsetzungsplan wird dem Sprint-Backlog abschließend hinzugefügt.

Die kurzfristige Arbeitsplanung findet im Daily Scrum statt. Das Daily Scrum ist ein 15-minütiges Meeting, das an jedem Arbeitstag eines Sprints stattfindet. Im Daily Scrum plant das Entwicklungsteam den Arbeitstag und überprüft die am vorherigen Tag erzielten Arbeitsfortschritte.

Nachdem ein Sprint beendet wurde, stellt das Entwicklungsteam sein Arbeitsergebnis in einem Sprint Review vor und berichtet über den Verlauf des Sprints. Der Product Owner lädt dazu Stakeholder*innen ein, für die das Produktinkrement relevant ist.

Die Stakeholder*innen tauschen sich mit dem Entwicklungsteam aus und besprechen gemeinsam die nächsten Entwicklungsschritte. Die Ergebnisse des Meetings werden in das Product Backlog eingebracht. Das Sprint Review dauert maximal vier Stunden.

In der Zeit zwischen dem abgeschlossenen Sprint Review und dem kommenden Sprint Planning wird die Sprint Retrospektive abgehalten. Das Scrum Team reflektiert in diesem Meeting die gemeinsame Zusammenarbeit und identifiziert all das, was im nächsten Sprint verbessert werden kann. Das Scrum Team stellt einen Plan auf, wie diese Verbesserungen umgesetzt werden können. Die Sprint Retrospektive dauert höchstens drei Stunden.


Die Artefakte

Die einzelnen Artefakte sind bereits zur Sprache gekommen, sollen aber an dieser Stelle noch etwas genauer beschrieben werden. Das Product Backlog ist ein Katalog aller Anforderungen, die für eine erfolgreiche Produktentwicklung erforderlich sind.

Das Product Backlog wird vom Product Owner verwaltet. Er priorisiert und verfeinert die einzelnen Anforderungen oder aktualisiert das Product Backlog bei Bedarf.

Ein solcher Bedarf ergibt sich durch neue Kund*innenanforderungen, gewandelte Marktbedingungen oder technologische Innovationen.

Das Entwicklungsteam schätzt den Arbeitsaufwand aller im Product Backlog hinterlegten Anforderungen ab.

Das Sprint Backlog umfasst alle Produktanforderungen aus dem Product Backlog, die für das Sprint-Ziel relevant sind und umgesetzt werden müssen, damit am Ende des Sprints ein anwendbares und auslieferungsfähiges Produktinkrement vorliegt.

Das Sprint Backlog beinhaltet auch einen Plan, aus dem hervorgeht, wie das Entwicklungsteam die einzelnen Anforderungen umsetzen will.

Schließlich fließen in das Sprint Backlog noch die Verbesserungsvorschläge aus der Sprint Retrospektive ein. So zeigt das Sprint Backlog immer den aktuellen Stand der Entwicklung.

Das Inkrement ist das Arbeitsergebnis eines abgeschlossenen Sprints. Das Inkrement beinhaltet alle bis dahin erledigten Anforderungen des Product Backlogs und schließt auch die Ergebnisse der vorherigen Sprints mit ein. 

Das Inkrement ist ein anwendbares und auslieferungsfähiges Zwischenprodukt, das alle bereits umgesetzten und fertiggestellten Funktionen umfasst.


Zusammenfassung

  • Scrum ist eine der bekanntesten agilen Methoden und wird vor allem in der Softwareentwicklung angewendet.

  • Der Begriff und die Idee dahinter tauchen zum ersten Mal 1986 in einem von Hirotaka Takeuchi und Ikujiro Nonaka verfassten Artikel für die Harvard Business Review auf.

  • Takeuchi und Nonaka sahen in der Spielweise eines Rugby-Teams das neue Vorbild für die Zusammenarbeit zukünftiger Entwicklungsteams. 

  • „Moving the Scrum Downfield“ ist die Formulierung im Artikel, bei dem der Begriff „Scrum“ zum ersten Mal im Kontext der Produktentwicklung vorkommt.

  • Die Basis für eine schnellere und flexiblere Produktentwicklung ist das permanente Zusammenspiel eines sorgfältig zusammengestellten inter-disziplinären Teams, das von Beginn an zusammenarbeitet. 

  • Der Entwicklungsprozess orientiert sich dabei nicht an einer vorgegebenen Phasenstruktur, sondern entsteht aus dem Zusammenspiel des Teams.

  • Seinen Weg in die Softwareentwicklung fand der Scrum-Ansatz 1993 über Jeff Sutherland. Auch Ken Schwaber testete damals ähnliche methodische Ansätze.

  • Sutherland und Schwaber geben seit 2010 den „Scrum Guide“ heraus und aktualisieren ihn regelmäßig: https://scrumguides.org/ 

  • Der Scrum Guide gilt als die offizielle Richtlinie, wie Scrum anzuwenden ist.

  • Scrum favorisiert eine iterative und inkrementelle Vorgehensweise, die sich auf Erfahrungswissen stützt.

  • Scrum Teams organisieren sich selbst und sind interdisziplinär zusammengesetzt.

  • Neben dem eigentlichen Entwicklungsteam gibt es bei Scrum noch die Rollen: Scrum Master und Product Owner

  • Die Aufgabenverteilung ist sehr klar: Das Entwicklungsteam kümmert sich um die Entwicklung des Produkts. Der Product Owner managt das Product Backlog, in dem alle Produktanforderungen hinterlegt sind. Der Scrum Master achtet darauf, dass Scrum nach allen Regeln der Kunst umgesetzt wird.

  • Scrum ist durch mehrere Ereignisse charakterisiert, die sich in einem regelmäßigen Rhythmus wiederholen: Das Herzstück von Scrum ist der Sprint. Jeder Sprint startet mit einem Sprint Planning. Die kurzfristige Arbeitsplanung findet im Daily Scrum statt. Nach einem Sprint stellt das Entwicklungsteam sein Arbeitsergebnis im Sprint Review vor. In der Sprint Retrospektive reflektiert das Scrum Team die gemeinsame Zusammenarbeit.

  • Es gibt drei Artefakte: Das Product Backlog beinhaltet alle Anforderungen, die für eine erfolgreiche Produktentwicklung erforderlich sind. Das Sprint Backlog umfasst alle Produktanforderungen aus dem Product Backlog, die für das Sprint-Ziel relevant sind. Ein Inkrement ist das Arbeitsergebnis eines abgeschlossenen Sprints