Scrum – kurz & gut E-Book

Rolf Dräther

• Herausgeber: O'Reilly
• Kategorie: Wissenschaft und neue Technologien
• Serie: kurz & gut
• Sprache: Deutsch
• Veröffentlichungsjahr: 2019

Seitenzahl: 280

Beschreibung

Scrum ist ein populäres Framework für das agile Projektmanagement. In der Softwareentwicklung ist Scrum mittlerweile weit verbreitet, und auch in anderen Branchen wird es zunehmend als Methode für die Arbeitsorganisation eingesetzt. Dieses Buch bietet allen, die sich für Scrum interessieren oder bereits mit Scrum arbeiten, einen kompakten und praxisbezogenen Überblick über das Framework. Scrum – kurz & gut beschreibt leicht verständlich alle Rollen, Meetings und Artefakte, die Bestandteil von Scrum sind, und bettet diese in den Gesamtkontext der Produktentwicklung ein. Das Buch beschränkt sich dabei nicht auf die Darstellung der reinen Scrum-Mechanik, sondern erläutert auch die agilen Werte und Prinzipien, die dieser Arbeitsmethode zugrunde liegen und durch die die Mechanik erst ihr volles Potenzial entfaltet. Dank wertvoller Praxistipps, Checklisten für die Organisation der Scrum-Meetings und eines umfassenden Glossars mit Definitionen aller Schlüsselbegriffe eignet sich Scrum – kurz & gut gleichermaßen als Kurzeinführung und als Nachschlagewerk für die tägliche Arbeit. Die überarbeitete und erweiterte 2. Auflage berücksichtigt alle Aktualisierungen des offiziellen Scrum Guides.

Leseprobe

Zu diesem Buch – sowie zu vielen weiteren O’Reilly-Büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei oreilly.plus+:

www.oreilly.plus

2. AUFLAGE

Scrum

kurz & gut

Rolf Dräther, Holger Koschekund Carsten Sahling

Rolf Dräther · Holger Koschek · Carsten Sahling

Lektorat: Alexandra Follenius

Korrektorat: Sibylle Feldmann, www.richtiger-text.de

Satz: III-satz, www.drei-satz.de

Herstellung: Stefanie Weidner

Umschlaggestaltung: Michael Oréal, www.oreal.de

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:

Print

978-3-96009-094-6

PDF

978-3-96010-252-6

ePub

978-3-96010-253-3

mobi

978-3-96010-254-0

2. Auflage

Copyright © 2019 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

Dieses Buch erscheint in Kooperation mit O’Reilly Media, Inc. unter dem Imprint »O’REILLY«. O’REILLY ist ein Markenzeichen und eine eingetragene Marke von O’Reilly Media, Inc. und wird mit Einwilligung des Eigentümers verwendet.

Hinweis:

Dieses Buch wurde auf PEFC-zertifiziertem Papier aus nachhaltiger Waldwirtschaft gedruckt. Der Umwelt zuliebe verzichten wir zusätzlich auf die Einschweißfolie.

Schreiben Sie uns:

Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es uns wissen: [email protected]

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen. Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen. Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Inhalt

Vorwort

1Einleitung

Was ist Scrum?

Scrum hilft, komplexe Entwicklungen zu meistern

Scrum ist angewandter Empirismus

Warum Scrum?

Die Historie von Scrum

Was macht Produktentwicklungsteams erfolgreich?

Das Agile Manifest

Mehr als nur Mechanik

Werte

Denkweise

Umfeld

Management

Das Schalenmodell agiler Produktentwicklung

Produkt

Projektmanagement

Release-Management

Produktmanagement

Entwicklungstechniken

Zusammenarbeit im Team

Zusammenarbeit zwischen Teams

Organisation

Werte

2Die Werte

Was sind Werte?

Die Werte in Scrum

Selbstverpflichtung (Commitment)

Mut (Courage)

Fokus (Focus)

Offenheit (Openness)

Respekt (Respect)

Das Zusammenspiel von Werten, Prinzipien und Praktiken

3Die Mechanik

Das Vorgehen im Überblick

Timebox

Sprints

Releases

Checklisten

Rollen

Das Entwicklungsteam

Der Product Owner

Der Scrum Master

Das Scrum-Team

Weitere Rollen

Meetings

Produktvision teilen

Sprint Planning

Daily Scrum

Refinement Meeting

Sprint Review

Sprint-Retrospektive

Artefakte

Product Backlog

Sprint Backlog

Inkrement

Definition of Done

Definition of Ready

Weitere Artefakte

4Scrum im Einsatz

Produktentwicklung mit Scrum

Vision und Ziele

Anforderungen

Priorisierung

Schätzen

Iterativ-inkrementelles Vorgehen

Release-Management

Wartung (Maintenance)

Vom Scrum-Lehrling zum Scrum-Meister

Nutze die Sprint-Retrospektive!

Shu-Ha-Ri

Schritt 1: Den Standort bestimmen

Schritt 2: Scrum lernen

Schritt 3: Scrum-Teams entwickeln

Schritt 4: Scrum in den organisatorischen Kontext einbetten

Schritt 5: Die agile Organisation

Scrum ist kontinuierliche Verbesserung

Was noch?

Agile Software Engineering

Mehrere Teams

Verteilt arbeitende Teams

Verstreut arbeitendes Team

ALiteratur

BGlossar und Index

Vorwort

In den letzten 18 Jahren hat sich Scrum einen festen Platz innerhalb der Projektmanagement-Methoden erobert. In dieser Zeit wurden viele Lehrbücher und weiterführende Werke veröffentlicht. Was fehlt, ist ein kompaktes Nachschlagewerk, das auf den Schreibtischen der Product Owner, Scrum Master und Entwickler darauf wartet, auf konkrete Detailfragen schnelle Antworten zu liefern, und ein Kompendium, das Führungskräften einen schnellen Einstieg in Scrum ermöglicht. Zu diesem Zweck haben wir dieses Buch geschrieben.

Die offizielle Referenz in Sachen Scrum ist der regelmäßig (letztmalig 2017) aktualisierte Scrum Guide ([Schwaber 2017] und [Schwaber 2017b]; wir werden den Begriff »Scrum Guide« im Folgenden ohne Literaturangabe verwenden). Hier beschreiben Ken Schwaber und Jeff Sutherland, die Väter von Scrum, die Mechanik ihres Prozess-Frameworks. Die ist schnell erklärt, denn Scrum kennt lediglich drei Rollen, fünf Events und drei Artefakte. Das Kennen und Beherrschen dieses Instrumentariums reicht aber nicht aus, um mit Scrum wirklich erfolgreich Projekte durchzuführen. Deshalb gehört zu Scrum ein agiles Wertesystem, das den Menschen in Scrum-Projekten neue Handlungsmöglichkeiten eröffnet, Innovation fördert und eine ergebnisorientierte Arbeitsweise ermöglicht. Außerdem muss ein Scrum-Projekt in die wertschöpfenden Prozesse der Produktentwicklung eingebettet werden. Und schließlich gibt es neben den Kernelementen von Scrum noch weitere Methoden, Prinzipien und Praktiken, die sich in den vergangenen Jahren im praktischen Einsatz bewährt haben.

Dieses Buch geht deshalb über den Inhalt des Scrum Guide hinaus, indem es Scrum im Gesamtkontext der Entwicklung komplexer Produkte betrachtet und beschreibt. Es zeigt außerdem verschiedene Möglichkeiten auf, wie man das für ein Team entworfene Scrum auf mehrere Teams skalieren kann.

Aufbau dieses Buchs

Kapitel 1, Einführung, geht den Fragen nach, was Scrum ist, woher Scrum kommt und warum man Scrum einsetzen sollte. Es wird gezeigt, dass es mehr als nur der reinen Mechanik bedarf, um mit Scrum erfolgreich zu sein. Darüber hinaus ordnen wir Scrum auf der Basis des Agilen Manifests in den Gesamtkontext agiler Methoden und Vorgehensweisen ein. Am Ende der Einführung eröffnet das skizzierte Schalenmodell agiler Produktentwicklung eine mögliche Perspektive auf das Umfeld und den Gesamtlebenszyklus eines Produkts und hebt hervor, an welchen Stellen Scrum zum Einsatz kommen kann.

Kapitel 2, Die Werte, beschäftigt sich mit dem Wertesystem, das hinter dem Scrum-Framework steht und das den Prinzipien und Praktiken eine Bedeutung und der Mechanik erst einen Sinn gibt. Unserer Meinung nach sind die agilen Werte essenziell, denn das Verständnis und die Verinnerlichung dieser immateriellen inneren Werte erschließen bei der Arbeit mit Scrum neue Handlungsmöglichkeiten und schaffen Raum für Innovation, Motivation und Vertrauen. Erst durch das Zusammenspiel von Werten, Prinzipien und Praktiken entfaltet Scrum sein volles Potenzial. Deshalb haben wir den Werten ein eigenes Kapitel gewidmet.

Kapitel 3, Die Mechanik, steht ganz im Zeichen der Scrum-Mechanik. Nach einem ausführlichen Überblick über das Gesamtvorgehen werden die Rollen, Events und Artefakte von Scrum detailliert beschrieben und bewertet. Dabei beschränken wir uns nicht auf die im Scrum Guide benannten Bestandteile, sondern stellen weitere Meetings und Artefakte vor, die sich in der Praxis bewährt und als hilfreich erwiesen haben. Zusammenfassungen und Checklisten am Ende jedes Abschnitts sollen beim Verständnis, der Übertragung in die Praxis und der täglichen Arbeit helfen.

Kapitel 4 des Buchs, Scrum im Einsatz, beleuchtet Themen, die beim konkreten Einsatz von Scrum in der Produktentwicklung von Bedeutung sind. Dabei wird der Bogen von der Vision über Anforderungen, Priorisierung, Schätzen, iterativ-inkrementelles Vorgehen und Release-Management bis hin zur Wartung (Maintenance) gespannt und so der komplette Produktlebenszyklus berücksichtigt. Der Frage, wie man den Weg vom Status quo zur ernsthaften Anwendung von Scrum bewältigt, gehen wir für einige Aspekte und Scrum-Prinzipien konkret nach. Spätestens an dieser Stelle fließen sehr viele Erfahrungen aus der Praxis ein, die dem Leser helfen sollen, seinen eigenen erfolgreichen Weg mit Scrum zu finden. Abschließend gibt das Kapitel einen kurzen Ausblick auf Themen aus verschiedenen Bereichen agilen Vorgehens, darunter Software Craftsmanship und das Arbeiten mit mehreren oder mit verteilten Scrum-Teams.

Eine Besonderheit stellt das Glossar am Ende des Buchs dar, das Sie aufgrund der enthaltenen Seitenverweise auch als Index nutzen können.

Wie arbeitet man mit diesem Buch?

In Abhängigkeit von der Intention des Lesers und seiner aktuellen Erfahrung mit dem Thema bieten sich folgende Herangehensweisen an:

Liest man das Buch von vorne nach hinten, vermittelt es einen aufeinander aufbauenden Gesamteindruck von Scrum, vertieft schrittweise das Verständnis des Lesers für die damit verbundenen Konzepte, Werte und Artefakte und gibt am Ende hilfreiche Unterstützung bei der Einführung und Überführung in die tägliche Praxis. Diese Vorgehensweise sei all denen empfohlen, die sich zum ersten Mal mit Scrum beschäftigen und verstehen wollen, ob und wie ihnen Scrum in der täglichen Projektpraxis helfen kann. Bei dieser Art zu lesen können einige Themen wiederholt auftauchen. Diese Wiederholungen sollen den Gebrauch des Buchs als kompaktes Nachschlagewerk unterstützen.

Wer sich über Scrum im engeren Sinne informieren möchte, findet in den Kapiteln 2, Die Werte, und 3, Die Mechanik, einen guten Überblick. Mit den flankierenden Themen und der Einbettung in den Gesamtkontext der Produktentwicklung kann man sich in diesem Fall auch zu einem späteren Zeitpunkt auseinandersetzen.

Hat man bereits praktische Erfahrung mit Scrum, kann man dieses Buch als kompaktes Nachschlagewerk nutzen und gezielt an den aktuell interessanten Stellen zu lesen beginnen. Geeignete Einstiegspunkte findet man beispielsweise über die im Glossar integrierten Seitenverweise. Auf diese Weise lässt sich unter anderem auffrischen, was bei der Vorbereitung und Durchführung einer Sprint-Retrospektive zu beachten ist, was es in Scrum bedeutet, mutig zu sein, was man unter den INVEST-Kriterien versteht oder wer für die Pflege des Product Backlog verantwortlich ist.

Einen sehr schnellen und gezielten Einstieg in konkrete Themen und Fragestellungen bietet die besondere Kombination aus Glossar und Index am Ende des Buchs. Darin werden die wesentlichen Scrum-Begriffe kompakt erläutert, und zugleich wird auf weiterführende Passagen in diesem Buch verwiesen. So kann man sich jederzeit über einen Schlüsselbegriff kurz und gut informieren und auf Wunsch anschließend zur Vertiefung in das zugehörige Kapitel des Buchs einsteigen und weiterlesen.

Darüber hinaus wird sicher jeder Leser einen eigenen Zugang zu diesem Buch finden und mit individuellen Kennzeichnungen seine Einstiegspunkte markieren.

Die Autoren

Dieses Buch ist ein Produkt, das von einem Team im besten Scrum-Sinn entwickelt wurde: in mittlerweile zwei Inkrementen (traditionell »Auflagen« genannt), geschrieben und aktualisiert von drei erfahrenen agilen Praktikern, jeder mit einem etwas anderen Schwerpunkt.

Rolf Dräther studierte Physik und arbeitete unter anderem als Schallschutzsachverständiger, Windsurf- und Snowboardlehrer, Softwareentwickler, Radkurier, Leiter einer Softwareentwicklungsabteilung sowie als Autor und Übersetzer. Als er spürte, dass ihn die Menschen mehr interessieren als die Technik, absolvierte er eine dreijährige berufsbegleitende Ausbildung am systemischen Institut Karlsruhe sowie eine Vielzahl von Weiterbildungen. Seit 2013 arbeitet er freiberuflich als Berater und Coach. Dabei ist für ihn Freude bei der Arbeit ein zentraler Erfolgsfaktor und besonderes Anliegen. Er ist Autor von »Retrospektiven – kurz & gut« (O’Reilly 2014), Koautor von »Neue Geschichten vom Scrum« (dpunkt.verlag 2018) und Übersetzer von »Der Bienenhirte« (dpunkt.verlag 2017). Er teilt sein Wissen gern und regelmäßig auf Konferenzen und Community-Events. 2015 überquerte er auf einem motorlosen Frachtsegler den Atlantik.

Holger Koschek ist selbstständiger Berater, Trainer und Coach für fortschrittliches Management in kleinen und großen Projekten und Organisationen. Er unterstützt Teams und Führungskräfte im Projekt- und Produktmanagement sowie im Projektmarketing. Dabei legt er Wert auf eine klare Vision, eine wirksame Kommunikation, eine dynamische Arbeitsorganisation und eine von gemeinsamen Werten getragene Zusammenarbeit. Holger Koschek gibt sein Wissen und seine langjährige Erfahrung gerne und regelmäßig in Form von Fachvorträgen und Büchern weiter. Dazu gehören »Geschichten vom Scrum« (dpunkt.verlag 2014), »Neue Geschichten vom Scrum« (dpunkt.verlag 2018) und »Management Y« (Campus 2014). In seiner Freizeit engagiert er sich ehrenamtlich in der Freiwilligen Feuerwehr Wedel.

Carsten Sahling leitet das Geschäftsfeld Agil bei der Holisticon AG. Als ehemaliger langjähriger Softwareentwickler, klassischer Projektmanager und Inhaber zahlreicher agiler Zertifizierungen vereint er verschiedene Sichtweisen der agilen Softwareentwicklung. Als agiler Coach und Trainer hilft er damit insbesondere größeren Unternehmen, die traditionell eher klassisch aufgestellt sind, bei der Einführung in die agile Denkweise und bei der erfolgreichen Durchführung auch großer agiler Projekte. Spaß bereitet ihm die Arbeit mit skeptischen Führungskräften und tollen Teams, die den Willen haben, noch besser zu werden. Am meisten ärgern ihn Verschwendung durch schlechte Kommunikation und fehlende Zusammenarbeit, gegen die er gerne mit Liberating Structures zu Werke geht.

Danksagungen

Neben dem Autorenteam haben andere Menschen wesentlich zum Gelingen dieses Buchprojekts beigetragen. Wir danken ganz herzlich:

Alexandra Follenius vom O’Reilly Verlag. Sie war ein guter Stakeholder, manchmal auch Product Owner des Buchs. Ihrem wertvollen Feedback hat dieses Buch seine klare Struktur und Zielgruppenansprache zu verdanken.

Andreas Erber, Erik Hogrefe, Dirk Jäger, Annabelle Kern, Jonas Laacke, Jörg Landmann, Thomas Lieder, Manfred Meyer, Goetz Perry, Michael Schulze-Ruhfus, Rebecca Stutter, Julia Wilkens, Nicola Wüpper und Dariusch Zohurian für ihre kritischen Anmerkungen und Anregungen zu unserem Manuskript. Wie schön, dass zu unserem Netzwerk so viele tolle Expertinnen und Experten gehören, die uns bei diesem Projekt ganz unkompliziert unterstützt haben.

Steffi Krause (GOagile!) für ihre wertvollen Impulse zur ersten Auflage dieses Buchs.

Holisticon AG für die freundliche Genehmigung, die Unterlagen aus den agilen Trainings und das agile Glossar als Grundlage für dieses Buch zu verwenden.

Ohne familiären Rückhalt ist ein solches Projekt nicht zu meistern. Deshalb widmen wir dieses Buch

Kess – R.D.

Andrea, Nele, Marit und Lotta – H. K.

Annika, Svenja, Louis und Eddie – C. S.

Die Website zum Buch

Wenn man ein kompaktes Nachschlagewerk wie dieses schreibt, kommt man immer wieder an den Punkt, an dem man noch so viel sagen möchte, damit aber eindeutig den Rahmen des Buchs sprengte. Deshalb haben wir eine Website eingerichtet:

www.scrum-kurz-und-gut.de

Hier finden Sie Links auf weiterführende Literatur, Lesenswertes zu Scrum und Agil aus den Weiten des Internets sowie die Checklisten aus diesem Buch in druckbarer Form.

Event, Ereignis oder Meeting?

In der englischen Version des Scrum Guide werden die Begriffe »Event« und »Scrum Event« verwendet, auch wenn Zusammenkünfte oder Meetings gemeint sind. Das mag seinen Ursprung in der Absicht haben, möglichst für alle Sachverhalte in Scrum neue Bezeichnungen zu finden und so einen Neuanfang ohne belastete Begriffe wie z.B. »Meeting« zu ermöglichen. Der deutsche Scrum Guide übersetzt »Event« mit »Ereignis«. Da wir das sehr unspezifisch und irritierend finden, haben wir uns entschlossen, je nach Kontext entweder von »Event« oder, wenn es sich um ein solches handelt, weiterhin von »Meeting« zu sprechen.

Anmerkung zur Gleichberechtigung in der sprachlichen Form

Wir haben uns viele Gedanken darüber gemacht, ob und wie wir die Leserinnen und Leser ansprechen. Da es ein »kurz & gut« werden sollte, haben wir uns letzten Endes im Interesse eines besseren Leseflusses für eine vielleicht traditionelle, aber wie wir meinen schlanke, kurze und prägnante Schreibweise entschieden. Wenn wir zum Beispiel »Teilnehmer« schreiben, sind immer Teilnehmerinnen und Teilnehmer gemeint. Wir hoffen, dass uns die Leserinnen diese Vereinfachung nachsehen.

KAPITEL 1

Einleitung

Dieses Kapitel beantwortet die grundlegende Frage »Was ist Scrum – und was ist es nicht?«. Wir verorten Scrum im Universum der agilen Methoden und beschreiben seine Rolle im Produktlebenszyklus. Anwendungsszenarien, wissenschaftliche Grundlagen, ein historischer Rückblick, das Agile Manifest und ein Schalenmodell der agilen Produktentwicklung sind die Perspektiven, aus denen wir Scrum in diesem Kapitel betrachten.

Was ist Scrum?

Laut Scrum Guide ist Scrum »ein Rahmenwerk zur Entwicklung, Auslieferung und Erhaltung komplexer Produkte«. Scrum wurde ursprünglich in der Softwareentwicklung eingesetzt, um (Software-)Produkte mit dem größtmöglichen fachlichen Nutzen zu entwickeln. Mittlerweile hat es auch in vielen anderen Domänen Einzug gehalten, um komplexe Aufgaben zu meistern – von der Produktentwicklung über Dienstleistungen bis hin zu Verwaltungs- und Managementfunktionen in Organisationen.

Scrum ist ein Framework, kein Prozess. Es definiert nur wenige Rollen, Events und Artefakte und beschreibt deren Zusammenspiel. Scrum-Projekte entwickeln ihr projektspezifisches Vorgehen in dem von Scrum abgesteckten Rahmen.

Scrum ist kein Allheilmittel. Sein immer breiter werdendes Einsatzspektrum erweckt bei einigen Menschen den Anschein, dass sich mit Scrum alle Probleme dieser Welt sehr leicht lösen lassen. Das ist nicht der Fall. Scrum kann z.B. Risiken nicht verhindern (das kann kein Vorgehensmodell), macht sie aber frühzeitig transparent und somit beherrschbar. Es fördert die Zusammenarbeit zwischen Menschen, den Austausch von Wissen und das organisationale Lernen und stärkt damit die Resilienz von Projekten und Organisationen.

Scrum per se ist kein Projektbeschleuniger. Teams werden nicht besser oder schneller, nur weil sie nach Scrum arbeiten. Da sie aber fokussiert nur die Dinge tun, die aktuell relevant sind, werden die wirklich wichtigen Dinge früher fertig.

Historisch bedingt, ist im Kontext von Scrum immer noch sehr viel von Produktentwicklung die Rede. Sein tatsächlich breiteres Einsatzspektrum findet im Scrum Guide erst seit der im November 2017 erschienenen Revision Erwähnung. Ein Produkt im Scrum-Sinne ist nicht zwingend ein physisches Artefakt oder ein Stück Software, sondern kann eine Dienstleistung, ein Konzept oder etwas völlig anderes sein. Wenn im Folgenden von »entwickeln« und »Entwicklung« die Rede ist, meinen wir damit (genau wie der Scrum Guide) generell das Bearbeiten komplexer Aufgabenstellungen.

Scrum hilft, komplexe Entwicklungen zu meistern

Die Entwicklung mit Scrum geschieht iterativ-inkrementell: Mit jeder Iteration, also mit jedem Entwicklungsabschnitt, in Scrum Sprint genannt, wird ein Inkrement (ein fertiges Stück des Gesamtprodukts) fertiggestellt, das benutzbar ist. Diese Methode eignet sich aufgrund ihrer kurzen Feedback-Zyklen besonders für die Entwicklung komplexer Produkte. Dafür sind lediglich drei Rollen erforderlich:

Product Owner:

Der Product Owner sagt, was innerhalb des nächsten Sprints entwickelt werden soll.

Entwicklungsteam

(engl. Development Team): Das Entwicklungsteam baut das Inkrement entsprechend der Wünsche des Product Owners und präsentiert das Ergebnis am Ende des Sprints.

Scrum Master:

Der Scrum Master ist verantwortlich dafür, dass der Produktentwicklungsprozess so reibungslos wie möglich verläuft, und unterstützt bei der kontinuierlichen Verbesserung des Prozesses und des Scrum-Teams.

Scrum ist angewandter Empirismus

Scrum ist eine Umsetzung der Theorie des Empirismus, nach der Wissen auf Erfahrung beruht und Entscheidungen auf der Grundlage dieses Wissens getroffen werden (eine schöne Begriffserläuterung liefert [3sat Philosophie 2012]). Die drei Säulen von Scrum schaffen die dafür notwendigen Voraussetzungen:

Transparenz (Transparency)

: Um Erkenntnisse aus Erfahrungen zu gewinnen, müssen alle notwendigen Informationen verfügbar und sichtbar sein.

Überprüfung (Inspection)

: Die Scrum-Nutzer müssen in angemessenen zeitlichen Abständen ihre Vorgehensweise auf den Prüfstand stellen. Es gilt zu beurteilen, ob die gewählte Arbeitsweise für das Erreichen des Ziels förderlich ist. Um sicherzustellen, dass das Scrum-Team auf das richtige Ziel hinarbeitet, wird in regelmäßigen Abständen auch das Inkrement hinsichtlich der Vision überprüft.

Anpassung (Adaptation)

: Die im Rahmen der oben beschriebenen Überprüfung erkannten Verbesserungspotenziale werden von den Scrum-Nutzern umgesetzt, sodass das Ziel besser oder schneller erreicht werden kann.

Die zyklische Struktur von Scrum mit seinen Iterationen und den wiederkehrenden Meetings bietet regelmäßig die Gelegenheit zur Überprüfung und Anpassung (Inspect and Adapt). Da diese Zyklen vergleichsweise kurz sind (zwischen wenigen Tagen und vier Wochen), können Risiken und Abweichungen schnell erkannt und frühzeitig angegangen werden. Auch der Fortschritt wird damit sofort sichtbar.

Warum Scrum?

Um diese Frage zu beantworten, werfen wir zunächst einen Blick in die Vergangenheit.

Die Historie von Scrum

Die geistigen Väter von Scrum sind Ken Schwaber und Jeff Sutherland. Beide beschäftigen sich zu Beginn der 1990er-Jahre zunächst unabhängig voneinander, später gemeinsam mit der Frage, wie man Produkte schneller und flexibler entwickeln kann. Aus dem Fachartikel »The New New Product Development Game« [Takeuchi 1986] beziehen sie nicht nur wesentliche Ideen für ihr Framework, sondern auch den Namen Scrum. Der Begriff stammt aus dem Rugby und bezeichnet dort den Neustart eines Spiels nach einer kleineren Regelverletzung [Rugby Scrum].

Die Welt der Softwareprojekte ist zu dieser Zeit geprägt von traditionellen Managementmethoden, die der Komplexität der Softwareproduktentwicklung durch Projekthierarchien, Kontrollmechanismen sowie langfristige und detaillierte Planung zu begegnen versuchen. 1994 veröffentlicht die Standish Group ihren ersten CHAOS-Report, in dem sie auf der Grundlage von mehr als 8.000 untersuchten IT-Projekten die Fehlerquote dieser Projekte berechnete. Die Ergebnisse sind alarmierend: 31 % aller Projekte wurden vor der Fertigstellung komplett abgebrochen – ein wirtschaftlicher Verlust von 80 Milliarden US-Dollar. 53 % der Projekte wurden mit erheblichen Mängeln fertiggestellt. Obwohl dabei nur durchschnittlich 61 % der ursprünglichen Anforderungen erfüllt wurden, brauchten diese Projekte das Doppelte der ursprünglich veranschlagten Dauer und wurden zudem doppelt so teuer wie geplant. Nur 16 % der Projekte wurden letztlich erfolgreich fertiggestellt.

1995 präsentiert Ken Schwaber während des Workshops »Business Object Design and Implementation« im Rahmen der OOPSLA-Konferenz den wissenschaftlichen Artikel »SCRUM Development Process« [Schwaber 1997], in dem er die Erfahrungen mit dem Entwicklungsprozess in seiner Firma »Advanced Development Methods« beschreibt. Co-Chair des Workshops ist Jeff Sutherland, der 1993 bei der Firma Easel gemeinsam mit Kollegen ein ähnliches Vorgehensmodell entwickelt und eingesetzt hat. Sutherland und Schwaber arbeiten fortan gemeinsam an der Weiterentwicklung von Scrum. 1999 veröffentlichen sie zusammen mit anderen Autoren den Artikel »SCRUM: An extension pattern language for hyperproductive software development«. Im Jahr 2001 erscheint das Buch »Agile Software Development with Scrum« von Mike Beedle und Ken Schwaber. Seitdem sind unzählige Veröffentlichungen über Scrum und agile (Software-)Produktentwicklung erschienen – darunter auch dieses Buch. Mit der zunehmenden Verbreitung von Scrum erobert das Framework neue Anwendungsgebiete. Ursprünglich in der Softwareentwicklung genutzt, wird Scrum mittlerweile auch in vielen anderen Bereichen eingesetzt (siehe [Wolf 2015]).

Was macht Produktentwicklungsteams erfolgreich?

In dem oben erwähnten Fachartikel »The New New Product Development Game« beschreiben Takeuchi und Nonaka die Charakteristika erfolgreicher Produktentwicklungsteams, die sie aus der Untersuchung von Teams unterschiedlicher Branchen abgeleitet haben. Drei Wesenszüge waren ihrer Analyse zufolge allen erfolgreichen Teams gemein:

Autonom

: Die Teams organisierten sich selbst.

Selbsttranszendent

: Die Teams strebten nach vorn, wollten immer besser werden.

Interdisziplinär

: Die Teams besaßen das notwendige Wissen und die erforderlichen Fertigkeiten, um das Produkt herzustellen.

Die Ursache für die schlechte Erfolgsquote von IT-Projekten lag offensichtlich in der Art und Weise ihrer Durchführung und weniger in der unzureichenden Ausbildung der Entwickler oder dem fehlenden Reifegrad der noch jungen Wissenschaft Informatik. Schwaber und Sutherland konzentrieren sich deshalb auf die Professionalisierung der Zusammenarbeit in Projektteams. Sie wollen eine Kultur des Lernens etablieren und das Augenmerk der Entwickler nicht nur auf das zu entwickelnde Produkt, sondern auch auf den Entwicklungsprozess lenken. An diesem wurde in der Vergangenheit nicht gerüttelt. Künftig sollten alle Projektbeteiligten darüber nachdenken, wie man besser und effektiver zusammenarbeiten könnte. In Kombination mit Entwicklungstechniken wie eXtreme Programming [Beck 2004] führen Schwaber und Sutherland ihre frühen Scrum-Projekte zum Erfolg und entwickeln Scrum kontinuierlich (und empiristisch) weiter.

Das Agile Manifest

2001 trafen sich 17 Vertreter verschiedener Softwareentwicklungsmethoden (darunter auch Ken Schwaber und Jeff Sutherland) in einem Skiort im US-amerikanischen Utah, um auszuloten, ob sich ihre Vorstellungen von Softwareentwicklung auf einen gemeinsamen Nenner bringen lassen. Dieser gemeinsame Nenner trägt heute den Namen »Manifest für agile Softwareentwicklung«, kurz »Agiles Manifest« [Agile Manifesto] (wir werden auf das Agile Manifest im Folgenden ohne Literaturangabe verweisen). Das Manifest besteht aus vier Gegenüberstellungen und zwölf Prinzipien [Agile Manifesto – Principles]. Aus den Prinzipien haben wir die aus unserer Sicht wesentlichen Schlagwörter herausgezogen (siehe Abbildung 1-1).

Abbildung 1-1: Die wesentlichen Schlagwörter aus den zwölf Prinzipien des Agilen Manifests

Bei den Gegenüberstellungen schätzen die Autoren des Agilen Manifests die Begriffe auf der linken Seite jeweils höher ein als die Begriffe auf der rechten Seite – was aber nicht heißt, dass Letztere bedeutungslos sind. Im Folgenden werden die vier Gegenüberstellungen erläutert und in Bezug zum konkreten Projektalltag gesetzt.

Individuen und Interaktionen mehr als Prozesse und Werkzeuge

Um IT-Projekte erfolgreich durchführen zu können, benötigt man motivierte und gut ausgebildete Menschen, die gern zusammenarbeiten und miteinander reden, anstatt übereinander zu sprechen. In solchen Projekten werden Entscheidungen gemeinsam herbeigeführt und schnell getroffen. Die fachlichen Anforderungen werden in Form einer geordneten Liste, dem Product Backlog, verwaltet. Der Product Owner bespricht die Anforderungen (die Backlog Items) gemeinsam mit dem Entwicklungsteam, das die Anforderungen umsetzen wird. Wer außer den Entwicklern kann abschätzen, wie aufwendig die Umsetzung einer Anforderung ist? Im Gespräch wird die Anforderungsbeschreibung weiter verfeinert – die Interaktion liefert echte Ergebnisse.

Zur Unterstützung der erfolgreichen Zusammenarbeit – aber nie um ihrer selbst willen – werden Prozesse etabliert und Werkzeuge eingesetzt. Bevor Sie sich also das nächste Mal fragen, welches Bug-Tracking-Tool oder Wiki Sie sich für Ihr Projekt am besten anschaffen, sollten Sie sich im Sinne des Agilen Manifests zunächst die Frage stellen, welches Problem Sie damit lösen wollen und ob Sie dafür nicht besser einen Raum für den Austausch Ihrer Teammitglieder schaffen und pflegen können.

Funktionierende Software mehr als umfassende Dokumentation

Peter DeGrace und Leslie Hulet Stahl beschreiben in [DeGrace 1990], dass die meisten Benutzer einer zu entwickelnden Software erst dann wissen, was sie wollen, wenn sie eine erste Version der Software gesehen (und benutzt) haben. Das deckt sich mit unseren Erfahrungen aus lang laufenden Softwareentwicklungsprojekten, bei denen der Kunde nach zwei Jahren Entwicklungszeit beim ersten Arbeiten mit dem Ergebnis sagt: »So wollte ich das aber nicht haben!« Ähnliches kann auch bei kurzen Softwareprojekten passieren – etwa dann, wenn das fachliche Konzept veraltet ist (weil sich z. B. die Marktgegebenheiten geändert haben) und nicht mehr den aktuellen Anforderungen entspricht. Das ist einer der Gründe dafür, dass agile Methoden großen Wert darauf legen, erste lauffähige Versionen der Software frühzeitig und regelmäßig zur Verfügung zu stellen. Die Erkenntnisse, die ein Benutzer mit diesen frühen Versionen gewinnt, können in die Weiterentwicklung einfließen. So entsteht am Ende ein Produkt, das den tatsächlichen Anforderungen der Anwender genügt – weil die Nutzer an der Entwicklung beteiligt waren und diese beeinflussen konnten.

Statt auf den Umfang einer Dokumentation sollte Wert auf Angemessenheit und Aktualität gelegt werden. Ein Benutzerhandbuch ist in den meisten Fällen sinnvoll, und grundsätzlich zahlt sich eine angemessene technische Dokumentation der Software spätestens in der Wartungsphase aus. Angemessen bedeutet, dass vor allem das beschrieben wird, was sich nicht aus der Software selbst und dem Programmcode ermitteln lässt. Dazu zählen unter anderem fachliche und technische Entscheidungen. Hier sollten neben der gewählten Variante auch die verworfenen Alternativen beschrieben und die Entscheidung begründet werden. Der Umfang der Dokumentation wird in einigen Branchen (z.B. der Medizintechnik) durch Gesetze und Bestimmungen geregelt. Hier kann sich die Auseinandersetzung mit den Dokumentationsanforderungen lohnen, denn oft stellt sich heraus, dass vermeintlich unabdingbare Dokumentationsbestandteile tatsächlich gar nicht vorgeschrieben sind. Grundsätzlich gilt: lieber weniger, dafür aber aktuell dokumentieren, denn nichts ist nutzloser als eine veraltete Dokumentation.

Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung

»Produktentwicklung ist Vertrauenssache« – so könnte man diese Gegenüberstellung auf den Punkt bringen, wenn man den Begriff »Vertrauenssache« nicht im Sinne von Laissez-faire (»ich lasse es mal laufen«) versteht. In einem Produktentwicklungsprojekt sollten Auftraggeber und Auftragnehmer vertrauensvoll zusammenarbeiten, um ein fachlich wertvolles Produkt von hoher Qualität zu schaffen. Der Auftraggeber muss darauf vertrauen, dass der Auftragnehmer die fachlichen Anforderungen nach bestem Wissen und mit einem hohen handwerklichen Anspruch umsetzt. Der Auftragnehmer wiederum muss dem Auftraggeber vertrauen, dass dieser die Anforderungen bestmöglich beschrieben hat. Gemeinsam werden sie die Anforderungen zur richtigen Zeit durch Nachfragen und Nachbessern weiter verfeinern, damit sie vom Auftragnehmer zur Zufriedenheit des Auftraggebers umgesetzt werden können. Beide Seiten wissen, dass sich die Anforderungen im Laufe des Projekts verändern können. Neue Anforderungen können hinzukommen, andere wegfallen. Das hat Auswirkungen auf die Dauer, den Umfang und die Kosten des Projekts. Deshalb kann der Auftraggeber zu Projektbeginn nicht alle drei dieser Parameter festlegen, sondern maximal zwei. Dieser Umstand hat Auswirkungen auf die Vertragsgestaltung zwischen Auftraggeber und Auftragnehmer. Spätestens wenn der Auftragnehmer ein externes Unternehmen ist, wird man auf schriftliche Verträge nicht verzichten können. Diese können aber nicht das Vertrauen der handelnden Personen ersetzen. Ein Projekt, über dessen Erfolg am Ende ein Gericht entscheidet, ist unserer Meinung nach kein erfolgreiches Projekt.

Reagieren auf Veränderung mehr als das Befolgen eines Plans

Scrum und die anderen agilen Methoden akzeptieren die Tatsache, dass sich im Laufe eines Projekts viele Dinge ändern. Kent Beck hat seinem Buch »eXtreme Programming eXplained« [Beck 2004] sogar den Untertitel »Embrace Change« (etwa: heiße die Veränderung willkommen) gegeben. Diese Grundhaltung prägt die Prinzipien und Praktiken agiler Methoden: Eine iterativ-inkrementelle Vorgehensweise, regelmäßiges Feedback, eine dynamische Anforderungsliste (anstelle des klassischen Lastenhefts) und die ständige Bereitschaft zur Anpassung sowohl der Produkteigenschaften als auch des Entwicklungsprozesses sind Ausdruck des offenen Umgangs mit Veränderungen. Wer Veränderung akzeptiert und zulässt, muss auch den Planungsprozess von Projekten überdenken. Im traditionellen Projektmanagement wird der Umfang zu Projektbeginn verbindlich festlegt. Dauer und Kosten – die beiden anderen Parameter im sogenannten »magischen Dreieck des Projektmanagements« – werden zwar prognostiziert, bleiben aber grundsätzlich variabel. Die Qualität ist keine Variable – sie muss immer das geforderte (hohe) Niveau haben. Auch agile Methoden gehen bei der Qualität keine Kompromisse ein, denn nachhaltige Kundenzufriedenheit ist das oberste Ziel. Allerdings stellen sie das magische Dreieck gewissermaßen auf den Kopf: Agile Projekte planen mit einer festgelegten Projektdauer und fixen Kosten, die auf einer stabilen Teamgröße beruhen. Das Projekt wird über den flexiblen Umgang mit fachlichen Anforderungen gesteuert, die sich wie oben beschrieben im Projektverlauf unweigerlich verändern werden (siehe Abbildung 1-2).

Abbildung 1-2: Agile Methoden stellen das magische Dreieck des Projektmanagements auf den Kopf.

Auch in agilen Projekten wird geplant und kontrolliert. In Scrum gibt es neben der kurzfristigen Sprint-Planung auch eine Release-Planung mit einem längerfristigen Horizont. Diese Pläne können sich jedoch jederzeit ändern – und das wissen alle Beteiligten. Dank einer tagesaktuellen Fortschrittskontrolle können Risiken (z.B. Verzögerungen) in Scrum-Projekten frühzeitig erkannt und entschärft werden. Agile Projekte funktionieren nach dem von Dwight D. Eisenhower formulierten Motto: »Pläne sind nichts. Planung ist alles.«

Mehr als nur Mechanik

Das Agile Manifest beschreibt eine Denkweise oder Grundhaltung, die allen agilen Methoden zugrunde liegt. Ohne sie bliebe jede Methode nur reine Mechanik und könnte nie die gewünschte Wirkung entfalten. Das sollten Sie bedenken, wenn Sie Scrum einführen: Sie müssen zunächst lernen, anders zu denken, bevor Sie anders handeln.

Werte

Anders zu denken, beginnt bei den Werten. Der Scrum Guide beschreibt ein Fundament aus fünf Werten, auf dem Scrum aufbaut:

Selbstverpflichtung (Commitment)

Mut (Courage)

Fokus (Focus)

Offenheit (Openness)

Respekt (Respect)

Diese Werte beschreiben wir ausführlich in Kapitel 2. Darüber hinaus kann ein Scrum-Team eigene Werte entwickeln oder sie aus dem Wertekanon der Organisation beziehen, in die das Team eingebettet ist.

Wenn Sie ein agiles Team bei der Arbeit beobachten, merken Sie recht schnell, ob die Teammitglieder durch gemeinsame Werte verbunden sind. Unserer Erfahrung nach sind die »Wert-vollen« Teams tatsächlich auch wertvoll (im Sinne von erfolgreich). Deshalb sollten Sie für Ihre agilen Teams eine Umgebung schaffen, in der Werte gelebt werden und erlebbar sind.

Denkweise

»Die richtigen Dinge richtig machen« – so könnte man die agile Denkweise zusammenfassen. Es geht darum, Produkte zu entwickeln, die der Kunde wirklich haben möchte und die ihm einen echten Mehrwert bieten. Daraus lassen sich alle agilen Werte, Prinzipien und Praktiken ableiten:

Um »das richtige Ding« zu entwickeln, muss ein kontinuierlicher Dialog zwischen dem Kunden und der Produktentwicklung etabliert werden mit dem Ziel, voneinander zu lernen. Das Entwicklungsteam lernt, die Bedürfnisse des Kunden zu begreifen, die (oft im Verborgenen) hinter den formulierten Anforderungen stehen. Der Kunde lernt, seine Anforderungen zielgerichteter zu formulieren. Und er kann an den ersten Versionen des Produkts nicht nur die Erfüllung seiner Anforderungen überprüfen, sondern auch deren Güte und Relevanz bewerten – oft mit der Folge, dass Anforderungen verändert oder zurückgezogen werden und neue Anforderungen hinzukommen. Damit dieser Dialog funktioniert, müssen sich Kunde und Entwicklungsteam als Partner verstehen und eine gemeinsame Sprache entwickeln.

Um das Produkt »richtig« zu entwickeln, muss das Produktentwicklungsteam gut ausgebildet sein, über alle erforderlichen Fertigkeiten und das notwendige Wissen verfügen sowie diszipliniert und ergebnisorientiert am Produkt arbeiten. Scrum bildet den Rahmen für einen solchen Entwicklungsprozess. Diesen Rahmen gilt es zu füllen. Ein Entwicklungsteam, das nachhaltig hohe Qualität, einfaches Design und kontinuierliches Lernen anstrebt, wird diesen Rahmen schnell mit Praktiken füllen, von denen wir einige in »Was noch?« auf Seite 160 vorstellen. In regelmäßigen Retrospektiven wird das Team seinen Prozess überprüfen und Anpassungen daran vornehmen.

Umfeld

Scrum hat seine Wurzeln in der Entwicklung komplexer Softwaresysteme. Der Schwerpunkt liegt in der Organisation der Anforderungsbeschreibungen und Entwicklungstätigkeiten. Konkrete Entwicklungstechniken gehören jedoch nicht zum Scrum-Repertoire. Außerdem ist die Softwareentwicklung nur ein Abschnitt im Leben eines Softwaresystems. Vor der Entwicklung steht die Produktidee, oft beschrieben als Vision. Nach der initialen Projektphase der Software (die bei Scrum iterativ geschieht) geht ein Softwareentwicklungsprojekt in die Produktweiterentwicklung über. Oft wird die Verantwortung für die Software dann in die Hände eines Wartungsoder Betriebsteams gelegt. Dieses Umfeld hat insgesamt einen maßgeblichen Einfluss auf ein Scrum-Projekt.

Management

Scrum trifft keine Annahmen über die Aufbau- und Ablauforganisation, in die Projekte eingebettet sind. Es trifft allerdings Annahmen über die Menschen, die in Scrum-Projekten arbeiten. Die allen agilen Methoden zugrunde liegende Denkweise und Grundhaltung sowie die Forderung nach Selbstorganisation innerhalb des Entwicklungsteams formulieren einen hohen Anspruch an Mensch und Organisation. Von Managern, die für Scrum-Projekte und -Teams verantwortlich sind, wird ein spezieller Führungsstil erwartet. Ein agiler Manager ist Mentor und Coach. Sein Ziel ist es, einen Rahmen zu schaffen, in dem die agilen Teams eigenverantwortlich und selbstorganisierend arbeiten können. Dazu stellt der agile Manager die organisatorischen und strategischen Leitplanken auf und ermöglicht allen Teammitgliedern, sich kontinuierlich weiterzuentwickeln, um den Anforderungen einer agilen Organisation gerecht zu werden. Um die agilen Werte nachhaltig in der Unternehmenskultur zu verankern, geht der Manager mit gutem Beispiel voran und lebt vor, was er von seinen Teams erwartet: Respekt, Fokus, Offenheit – um nur einige Werte zu nennen.

Eine wachsende Anzahl an Publikationen zu agilem Management ist ein Indiz für die Relevanz dieses Themas. Jurgen Appelo liefert in [Appelo 2011] ein komplettes agiles Managementmodell, das sechs Handlungsfelder benennt:

Gib Menschen Energie.

Ermächtige Teams.

Justiere die Rahmenbedingungen.

Entwickle Kompetenz.

Lasse Strukturen wachsen.

Verbessere alles.

Auch Appelos Sichtweise basiert letztendlich auf dem Agilen Manifest. Und es stellt den Menschen in den Mittelpunkt. Nur ein Manager, der es wagt, eine echte Beziehung zu seinen Mitarbeitern aufzubauen, um deren Potenzial zu erkennen und zu fördern, wird sich eines Tages über einen Zustand freuen, der in der Literatur als Hyperproduktivität beschrieben wird. Dieser beschreibt die Arbeitsweise von Teams, die in einem Umfeld arbeiten, das ihnen genügend Freiraum lässt, um die Innovations- und Schaffenskraft voll zu entfalten, auf der anderen Seite aber eng genug ist, um fokussiert auf ein klar erkennbares Ziel hinzuarbeiten. Keine Angst: So wie ein Scrum-Team nicht vom ersten Tag an das Potenzial des Scrum-Frameworks auszuschöpfen vermag, wird ein Manager einige Zeit brauchen, bis er diese neue Art der Führung verinnerlicht hat. Mithilfe von Inspect and Adapt kann diese Entwicklung in kleinen, kontrollierten Schritten erfolgen.

Das Schalenmodell agiler Produktentwicklung

Wie bereits im Abschnitt »Umfeld« auf Seite 12 angedeutet, betrachtet Scrum nur einen Ausschnitt des Lebenszyklus eines Produkts. Abbildung 1-3 stellt den Rahmen der Produktentwicklung und die Rolle von Scrum in diesem Rahmen in einem Schalenmodell dar.

Abbildung 1-3: Das Schalenmodell agiler Produktentwicklung

Uns ist bewusst, dass das Schalenmodell nur eine mögliche Sichtweise darstellt. Daneben kann es noch viele weitere Perspektiven geben – die aber den Rahmen dieses Buchs sprengten.

Produkt

Im Kern des Schalenmodells steht das Produkt. Es soll den Kunden nutzen (funktionale Eigenschaften) sowie robust und fehlerarm zu verwenden sein (nicht funktionale Eigenschaften). Ein Produkt im Scrum-Sinne ist nicht zwingend ein lauffähiges Stück Software, sondern kann auch eine Dienstleistung, ein Konzept oder etwas völlig anderes sein.

Projektmanagement