Vorwort
Aufbau dieses Buchs
Wie arbeitet man mit diesem Buch?
Die Autoren
Danksagungen
Die Website zum Buch
1. Einführung
Was ist Scrum?
Scrum hilft, komplexe Produkte zu entwickeln
Scrum ist angewandter Empirismus
Warum Scrum?
Die Historie von Scrum
Was macht Produktentwicklungsteams erfolgreich?
Das Agile Manifest
Individuen und Interaktionen mehr als Prozesse und Werkzeuge
Funktionierende Software mehr als umfassende Dokumentation
Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
Reagieren auf Veränderung mehr als das Befolgen eines Plans
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
2. Die Werte
Was sind Werte?
Die Werte in Scrum
Selbstverpflichtung (Commitment)
Fokus (Focus)
Offenheit (Openness)
Respekt (Respect)
Mut (Courage)
Das Zusammenspiel von Werten, Prinzipien und Praktiken
3. Die Mechanik
Der Prozess im Überblick
Sprints
Dauer eines Sprints
Taktung der Sprints
Struktur eines Sprints
Der Sprint als geschützter Raum
Ergebnis eines Sprints
Wenn’s mal nicht klappt
Releases
Marktfähige Teilprodukte
Release-Management
Scrum und Release-Planung: ein Widerspruch?
Checklisten
Vorbereitung eines Scrum-Projekts
Sprint-Kalkulator
Rollen
Die Metarollen (Pigs & Chicken)
Das Entwicklungsteam
Zusammenfassung
Der Product Owner
Zusammenfassung
Der Scrum Master
Zusammenfassung
Das Scrum-Team
Weitere Rollen
Anwender
Kunden
Manager
Projektleiter
Meetings
Produktvision teilen
Sprint Planning
Sprint Planning 1
Sprint Planning 2
Daily Scrum
Estimation Meeting
Sprint Review
Retrospektive
Artefakte
Product Backlog
Sprint Backlog
Inkrement
Definition of Done
Weitere Artefakte
Vision
Release-Plan
Selected Product Backlog
Taskboard
Impediment Backlog
Burndown Chart
Release Burndown Chart
Sprint Burndown Chart
Story Burndown
Task Burndown
Tages- oder Stunden-Burndown
Team Backlog
Velocity Chart
Regeln für die Zusammenarbeit
Themen und Themenpark
4. Scrum im Einsatz
Produktentwicklung mit Scrum
Vision und Ziele
Visionen
Ziele
Zuständigkeiten
Anforderungen
INVEST-Kriterien
User Stories
Granularität der Anforderungen
Priorisierung
Schätzen
Relatives Schätzen
Story Points als Schätzeinheit
Estimation Meetings
Planning Poker®
Iterativ-inkrementelles Vorgehen
Iterativ
Inkrementell
Iterativ-inkrementell
Release-Management
Wartung (Maintenance)
Vom Scrum-Lehrling zum Meister
Nutze die Retrospektive!
Shu-Ha-Ri
Schritt 1: Den Standort bestimmen
Schritt 2: Scrum lernen
Ausbildungswege
Aller Anfang ist schwer
»Machen wir wirklich Scrum?«
Der Scrum Guide ist für die Shu-Stufe geschrieben
Der Scrum Guide fordert Inspect and Adapt
Schritt 3: Scrum-Teams entwickeln
Das Tuckman-Modell der Teamentwicklung
Scrum-Teams sind selbstorganisiert
Selbstorganisation vermitteln
Selbstorganisation lernen
Mentoring
Warum braucht ein selbstorganisiertes Entwicklungsteam einen Scrum Master?
Scrum-Teams sind funktionsübergreifend (cross-functional)
Collective Ownership
Alle sind »Developer« – aber nicht zwingend Generalisten
Zusammenarbeit – intern und extern
Arbeit am Taskboard
Zusammenarbeit mit dem Product Owner
Was mache ich mit Einzelkämpfern?
Schritt 4: Scrum in den organisatorischen Kontext einbetten
Wie hole ich Hilfe aus der Welt jenseits von Scrum?
Synchronisierung von Sprints und nicht-agilen Projektplänen
Einbettung in ein nicht-agiles Projekt
Rollenverständnis
Bedeutung von Anforderungsbeschreibungen
Vertikaler Durchstich vs. schichtenorientierte Entwicklung
Einbettung in eine nicht-agile Organisation
Schritt 5: Die agile Organisation
Die eigene Geschichte erzählen
Einblicke bieten und erklären
Unterstützen und begleiten
Gemeinsam lernen
Scrum ist kontinuierliche Verbesserung
Was noch?
Agile Software Engineering
Software Craftsmanship
Pair Programming
Continuous Integration
Mehrere Teams
Ein Product Owner pro Team
Ein Scrum Master pro Team
Gemeinsames Product Backlog
Abstimmung zwischen den Teams
Schneidung von Teams
Beziehungen zwischen Teams
Verstreute Teams
A. Literatur
B. Glossar und Index
Stichwortverzeichnis
Impressum
In den letzten zehn Jahren hat sich Scrum einen festen Platz in der Riege 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 Scrum – kurz & gut geschrieben.
Die offizielle Referenz in Sachen Scrum ist der zuletzt 2011 aktualisierte Scrum Guide [Schwaber 2011]. Hier beschreiben Ken Schwaber und Jeff Sutherland, die Väter von Scrum, die Mechanik ihres Projektmanagement-Frameworks. Die ist schnell beschrieben, denn Scrum kennt lediglich drei Rollen, vier Meetings und drei Artefakte. Das Kennen und Beherrschen dieses Instrumentariums reicht aber nicht aus, um mit Scrum wirklich erfolgreich Projekte durchzuführen. Ein agiles Wertesystem erschließt den Menschen in Scrum-Projekten neue Handlungsmöglichkeiten, fördert Innovation und eine ergebnisorientierte Arbeitsweise. 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 zehn Jahren im praktischen Einsatz bewährt haben.
Dieses Buch geht deshalb über den Inhalt des Scrum Guide hinaus, indem es Scrum im Gesamtkontext der Produktentwicklung betrachtet und beschreibt.
Kapitel 1, 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, 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 essentiell, 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, steht ganz im Zeichen der Scrum-Mechanik. Nach einem ausführlichen Überblick über den Gesamtprozess werden die Rollen, Meetings 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 Buches 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 konkret für einige Aspekte und Scrum-Prinzipien 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 Agile Software Engineering, Software Craftsmanship und das Arbeiten mit mehreren oder mit verteilten Scrum-Teams.
Eine Besonderheit stellt die Kombination von Glossar und Index am Ende des Buches dar.
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, so 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 Buches als kompaktes Nachschlagewerk unterstützen.
Wer sich über Scrum im engeren Sinne informieren und ein Bild machen möchte, der findet in Kapitel 2, und in Kapitel 3, einen guten Überblick. Mit den flankierenden Themen und der Einbettung in den Gesamtkontext der Produktentwicklung kann man sich in diesem Falle 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 über den in das Glossar integrierten Index. Auf diese Weise lässt sich zum Beispiel auffrischen, was bei der Vorbereitung und Durchführung einer 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 Backlogs verantwortlich ist.
Einen weiteren, sehr schnellen und gezielten Einstieg in konkrete Themen und Fragestellungen bietet die besondere Kombination aus Glossar und Index am Ende des Buches. Darin werden die wesentlichen Scrum-Begriffe kompakt erläutert und zugleich 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 Buches einsteigen und weiterlesen.
Darüber hinaus wird sicher jeder Leser einen eigenen Zugang zu diesem Buch finden und mit individuellen Kennzeichnungen seine Einstiegspunkte markieren.
Dieses Buch ist ein Produkt, das von einem Team im besten Scrum-Sinne entwickelt wurde: drei erfahrene agile Praktiker, jeder mit einem etwas anderen Schwerpunkt.
Rolf Dräther arbeitet als selbstständiger Berater und Coach. Er ist Certified Scrum Professional und Certified Scrum Master, akkreditierter Trainer für das Team Management System von Margerison-McCann und systemischer Berater. Mit seinem ganzen Wissen, Können, seiner Intuition und seinen langjährigen Erfahrungen mit objektorientierter und agiler Softwareentwicklung unterstützt er Teams, Führungskräfte und Unternehmen bei der Einführung und Anpassung von Scrum sowie anderen agilen Vorgehensweisen und im täglichen Leben damit.
Holger Koschek ist selbstständiger Berater, Trainer und Coach. Er begleitet Projekte und Organisationen bei der Einführung agiler Vorgehensweisen im Produktmanagement, Projektmanagement und der Unternehmensführung. Unternehmensportale bilden den fachlichen Schwerpunkt des Diplom-Informatikers. Er ist Autor der Geschichten vom Scrum (dpunkt.verlag) sowie Koautor von Agile Projekte mit Scrum, XP und Kanban im Unternehmen durchführen (dpunkt.verlag), Unternehmensportale (Springer-Verlag) und vieler anderer Fachpublikationen.
Carsten Sahling leitet das Geschäftsfeld Agil bei der Holisticon AG. Als klassischer Projektmanager (GPM), Certified Scrum Professional, Inhaber des DSDM Atern Foundation Exam, agiler Coach und Trainer vereint er verschiedene Sichtweisen des Projektmanagements und hilft 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.
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.
Steffi Krause (GOagile!), weil sie unsere Sicht auf Scrum immer wieder um neue Perspektiven ergänzt hat. Das Wissen aus ihren agilen Trainings hat den Weg über unsere Köpfe in dieses Buch gefunden.
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.
Anja, Annika, Svenja und Louis – C. S.
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.
Dieses Kapitel beantwortet die grundlegende Frage »Was ist Scrum – und was ist es nicht?«. Wir verorten Scrum im Universum der agilen Methoden und 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.
Scrum ist ein agiles Projektmanagement-Framework. Es wird hauptsächlich in der Softwareentwicklung verwendet, kann aber auch in anderen Domänen im Rahmen der Entwicklung komplexer Produkte eingesetzt werden.
Scrum ist ein Framework, kein Prozess. Es definiert verschiedene Rollen, Meetings und Artefakte und beschreibt deren Zusammenspiel. Scrum-Projekte entwickeln ihr projektspezifisches Vorgehen in dem von Scrum abgesteckten Rahmen.
Scrum ist kein Allheilmittel. Es kann Projektrisiken nicht verhindern (das kann kein Vorgehensmodell), macht sie aber frühzeitig transparent und somit beherrschbar.
Scrum ist per se kein Projektbeschleuniger. Teams werden nicht besser oder schneller, nur weil sie nach Scrum arbeiten. Aber da sie fokussiert nur die Dinge tun, die aktuell relevant sind, werden die wirklich wichtigen Dinge früher fertig.
Produktentwicklung mit Scrum geschieht iterativ-inkrementell: Mit jeder Iteration (in Scrum Sprint genannt) wird ein Produktinkrement (ein fertiges Stück des Gesamtprodukts) entwickelt, das benutzbar ist. Diese Technik eignet sich durch kurze Feedback-Zyklen besonders für die Entwicklung komplexer Produkte. Auf Scrum.org ist eine bestechend einfache Beschreibung dieses Produktentwicklungsprozesses unter Berücksichtigung der drei Scrum-Rollen zu finden (vgl. [Scrum.org]):
Der Product Owner sagt, was innerhalb des nächsten Sprints entwickelt werden soll.
Das Entwicklungsteam (engl. Development Team) baut das Inkrement entsprechend den Wünschen des Product Owners und präsentiert das Ergebnis am Ende des Sprints.
Der Scrum Master stellt sicher, dass der Produktentwicklungsprozess so reibungslos wie möglich läuft, und unterstützt bei der kontinuierlichen Verbesserung des Prozesses, des Teams und des Produkts.
Scrum ist eine Implementierung der Theorie des Empirismus, der zufolge Wissen auf Erfahrung beruht und Entscheidungen auf der Grundlage dieses Wissens getroffen werden (eine schöne Begriffserläuterung liefert [3sat Philosophie 2012]). Dazu sind drei Voraussetzungen zu schaffen:
Um Erkenntnisse aus Erfahrungen zu gewinnen, müssen alle notwendigen Informationen verfügbar und sichtbar sein.
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.
Sollten die Scrum-Nutzer im Rahmen der Überprüfung signifikante Abweichungen feststellen, dann sind sie gefordert, ihre Vorgehensweise so anzupassen, dass 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 klein sind (zwischen wenigen Tagen und vier Wochen), können Risiken schnell erkannt und frühzeitig beseitigt werden.
Um diese Frage zu beantworten, werfen wir zunächst einen Blick in die Vergangenheit.
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 Artikel »The New New Product Development Game« (Hirotaka Takeuchi, Ikujiro Nonaka; Harvard Business Review 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 und langfristige 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 ohne Mängel 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«, 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. Mit der zunehmenden Verbreitung von Scrum eroberte das Framework neue Anwendungsgebiete. Ursprünglich auf die Softwareentwicklung ausgelegt, wird Scrum mittlerweile in vielen anderen Bereichen eingesetzt, z. B. in der Logistik oder im Event-Management.
In dem oben erwähnten Artikel »The New New Product Development Game« beschreiben Takeuchi und Nonaka die Charakteristika erfolgreicher Produktentwicklungsteams, die sie aus der Untersuchung von Teams aus unterschiedlichen Branchen abgeleitet haben. Drei Wesenszüge waren ihrer Analyse zufolge allen erfolgreichen Teams gemein:
Autonom: Die Teams organisierten sich selbst.
Funktionsübergreifend (cross-functional): Die Teams besaßen das notwendige Wissen und die erforderlichen Fertigkeiten, um das Produkt herzustellen.
Transzendent: Die Teams strebten nach vorn, wollten immer besser werden.
Die Ursache für die schlechte Erfolgsquote von IT-Projekten lag offensichtlich in der Art und Weise ihrer Durchführung begründet und weniger in der unzureichenden Ausbildung der Entwickler oder dem fehlenden Reifegrad der noch jungen Wissenschaft namens Informatik. Deshalb konzentrierten sich Schwaber und Sutherland auf die Professionalisierung der Zusammenarbeit in Projektteams. Sie wollten 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. Jetzt sollten alle Projektbeteiligten darüber nachdenken, wie man besser und effektiver zusammenarbeiten konnte. In Kombination mit Entwicklungstechniken wie eXtreme Programming [Beck 2004] führten Schwaber und Sutherland ihre frühen Scrum-Projekte zum Erfolg und entwickelten Scrum kontinuierlich (und empiristisch) weiter.
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 »Agiles Manifest« [Agile Manifesto] (wir werden auf das Agiles Manifest im Folgenden ohne Literaturangabe verweisen). Das Manifest besteht aus vier Wertepaaren und zwölf Prinzipien [Agile Manifesto – Principles]. Aus den Prinzipien haben wir einmal die aus unserer Sicht wesentlichen Schlagwörter herausgezogen (Abbildung 1.1).
Abbildung 1.1 Die wesentlichen Schlagwörter aus den zwölf Prinzipien des Agilen Manifests
Die Werte des Agilen Manifests sind paarweise beschrieben, wobei die Werte auf der linken Seite jeweils höher eingeschätzt werden als die Werte auf der rechten Seite – was aber nicht heißt, dass Letztere bedeutungslos sind. Die Wertepaare lauten:
In allen erfolgreichen IT-Projekten findet 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 bespricht der Produktverantwortliche gemeinsam mit dem Entwicklungsteam, das die Anforderungen umsetzen soll. 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 für Ihr Projekt anschaffen sollen, sollten Sie sich im Sinne des Agilen Manifests zunächst die Frage stellen, wie Sie einen Raum für den Austausch Ihrer Teammitglieder schaffen und pflegen können.
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 Blick auf das Ergebnis sagt: »So wollte ich das aber nicht haben!« Ähnliches kann auch bei kurzen Softwareprojekten passieren – etwa dann, wenn das fachliche Konzept veraltet ist und nicht 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 Benutzerbedürfnissen genügt – weil sie an der Entwicklung beteiligt waren und diese beeinflussen konnten.
Statt einer umfassenden Dokumentation sollte Wert auf Angemessenheit und Aktualität gelegt werden. Ein Benutzerhandbuch ist in den meisten Fällen sinnvoll – es sei denn, alle Benutzer haben an der Entwicklung mitgewirkt und kennen die Software deshalb in- und auswendig. Eine angemessene technische Dokumentation der Software zahlt sich 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 Alternative 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.
»Produktentwicklung ist Vertrauenssache« – so könnte man diesen Wert auf den Punkt bringen, wenn man den Begriff »Vertrauenssache« nicht im Sinne von »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, dessen Erfolg am Ende von einem Gericht entschieden werden muss, ist unserer Meinung nach kein erfolgreiches Projekt.
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 die Planung von Projekten überdenken. Ein Plan, der zu Projektbeginn sowohl die Dauer als auch den Umfang und das Budget verbindlich festlegt, ist unrealistisch. Einer der drei Parameter im sogenannten »magischen Dreieck des Projektmanagements« muss variabel bleiben. Die Qualität ist keine Variable – sie muss immer das geforderte (hohe) Niveau haben. Bei der Qualität gehen agile Methoden keine Kompromisse ein, denn nachhaltige Kundenzufriedenheit ist das oberste Ziel (siehe Abbildung 1.2).
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 bekämpft werden. Agile Projekte leben nach dem von Dwight D. Eisenhower formulierten Motto: »Pläne sind nichts. Planung ist alles.«
Abbildung 1.2 Das magische Dreieck des Projektmanagements
Das Agile Manifest beschreibt ein Wertesystem, das allen agilen Methoden zugrunde liegt. Ohne dieses Wertesystem 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.
Das andere Denken beginnt bei den Werten. Das Wertesystem des Agilen Manifests haben wir bereits beschrieben. Mike Beedle und Ken Schwaber beschreiben in [Schwaber 2001] ein Fundament aus fünf Werten, auf dem Scrum beruht:
Selbstverpflichtung (Commitment)
Fokus (Focus)
Offenheit (Openness)
Respekt (Respect)
Mut (Courage)
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.
»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 Produktentwicklungsteam als Partner verstehen und eine gemeinsame Sprache entwickeln. Oft müssen sie sogar die Grundregeln der Kommunikation neu erlernen.
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 stellt den Rahmen für einen solchen Entwicklungsprozess dar. 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 im Abschnitt „Was noch?“ vorstellen. In regelmäßigen Retrospektiven wird das Team die Güte seines Prozesses überprüfen und gegebenenfalls Anpassungen am Prozess vornehmen.
Scrum hat seine Wurzeln in der Entwicklung komplexer Softwaresysteme. Der Schwerpunkt von Scrum liegt in der Organisation der Anforderungsbeschreibungen und Entwicklungstätigkeiten. Konkrete Entwicklungstechniken gehören 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 Entwicklung und Produktivsetzung der Software (die bei Scrum iterativ geschieht) ist ein Softwareentwicklungsprojekt irgendwann einmal zu Ende. Oft wird die Verantwortung für die Software dann in die Hände eines Wartungs- oder Betriebsteams gelegt. Wie Scrum in dieses Umfeld eingebettet ist, illustrieren wir im Abschnitt „Das Schalenmodell agiler Produktentwicklung“.
Eine wachsende Anzahl an Publikationen zu agilem Management ist ein Indiz für die Relevanz dieses Themas. Jurgen Appelo liefert in [Appelo 2010] ein komplettes agiles Managementmodell, das aus sechs Perspektiven besteht:
Ermächtige Teams.
Entwickle Kompetenz.
Verbessere alles.
„Umfeld“Abbildung 1.3
Mit der Fertigstellung einer Produktversion endet der Lebenszyklus eines Produkts noch lange nicht. Jetzt muss es seine Alltagstauglichkeit unter Beweis stellen. Fehler müssen behoben werden, und neue Anforderungen werden an das Produkt gestellt, die es zu priorisieren und gegebenenfalls umzusetzen gilt. Bei Softwareprodukten hat die Betriebs- oder Wartungsphase begonnen. Diese kann als Scrum-Projekt organisiert sein. Oft kommen aber andere Methoden zum Einsatz, z. B. Software-Kanban [Anderson 2011].
„Was noch?“
Je umfangreicher ein Produkt, desto mehr Personen werden für dessen Entwicklung benötigt. Da die ideale Teamgröße neun Personen nicht überschreiten soll, empfiehlt es sich in diesem Fall, mehrere Teams zu bilden. Die Organisation der Zusammenarbeit zwischen Scrum-Teams wird im Scrum Guide [Schwaber 2011] (wir werden auf den Scrum Guide im Folgenden ohne Literaturangabe verweisen). nicht beschrieben. Es gibt aber erprobte Praktiken, z. B. das , mit dem die erfolgreiche Zusammenarbeit zwischen Teams gelingt.
„Scrum-Teams sind funktionsübergreifend (cross-functional)“
„Das Agile Manifest“„Mehr als nur Mechanik“Kapitel 2