Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.
- Herausgeber: MITP
- Kategorie: Fachliteratur
- Serie: mitp Professional
- Sprache: Deutsch
- Umfassendes Scrum-Wissen auf Team-, Produkt- und Portfolio-Ebene
- Kernkonzepte, Rollen, Planung und Sprints ausführlich erläutert
- Auch geeignet zur Vorbereitung auf die Scrum-Zertifizierung
Dieses Buch beschreibt das Wesen von Scrum – die Dinge, die Sie wissen müssen, wenn Sie Scrum erfolgreich einsetzen wollen, um innovative Produkte und Dienstleistungen zu entwickeln.Es ist entstanden, weil der Autor Kenneth S. Rubin als Agile- und Scrum-Berater oft nach einem Referenzbuch für Scrum gefragt worden ist – einem Buch, das einen umfassenden Überblick über das Scrum-Framework bietet und darüber hinaus die beliebtesten Ansätze für die Anwendung von Scrum präsentiert.
Dieses Buch ist der Versuch, die eine entscheidende Quelle für alles Wesentliche über Scrum bereitzustellen.Rubin beleuchtet die Werte, Prinzipien und Praktiken von Scrum und beschreibt bewährte, flexible Ansätze, die Ihnen helfen werden, sie viel effektiver umzusetzen. Dabei liefert er mehr als nur die Grundlagen und weist zudem auf wichtige Probleme hin, die Ihnen auf Ihrem Weg begegnen können.Ob Sie sich nun zum ersten Mal an Scrum versuchen oder es schon seit Jahren benutzen: Dieses Buch weiht Sie in die Geheimnisse des Scrum-Entwicklungsverfahrens ein und vermittelt Ihnen ein umfangreiches Scrum-Wissen auf Team-, Produkt- und Portfolio-Ebene. Für diejenigen, die bereits mit Scrum vertraut sind, eignet es sich als Scrum-Referenz.Rubin hat das Buch nicht für eine bestimmte Scrum-Rolle geschrieben. Stattdessen soll es allen, die direkt oder indirekt mit Scrum zu tun haben, ein gemeinsames Verständnis von Scrum und den Prinzipien, auf denen es beruht, vermitteln.
1. Teil: Kernkonzepte
- Scrum-Framework
- Agile Prinzipien
- Sprints
- Anforderungen und User Stories
- Das Product Backlog
- Schätzungen und Velocity
- Technische Schulden
2. Teil: Rollen
- Product Owner
- Scrum
- Master
- Entwicklungsteam
- Strukturen des Scrum-Teams
- Manager
3. Teil: Planung
- Scrum-Planungsprinzipien
- Mehrstufige Planung
- Portfolio-Planung
- Visionsfindung/Produktplanung
- Release-Planung
4. Teil: Sprints
- Sprint-Planung
- Sprint-Ausführung
- Sprint Review
- Sprint-Retrospektive
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 718
Veröffentlichungsjahr: 2014
Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:
Ähnliche
»Agile Coaches werden von Essential Scrum begeistert sein! Kenny Rubin stellt uns mit seinem Werk einen unentbehrlichen Fundus an wertvollen Informationen zur Verfügung. Sie haben es mit einem Management zu tun, das »es« einfach nicht einsehen will? Dann geben Sie ihnen Kapitel 3 zu lesen, das in umfassender Art und Weise und unter Einbeziehung relevanter wirtschaftlicher Aspekte darlegt, inwiefern Scrum deutlich weniger Risikopotenzial birgt als herkömmliche plangesteuerte Entwicklungsverfahren. Sie wollen die Entwicklungsteams beim Erreichen eines gemeinsamen Verständnisses von Scrum unterstützen? Die in diesem Nachschlagewerk präsentierte neuartige visuelle Beschreibungssprache Visual AGILExicon wird Ihnen bei der Bewältigung dieser Aufgabe wertvolle Dienste leisten. Und das sind nur zwei von vielen weiteren Möglichkeiten, wie Ihnen dieses Buch beim Coachen von Scrum-Teams behilflich sein kann. Nutzen Sie es zu Ihrem Vorteil!«
– Lyssa Adkins, Trainerin für agile Coaches, Agile Coaching Institute; Autorin von Coaching Agile Teams
»Dieses Buch liefert die besten und weitreichendsten Erläuterungen zum Thema Scrum-Framework, die man sich nur wünschen kann! Essential Scrum richtet sich an alle, die an den wesentlichen Aspekten des Entwicklungsprozesses interessiert sind – unabhängig davon, ob bereits Scrum-Vorkenntnisse vorhanden sind oder nicht. Unter Zuhilfenahme gemeinverständlicher visueller Elemente veranschaulicht Kenny die Kernprinzipien des Scrum-Frameworks in bestechend nachvollziehbarer Weise. Bei meiner Arbeit als Scrum-Coach greife ich fortlaufend auf Referenzmaterial zurück, das neue Wege einschlägt, um den Teams beim Erlernen und der Nutzung des Frameworks zu helfen. Dennoch musste ich in den vergangenen mehr als zehn Jahren immer wieder erleben, dass Scrum sowohl vonseiten der großen Unternehmen als auch der Toolanbieter regelmäßig falsch interpretiert und schlecht umgesetzt wird. Dieses Buch richtet den Fokus jedoch wieder auf den Kern der Sache und konzentriert sich auf das, was in diesem Zusammenhang wirklich wichtig ist.«
– Joe Balistrieri, Process Development Manager, Rockwell Automation
»Kennys weitreichender Erfahrungsschatz aus seiner Tätigkeit als Berater, Trainer und ehemaliger Managing Director der Scrum Alliance kommt in diesem Werk voll und ganz zur Geltung. Neben der ausführlichen Auseinandersetzung mit den elementaren Aspekten des Scrum-Prinzips beschäftigt sich dieses Buch auch mit der Frage aller Fragen: Was geschieht mit den Projektmanagern? Essential Scrum zeichnet ein verständliches Bild des großen Ganzen und demonstriert sehr anschaulich, wie sich die Unternehmensleitung einbringen und ihre Scrum-Teams bei der erfolgreichen Umstellung auf agile Methoden unterstützen kann.«
– Sameer S. Bendre, Certified ScrumMaster (CSM) & Project Management Professional (PMP), Senior Consultant, 3i Infotech Inc.
»Wenn agile Vorgehensmodelle oder das Scrum-Verfahren Neuland für Sie sind, wird Ihnen dieses Buch zu einem »fliegenden Start« verhelfen. Die Beispiele und Beschreibungen sind klar verständlich und lebendig formuliert, und Sie werden feststellen, dass ein Thema oder eine Frage, die sich Ihnen aufdrängt, oftmals schon unmittelbar im nächsten Moment angesprochen wird.«
– Johannes Brodwall, Principal Solution Architect, Steria Norway
»Kennys sorgfältig strukturierte Ausführungen spiegeln die Sensibilität der Programmiersprache Smalltalk wider – der Entwicklungsumgebung, in der er jahrelang gearbeitet hat und aus der sowohl Scrum als auch das Extreme Programming hervorgingen. Essential Scrum greift die maßgeblichen Agile-Management-Prinzipien auf und geleitet seine Leserschaft zielsicher auf den Weg zu einem effizienteren agilen Entwicklungsansatz.«
– Rowan Bunning, Gründer, Scrum WithStyle
»Es gibt heutzutage eine ganze Reihe von Referenzmaterial zum Thema Scrum – Essential Scrum betrachtet die Dinge allerdings aus einer ganz neuen Perspektive: in Form eines »Reality-Checks« für praktizierende Softwareentwickler. Kenny zeigt anhand von unmissverständlich illustrierten Beispielen aus der realen Arbeitswelt auf, wie sich ein solides Fundament für die erfolgreiche agile Entwicklung legen lässt. Er vermittelt dem Leser unter anderem ein klares Verständnis vom Wert der Qualitätsimplementierung und liefert schlüssige Antworten auf die Frage, warum wir als Entwickler nicht schon im Voraus alles richtig machen können – sondern vielmehr inkrementell arbeiten und im Laufe des Prozesses hinzulernen müssen. Trotz der ausdrücklichen Nennung des Begriffs »Scrum« im Titel werden in diesem Buch darüber hinaus aber auch andere effiziente Praktiken aus dem agilen Universum thematisiert, um Managern und ihren Teams zum Erfolg zu verhelfen.«
– Lisa Crispin, Co-Autorin von Agile Testing
»Kenny Rubin hat es fertiggebracht, ein Buch zu schreiben, das meiner Meinung nach wirklich jeder, der mit dem Vorgehensmodell Scrum zu tun hat, lesen sollte! Seine Ausführungen repräsentieren eine lückenlose Darstellung dessen, was man über Scrum wissen muss, und noch vieles mehr!«
– Martine Devos, europäische Scrum-Pionierin und Certified ScrumMaster
»Nachdem ich in den vergangenen Jahren eine ganze Reihe von Büchern über agile Methoden rezensiert habe, drängt sich mir natürlich die Frage auf: »Brauchen wir denn wirklich noch eins?« Nun, im Fall von Essential Scrum kann ich dies nur mit einem überzeugten »Ja« beantworten. Anders als die gewohnten Nachschlagewerke dieser Art bringt Kenny dem Leser außergewöhnliche, von Erfahrung geprägte Perspektiven näher, die wertvolle neue Einblicke gewähren. Zweifellos einzigartig an diesem Buch ist die innovative »Ikonografie« – die Bildsprache, die Kenny selbst speziell für Scrum und andere agile Methoden entwickelt hat. Für mich steht fest: Dieses Buch bietet eine unverzichtbare Hilfestellung für den Ausbau eigener Ideen im Hinblick auf den erfolgreichen Einsatz des Scrum-Modells.«
– Scott Duncan, Agile/Scrum-Coach und -Trainer
»Wer ein Scrum-Training absolviert hat oder schon einmal in einem Scrum-Team tätig war, wird in Essential Scrum eine großartige Aufbaulektüre finden. Dieses Buch demonstriert in eindrucksvoller Weise, wie Sie durch die Adaption von Scrum-Prozessen agiler werden und wie sich komplexe Projekte in handhabbare Segmente (bzw. »Sprints«) gliedern lassen. Kenny Rubin beschreibt eine Vielzahl von praxisorientierten Fallstudien, die offenbaren, was in diversen Organisationen funktioniert hat und was nicht. Das geordnete Layout und die professionellen Grafiken in diesem Buch gewährleisten eine gute Übersichtlichkeit und erleichtern das schnelle Auffinden bestimmter Themenbereiche. Organisationen, die sich vom traditionellen Wasserfall-Modell weg und hin zu einem agileren Entwicklungsverfahren orientieren möchten, finden in Essential Scrum einen verlässlichen Wegweiser und Ratgeber.«
– Julia Frazier, Produktmanagerin
Essential Scrum
Umfassendes Scrum-Wissen aus der Praxis
Kenneth S. Rubin
Übersetzung aus dem Englischen von Kathrin Lichtenberg
Impressum
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.
ISBN 978-3-8266-8390-9
1. Auflage 2014
www.mitp.de
E-Mail: [email protected]
Telefon: +49 6221 / 489 -555
Telefax: +49 6221 / 489 -410
© 2014 mitp, eine Marke der Verlagsgruppe Hüthig Jehle Rehm GmbH Heidelberg, München, Landsberg, Frechen, Hamburg
Dieses Werk, einschließlich aller seiner Teile, ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Dies gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften.
Authorized translation from the English language edition, entitled ESSENTIAL SCRUM: A PRACTICAL GUIDE TO THE MOST POPULAR AGILE PROCESS, 1st Edition, 0137043295 by RUBIN, KENNETH S., published by Pearson Education, Inc, publishing as Addison-Wesley Professional, Copyright © 2013 by Pearson Education, Inc.
All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from Pearson Education, Inc. GERMAN language edition published by mitp, an imprint of Verlagsgruppe Hüthig Jehle Rehm GmbH, Copyright © 2014.
Lektorat: Sabine Schulz
Sprachkorrektorat: Maren Feilen
electronic publication: III-satz, Husby, www.drei-satz.de
Dieses Ebook verwendet das ePub-Format und ist optimiert für die Nutzung mit dem iBooks-reader auf dem iPad von Apple. Bei der Verwendung anderer Reader kann es zu Darstellungsproblemen kommen.
Der Verlag räumt Ihnen mit dem Kauf des ebooks das Recht ein, die Inhalte im Rahmen des geltenden Urheberrechts zu nutzen. Dieses Werk, einschließlich aller seiner Teile, ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheherrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Dies gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und Einspeicherung und Verarbeitung in elektronischen Systemen.
Der Verlag schützt seine ebooks vor Missbrauch des Urheberrechts durch ein digitales Rechtemanagement. Bei Kauf im Webshop des Verlages werden die ebooks mit einem nicht sichtbaren digitalen Wasserzeichen individuell pro Nutzer signiert.
Bei Kauf in anderen ebook-Webshops erfolgt die Signatur durch die Shopbetreiber. Angaben zu diesem DRM finden Sie auf den Seiten der jeweiligen Anbieter.
Vorwort von Mike Cohn
Ich habe heute Mittag bei Burger King gegessen. Auf einem Schild an der Wand war zu lesen, das Restaurant sei »Home of the Whopper« und es gäbe mehr als eine Million Möglichkeiten, einen Whopper zu bestellen. Wenn verschiedene Kombinationen aus zusätzlichen oder keinen Gurken, Tomaten, Salatblättern, Käsescheiben usw. zu mehr als einer Million Möglichkeiten führen können, einen Hamburger herzustellen, dann muss es Milliarden mögliche Wege geben, Scrum umzusetzen. Und auch wenn es den einen richtigen Weg nicht gibt, so gibt es doch bessere und schlechtere Methoden, um Scrum zu implementieren.
Mit Essential Scrum hilft Kenny Rubin den Lesern, bessere Wege zu finden. Er will mit seinem Buch nichts vorschreiben – er sagt nicht »Sie müssen dies oder jenes tun«. Stattdessen lehrt er die wichtigsten Prinzipien, die dem Erfolg mit Scrum zugrunde liegen, und zeigt uns Wahlmöglichkeiten auf, die wir haben, um diesen Prinzipien zu genügen. So gibt es z. B. keine Methode zur Planung von Sprints, die für alle Teams gilt. Was in einem Unternehmen oder Projekt funktioniert, könnte in einem anderen zum Scheitern führen. Und so lässt Kenny uns die Wahl. Er beschreibt eine Gesamtstruktur, die den Ausgangspunkt dafür bildet, warum Scrum-Teams ihre Sprints planen und welche Ergebnisse die Sprint-Planung nach sich ziehen sollte, und zeigt alternative Ansätze, die ebenfalls funktionieren. Am Ende aber liegt die Entscheidung bei den einzelnen Teams – und glücklicherweise steht diesen Teams nun dieses Buch zur Seite.
Ein unerwarteter Bonus von Essential Scrum ist die visuelle Sprache, die Kenny für die Kommunikation über Scrum einführt. Mir haben diese Bilder sehr dabei geholfen, dem Text zu folgen, und ich vermute, dass sie in künftigen Diskussionen über Scrum zum Allgemeingut werden.
Die Welt hat schon lange auf dieses Buch gewartet. Scrum begann als kleines Konzept. Das erste Buch, in dem es Erwähnung fand – Wicked Problems, Righteous Solutions von DeGrace und Stahl aus dem Jahr 1990 –, erledigte das auf sechs Seiten. Doch in den mehr als 20 Jahren seit Erscheinen dieses Buches hat sich Scrum ausgeweitet. Es wurden neue Rollen, Meetings und Artefakte eingeführt und verfeinert. Mit jeder neuen Ergänzung bestand allerdings auch die Gefahr, dass wir das »Herz« von Scrum verlieren – also den Teil, bei dem es darum geht, dass das Team plant, wie es etwas machen möchte, einen kleinen Teil davon erledigt und dann reflektiert, was die Teammitglieder bewerkstelligt und wie gut sie zusammengearbeitet haben.
Mit Essential Scrum holt Kenny uns zurück in das Herz von Scrum. Und von dort aus können die Teams beginnen, die Entscheidungen zu treffen, die notwendig sind, wenn sie Scrum anwenden und sich zu eigen machen wollen. Dieses Buch erweist sich als unentbehrlicher Führer, der den Teams hilft, aus den Milliarden möglichen Wegen zur Umsetzung von Scrum denjenigen auszuwählen, der zum Erfolg führt.
– Mike Cohn
Autor von Succeeding with Agile, Agile Estimating and Planning und User Stories Applied
www.mountaingoatsoftware.com
Vorwort von Ron Jeffries
Als Kenny mich bat, ein Vorwort für Essential Scrum zu schreiben, dachte ich: »Das geht schnell und leicht, schließlich wird es nur ein kurzes Buch sein, eine direkte und einfache Beschreibung von Scrum.« Ich kannte Kennys Arbeit und wusste daher, dass es sich gut lesen lassen und nicht zu lang sein würde. Es gibt nichts Besseres!
Stellen Sie sich meine Überraschung und mein Entzücken vor, als ich feststellte, dass das Buch praktisch alles behandelt, was man über Scrum wissen muss – sowohl als Anfänger als auch als alter Hase. Doch damit nicht genug: Kenny beginnt mit den zentralen Konzepten, darunter die agilen Prinzipien, die allen agilen Methoden zugrunde liegen, und einem schnellen Überblick über das Scrum-Framework. Und dann dringt er tiefer und tiefer und tiefer vor. Das Buch liest sich trotzdem immer noch gut und ist außerdem unglaublich umfangreich.
Kenny behandelt zunächst ausführlich die Planung, betrachtet Anforderungen, Stories, das Backlog, Schätzungen sowie die Velocity. Dann führt er uns tiefer in die Scrum-Prinzipien ein und hilft uns beim Umgang mit allen Ebenen des Planens und all den Zeithorizonten. Er beschreibt, wie Sprints geplant, ausgeführt, nachgeprüft und verbessert werden. Und dabei liefert er mehr als nur die Grundlagen und weist zudem auf wichtige Probleme hin, die Ihnen auf Ihrem Weg begegnen können.
Mein eigener Fokus in Scrum und den agilen Arbeitsweisen liegt auf den notwendigen Entwicklerfähigkeiten, die sicherstellen sollen, dass Teams in jedem Sprint echte, funktionierende, unternehmensfokussierte Software abliefern. Kenny hilft uns dabei zu verstehen, wie man Konzepte wie die Velocity und technische Schulden sicher und gut einsetzen kann. Beides sind wichtige Themen, mit denen Sie sich unbedingt vertraut machen sollten.
Die Velocity verrät uns, wie viel das Team im Laufe der Zeit abliefert. Wir können sie nutzen, um ein Gefühl dafür zu entwickeln, wie viel wir schaffen und ob wir uns verbessern. Kenny warnt uns jedoch, dass wir unsere Geschäftsergebnisse schädigen, wenn wir die Velocity als Maß für die Leistung verwenden – und er verrät uns auch, woran das liegt.
Technische Schulden sind zu einem sehr weit gefassten Begriff geworden, der sich auf fast alles bezieht, was im Code schiefgehen kann. Deshalb klärt Kenny für uns die verschiedenen Bedeutungen auf und hilft uns dabei zu verstehen, warum wir uns um diese scheinbar technischen Details kümmern sollten. Mir gefällt vor allem seine Erklärung, dass Druck, der auf das Team ausgeübt wird, ganz unweigerlich dazu führt, dass die Qualität und die Pünktlichkeit leiden.
Scrum nutzt wie alle agilen Methoden einen untersuchenden Ansatz mit schnellem Feedback. Kenny erzählt uns in diesem Zusammenhang auch davon, wie er einmal Lochkarten benutzt hat – und das erinnerte mich an meine früheste Erfahrung mit Rechentechnik, viele Jahre, bevor Kenny seine erste Lochkarte gesehen hat.
Als College-Student hatte ich das Glück, eine Art Praktikum im Hauptquartier der Strategic Air Command in Omaha machen zu dürfen. Damals wurden noch Lochkarten benutzt. Meine Karten wurden im SAC-Hauptquartier mehrere Etagen unter die Erde geschickt und auf dem Computer ausgeführt, der auch in einem Krieg eingesetzt werden würde. Ich hatte das Glück, ein oder zwei Durchläufe pro Tag zu bekommen.
Sobald meine Sicherheitsfreigabe kam, ging ich mitten in der Nacht hinunter in den Computerraum. Ich beschwatzte Sergeant Whittaker, mich meine eigenen Programme ausführen zu lassen. Dazu setzte ich mich an die Konsole der Maschine – ja genau, an die Maschine, deren Hauptaufgabe es sein würde, einen Atomwaffenangriff durchzuführen. Aber nur keine Panik, der rote Knopf war nicht in diesem Raum.
Durch das direkte Arbeiten an der Maschine schaffte ich zehnmal mehr Arbeit, als wenn ich darauf hätte warten müssen, dass meine Karten nach unten und die gedruckten Ergebnislisten wieder nach oben gebracht worden wären. Die Feedbacks kamen schneller, ich lernte schneller und meine Programme funktionierten eher.
Und genau darum geht es auch bei Scrum. Anstatt Monate oder gar Jahre darauf zu warten, zu erfahren, was die Programmierer eigentlich machen, finden wir das mit Scrum alle paar Wochen heraus. Ein Scrum-Product-Owner mit einem wirklich guten Team sieht schon nach wenigen Tagen, wie die Funktionen Form annehmen!
Das ist es auch, worum es in Kennys Buch geht. Wenn Scrum für Sie neu ist, dann lesen Sie es von vorn bis hinten durch und legen Sie es anschließend nicht allzu weit weg. Wenn Sie Scrum schon eine Weile benutzen, dann überfliegen Sie es und halten Sie es anschließend weiterhin in griffbereiter Nähe.
Wenn Sie über irgendetwas nachgrübeln, was gerade in Ihrem Team passiert oder sich fragen, welche Dinge Sie einmal ausprobieren könnten, dann nehmen Sie das Buch zur Hand und schauen Sie sich um. Sie werden aller Wahrscheinlichkeit nach fündig werden.
– Ron Jeffries
Einleitung
Dieses Buch beschreibt das Wesen von Scrum – die Dinge, die Sie wissen müssen, wenn Sie Scrum erfolgreich einsetzen wollen, um innovative Produkte und Dienstleistungen bereitzustellen.
Was ist das Wesen von Scrum?
Scrum beruht auf einer kleinen Menge an Kernwerten, -prinzipien und -praktiken (zusammenfassend als Scrum-Framework bezeichnet). Organisationen, die Scrum einsetzen, müssen das Scrum-Framework in seiner Gänze annehmen. Das muss sicher nicht in der ganzen Organisation auf einmal geschehen, aber zumindest in den ersten Teams, die Scrum benutzen werden. Scrum komplett anzunehmen, bedeutet jedoch nicht, dass die Organisationen dieses Entwicklungsverfahren entsprechend einer vorgefertigten Einheitsformel umsetzen müssen. Es bedeutet vielmehr, dass sie sich immer an das Scrum-Framework halten müssen, während sie ihre eigene passende Mischung aus den Vorgehensweisen für ihre individuelle Scrum-Umsetzung entwickeln.
Essential Scrum kombiniert die Werte, Prinzipien und Praktiken von Scrum mit einer Reihe bewährter Ansätze, die mit dem Scrum-Framework konsistent sind, aber nicht von ihm vorgegeben werden. Einige dieser Ansätze werden sich für Ihre Situation eignen, andere wiederum nicht. Jeder Ansatz muss untersucht und an Ihre jeweiligen Umstände angepasst werden.
Die Ursprünge dieses Buches
Als Agile/Scrum-Berater und -Trainer werde ich oft nach einem Referenzbuch für Scrum gefragt – einem, das einen umfassenden Überblick über das Scrum-Framework bietet und darüber hinaus die beliebtesten Ansätze für die Anwendung von Scrum präsentiert. Da es mir nicht gelungen ist, ein einziges Buch zu finden, das diese Themen auf einem Niveau behandelt, das für heutige Anwender sinnvoll wäre, habe ich immer gleich eine ganze Sammlung an Büchern empfohlen: einige, die das Scrum-Framework diskutieren, aber nicht mehr aktuell oder in gewisser Weise unvollständig sind, einige hoch angesehene Agile-Bücher, die sich nicht ausschließlich auf Scrum beschränken, und eine Handvoll Bücher, die sich auf einen speziellen Aspekt von Scrum oder einen bestimmten Ansatz konzentrieren, aber nicht das komplette Scrum-Framework in aller Tiefe behandeln. Das sind viele Bücher für jemanden, der nur eine einzige Ressource sucht, die das Wesen von Scrum abdeckt!
Die Begründer von Scrum (Jeff Sutherland und Ken Schwaber) bieten eine Scrum-spezifische Publikation namens The Scrum Guide. Dieses kurze Dokument (ca. 15 Seiten) wird von seinen Autoren als das »definitive Regelbuch zu Scrum und die Dokumentation von Scrum selbst« beschrieben (Schwaber und Sutherland 2011). Sie vergleichen ihr Werk mit den Regeln des Schachspiels, die »beschreiben, wie die Figuren gesetzt werden, wie gewechselt wird, was ein Gewinn ist usw.«. Obwohl The Scrum Guide als Überblick oder Regelwerk zu Scrum ganz nützlich ist, ist es von seiner Anlage her nicht als umfassende Quelle für alle wesentlichen Scrum-Kenntnisse gedacht. Stellen Sie sich zur Verdeutlichung einfach vor, Sie würden einem Schachanfänger eine 15-seitige Beschreibung der Regeln des Schachspiels geben und dann von ihm erwarten, dass er anschließend ein anständiger Spieler ist. Das funktioniert nicht. Genauso wenig können Sie erwarten, dass jemand The Scrum Guide liest und sofort gute Ergebnisse abliefert.
Dieses Buch, Essential Scrum, ist der Versuch, die eine entscheidende, bisher fehlende Quelle für alles wesentliche Wissen über Scrum bereitzustellen. Es enthält eine tiefgreifende Diskussion der Scrum-Prinzipien, -werte und -praktiken – eine, die in den meisten Fällen mit führenden Köpfen aus der Agile-Szene sowie dem The Scrum Guide konform geht. (Ich weise darauf hin und erkläre, wo von den allgemein bekanntesten Ansichten abgewichen wird.) Dieses Buch beschreibt außerdem Ansätze, die mit dem Scrum-Framework konsistent sind und erfolgreich von mir und den von mir trainierten Teams eingesetzt wurden. Es soll keine anderen Bücher ersetzen, die eine tiefgreifende vertikale Behandlung einer vorhandenen Scrum-Praxis oder -Vorgehensweise liefern. Solche Bücher ergänzen vielmehr dieses Buch und gehen teilweise sogar darüber hinaus. Stellen Sie sich Essential Scrum lieber als einen Ausgangspunkt Ihrer Reise vor, auf der Sie Scrum einsetzen, um Ihre Kunden zu erfreuen.
Zielgruppe
Für die vielen Tausend Leute, die meine Kurse »Working on a Scrum Team«, »Certified ScrumMaster« und »Certified Scrum Product Owner« besucht haben, und die vielen Teams, die ich trainiert habe, wird dieses Buch Themen, die wir bereits diskutiert haben, wieder auffrischen und vielleicht auch näher erläutern. Und für die noch viel größere Anzahl an Leuten, mit denen ich noch nicht das Vergnügen hatte zusammenzuarbeiten, wird es entweder eine erste Einführung in Scrum und agile Praktiken sein oder eine Chance, Scrum in einem anderen Licht zu sehen und die eigene Anwendung von Scrum zu verbessern.
Ich habe dieses Buch nicht für eine bestimmte Rolle geschrieben – es ist nicht speziell für Product Owner oder ScrumMaster oder Mitglieder des Entwicklungsteams gedacht. Stattdessen soll es allen, die direkt oder indirekt mit Scrum zu tun haben, ein gemeinsames Verständnis von Scrum und den Prinzipien, auf denen es beruht, vermitteln. Ich hoffe, dass Ihre Organisation mit dieser gemeinsamen Grundlage in eine bessere Lage versetzt wird, Scrum erfolgreich einzusetzen.
Ich stelle mir vor, dass jedes Mitglied des Scrum-Teams dieses Buch auf seinem Schreibtisch hat, aufgeschlagen in einem Kapitel, das für die gerade ausgeführte Arbeit relevant ist. Ich stelle mir außerdem Manager auf allen Ebenen der Organisation vor, die das Buch lesen, weil sie verstehen wollen, wie sich Scrum effektiv zum Organisieren der Arbeit einsetzen lässt und welche organisatorischen Änderungen erforderlich sind, um Scrum erfolgreich umzusetzen. Organisationen, die einen anderen agilen Ansatz als Scrum benutzen oder benutzen wollen, werden die hier enthaltenen Informationen nichtsdestotrotz für ihre spezielle Version des agilen Denkens hilfreich finden.
Der Aufbau dieses Buches
Dieses Buch beginnt mit einer kurzen Einführung in Scrum (Kapitel 2) und schließt mit einer Diskussion des vorwärtsweisenden Weges (Kapitel 23). Die restlichen Kapitel sind in vier Teile gegliedert:
Teil I – Kernkonzepte (Kapitel 2–8): Scrum-Framework, agile Prinzipien, Sprints, Anforderungen und User Stories, Product Backlog, Schätzungen und Velocity sowie technische Schulden
Teil II – Rollen (Kapitel 9–13): Product Owner, ScrumMaster, Entwicklungsteam, Scrum-Team-Strukturen und -Manager
Teil III – Planung (Kapitel 14–18): Scrum-Planungsprinzipien, mehrstufige Planung, Portfolio-Planung, Visionsbildung/Produktplanung und Release-Planung
Teil IV – Sprints (Kapitel 19–22): Sprint-Planung, Sprint-Ausführung, Sprint Review und Sprint-Retrospektive
Wie Sie dieses Buch benutzen
Wie man es erwarten würde, schrieb ich dieses Buch in der Annahme, dass die meisten Leute es strikt von vorn nach hinten lesen würden. Wenn Sie mit Scrum noch nicht so vertraut sind, dann sollten Sie auch tatsächlich so vorgehen, weil die Kapitel normalerweise aufeinander aufbauen. Sollten Sie sich zunächst einmal einen Komplettüberblick über das Scrum-Framework verschaffen wollen, dann lesen Sie Kapitel 2.
Für diejenigen, die bereits mit Scrum vertraut sind, eignet sich dieses Buch als Scrum-Referenz. Falls Sie sich für Sprint-Retrospektiven interessieren, dann gehen Sie direkt zu Kapitel 22. Wollen Sie die Feinheiten des Product Backlogs untersuchen, lesen Sie Kapitel 6. Ich empfehle jedoch allen – auch denen, die Scrum schon kennen – dringend, Kapitel 3 komplett zu lesen. Die Prinzipien, die dort dargestellt werden, bilden die Grundlage für das Scrum-Framework und den Rest des Buches – und dabei handelt es sich nicht einfach um eine Wiederholung der Werte und Prinzipien des Agile Manifesto (Beck et al. 2001), die Sie in vielen anderen Beschreibungen von Scrum finden.
Visual AGILExicon
Ich bin stolz, in diesem Buch eine neue visuelle Sprache zur Beschreibung von Scrum präsentieren zu dürfen – Visual AGILExicon. Mithilfe dieser Sprache wurden die mehr als 200 Grafiken in diesem Buch erstellt. Visual AGILExicon besteht aus einem Vokabular aus Icons, die speziell zur Darstellung der wesentlichen Scrum-Rollen, -Artefakte und -Aktivitäten entworfen wurde, und stellt somit eine effektive Methode dar, um Konzepte zu vermitteln und das allgemeine Verständnis von Scrum zu verbessern. Wenn Sie Visual AGILExicon in ihrer ganzen Farbenpracht genießen wollen, finden Sie unter www.innolution.com weiterführende Informationen. Diese Website enthält auch eine Vielzahl an Ressourcen und Diskussionen im Zusammenhang mit diesem Buch.
Legen wir los
Wie auch immer Ihre Rolle oder Situation aussieht: Es gibt sicher einen Grund, weshalb Sie dieses Buch gewählt haben. Nehmen Sie sich Zeit, um Scrum kennenzulernen. Auf den folgenden Seiten wird ein mächtiges Framework vorgestellt, das Sie sich zu eigen machen können und das es Ihnen ermöglicht, die Art und Weise zu verbessern, in der Sie Produkte und Dienstleistungen entwickeln und ausliefern, um Ihre Kunden zufriedenzustellen.
Danksagungen
Dieses Buch wäre ohne die Hilfe vieler Leute, einschließlich der Tausenden von Teilnehmern an meinen Agile-Kursen und Trainingssessions, nicht möglich gewesen. All diese Menschen namentlich aufzuführen, wäre schier unmöglich, daher werde ich mich hier auf einzelne Personen beschränken. Aber auch diejenigen, die ich an dieser Stelle nicht namentlich erwähne, sollen wissen, dass all unsere Diskussionen und E-Mail-Korrespondenzen von unschätzbarem Wert für mich gewesen sind und dieses Buch definitiv beeinflusst haben!
Mein besonderer Dank gilt Mike Cohn, Rebecca Traeger und Jeff Schaich. Ohne die unverzichtbaren Beiträge dieser drei Menschen wäre dieses Buch nur ein Schatten seiner selbst.
Mike Cohn ist mein Freund und Kollege, seit wir im Jahr 2000 bei Genomica das erste Mal zusammengearbeitet haben. Er war so großzügig, mein Buch in die Mike Cohn Signature Series aufzunehmen. Durch die Verbindung zu Mike und den anderen angesehenen Autoren dieser Buchreihe fällt ein Teil des Glanzes auch auf mich, wie meine Eltern sagen würden. Mike war mein Ansprechpartner, wann immer ich Ideen wälzen oder Buchstrategien diskutieren wollte. Er hat trotz seines irren Terminkalenders immer Zeit gefunden, die einzelnen Kapitel zu lesen und mir seine Meinung dazu zu sagen. Die Zusammenarbeit mit Mike im Laufe der letzten Jahre war ausgesprochen lohnend – und ich hoffe, wir können sie auch in der Zukunft fortsetzen.
Rebecca Traeger war bei diesem Buch meine persönliche Lektorin. Wir arbeiten bereits seit meiner Zeit als Managing Director der Scrum Alliance im Jahr 2007 zusammen. Damals war Rebecca Redakteurin der Website von Scrum Alliance. Durch diese Arbeit wurde sie zur führenden Fachredakteurin zum Thema Agile. Gleich als ich anfing, dieses Buch zu schreiben, habe ich Rebecca gefragt, ob sie wieder mit mir zusammenarbeiten würde. Und zu meinem großen Glück hat sie zugesagt. Sie war stets die Erste, die die fertiggestellten Kapitel zu sehen bekam. Manchmal brachte mich ihr Feedback sogar etwas in Verlegenheit, weil sie meine Ausführungen häufig so umformulierte, dass sie verständlicher und auch nachvollziehbarer waren. Sollten Sie also irgendeinen Abschnitt dieses Buches als ganz besonders gut beschrieben empfinden, dann können Sie sicher sein, dass das an Rebecca liegt – im anderen Fall habe ich vermutlich idiotischerweise ihre Vorschläge ignoriert.
Jeff Schaich ist ein außergewöhnlicher Künstler und Designer. Wir haben an so vielen verschiedenen Kunstprojekten zusammengearbeitet, dass ich mich gar nicht mehr an alle erinnern kann. Bereits in der Frühphase dieses Buches hatte ich den Wunsch, ein Agile/Scrum-Vokabular aus Icons zu schaffen, das als Grundlage für meine Trainingspräsentationen und viele der mehr als 200 Abbildungen in diesem Buch dienen könnte. Ich wusste, dass ich dafür einen großartigen Designer brauchen würde. Und Jeff nahm die Herausforderung an. Manchmal erschien mir die Arbeit an diesem Buch wie zwei separate Projekte – einerseits das Schreiben und andererseits die Ausarbeitung der künstlerischen Konzepte. Ich weiß wirklich nicht, was länger gedauert hat – allerdings steht zweifelsfrei außer Frage, dass dieses Buch ohne Jeffs künstlerischen Beitrag beträchtlich schlechter geworden wäre.
Ich fühle mich äußerst geehrt, dass sowohl Mike Cohn als auch Ron Jeffries, zwei Koryphäen der agilen Gemeinde, Vorwörter zu diesem Buch geschrieben haben! Sie haben es auf ihre jeweils ganz eigene Weise geschafft, es in einen Kontext zu setzen und die Tür für eine Diskussion zu öffnen. Außerdem: Mike, hör auf, bei Burger King zu essen, und danke, Ron, dass du den roten Knopf nicht gedrückt hast!
Außerdem möchte ich den vielen Menschen danken, die sich die Zeit genommen haben, die Kapitel fachlich zu begutachten und mir ihre Meinungen mitzuteilen. Für ihr umfangreiches Feedback möchte ich mich vor allem bedanken bei: Joe Balistrieri, Johannes Brodwall, Leyna Cotran, Martine Devos, Scott Duncan, Ilan Goldstein, John Hebley, Geir Hedemark, James Kovacs, Lauri Mackinnon, Robert Maksimchuk und Kevin Tureski.
Für ihr ausgezeichnetes Feedback zu ausgewählten Kapiteln danke ich außerdem: Lyssa Adkins, John Bauer, Sameer Bendre, Susan Briscoe, Pawel Brodzinski, Rowan Bunning, Josh Chappell, Lisa Crispin, Ward Cunningham, Cornelius Engelbrecht, Julia Frazier, Brindusa Gabur, Caroline Gordon, Drew Jemilo, Mike Klimkosky, Tom Langerhorst, Bjarne Larsen, Dean Leffingwell, Maurice le Rutte, David Luzquiños, Lv Yi, Shay McAulay, Armond Mehrabian, Sheriff Mohamed, Cuan Mulligan, Greg Pease, Roman Pichler, Jacopo Romei, Jens Schauder, Bill Schroeder, Yves Stalgies, Branko Stojaković, Howard Sublett, Julie Sylvain, Kevin Tambascio, Stephen Wolfram und Michael Wollin.
Darüber hinaus gilt mein Dank auch den Mitarbeitern bei Pearson, die sich bei diesem Projekt als großartige Partner erwiesen haben. Sie tolerierten meine Verspätungen mit viel Geduld und haben mich stets ermutigt. Besonderer Dank geht an Chris Guzikowski, der dieses Buchprojekt von Anfang an begleitet hat. Er war von meinem ersten Pearson-Treffen in einer Kneipe in Lexington, MA, bis zum Ende der Produktion mit dabei. Auch möchte ich Olivia Basegio danken, die sich gekonnt um die Logistik gekümmert hat, sowie Julie Nahil, die das Projekt ganz fantastisch überwacht hat. Danke auch an Barbara Wood für ihre großartige Hilfe beim Aufpolieren des Manuskripts und an Gail Cocker für das Zusammensetzen der Grafiken zu einem wunderbaren Ganzen.
Meiner Assistentin Lindsey Kalicki bin unglaublich dankbar dafür, dass ich viele wichtige Aufgaben auf sie abladen und mich dadurch weiter auf die Entwicklung des Buches konzentrieren konnte. Ich habe Glück, mit einem solchen Profi zusammenarbeiten zu dürfen.
Die größte Anerkennung gebührt jedoch meiner Familie – Jenine, Jonah und Asher – und der entscheidenden Rolle, die sie gespielt hat. Ich habe ihnen während der langen Entstehungsphase dieses Buches sehr viel abverlangt. Keine noch so große Dankbarkeit kann den Druck auf meine Familie und unsere verlorene gemeinsame Zeit wiedergutmachen.
Jenine ist meine wahre Seelenverwandte und hat mir durch die Höhen und Tiefen beim Schreiben dieses Buches stets zur Seite gestanden. Wenn ich auch nur versuchen wollte, all die Opfer aufzuzählen, die sie gebracht hat, damit ich schreiben konnte, würde dieses Buch auf den doppelten Umfang anwachsen. Ohne sie hätte ich es nicht geschafft!
Das Witzige ist: In dem Jahr nach unserer Heirat 1993 brachte ich mein erstes Buch, Succeeding with Objects, heraus. Damals musste ich Jenine versprechen, dass ich nie wieder ein Buch schreiben würde. Zu meinem Glück verblassen die Erinnerungen nach 15 Jahren und die Belastung schien rückblickend nicht so schlimm gewesen zu sein. Deswegen war ich mehr als überrascht, als sie mich drängte, dieses Buch zu schreiben! Sie hat mir bisher noch nicht gesagt, dass ich Buch Nummer Drei nicht schreiben dürfe, aber ich vermute, dass es weitere 15 Jahre dauern dürfte, bis die Erinnerung an dieses Buch so weit in Vergessenheit geraten ist, dass wir beide ein weiteres schreiben wollen!
Natürlich weiß ich auch die liebende Unterstützung meiner beiden Söhne Jonah und Asher außerordentlich zu schätzen. Sie haben auf Zeit mit ihrem Dad verzichtet, damit ich schreiben konnte. Sie waren immer da, um Ideen zu wälzen und etwas zu diesem Buch beizutragen. Nicht wenige ihrer inhaltlichen und künstlerischen Vorschläge haben es in das Buch geschafft – dank ihnen ist es besser geworden! Ich hoffe, sie haben den Wert der Beharrlichkeit erkannt und gelernt, dass selbst die abschreckendste Arbeit zu schaffen ist, wenn man immer einen Schritt nach dem anderen macht und nicht aufgibt.
Schließlich möchte ich meinen Eltern, Joyce und Manny Rubin, für all ihre Liebe und Unterstützung danken. Ohne ihren Einfluss wäre dieses Buch niemals möglich gewesen. Leider hat keiner von beiden mehr seine Veröffentlichung erlebt. Mom verstarb im Januar 2012 und Dad im Juli 2012. Sie hinterließen in meinem Leben und dem meiner Familie eine Leere, die niemals wieder gefüllt werden kann. Sie waren für viele, die sie gekannt haben, ganz besondere Menschen. Mom und Dad, ich vermisse euch mehr, als sich mit Worten ausdrücken lässt.
Über den Autor
Kenny Rubin bietet Scrum- und Agile-Training und -Beratung an, um Unternehmen zu helfen, Produkte auf effektive und wirtschaftlich vernünftige Weise zu entwickeln. Als Certified Scrum Trainer hat Kenny mehr als 19.000 Menschen in agilen Techniken und Scrum, Smalltalk-Entwicklung, der Organisation objektorientierter Projeke und im Übergangsmanagement unterwiesen. Dabei hat er mehr als 200 Unternehmen beraten, von Start-ups bis zu Fortune-10-Unternehmen.
Kenny war der erste Managing Director der weltweit agierenden Scrum Alliance, einer nicht-kommerziellen Organisation, die sich auf die erfolgreiche Übernahme von Scrum konzentriert. Er ist außerdem Co-Autor des 1995 erschienenen Buches Succeeding with Objects: Decision Frameworks for Project Management. Seinen Bachelor of Science in Information and Computer Science hat Kenny am Georgia Institute of Technology erworben, seinen Master of Science in Computer Science hat er an der Stanford University gemacht.
Ursprünglich war Kenny hauptsächlich mit der Objektorientierung befasst. Er begann 1985 als Smalltalk-Entwickler an einem NASA-finanzierten Projekt und entwickelte das erste Blackboard-Expertensystem außerhalb von LISP. 1988 wechselte er zu ParcPlace Systems, einem Start-up-Unternehmen, das aus Xerox PARC hervorgegangen war und dessen Ziel darin bestand, die objektorientierte Technik aus den Forschungslaboren zu befreien und auf die Welt loszulassen. Als Berater für Smalltalk-Entwicklung bei vielen unterschiedlichen Organisationen in den späten 1980ern und den 1990ern gehörte Kenny zu den frühen Verfechtern agiler Praktiken. Das erste Mal setzte er Scrum im Jahr 2000 bei der Entwicklung von Bioinformatik-Software ein.
Im Laufe seiner Karriere hat Kenny viele Positionen eingenommen. So war er unter anderem als Scrum-Product-Owner, ScrumMaster und Mitglied von Entwicklungsteams, aber auch im Management erfolgreich tätig, als CEO, COO, VP of Engineering, VP of Product Management und VP of Professional Services. Er überwachte die Entwicklung von fünf kommerziellen Software-Suites und generierte damit Einnahmen von insgesamt mehr als 200 Millionen Dollar. Darüber hinaus war er unmittelbar an der Beschaffung von mehr als 150 Millionen Dollar an Venture Capital beteiligt und hat dabei geholfen, zwei Unternehmen an die NASDAQ zu bringen.
Dank seiner vielfältigen Erfahrungen besitzt Kenny die außergewöhnliche Fähigkeit, Scrum und seine Implikationen aus verschiedenen Perspektiven gleichermaßen gut zu verstehen (und zu erklären): vom Entwicklungsteam bis hin zum Vorstand.
Kapitel 1: Einführung
Am 21. Juni 2000 war ich als stellvertretender Vorstandsvorsitzender bei Genomica tätig, einer Bioinformatik-Firma in Boulder, Colorado. Dieses Datum ist mir deshalb in besonderer Erinnerung, weil mein Sohn Asher an diesem Tag um 1 Uhr nachts geboren wurde. Und seine Geburt war zweifellos ein guter Auftakt für diesen Tag. Asher wurde tatsächlich am berechneten Geburtstermin geboren (das passiert in den USA nur bei etwa 5% der Geburten) – wir (oder besser gesagt meine Frau Jenine) hatten unser Neun-Monats-»Projekt« also absolut pünktlich abgeschlossen. Und zur Krönung des Ganzen war ihm auch noch ein sehr hoher Apgar-Wert attestiert worden, was eindeutig belegte, dass wir ein gesundes, hochwertiges »Erzeugnis« produziert hatten! Unser wichtigster »Anteilseigner« (Stakeholder), unser älterer Sohn Jonah, war begeistert, einen jüngeren Bruder zu haben. Ein pünktlich geliefertes, hochwertiges Produkt und noch dazu hocherfreute Anteilseigner – es war wirklich ein guter Tag!
Nach einem kurzen Nickerchen rief ich meine E-Mails ab und sah, dass der Vorstandschef von Genomica eine dringende Nachricht geschickt hatte, in der er mich bat, um 8 Uhr zu einem Treffen des Vorstands zu erscheinen. Widerstrebend verließ ich das Krankenhaus und ging zu der Sitzung.
Als ich ankam, erfuhr ich, dass der Leiter der technischen Entwicklungsabteilung am Abend zuvor gefeuert worden war und ich das 90 Leute starke Technikteam geerbt hatte. Das überraschte mich allerdings nicht: Bereits seit mehreren Monaten hatten die Führungsmannschaft und der Vorstand Genomicas Unfähigkeit diskutiert, wertige Produkte von guter Qualität pünktlich auszuliefern – und der Leiter der technischen Entwicklung hatte im Mittelpunkt dieser Diskussion gestanden.
Jetzt war ich verantwortlich dafür, die Ergebnisse unserer Produktentwicklung deutlich zu verbessern. Ich erinnere mich noch, wie paradox es mir vorkam, dass zwei so bedeutsame Ereignisse wie die glückliche Geburt meines Sohnes und die Übernahme meines neuen Verantwortungsbereichs auf ein und denselben Tag fielen.
Da ich mit dem Verkauf und dem Marketing ohnehin schon ziemlich ausgelastet war, gestand man mir zu, dass ich nach meinem Ermessen einen Technikchef einstellen konnte, der mir direkt unterstellt war. Also besetzte ich diesen Posten mit Mike Cohn (Cohn 2004; Cohn 2006; Cohn 2010) und wir beschlossen, es mit Scrum zu versuchen.
1.1 Was ist Scrum?
Scrum ist ein agiler Ansatz zur Entwicklung innovativer Produkte und Dienstleistungen. Abbildung 1.1 zeigt ein solches agiles Entwicklungskonzept in einer einfachen, generischen Variante.
Bei einem agilen Ansatz beginnen Sie zunächst mit einem Product Backlog – einer priorisierten Liste der Funktionen und Fähigkeiten, die erforderlich sind, um ein erfolgreiches Produkt zu entwickeln. Wenn Sie sich an das Product Backlog halten, arbeiten Sie immer zuallererst die wichtigsten Aufgaben ab, also diejenigen mit der höchsten Priorität. Sollten Ihnen dann irgendwann die Ressourcen ausgehen (wie z. B. die Zeit), haben somit alle noch verbleibenden Aufgaben eine niedrigere Priorität als die bereits abgeschlossenen Arbeiten.
Abb. 1.1: Übersicht über die agile Entwicklung
Die Arbeiten selbst werden in kurzen, zeitlich fest begrenzten (time-boxed) Iterationen durchgeführt, wobei sich der hierfür vorgesehene Zeitrahmen normalerweise zwischen einer Woche und einem Kalendermonat bewegt. Während der einzelnen Iterationen erledigt ein Team die Arbeiten, die nötig sind, um abgeschlossene, funktionierende Elemente herzustellen, die dann in die Produktion überführt werden können. Das Team organisiert sich selbst und kann sich mehrerer Funktionen annehmen – wie etwa dem Entwerfen, Bauen und Testen.
Üblicherweise ist in der Planung eines Product Backlogs deutlich mehr Arbeit vorgesehen, als ein Team innerhalb einer kurzen Iteration bewältigen kann. Deshalb legt das Team zu Beginn jeder Iteration zunächst einmal fest, welche hoch priorisierte Teilmenge des Product Backlogs in der kommenden Iteration erledigt werden soll. In dem Beispiel aus Abbildung 1.1 ist es z. B. übereingekommen, sich den Funktionen A, B und C zu widmen.
Am Ende der Iteration prüft das Team die abgeschlossenen Funktionen noch einmal gemeinsam mit den Stakeholdern, um deren Feedback zu erhalten. Und je nachdem, welche Kritikpunkte dabei zutage treten, können der Product Owner und das Team ihre Pläne für die nächsten Arbeitsschritte ändern. Falls die Stakeholder bei genauerer Betrachtung einer bereits abgeschlossenen Funktion also etwa feststellen, dass noch eine andere Funktion in das Produkt eingebracht werden muss, die zuvor unberücksichtigt geblieben war, kann der Product Owner hierfür einfach ein entsprechendes neues Element anlegen, das dann an der passenden Stelle im Product Backlog eingefügt und in einer künftigen Iteration bearbeitet wird.
Am Ende der einzelnen Iterationen sollte das Team ein potenziell auslieferungsfähiges Produkt haben (oder ein Inkrement des Produkts, also eine Produktfunktionalität), das prinzipiell freigegeben werden könnte. Sollten individuelle Freigaben nach jeder Iteration hingegen nicht sinnvoll sein, könnten alternativ auch Funktionssätze aus mehreren Iterationen zusammen freigegeben werden.
Nach Beendigung einer Iteration fängt der ganze Prozess mit der Planung der nächsten Iteration wieder von vorn an.
1.2 Die Ursprünge von Scrum
Die reiche Geschichte von Scrum lässt sich bis zu einem Artikel im Harvard Business Review aus dem Jahre 1986 zurückverfolgen: »The New New Product Development Game« (Takeuchi und Nonaka 1986). Dieser Artikel beschreibt, wie Unternehmen wie Honda, Canon und Fuji-Xerox mit einem skalierbaren, teambasierten Ansatz für die ganzheitliche Produktentwicklung erstklassige Ergebnisse erzielten. Er betont außerdem die Bedeutung selbstorganisierter Teams mit Entscheidungsvollmacht und umreißt die Rolle des Managements im Entwicklungsprozess.
Die besondere Relevanz dieses Artikels von 1986 bestand darin, dass er viele der Konzepte miteinander verband, die am Ende das ausmachten, was wir heute als Scrum bezeichnen. Scrum ist kein Akronym, sondern ein Begriff aus dem Rugby, wo er sich auf eine Methode bezieht, das Spiel nach einem Verstoß oder einem Aus des Balls wieder aufzunehmen. Im Prinzip bezeichnet es das Gedränge, wenn zwei zum Angriff ansetzende Spielerhorden mit gesenkten Köpfen und verschränkten Armen aufeinander losstürmen, um in den Besitz des Balls zu gelangen.
Takeuchi und Nonaka benutzten diese Rugby-Metapher zur Beschreibung der Produktentwicklung:
Der ... »Stafettenlauf«-Ansatz für die Produktentwicklung ... widerspricht vermutlich dem Streben nach maximaler Geschwindigkeit und Flexibilität. Allerdings ist ein holistisches oder »Rugby«-Vorgehen – bei dem das Team als Einheit agiert und sich auf dem Weg zum Tor den Ball zuspielt – für die heutigen Konkurrenzbedingungen möglicherweise besser geeignet.
1993 schufen Jeff Sutherland und sein Team bei der Easel Corporation den Scrum-Prozess, um ihn bei der Software-Entwicklung einzusetzen. Dabei kombinierten sie Konzepte aus dem Artikel von 1986 mit Konzepten aus der objektorientierten Entwicklung, der empirischen Prozesssteuerung, der iterativen und inkrementellen Entwicklung, der Software-Prozess- und -Produktivitätsforschung und aus komplexen adaptiven Systemen. 1995 veröffentlichte Ken Schwaber bei der OOPSLA 1995 einen ersten Artikel zum Thema Scrum (Schwaber 1995). Seither haben Schwaber und Sutherland sowohl zusammen als auch einzeln mehrere Scrum-spezifische Veröffentlichungen herausgebracht, darunter »Agile Software Development with Scrum« (Schwaber und Beedle 2001), »Agile Project Management with Scrum« (Schwaber 2004) und »The Scrum Guide« (Schwaber und Sutherland 2011).
Obwohl Scrum vorwiegend für die Entwicklung von Software-Produkten eingesetzt wird, lassen sich seine Grundwerte und Prinzipien auch für die Entwicklung anderer Produkte oder zum Organisieren der Arbeitsabläufe (Workflow) unterschiedlicher Betätigungsfelder nutzen. So habe ich beispielsweise mit Organisationen zusammengearbeitet, in denen Scrum ebenso erfolgreich für die Abwicklung und Verwaltung von Hardware-Entwicklungen, Marketingprogrammen und Verkaufsinitiativen eingesetzt wurde.
1.3 Wieso Scrum?
Aber aus welchem Grund war denn nun ein agiler Ansatz wie Scrum eine gute Wahl für Genomica? Zunächst einmal war unübersehbar, dass die frühere Vorgehensweise in Bezug auf die Entwicklungsarbeit bei Genomica einfach nicht funktionierte. Das war die schlechte Nachricht. Die gute Nachricht lautete, dass sich in diesem Punkt fast alle Beteiligten einig waren.
Genomica agierte in einem komplexen Betätigungsfeld, in dem es mehr unbekannte als bekannte Faktoren gab. Wir stellten Produkte her, die noch niemals zuvor gebaut worden waren. Unser Fokus lag auf technologisch absolut neuartigen, sich ständig weiterentwickelnden Informatikplattformen, die von Wissenschaftlern in der Forschung benutzt werden würden, um neue bahnbrechende Moleküle zu entdecken. Dementsprechend benötigten wir eine Entwicklungsmethode, die es uns erlaubte, neue Ideen und Ansätze schnellstmöglich auf den Prüfstand zu stellen und herauszufinden, welche Lösungen machbar waren und welche nicht. Wir hatten ein Partnerunternehmen, dem wir alle paar Wochen funktionierende Ergebnisse präsentieren mussten, um ein Feedback zu erhalten, weil unser Produkt in deren Linie von DNA-Sequenzern passen musste. Aber die daraus resultierende Notwendigkeit für schnelle Machbarkeitsstudien und Feedback passte nicht zu der bei uns üblichen ausführlichen Vorausplanung.
Darüber hinaus wollten wir es vermeiden, schon im Vorfeld einen riesigen Architekturentwurf ausarbeiten zu müssen. Ein früherer Versuch, eine neue Generation von Genomicas Kernprodukt zu schaffen, hatte dazu geführt, dass die Organisation fast ein ganzes Jahr ausschließlich mit der Arbeit an der Architektur zugebracht hatte, um eine umfassende, einheitliche Bioinformatik-Plattform herzustellen. Doch als die erste rein forschungsorientierte Anwendung auf diese Architektur aufgesetzt wurde und wir schließlich Designentscheidungen validieren konnten, die wir Monate zuvor getroffen hatten, dauerte es ganze 42 Sekunden, um auf dem Bildschirm von einem Feld zum nächsten zu springen. Und wenn Sie glauben, dass der typische Benutzer ungeduldig ist, dann stellen Sie sich nur mal einen promovierten Molekularbiologen vor, der 42 Sekunden warten muss! Es war katastrophal. Wir brauchten einen anderen, ausgeglicheneren Designansatz, der einen gewissen Anteil des Vorabdesigns mit einer gesunden Dosis an neuem, situationsbezogenen »Just-in-time«-Design kombinierte.
Außerdem sollten unsere Teams vielseitiger werden. Bislang hatte Genomica wie die meisten Organisationen gearbeitet: Die Entwicklungsabteilung übergab die Arbeiten erst dann an die Testteams, wenn sie vollständig abgeschlossen waren. Jetzt wollten wir hingegen dazu übergehen, dass sich die Teammitglieder wesentlich häufiger miteinander synchronisierten – vorzugsweise täglich. Denn in der Vergangenheit hatte die mangelhafte Kommunikation hinsichtlich gravierender Probleme, die bereits während der Entwicklungsphase aufgetreten waren, zu einer Verschärfung der zugrunde liegenden Fehler geführt. Die Leute in den unterschiedlichen Bereichen redeten einfach nicht oft genug miteinander.
Aus diesen und anderen Gründen entschieden wir, dass Scrum sich gut für Genomica eignen würde.
1.4 Ergebnisse bei Genomica
Als wir beschlossen, es mit Scrum zu versuchen, war diese Methode noch relativ unbekannt – das erste Scrum-Buch erschien erst im darauffolgenden Jahr (Schwaber und Beedle 2001). Also sammelten wir so viele verfügbare Informationen wie möglich und bemühten uns sehr, das Erlernte umzusetzen – was in jedem Fall deutlich besser funktionierte als die Art und Weise, wie wir vorher vorgegangen waren (siehe Tabelle 1.1).
Der Aufwand für die Entwicklung eines vergleichbaren Volumens an Produktfunktionalität reduzierte sich mit der Scrum-Entwicklung im Vergleich zu unserem früheren planorientierten Vorgehen nach dem Wasserfall-Modell auf ein Zehntel (berechnet in Mann-Monaten). Mindestens genauso wichtig war, dass die Scrum-Entwicklung siebenmal schneller voranging als die Wasserfall-Entwicklung – und damit produzierte sie auch etwa siebenmal mehr wertvolle Funktionen als das Wasserfall-Entwicklungsverfahren. Noch überzeugender war allerdings die Tatsache, dass wir die Software in einem zeitlichen Rahmen an unseren Partner liefern konnten, der die Anforderungen für die Einführung seiner neuen Hardware-Plattform erfüllte. Und dadurch waren wir nun in der Lage, eine bereits lange bestehende Partnerschaft zu stärken, was sich wiederum positiv auf den wirtschaftlichen Wert von Genomica auswirkte.
Maß
Wasserfall
Scrum
Aufwand
10x
1x
Schnelligkeit
1x
7x
Kundenzufriedenheit
Schlecht
Ausgezeichnet
Tabelle 1.1: Scrum-Ergebnisse bei Genomica
1.5 Kann Scrum Ihnen helfen?
Die Erfahrungen, die Genomica vor der Einführung der Scrum-Technik gemacht hatten, nämlich dass Funktionen entwickelt wurden, die niemand wollte und diese zudem in schlechter Qualität und verspätet ausgeliefert wurden, sind nicht ungewöhnlich. Wie viele andere Organisationen hat auch Genomica überlebt, weil es nicht schlechter als die Konkurrenz war. Das gleiche Problem konnte ich bereits beobachten, als ich Mitte der 1980er Jahre begonnen hatte, in der kommerziellen Software-Entwicklung zu arbeiten. Und für viele hat sich die Situation auch mehr als 30 Jahre später noch nicht verbessert.
Welche Antwort würden Sie bekommen, wenn Sie Ihre Manager und Entwickler heute zusammenrufen und fragen würden: »Seid ihr mit den Ergebnissen eurer Software-Entwicklungsbemühungen zufrieden?« oder »Glaubt ihr, dass wir unseren Kunden zu einem spürbaren zeitlichen, wirtschaftlichen und qualitativen Nutzen verhelfen?«
In sehr vielen Fällen haben die Leute, die ich im Rahmen meiner weltweiten Trainings- und Beratungstätigkeit dazu befragt habe, mit einem klaren »Nein« geantwortet. Vielmehr tönte es von allen Seiten: »Die Projektausfallrate ist inakzeptabel hoch«, »Die Auslieferung erfolgt immer verspätet«, »Die Rentabilität liegt unter den Erwartungen«, »Die Software-Qualität ist mies«, »Die Produktivität ist beschämend«, »Niemand übernimmt die Verantwortung für die Ergebnisse«, »Die Arbeitsmoral ist schlecht«, »Wir haben eine hohe Mitarbeiterfluktuation«. Und dann wird mit einem desillusionierten Lächeln und ironischem Unterton noch angefügt: »Es müsste doch auch besser gehen.«
Bei aller Verdrossenheit scheinen sich die meisten Leute damit abgefunden zu haben, dass Unzufriedenheit zur Software-Entwicklung einfach dazugehört. Dabei muss das nicht so sein.
Organisationen, die Scrum gewissenhaft einsetzen, haben da ganz andere Erfahrungen gemacht (siehe Abbildung 1.2).
Abb. 1.2: Die Vorteile von Scrum
Diese Organisationen begeistern ihre Kunden in schöner Regelmäßigkeit, indem sie ihnen wirklich das liefern, was sie sich wünschen, und nicht bloß die Funktionen, die am ersten Tag festgelegt wurden, als noch niemand den wahren Bedarf kannte. Außerdem erwirtschaften sie eine bessere Rendite, weil sie häufiger kleinere Releases herausbringen. Und durch das schonungslose Aufdecken mangelhafter organisatorischer Abläufe und Verschwendungen sind diese Organisationen zudem in der Lage, die Kosten zu senken.
Da sich Scrum darauf konzentriert, funktionierende, integrierte, getestete und geschäftsfördernde Funktionen zu liefern, führt jede Iteration zu Ergebnissen, die zügig ausgeliefert werden können. Darüber hinaus erleichtert es dieses Entwicklungsverfahren den Organisationen, in einer komplexen Welt, in der man sich schnellstmöglich anpassen muss, weil inzwischen alles miteinander vernetzt ist – Konkurrenten, Kunden, Anwender, Aufsichtsbehörden und andere Akteure – erfolgreich zu sein. Und schließlich bereitet Scrum wirklich allen Beteiligten mehr Spaß an der Sache – nicht nur den Kunden, sondern auch den Leuten, die die eigentliche Arbeit verrichten –, denn sie arbeiten öfter und enger zusammen, was zu verbesserten zwischenmenschlichen Beziehungen und größerem gegenseitigen Vertrauen unter den Teammitgliedern führt.
Abb. 1.3: Cynefin-Framework
Verstehen Sie mich nicht falsch: Scrum ist zwar in vielen Situationen eine ausgezeichnete Lösung, aber trotzdem nicht in allen Fällen das geeignete Mittel zum Zweck. Das Cynefin-Framework (Snowden und Boone 2007) ist ein sinnvolles Hilfsmittel, um die vorliegende Situation beurteilen und feststellen zu können, ob Handlungsbedarf besteht und welcher Verfahrensansatz der richtige ist. Dieses Framework definiert und vergleicht die Eigenschaften fünf unterschiedlicher Domänen: Simple (einfach), Complicated (kompliziert), Chaotic (chaotisch), Complex (komplex) und Disorder (Nicht-Wissen, Regellosigkeit), wobei Letztere dann zutrifft, wenn sich Ihre Situation keiner der anderen Domänen eindeutig zuordnen lässt (siehe Abbildung 1.3). Im Folgenden werde ich anhand des Cynefin-Frameworks Situationen aufzeigen, in denen Scrum eine sinnvolle Lösungsmöglichkeit darstellt und in denen das nicht der Fall ist.
Zunächst einmal muss an dieser Stelle jedoch festgehalten werden, dass sich die vielen Facetten der Software-Entwicklung und des Software-Supports nicht fein säuberlich in nur eine Cynefin-Domäne pressen lassen. Vielmehr handelt es sich um ein weit gefasstes Betätigungsfeld, das einige sich überschneidende Aspekte, aber auch individuelle Aktivitäten umfasst, die in unterschiedliche Domänen fallen (Pelrine 2011). Die Software-Entwicklungsarbeit lässt sich also zwar meist den Domänen Complicated oder Complex zuordnen, es wäre aber naiv zu behaupten, dass die Software-Entwicklung eine komplexe Domäne wäre. Das gilt vor allem, wenn wir definieren, dass sie ein Arbeitsspektrum aufweist, das von der Entwicklung innovativer neuer Produkte über die Wartung und Weiterentwicklung vorhandener Software-Produkte bis zum Betrieb und Support von Software reicht.
1.5.1 Die Complex-Domäne
Beim Umgang mit komplexen Problemen hat man es mit mehr unvorhersehbaren als vorhersehbaren Faktoren zu tun. Wenn es eine richtige Lösung gibt, erkennt man diese oft erst im Nachhinein. Es ist die Domäne der Emergenz, des »In-Erscheinung-Tretens«. Wir müssen Sachverhalte erkunden, um das Problem zu ergründen, dann müssen wir sie überprüfen und anhand unserer Erkenntnisse eine Anpassung vornehmen (»Inspect and Adapt«). Das Arbeiten in komplexen Domänen erfordert ein kreatives und innovatives Vorgehen. Vorgestanzte Routinelösungen lassen sich einfach nicht anwenden. Wir müssen eine gesicherte Umgebung für Experimente schaffen, damit wir wichtige Informationen entdecken können. In dieser Umgebung ist ein hohes Maß an Interaktion und Kommunikation unerlässlich. Die Entwicklung innovativer neuer Produkte fällt ebenso in diese Kategorie wie das Verbessern vorhandener Produkte mit innovativen neuen Funktionen und Eigenschaften.
Scrum ist für das Arbeiten in einer komplexen Domäne besonders gut geeignet. In solchen Situationen ist unsere Fähigkeit zum Erkunden, Untersuchen und Reagieren entscheidend.
