Scrum – verstehen und erfolgreich einsetzen

Henning Wolf, Stefan Roock

• Verlag: dpunkt.verlag
• Jahr: 2021
• ISBN drucken: 9783864908484
• eBook-ISBN: 9783969105399
• Auflage: 3
• Thema: Betriebswirtschaft
• Thema: Projektmanagement

Das ultimative Scrum-Handbuch

• didaktisch sehr gut aufgebautes Grundlagenbuch
• mit Empfehlungen der Autoren aus der Praxis für die Praxis
• geeignet auch für Scrum-Zertifizierungskurse: Scrum Basics, Certified Scrum Master

Scrum dient dem agilen Management innovativer Produktentwicklung mit selbstorganisierten Teams. Mit seinem iterativ-inkrementellen Ansatz führt Scrum zu mehr Transparenz und Flexibilität als klassische sequenzielle Entwicklungsmethoden.
Die Autoren beschreiben in kompakter Form die Scrum-Grundlagen und die hinter Scrum stehenden Werte und Prinzipien. Dabei unterscheiden sie zwischen den produktbezogenen Aspekten, den entwicklungsbezogenen Aspekten und dem kontinuierlichen Verbesserungsprozess.
Im Einzelnen werden behandelt: die Scrum-Historie sowie Vorteile und Eignung von Scrum, der Scrum-Flow und die verschiedenen Rollen in Scrum mit ihren Verantwortlichkeiten (Scrum Master, Entwicklungsteam, Product Owner), selbstorganisierte Teams, die Scrum-Meetings (Daily Scrum, Sprint Planning, Sprint-Review, Sprint-Retrospektive), Scrum-Artefakte (Product Backlog, Sprint Backlog, lieferbares Produktinkrement), Releasemanagement und Schätzverfahren sowie die Einführung von Scrum im Unternehmen, Scrum-Skalierung, verteiltes Scrum und Leadership.
Im Anhang werden die Elemente des Scrum-Frameworks sowie einige sehr häufig anzutreffende Praktiken noch einmal in Kurzform dargestellt.
Die 3. Auflage wurde an die neue Fassung des Scrum Guide aus November 2020 angepasst, was neben Details auch das Konzept des Produktziels umfasst. Zudem gibt es einen Ausblick auf das Konzept der wirkungsvollen Agilität.

1Scrum: Historie, Vorteile, Eignung und Herausforderungen

»Everybody is on a team. There’s none of this nonsense of designers working separate.«

Jeff Sutherland, Ken Schwaber¹

Die Historie von Scrum ist gut geeignet, um neue Perspektiven auf Scrum zu erlangen und die Vielgestaltigkeit von Scrum besser zu verstehen.

Wir beginnen das Kapitel mit der Frage, was Autos, Kopierer, Spiegelreflexkameras und andere Produkte aus den 1970er- und 1980er-Jahren mit Scrum zu tun haben. Über Produktinnovation und lernende Organisationen landen wir im Jahr 1993 und gelangen zu Scrum in der Softwareentwicklung. Wir sehen, wie Scrum andere Ansätze (wie eXtreme Programming) inspiriert hat und wie Scrum sich selbst immer weiter verbreitete bis zum heutigen De-facto-Standard agiler Softwareentwicklung.

Auf dieser Basis diskutieren wir, für welche Bereiche Scrum geeignet ist und welche Vorteile der Einsatz von Scrum mit sich bringen kann.

1.1Historie

1.1.1Scrum-Teams nach Nonaka und Takeuchi

Im Jahr 1986 veröffentlichten Hirotaka Takeuchi und Ikujiro Nonaka in der Harvard Business Review einen Artikel mit dem Titel »The New New Product Development Game« (siehe [TakeuchiNonaka1986]). In diesem Artikel beschreiben die Autoren verschiedene Fallbeispiele von Produktentwicklungen, die besonders schnell und innovativ waren: Pkws bei Honda, Spiegelreflexkameras bei Canon, Kopierer bei Fuji-Xerox und bei Canon sowie Personal Computer bei NEC. Als eine wichtige Zutat wurde die Arbeit in sogenannten Scrum-Teams genannt (unseres Wissens nach taucht hier der Begriff des Scrum-Teams das erste Mal in der Literatur auf). Es verwundert daher nicht, dass vielen dieser Artikel als die Geburtsstunde von Scrum gilt. Jeff Sutherland bezieht sich immer wieder auf die Arbeiten von Nonaka und Takeuchi, wenn er über Scrum für die Softwareentwicklung spricht.

Der besagte Artikel in der Harvard Business Review stellt wesentliche Unterschiede zwischen klassischer Entwicklung und der Entwicklung in Scrum-Teams so wie in Abbildung 1–1 dar. Klassisch folgen verschiedene Phasen, wie Marktforschung, Design, Produktspezifikation, Entwicklung und Qualitätssicherung, sequenziell aufeinander. In den Phasen arbeiten die jeweiligen Spezialisten. Erst wenn eine Phase abgeschlossen ist, wird mit der nächsten begonnen. In den untersuchten Produktentwicklungen wurde von diesem strikten sequenziellen Verfahren abgewichen; es gab überlappende Phasen (siehe den Mittelteil in Abb. 1–1). Die nächste Phase beginnt, bevor die aktuelle Phase vollständig abgeschlossen ist. Bereits diese Überlappung bringt gravierende Änderungen mit sich:

• Die Projektbeteiligten müssen miteinander kooperieren, um die Phasenübergänge gestalten zu können.
• Probleme mit dem Ergebnis einer Phase können während der Kooperation entdeckt und sofort gemeinsam beseitigt werden.
• Die Time-to-Market sinkt (je nach Breite der Überlappung marginal bis erheblich).

Abb. 1–1Klassische Entwicklung vs. Scrum

Treibt man diese Phasenüberlappung ins Extrem, finden alle Phasen gleichzeitig statt (unterer Teil in Abb. 1–1). Die Folgen sind entsprechend auch extrem:

• Alle Beteiligten müssen sich kontinuierlich abstimmen, damit kein Chaos ausbricht. Kooperation wird maximiert.
• Durch die enge Zusammenarbeit der Beteiligten werden zu jedem Zeitpunkt verschiedenste Perspektiven eingebracht. Das wirkt positiv gegen Groupthink (Gruppendenken) und erhöht die Chance auf Innovation.
• Die Time-to-Market sinkt erheblich.

Nonaka und Takeuchi vergleichen die sequenzielle Arbeitsweise mit einem Staffellauf. Jeder Läufer hat seine Strecke zu absolvieren, übergibt den Staffelstab an den nächsten Läufer und hat dann mit dem Geschehen nichts weiter zu tun.

Die dritte Variante nennen sie in Anlehnung an das Rugby-Spiel Scrum², weil ein Rugby-Team sich gemeinsam über das Spielfeld bewegen muss, um erfolgreich zu sein. Das wird durch die Rugby-Regeln verursacht: Die ballführende Mannschaft darf den Ball immer nur nach hinten, nie nach vorne abspielen. Ein Scrum-Team nach Nonaka und Takeuchi ist cross-funktional (interdisziplinär) besetzt, führt alle Phasen gleichzeitig aus, kooperiert eng, arbeitet autonom und organisiert sich selbst (siehe Abb. 1–2).

Abb. 1–2Scrum-Team

Wir bringen Scrum-Teams auf den Punkt:

Scrum-Teams

Scrum-Teams sind autonome, businessfokussierte Teams, die ihren Prozess in Besitz nehmen und die Verantwortung für ihn tragen.

Interessant ist der Vergleich der Scrum-Teams nach Nonaka und Takeuchi mit dem, was sich in der heutigen Praxis der Softwareentwicklung findet. In der Softwareentwicklung sind minimal-cross-funktionale Teams üblich, die Programmierer:innen und Tester:innen enthalten. Schon bei der Integration von Designer:innen geraten viele Unternehmen ins Straucheln. Dabei ist das im Vergleich zu den Teams bei Canon, Honda, Fuji-Xerox und NEC der reinste Ponyhof. Bei Honda waren z.B. Vertrieb, Entwicklung, Qualitätssicherung und Produktion mit im Team. Bei einer so weitreichenden Abdeckung der Wertschöpfungskette hat das Team zwangsläufig direkten Kontakt zu den Endkund:innen. Weiterhin können wir bei innovativer Entwicklungsarbeit nicht davon ausgehen, dass die Endkund:innen besondere Expertise in der Produktkonzeption hätten. Das Team setzt also nicht Anforderungen um, die es von den Endkund:innen oder Dritten bekommt, sondern löst Probleme der Endkund:innen. Aus diesen beiden Aspekten resultiert der sehr einfache agile Kernzyklus aus Abbildung 1–3: Das selbstorganisierte agile Team löst in kurzen Zyklen Probleme der Endkund:innen.

Abb. 1–3Agile Teams lösen Probleme der Endkund:innen.

Wer genau mit Endkund:innen gemeint ist, diskutieren wir in Kapitel 3.

1.1.2Erste Scrum-Projekte in der Softwareentwicklung

Jeff Sutherland hat 1993 bei Easel – inspiriert durch die Arbeiten von Nonaka und Takeuchi – Scrum für die Softwareentwicklung eingesetzt (siehe [Sutherland2005], [Sutherland2004], [Denning2010]). Dort war ein Projekt zur Entwicklung eines objektorientierten Designtools ins Straucheln geraten. Jeff Sutherland überzeugte den CEO, es mit einem Scrum-Team zu versuchen. Jeff Sutherland kümmerte sich um den Prozess und kann damit als erster Scrum Master gelten.

Das Team zeichnete sich durch einen hohen Grad an Selbstorganisation aus, für die das tägliche Koordinationsmeeting (Daily Scrum) eine wichtige Rolle spielte. Die Teammitglieder trafen sich jeden Werktag für maximal 15 Minuten, um Probleme aus dem Weg zu räumen und die Arbeit für den Tag gemeinsam zu planen.

Ungefähr zur gleichen Zeit experimentierte Ken Schwaber mit ähnlichen Techniken. Schwaber und Sutherland entdeckten die Gemeinsamkeiten ihrer Ansätze und schufen das heute bekannte Scrum für die Softwareentwicklung.

1.1.3Von den ersten Artikeln bis zum Scrum Guide

Im Jahr 1997 veröffentlichte Ken Schwaber ein Paper mit dem Titel »SCRUM Development Process« auf der OOPSLA (siehe [Schwaber1997]). Dieser Artikel war die erste veröffentlichte Beschreibung von Scrum für die Softwareentwicklung. Im Jahre 1999 veröffentlichten Mike Beedle, Martine Devos, Yonat Sharon, Ken Schwaber und Jeff Sutherland auf der PLOP-Konferenz einen Artikel mit dem Titel »SCRUM: A Pattern Language for Hyperproductive Software Development« (siehe [Beedle et al. 1999]).

2000 veröffentlichte Kent Beck sein Buch »Extreme Programming Explained – Embrace Change« (siehe [Beck2000]) und begleitete die Markteinführung des Buches durch eine Reihe von Konferenzvorträgen. eXtreme Programming (XP) nahm Grundgedanken von Scrum auf und ergänzte sie um Programmiertechniken, wie die testgetriebene Entwicklung und das Pair Programming. XP war für die damalige Zeit radikal und polarisierte: Der Großteil der Softwareentwicklungsbranche fand XP absurd oder utopisch. Eine kleine, aber sehr leidenschaftliche Gemeinschaft von Entwickler:innen sah darin jedoch einen notwendigen Paradigmenwechsel. Immer mehr Teams setzten XP erfolgreich ein, und das Interesse stieg immer weiter an. In diesem Zuge erlangte auch Scrum eine größere Bekanntheit. Die Community war sehr wissbegierig und experimentierfreudig und suchte stets nach neuen Inspirationen. So wurden weitere Ansätze mit ähnlichen Denkmodellen entdeckt oder entwickelt, wie z.B. Crystal (siehe [Cockburn2004]) und Feature Driven Development (siehe [PalmerFelsing2002]).

Diese Ansätze wurden zunächst unter dem Sammelbegriff »leichtgewichtig« zusammengefasst. Im Jahre 2001 trafen sich einflussreiche Vertreter:innen dieser »leichtgewic...

Inhaltsverzeichnis

• Cover
• Titel
• Impressum
• Vorwort
• Danksagung
• Überblick über das Buch
• Inhaltsübersicht
• Inhaltsverzeichnis
• 1 Scrum: Historie, Vorteile, Eignung und Herausforderungen
• 2 Überblick über den Scrum-Ablauf, die Verantwortungen, Meetings, Artefakte und Prinzipien
• 3 Scrum produktbezogen
• 4 Entwicklung mit Scrum
• 5 Kontinuierliche Verbesserung
• 6 Releasemanagement
• 7 Streiflicht auf fortgeschrittenes Scrum
• Anhang
• Index
• Fußnoten