Kitabı oxu: «30 Minuten Scrum»
Jürgen Hoffmann
30 Minuten
Bibliografische Information der Deutschen Nationalbibliothek
Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.
©2021 GABAL Verlag GmbH, Offenbach
Das E-Book basiert auf dem 2021 erschienenen Buchtitel »30 Minuten Scrum« von Jürgen Hoffmann ©2021 GABAL Verlag GmbH, Offenbach.
ISBN Buchausgabe: 978-3-96739-079-7
ISBN epub: 978-3-96740-128-8
Umschlaggestaltung: die imprimatur, Hainburg
Umschlagkonzept: Martin Zech Design, Bremen
Lektorat: Eva Gößwein, Berlin
Abbildungen: Jürgen Hoffmann
Autorenfoto: Frank Hügle
Satz: Zerosoft, Timisoara (Rumänien)
© 2021 GABAL Verlag GmbH, Offenbach
Alle Rechte vorbehalten. Nachdruck, auch auszugsweise, nur mit schriftlicher Genehmigung des Verlags.
www.gabal-verlag.de
www.gabal-magazin.de
www.twitter.com/gabalbuecher
www.facebook.com/Gabalbuecher
www.instagram.com/gabalbuecher
In 30 Minuten wissen Sie mehr!
Dieses Buch ist so konzipiert, dass Sie in kurzer Zeit prägnante und fundierte Informationen aufnehmen können. Mithilfe eines Leitsystems werden Sie durch das Buch geführt. Es erlaubt Ihnen, innerhalb Ihres persönlichen Zeitkontingents (von 10 bis 30 Minuten) das Wesentliche zu erfassen.
Kurze Lesezeit
In 30 Minuten können Sie das ganze Buch lesen. Wenn Sie weniger Zeit haben, lesen Sie gezielt nur die Stellen, die für Sie wichtige Informationen beinhalten.
Zahlreiche Zusammenfassungen innerhalb der Kapitel erlauben das schnelle Querlesen. | |
Ein Fast Reader am Ende des Buches fasst alle wichtigen Aspekte zusammen.
Inhalt
Vorwort
1. Was ist Scrum?
Die „Entdeckung“ von Scrum
Wann ist Scrum sinnvoll?
Scrum-Werte
2. Scrum heute
Verantwortungen des Scrum Teams
Events im Rhythmus der Produktentwicklung
Scrum-Artefakte und Commitments
3. Von der Vision zum Produkt
Kick-off und Erarbeitung des Produkt-Ziels
Anforderungen verstehen
Kundenzentrierte Produktentwicklung
Scrum in der Praxis – Beispiele
7 Erfolgsregeln für den Start mit Scrum
Fast Reader
Der Autor
Weiterführende Literatur
Vorwort
Warum sollten Sie sich mit Scrum beschäftigen? Scrum ist seit einigen Jahren der Standard in der Produktentwicklung. Im Jahr 2020 gaben von weltweit mehr als 40.000 befragten Führungskräften, Anwendern und Beratern 75 Prozent an, dass sie Scrum einsetzen (digital.ai, 2020), und das umfasst praktisch jede Branche bis hin zu Non-Profit-Organisationen. Dabei nutzen große Firmen mit mehr als 20.000 Mitarbeitern Scrum schon länger als fünf Jahre – während mittelständische Unternehmen mit weniger als 1000 Mitarbeitern Scrum viel intensiver quer durch viele Funktionsbereiche einsetzen.
Die Fähigkeit, mit wechselnden Prioritäten gut umzugehen, ist die am häufigsten genannte Motivation für den Einsatz von Scrum. Dicht gefolgt von Transparenz in der Produktentwicklung, besserer Kooperation zwischen Geschäftsbereichen und IT, schnellerer Time-to-Market, höherer Team-Motivation und Produktivität sowie der Verringerung von Risiken und besseren Prognosen in der Produktentwicklung. Wenn Sie auch nur eines dieser Themen interessiert, dann ist dieses Buch für Sie der ideale Einstieg. An einigen Stellen im Text habe ich Verweise auf Bücher und kostenlos verfügbare Spezialliteratur hinzugefügt, falls Sie nach dem Einstieg noch etwas tiefer bohren möchten.
Bei der Benennung und Schreibweise der Scrum-Fachbegriffe folge ich den Übersetzern der deutschen Ausgabe des Scrum Guides vom November 2020. Dort ist auf den letzten zwei Seiten ein Glossar mit den entsprechenden für den deutschen Sprachraum empfohlenen Begriffen veröffentlicht.
Aufgrund des kompakten Buchformats nutze ich bei Pluralformen in der Regel das generische Maskulinum, bei Beispielen im Singular wechsle ich zwischen männlichen und weiblichen Formen. In jedem Fall beziehen sich die Aussagen auf alle Geschlechter.
Viel Erfolg mit Scrum wünscht Ihnen
Dr. Jürgen Hoffmann
www.emendare.de
1.Was ist Scrum?
Um größere Ziele zu erreichen, schließen sich Menschen seit Jahrtausenden in Organisationen zusammen. Über Jahrhunderte strukturierten sich große Organisationen in Einliniensystemen. Jeder Mensch hat genau einen Vorgesetzten und die Kollegen haben eine ähnliche Ausbildung und vergleichbare Tätigkeiten. Frederick Taylor beschreibt in seinem Hauptwerk „The Principles of Scientific Management“ die dazu passende Trennung von Denken und Handeln als die Aufteilung in Aufgaben von Management und Aufgaben der Arbeiterschaft. Er vertrat die Ansicht, dass der Arbeiter nicht fähig wäre, die beste Arbeitsmethode zu finden. Dieses Unterfangen müsse mit wissenschaftlichen Methoden von Spezialisten im Management durchgeführt werden. Scrum hingegen ist ein Ansatz, der das Denken und Handeln wieder an einer Stelle – im Scrum Team – zusammenführt. Ziel ist es, komplexe Probleme der Produktentwicklung schneller zu lösen und aus einer Kommunikation zwischen Bereichen, Abteilungen und Teams – aus der Inter-Team-Kommunikation – eine Intra-Team-Kommunikation zu machen.
1.1Die „Entdeckung“ von Scrum
Traditionelle Produktentwicklung ist mit einem Staffellauf vergleichbar. Spezialisten eines Fachgebiets geben den Staffelstab an die nächsten Spezialisten sequenziell weiter. Takeuchi und Nonaka veröffentlichten 1986 im Harvard Business Review (Takeuchi, 1986) eine Analyse der Produktentwicklungsprozesse erfolgreicher Produkte aus der Mitte der 1970er-Jahre. Sie entdeckten gemeinsame Muster und benutzten Rugby als Metapher für die neue Art der Produktentwicklung, bei der der Entwicklungsprozess aus der ständigen Interaktion von Spezialisten verschiedener Fachrichtungen entsteht. Das multidisziplinäre und handverlesene Team arbeitet von der ersten bis zur letzten Minute der Produktentwicklung zusammen. Der Wechsel zu einem solchen integrierten Ansatz ermöglicht schnelles Lernen und neue Denkansätze auf allen Ebenen der Organisation. Damit ist er auch ein Katalysator für marktangepasste Organisationsveränderungen.
Was hat Scrum mit Rugby zu tun?
Dass Scrum auf die Rugby-Metapher von Takeuchi und Nonaka zurückgeht, verrät schon der Begriff: „Scrum“ ist eine Bezeichnung aus dem Rugby-Sport und bedeutet „Gedränge“.
Sechs Erfolgsfaktoren
Nonaka und Takeuchi identifizierten in diversen Firmen wie zum Beispiel Honda, Epson, Fuji-Xerox, Canon und 3M sechs Erfolgsfaktoren. Diese führenden Unternehmen setzten Mitte der 1970er-Jahre mit Scrum auf folgende ineinandergreifende und sich ergänzende Erfolgsfaktoren beim Management ihrer Produktentwicklungsprozesse:
1. Eingebaute Instabilität
Die Unternehmensführung gibt nur ein sehr grobes Ziel oder eine strategische Richtung in Kombination mit herausfordernden Rahmenbedingungen vor. Alle Details bleiben in der Hand des Produktentwicklungsteams, das in einem täglichen Ringen um das tatsächlich Mögliche die Grenzen weitersteckt. Das Team startet aus einem Zustand von „Zero Information“ und erarbeitet sich immer weiter reichendes Wissen.
2. Selbstorganisierende Teams
Man erkennt ein selbstorganisierendes Team an drei charakteristischen Merkmalen:
Autonomie – es hat oder entwickelt alle Fähigkeiten, um zu liefern.
Gegenseitige Inspiration – es besteht aus einer breiten Mischung von Spezialisten und Persönlichkeiten.
Selbsttranszendenz – es reicht über sich selbst hinaus und verschiebt scheinbar unerreichbare Grenzen in der Produktentwicklung immer weiter.
3. Überlappende Entwicklungsphasen
Der sehr herausfordernde Zero-Information-Startpunkt zwingt die Teammitglieder, all ihr Wissen auf den Tisch zu bringen, um gemeinsam den nächsten Schritt zu gehen. Marktinformationen und technische Details spielen von der ersten Minute an zusammen und es entsteht ein gemeinsamer Rhythmus und ein perfektes Zusammenspiel aller beteiligten Experten.
4. Lernen auf allen Führungsebenen und in allen Fachrichtungen
Beschleunigtes individuelles Lernen und Gruppenlernen werden gefördert durch den Blick über den Tellerrand und herausfordernde Ziele, die den äußersten Einsatz von Kreativität fordern. Der Erwerb von Wissen außerhalb der eigenen Spezialisierung wird gefördert und ist erwünscht.
5. Fast unmerkliche Kontrolle
Kontrolle findet nicht durch Kontrolle der Tätigkeiten statt – das Management übt Kontrolle eher über die Gestaltung von Rahmenbedingungen aus. Nonaka und Takeuchi haben folgende Beispiele dafür zusammengestellt:
Wie sind Teams zusammengesetzt?
Unterstützt die Arbeitsumgebung Zusammenarbeit?
Wann haben die Ingenieure das letzte Mal mit einem Kunden gesprochen?
Führung durch Teamziele statt individueller Ziele.
Etablieren einer offenen Fehlerkultur, in der Fehler als Lernmomente begriffen werden.
Das Belohnen der Selbstorganisation von Zulieferern – sie erhalten den Auftrag, Probleme zu lösen, statt vorgedachte Lösungen anzufertigen.
6. Unternehmensweiter Wissenstransfer
Die Mitarbeiter geben ihr neu gelerntes Wissen innerhalb des Unternehmens gerne weiter – wenn das Management Kontaktmöglichkeiten schafft. Erfahrungen werden auch institutionalisiert. Wobei man da vorsichtig sein muss: Unter sich plötzlich ändernden Bedingungen können Lehren der Vergangenheit hinderlich sein. Es braucht einen Wechsel von Lernen und Abgewöhnen von Vertrautem, um in sich schnell wandelnden Märkten zu bestehen.
Die Entdeckung von Scrum für Software
1993 formte Jeff Sutherland das erste Scrum Team bei der Easel Corporation. 1995 präsentierte Ken Schwaber die Erfahrungen mit Scrum in der Softwareentwicklung auf der OOPSLA-Konferenz. In den Jahren seitdem ist Scrum von der Agile Community weiterentwickelt worden. Unzählige Beiträge von Anwendern und viele Konferenzen haben geholfen, Scrum zu verbessern und auf der ganzen Welt bekannt zu machen.
| Scrum ist nicht am Reißbrett entstanden. Es ist die kondensierte Erfahrung aus der Entwicklung Tausender Produkte. Sein erfolgreicher Einsatz setzt ein auf gegenseitigem Vertrauen basierendes Zusammenspiel von Management und Produktentwicklungsteams voraus. | |
1.2Wann ist Scrum sinnvoll?
Nicht in jeder Situation ist der Einsatz von Scrum sinnvoll. Ein Denkmodell, um sinnvolle Einsatzszenarien zu identifizieren, stammt aus frühen Versionen des Buches „Strategic Management and Organisational Dynamics“ von Ralph Stacey.

Abb. 1: Die Stacey-Matrix
Die den Denkraum aufspannenden Achsen sind die Fragen nach dem „Was“ (den Anforderungen) und dem „Wie“ (der Technologie) der zu bewältigenden Herausforderung. Im Bild erkennen wir nahe des Ursprungs beider Achsen die einfache Domäne. Hier geht es um sich wiederholende einfache Tätigkeiten, wie sie zum Beispiel in der Produktion am Fließband anfallen.
Beispiel: Als Student habe ich im Mercedes-Werk in Wörth am Rhein in der Fahrerhaus-Produktion mitgearbeitet. Alles, was ich für diesen Job – Einbau von Mittelkonsolen – wissen musste, hatten mir meine beiden Kollegen an der Fließbandstation innerhalb eines Tages beigebracht.
Wenn das zu lösende Problem etwas weiter weg vom Ursprung verortet ist, liegt es im Modell in der komplizierten Domäne. Hier ist eine Analyse einer Expertin erforderlich. Sie wird dann einen Plan entwickeln. Wenn die richtigen Mitarbeiter diesen Plan korrekt ausführen, wird er funktionieren.
Ganz anders die Situation sehr weit weg vom Ursprung: Wir wissen weder annähernd, was das Produkt können soll, noch haben wir die leiseste Idee, mit welcher Technologie eine Umsetzung gelingen kann. Vielleicht müssen wir die Technologie erst erfinden? Das ist die chaotische Domäne – manchmal auch Forschung oder Vision genannt. Bei dieser Art von Herausforderung braucht es ein paar Ansagen, um zum Beispiel auf der „Was“-Achse näher an den Ursprung zu gelangen.
Beispiel: Die Firma SpaceX wurde gegründet, um der Menschheit zu ermöglichen, den Mars zu kolonisieren. Zum Gründungsdatum im Juni 2002 war die Herausforderung in der chaotischen Domäne. Der wichtige Shift in die komplexe Domäne gelang durch den Fokus auf: „Baut erst mal eine Rakete, die starten und wieder landen kann. Über den Mars sprechen wir später.“
In der komplexen Domäne sind die Probleme lösbar durch einen Zyklus aus Experiment, einem Schritt der Überprüfung und einer anschließenden Anpassung des Experiments. Wie wir später sehen werden, realisiert Scrum einen solchen Zyklus.
Kompliziert oder komplex?
Im Scrum-Training werde ich oft nach dem genauen Unterschied zwischen „kompliziert“ und „komplex“ gefragt. Dazu ein Beispiel:
•Kompliziert: In der komplizierten Domäne kann die Expertin tatsächlich einen realistischen Plan machen. Sie fügt noch eine Liste mit zu klärenden Fragen hinzu und sobald die Mitarbeiter diese Liste abgearbeitet haben, steht der Plan fest.
•Komplex: In der komplexen Domäne hilft uns diese Analyse nur für einen sehr kleinen Schritt, weil dann auf einmal unsere Liste mit offenen Fragen um neue Fragen ergänzt wird. Im Komplexen ist es prinzipiell nicht möglich, einen Plan zu machen, der den gesamten Weg bis zur Lösung Bestand hat. Wir müssen ihn ständig neu anpassen und immer wieder neue Experimente vornehmen, die zu Beginn nicht absehbar waren. Das Ziel bewegt sich vor unseren Augen. Retrospektiv betrachtet sehen wir die Evolution der exzellenten Lösung – die man vorwärts in die Zukunft nicht planen konnte. Überall fehlten Daten und Erfahrungen, über die wir am Ende der Entwicklung verfügen.
Da Scrum den abgebildeten Zyklus aus „Experiment“, „Anpassen“ und „Überprüfen“ realisiert, ist es sinnvoll, Scrum in der komplexen Domäne einzusetzen. Hierbei ist es wichtig, zu verstehen, dass Produktentwicklung immer aus einer Mischung von einfachen, komplizierten, komplexen oder auch chaotischen Herausforderungen besteht. Wenn der Schwerpunkt im Komplexen liegt, ist der Einsatz von Scrum empfehlenswert. Und das ist der Erfahrung nach bei der Entwicklung wirklich neuer Produkte der Fall.
Dabei kann es sein, dass ein Produkt seinen Lebenszyklus in der chaotischen Domäne beginnt. Eine vage Idee – noch sehr unscharf – ist entstanden. Mit der Fokussierung auf einen Markt, eine Kundengruppe oder eine bestimmte Technologie bewegt sich das Produkt in die komplexe Domäne. Extrem beschleunigtes Lernen während der Entwicklung hilft uns, den entscheidenden Vorteil vor der Konkurrenz herauszuarbeiten.
Irgendwann ist das Produkt bei vielen Kunden im Einsatz. Es findet noch Produktpflege im geringen Umfang statt. Erfahrung und stabile Messwerte helfen jetzt, wo das Produkt in der komplizierten Domäne angekommen ist. Ein Kundenproblem kann von einem der Produktexperten analysiert und einer Kundin kann eine wasserdichte Reparaturanleitung oder ein funktionierender Workaround übermittelt werden.
In der einfachen Domäne angekommen, geht es nur noch um die Nutzung des Produktes. Einfache Schrittfür-Schritt-Anleitungen helfen, jedes mögliche Einsatzszenario in den Griff zu bekommen. Am Produkt selbst ändert sich nichts mehr.
Zahlreiche Zusammenfassungen innerhalb der Kapitel erlauben das schnelle Querlesen.