Die Kunst der agilen Entwicklung E-Book

James Shore

• Herausgeber: dpunkt.verlag
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Deutsch
• Veröffentlichungsjahr: 2023

Seitenzahl: 1213

Beschreibung

US-Bestseller in 2. Auflage: ein Muss für jeden, der mit oder in einem Softwareentwicklungsteam arbeitet!

• leicht zu lesen, pragmatisch und umfassend von den agilen Grundsätzen bis hin zu Details bei der agilen Softwareentwicklung
• hoher Praxisbezug durch zahlreiche Tipps und Fallbeispiele
• geeignet für neu startende Projekte und auch bestehende Teams

Um agile Entwicklung zu meistern, müssen Sie im Team lernen, unzählige Möglichkeiten von Moment zu Moment zu bewerten und intuitiv die beste Vorgehensweise auszuwählen.

Dieses Buch beschreibt umfassend und praxisorientiert die Grundlagen, Methoden und Praktiken agiler Softwareentwicklung. James Shore gibt wertvolle Ratschläge für den Projektstart, inkrementellen Entwurf, Continuous Integration, iterative Planung und testgetriebene Entwicklung sowie die Bereitstellung und Refactoring von Software, die aus über zwei Jahrzehnten Erfahrung mit Agilität stammen. Er bringt den State of the Art aus Extreme Programming, Scrum, Lean, DevOps und mehr in ein zusammenhängendes Ganzes und vermittelt darüber hinaus, dass Agilität zu meistern auch bedeutet, in Abhängigkeit von Projektgegebenheiten und der Organisation, in der Software entwickelt wird, Praktiken anzupassen.

Diese 2. Auflage ist vollständig überarbeitet und von Grund auf neu geschrieben worden und berücksichtigt dabei die Weiterentwicklung auf dem Gebiet der agilen Entwicklung der letzten 14 Jahre. Neu aufgenommen wurden Themen wie agile Skalierung, DevOps, die Arbeit mit Remote-Teams sowie das Agile Fluency Model zur Einführung und Anpassung von Agilität an die Bedürfnisse des Unternehmens.

Leseprobe

Stimmen zur zweiten Auflage von»Die Kunst der agilen Entwicklung«

»Die Kunst der agilen Entwicklung« vollbringt in der 2. Auflage das Kunststück, moderne Softwareentwicklung in einem kurzen, lesbaren und unterhaltsamen Buch zusammenzufassen. Für Neueinsteiger der iterativen Lieferung bietet es einen guten Überblick über die gängigen Praktiken. Für diejenigen, die sich in den Wirren der überdimensionierten »skalierten agilen« Prozesse verirrt haben, zeigt es gute Ideen auf, um dieser Hölle zu entkommen. Die erste Auflage hatte vor zwei Jahrzehnten einen großen Einfluss auf meine Karriere, und ich bin sicher, dass auch die zweite Auflage Millionen von Entwicklerinnen und Entwicklern in ähnlicher Weise dabei helfen wird, die Art und Weise, wie sie Software liefern, zu verbessern.

– Gojko Adzic, Autor von Running Serverless, Impact Mapping, Specification by Example

Vom Code bis zur Auslieferung des Produkts – dieses Buch bietet alles. Jahrzehntelanges, hart erarbeitetes Wissen in lesbarer und verdaulicher Form – ein Muss für jeden, der mit oder in einem Softwareentwicklungsteam arbeitet.

– Avi Kessner, Staff Engineer, Forter

Dieses Buch wird einen festen Platz in meinem am besten erreichbaren Bücherregal haben.

– Krishna Kumar, Gründer und CEO, Exathink Research

Die erste Auflage dieses Buches hat mich so fasziniert, dass ich es immer noch als Nachschlagewerk in meinem Bücherregal stehen habe. Die zweite Auflage behält diese Rezeptur bei und fügt noch mehr Erkenntnisse aus dem letzten Jahrzehnt hinzu.

– Benjamin Muskalla, Senior Software Engineer, GitHub

Eines der umfassendsten Bücher über agile Softwareentwicklung, die ich je gelesen habe. Sehr pragmatisch, mit aussagekräftigen Beispielen, die leicht auf jedes Softwareentwicklungsprojekt anwendbar sind, unabhängig von der technischen Ausstattung, der Teamgröße oder der Branche. Auf jeden Fall ein Juwel, das Sie an Ihrem Arbeitsplatz griffbereit haben sollten.

– Luiza Nunes, Programm-Managerin, Thoughtworks

Dies ist mein Lieblingsbuch über agile Entwicklung. Es behandelt technische und Managementthemen. Ich verwende es in meinen Kursen und empfehle es auch immer meinen Kunden.

– Nicolás Paez, Software Engineer und Professor, Universidad de Buenos Aires

Jim deckt seinen erfahrungsbasierten Ansatz zur agilen Softwareentwicklung mit leicht verständlichen Kapiteln, die Konzepte mit Praktiken verbinden, umfassend ab.

– Ken Pugh, Principal Consultant, Autor von Prefactoring: Extreme Abstraction, Extreme Seperation, Extreme Readability

Es gibt Tausende Bücher zu Agilität und Sie fragen sich, welches Sie lesen sollten? Ich empfehle Ihnen, dieses Buch in Betracht zu ziehen. James ist seit den frühen Tagen der Agilität dabei und kennt sich aus. Das Buch setzt sich von dem Unfug in unserer Branche, dem bedeutungslosen »Agile«, das überall zu finden ist, ab und bietet einen gründlichen, ganzheitlichen Ansatz. Dieser Ansatz wird nicht schnell und einfach sein, aber es wird sich lohnen. Ich habe »Die Kunst der agilen Entwicklung« geliebt. Es ist ein Buch mit Haltung!

– Bas Vodde, Mitbegründer von LeSS

James Shore hat »Die Kunst der agilen Entwicklung« mit neuen Werkzeugen, Techniken und Lektionen aus dem letzten Jahrzehnt komplett überarbeitet. Dieses Juwel von einem Buch wird Ihnen dabei helfen, Ihre Arbeitsweise zu einer wirklich agilen und effektiven Art und Weise weiterzuentwickeln.

– Bill Wake, XP123, LLC

Autor

James Shore leitet seit 1999 Teams, die agile Entwicklung praktizieren. Er kombiniert ein tiefes Verständnis der agilen Ideen mit jahrzehntelanger praktischer Erfahrung in der Entwicklung und nutzt diese Erfahrung, um Menschen dabei zu unterstützen, zu verstehen, wie alle Aspekte von Agilität zusammenpassen, um herausragende Ergebnisse zu erzielen. James hat den Gordon Pask Award der Agile Alliance für Beiträge zur agilen Praxis erhalten, ist Moderator mehrerer Screencasts zur Softwareentwicklung und Mitbegründer des Agile Fluency Model. Er ist online unter jamesshore.com zu finden.

Übersetzer

Wolf-Gideon Bleek ist bei der it-agile GmbH in Hamburg tätig. Nach dem Studium der Informatik promovierte er zum Thema Software-Infrastruktur-Entwicklung. Er ist Ende der 90er-Jahre zuerst mit agilen Methoden in Kontakt gekommen. In Industrieprojekten für verschiedene Kunden konnte er Erfahrungen in Scrum, XP und Kanban als Developer, Agile Coach und Product Owner sowie als Führungskraft sammeln. Sein Interesse gilt dem Zusammenspiel zwischen Technik, Prozess und Organisation. In Publikationen und auf Konferenzen gibt er seine Erfahrungen weiter.

Tim Müller arbeitet bei der it-agile GmbH in Hamburg und ist ausgebildeter Fachinformatiker in der Fachrichtung Anwendungsentwicklung. Als Softwareentwickler lernte er in verschiedenen Projekten sowohl klassische als auch agile Methoden und Werkzeuge aus dem Extreme Programming kennen. Die Arbeit mit agilen Werten und Methoden überzeugten Tim und sorgten dafür, dass er das dort Erlernte wann immer möglich anwendet. Diese Erfahrung und Begeisterung gibt er jetzt gerne an andere Teams weiter.

Coypright und Urheberrechte:Die durch die dpunkt.verlag GmbH vertriebenen digitalen Inhalte sind urheberrechtlich geschützt. Der Nutzer verpflichtet sich, die Urheberrechte anzuerkennen und einzuhalten. Es werden keine Urheber-, Nutzungs- und sonstigen Schutzrechte an den Inhalten auf den Nutzer übertragen. Der Nutzer ist nur berechtigt, den abgerufenen Inhalt zu eigenen Zwecken zu nutzen. Er ist nicht berechtigt, den Inhalt im Internet, in Intranets, in Extranets oder sonst wie Dritten zur Verwertung zur Verfügung zu stellen. Eine öffentliche Wiedergabe oder sonstige Weiterveröffentlichung und eine gewerbliche Vervielfältigung der Inhalte wird ausdrücklich ausgeschlossen. Der Nutzer darf Urheberrechtsvermerke, Markenzeichen und andere Rechtsvorbehalte im abgerufenen Inhalt nicht entfernen.

James Shore

Die Kunst der agilen Entwicklung

Grundlagen, Methoden und Praktiken

Aus dem Englischen von Wolf-Gideon Bleek und Tim Müller

James Shore • [email protected]

Unter Mitwirkung von Diana Larsen, Gitte Klitgaard & Shane Warden

Lektorat: Christa Preisendanz

Lektoratsassistenz: Julia Griebel, Anja Weimer

Übersetzung: Wolf-Gideon Bleek, Tim Müller

Copy-Editing: Ursula Zimpfer, Herrenberg

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

Herstellung: Stefanie Weidner, Frank Heidt

Umschlaggestaltung: Helmut Kraus, www.exclam.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-86490-860-6

PDF

978-3-96910-866-6

ePub

978-3-96910-867-3

mobi

978-3-96910-868-0

1. Auflage 2023

Translation Copyright für die deutschsprachige Ausgabe © 2023 dpunkt.verlag GmbHWieblinger Weg 17

69123 Heidelberg

Authorized German translation of the English edition of The Art of Agile Development, 2nd Edition ISBN 9781492080695 © 2021 James Shore and Big Blue Marble LLC

This translation is published and sold by permission of O’Reilly Media, Inc., which owns or controls all rights to publish and sell the same.

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 noch Übersetzer 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

Für meine Familie

Inhaltsübersicht

Geleitwort

Vorwort

Vorwort der Übersetzer

Teil IAgilität verbessern

1Was ist Agilität?

2Wie können wir agil sein?

3Wählen Sie Ihre Agilität

4In Agilität investieren

5In Veränderung investieren

6Agilität skalieren

Teil IIFokus auf Mehrwert

7Teamwork

8Planen

9Ownership

10Verantwortlichkeit

11Verbesserung

Teil IIIZuverlässig liefern

12Zusammenarbeit

13Entwicklung

14Entwurf

15DevOps

16Qualität

Teil IVOptimierung der Ergebnisse

17Autonomie

18Entdeckung

19In die Zukunft

Anhang

Literaturverzeichnis

Index

Inhaltsverzeichnis

Geleitwort

Vorwort

Vorwort der Übersetzer

Teil IAgilität verbessern

1Was ist Agilität?

1.1Die Entstehung von Agilität

1.2Aus der Krise geboren

1.3Das Manifest für Agile Softwareentwicklung

1.4Die Essenz von Agilität

1.5Warum Agilität gewonnen hat

1.6Warum Agilität funktioniert

1.7Warum Agilität scheitert

2Wie können wir agil sein?

2.1Agilität praktizieren

2.2Der Weg zur Meisterschaft

2.3Wie es losgeht

3Wählen Sie Ihre Agilität

3.1Das Agile Fluency-Modell

3.2Wählen Sie Ihre Zonen

4In Agilität investieren

4.1Ermöglichen Sie Zeit für das Lernen

4.2Wählen oder bilden Sie agile Teams

4.3Wählen Sie agile Coaches aus

4.4Delegieren Sie Befugnisse und Verantwortung an Teams

4.5Passen Sie den Managementstil auf Teamebene an

4.6Richten Sie Teamräume ein

4.7Etablieren Sie für jedes Team ein lernfreundliches Ziel

4.8Ersetzen Sie Steuerungsansätze nach dem Wasserfallmodell

4.9Passen Sie nachteilige Vorgaben aus der Personalabteilung an

4.10Sprechen Sie Sicherheitsbedenken an

5In Veränderung investieren

5.1Veränderung verstehen

5.2Veränderung im Großen

5.3Veränderungen durchführen

5.4Besorgen Sie sich die Unterstützung des Managements

5.5Besorgen Sie sich die Zustimmung des Teams

5.6Besorgen Sie sich die Zustimmung der Stakeholder

5.7Weiterführende Literatur

6Agilität skalieren

6.1Fluency skalieren

6.2Produkte und Portfolios skalieren

Teil IIFokus auf Mehrwert

Willkommen in der Focusing-Zone

Praktiken der Focusing-Zone meistern

7Teamwork

7.1Komplettes Team

7.2Teamraum

7.3Sicherheit

7.4Zweck

7.5Kontext

7.6Ausrichtung

7.7Energiegeladene Arbeit

8Planen

8.1Storys

8.2Adaptives Planen

8.3Visuelles Planen

8.4Das Planning Game

8.5Echte Kundenbeteiligung

8.6Inkrementelle Anforderungen

9Ownership

9.1Aufgabenplanung

9.2Kapazität

9.3Freiraum

9.4Standup-Meetings

9.5Informative Arbeitsumgebung

9.6Kundenbeispiele

9.7»fertig, fertig«

10Verantwortlichkeit

10.1Vertrauen der Stakeholder

10.2Stakeholder-Demos

10.3Prognosen

10.4Roadmaps

10.5Management

11Verbesserung

11.1Retrospektiven

11.2Teamdynamik

11.3Beseitigung von Hindernissen

Teil IIIZuverlässig liefern

Willkommen in der Delivering-Zone

Praktiken der Delivering-Zone meistern

12Zusammenarbeit

12.1Collective Code Ownership

12.2Pair Programming

12.3Mob Programming

12.4Ubiquitous Language

13Entwicklung

13.1Keine Reibungsverluste

13.2Continuous Integration

13.3Testgetriebene Entwicklung

13.4Schnelle, zuverlässige Tests

13.5Refactoring

13.6Spike-Lösungen

14Entwurf

14.1Inkrementeller Entwurf

14.2Einfacher Entwurf

14.3Reflektierender Entwurf

15DevOps

15.1Für den Betrieb bauen

15.2Feature Flags

15.3Continuous Deployment

15.4Evolutionäre Systemarchitektur

16Qualität

16.1Keine Fehler

16.2Aufdecken blinder Flecken

16.3Vorfallanalyse

Teil IVOptimierung der Ergebnisse

Willkommen in der Optimizing-Zone

Optimizing Fluency erreichen

17Autonomie

17.1Geschäftsbezogenes Fachwissen

17.2Geschäftsbezogene Entscheidungen

17.3Verantwortlichkeit und Beaufsichtigung

17.4Finanzierung

17.5Experimente und weiterführende Literatur

18Entdeckung

18.1Validiertes Lernen

18.2Anpassungsfähigkeit

18.3Experimente und weiterführende Literatur

19In die Zukunft

Anhang

Literaturverzeichnis

Index

Geleitwort

Als wir das Manifest für Agile Softwareentwicklung verfassten, handelte es sich bei den Personen, die uns unterstützten, um eine kleine Minderheit, die versuchte, eine Branche zu verändern. Heute, 20 Jahre später, ist »agil« im Mainstream angekommen. Aber ich schreibe »agil« nicht ohne Grund in Anführungszeichen – viele Leute sagen, dass sie agile Softwareentwicklung betreiben, und die meisten glauben das auch wirklich. Doch ihre Handlungen haben wenig Ähnlichkeit mit der gemeinsamen Vision, die wir vor zwei Jahrzehnten teilten.

Die Wahrheit ist, dass eine agile Arbeitsweise ein Netz miteinander verbundener Praktiken erfordert, die sowohl das Management als auch die technische Ausführung der Softwareentwicklungsarbeit umfassen. Viele dieser Praktiken, insbesondere die technischen, sind nicht gut verstanden oder werden nicht allgemein gelehrt. Infolgedessen haben zu viele eine verfälschte Vorstellung davon, wie effektiv die Entwicklung von Softwareprodukten sein kann.

James Shore war einer der frühen Pioniere auf dem Weg zu Extreme Programming, einer zentralen Säule der agilen Bewegung. Seine erste Auflage dieses Buches war einer meiner Favoriten: ein Handbuch für Teams, das ihnen das nötige Wissen vermittelte, um einen agilen Prozess richtig durchzuführen. Später arbeitete er mit Diana Larsen zusammen, um das Agile Fluency Model zu entwickeln – ein Modell, das ihre Erfahrungen festhält, auf welche verschiedenen Arten Menschen ihre Fähigkeiten im Umgang mit agilen Ansätzen entwickeln können. In diesem Modell bietet eine einfache Anwendung von Projektmanagementtechniken, die oft als grundlegender Scrum-Ansatz bezeichnet wird, einen gewissen Wert, indem sie sich auf die Kundenbedürfnisse konzentriert. Es fehlen aber die technischen Fähigkeiten, die Sie benötigen, um die hohe Produktivität und Zuverlässigkeit auszuschöpfen, die viele Teams erreichen.

Diese Sichtweise bestimmt zu Recht die Struktur dieses Buches, das den Schwerpunkt darauf legt, wie Sie sich auf die Wertstiftung konzentrieren und wie Sie diesen Wert zuverlässig liefern. Ausrichtung an der Wertstiftung heißt, dass Sie die Bedeutung einer starken Teamarbeit verstehen, Fähigkeiten zur adaptiven Planung entwickeln und eng mit den Kunden und Benutzerinnen der entstehenden Software zusammenarbeiten. Zuverlässig liefern konzentriert sich auf wesentliche technische Praktiken für Tests, Refactoring, Entwurf und kollaborative Entwicklung. Dabei wird die oft kontraintuitive Vorstellung berücksichtigt, dass die Erstellung von Software mit hoher interner Qualität die Kosten senkt und die Geschwindigkeit der Codebereitstellung erhöht. Kombiniert mit einer DevOps-Kultur und Continuous Delivery ermöglicht dies eine hohe Frequenz, Funktionen schnell in Produktion zu bringen, was wiederum den Teams die Möglichkeit gibt, mehr darüber zu erfahren, was wertstiftend ist, indem sie beobachten, wie die Software in der Praxis genutzt wird.

Ich hatte das Glück, vor 20 Jahren bei Thoughtworks ein Zuhause zu finden, wo unsere Teams diese Art von Fähigkeiten nutzen, um unsere Kunden bei der Entwicklung neuer Softwareprodukte zu unterstützen und alte Traditionen abzulösen. Wie James haben auch wir festgestellt, dass Extreme Programming eine solide Grundlage für unsere Arbeit darstellt, und wir haben diese Techniken in den letzten zwei Jahrzehnten mit großem Erfolg angewandt. Ich freue mich daher sehr darüber, dass James ein weiteres Jahrzehnt seiner Coaching-Erfahrung in die Überarbeitung seines Buches eingebracht hat. Das Ergebnis ist eine solide Grundlage für das Erlernen dieser Fähigkeiten, die uns so sehr geholfen haben. Wie alles, was sich lohnt, wird es Zeit brauchen, und auf dem Weg dorthin wird es Frustrationen geben. Aber dieser Leitfaden kann Ihnen auf dieser Reise helfen – weg von öden Zeremonien hin zu der Kraft, die wir empfunden haben, als James und ich diese Techniken vor all den Jahren zum ersten Mal angewandt haben.

– Martin FowlerChief Scientist, Thoughtworks

Vorwort

F: Wie komme ich zur Carnegie Hall1?

A: Üben, üben, üben!

Ich möchte Ihnen helfen, die Kunst der agilen Entwicklung zu meistern.

Die agile Entwicklung ist, wie jeder teambasierte Ansatz zur Softwareentwicklung, eine grundlegend menschliche Kunst, die den Unwägbarkeiten des Einzelnen und seiner Interaktionen unterliegt. Um die agile Entwicklung zu meistern, müssen Sie lernen, unzählige Möglichkeiten von Augenblick zu Augenblick zu bewerten und intuitiv die beste Vorgehensweise auszuwählen.

Wie können wir eine so schwierige Kunst überhaupt erlernen? Durch Üben!

Dieses Buch ist in erster Linie ein Leitfaden für die Praxis. Es ist eine detaillierte Beschreibung einer Art und Weise, wie Sie agile Entwicklung praktizieren können. Es basiert auf Extreme Programming, lässt aber auch Ideen und Praktiken aus Scrum, Kanban, DevOps, Lean Software Development, Lean Startup und anderen Methoden einfließen. Letztendlich ist es ein praktischer Leitfaden, der es Ihnen ermöglicht, die agile Entwicklung erfolgreich in Ihrem Team und Ihrer Organisation einzuführen – oder er wird Ihnen helfen, herauszufinden, dass Agilität keine gute Wahl für Ihre Situation ist.

Zweitens soll Ihnen dieses Buch dabei helfen, die Kunst der agilen Entwicklung zu meistern. Agilität zu meistern bedeutet, über ein Kochbuch mit Praktiken hinauszugehen. Softwareentwicklung ist zu kontextabhängig, als dass ein einzelner Ansatz perfekt passen könnte, und zu vielschichtig, als dass Ihnen irgendein Buch lehren könnte, wie Sie sie beherrschen. Die Beherrschung kommt von innen: aus Erfahrung und einem intuitiven Verständnis der Auswirkungen, die selbst die kleinste Entscheidung verursacht.

Ich kann Ihnen nicht beibringen, wie sich Ihre Entscheidungen auf Ihr gesamtes Unternehmen auswirken werden. Ich versuche es auch gar nicht. Sie müssen selbst für die Feinheiten und das Verständnis sorgen. Nur so können Sie diese Kunst beherrschen. Befolgen Sie die Praktiken und beobachten Sie, was passiert. Überlegen Sie, warum sie funktioniert haben … oder auch, warum sie nicht funktioniert haben. Dann wiederholen Sie es. Was war gleich? Was war anders? Und warum war es das? Dann wiederholen Sie es erneut. Und noch einmal.

Am Anfang werden Sie vielleicht nicht verstehen, wie Sie die einzelnen Praktiken anwenden sollen. Auf dem Papier sehen sie einfach aus, aber die Umsetzung einiger Praktiken wird schwierig sein. Üben Sie weiter, bis sie einfach anzuwenden sind.

Wenn Ihnen das agile Vorgehen leichter fällt, werden Sie feststellen, dass einige meiner Ratschläge für Sie nicht funktionieren. Am Anfang werden Sie nicht erkennen können, ob das Problem in den Anweisungen liegt, die ich Ihnen gebe, oder in der Art und Weise, wie Sie sie befolgen. Üben Sie weiter, bis Sie sich sicher sind. Wenn Sie sicher sind, brechen Sie die Regeln. Ändern Sie meine Anleitungen, um sie besser auf Ihre spezielle Situation abzustimmen. Jede Praktik hat einen Abschnitt »Alternativen und Experimente« mit Ideen zum Ausprobieren.

Eines Tages werden Regeln für Sie nicht mehr von Interesse sein. Schließlich geht es bei Agilität nicht darum, Regeln zu befolgen. »Es geht um Einfachheit und Feedback, Kommunikation und Vertrauen«, werden Sie denken. »Es geht darum, Wert zu liefern – und den Mut zu haben, das Richtige zur richtigen Zeit zu tun.« Sie werden von Augenblick zu Augenblick unzählige Möglichkeiten bewerten und intuitiv die beste Vorgehensweise auswählen.

Wenn Sie das getan haben, geben Sie dieses Buch an eine andere Person weiter, selbst wenn Ihr Exemplar schon ein paar Eselsohren hat. So kann auch die nächste Person die Kunst der agilen Entwicklung meistern.

Für die Pragmatiker

Was, wenn Sie keine sogenannte »Kunst« beherrschen wollen? Was ist, wenn Sie einfach nur gute Software entwickeln wollen?

Keine Sorge – dieses Buch ist auch für Sie. Ich habe meine jahrelange Erfahrung mit agiler Entwicklung in einem einzigen, klar definierten und umfassenden Ansatz zusammengefasst.

Das erlaubt mir, eine einfache, unkomplizierte Sprache zu verwenden. Ich gebe eine Menge praktischer Tipps und beschreibe offen, wann mein Ansatz nicht funktioniert und welche Alternativen Sie dann in Betracht ziehen können. Kapitel 2 wird Ihnen den Einstieg erleichtern.

Die Erörterung nur eines Ansatzes hat einen Nachteil: Kein einzelner Ansatz ist für alle passend. Meine Ratschläge sind möglicherweise nicht für Ihr Team oder Ihre Organisation geeignet. Lesen Sie die Kapitel 4 und 5, um die allgemeinen Voraussetzungen für den Erfolg zu verstehen, und lesen Sie den Abschnitt »Voraussetzungen« für jede Praktik, um Einzelheiten zu erfahren.

Aber gehen Sie nicht einfach davon aus, dass eine bestimmte Praktik für Sie nicht geeignet ist. Einige der Praktiken in diesem Buch sind kontraintuitiv oder klingen einfach nicht nach Spaß. Die meisten der Praktiken funktionieren am besten im Zusammenspiel mit anderen. Wenn Sie können, probieren Sie die Praktiken ein paar Monate lang so aus, wie sie beschrieben sind. Sammeln Sie praktische Erfahrungen damit, wie sie in Ihrer Umgebung funktionieren, und passen Sie sie dann an.

Ich setze diese Ideen seit mehr als 20 Jahren in die Praxis um. In der richtigen Umgebung funktionieren sie wirklich. Agile Entwicklung hat mehr Spaß gemacht und war erfolgreicher als jeder andere Ansatz zur Softwareentwicklung, den ich ausprobiert habe. Kommen Sie mit auf die Reise.

Was ist neu in der zweiten Auflage?

Diese zweite Auflage von Die Kunst der agilen Entwicklung ist eine vollständige, grundlegende Überarbeitung der ersten Auflage. Sie behält den bodenständigen, praktischen Ansatz der ersten Auflage bei, ebenso wie die meisten Praktiken der ersten Auflage. Aber fast alle wurden neu geschrieben, um die Vorteile von 14 Jahren Fortschritt in der agilen Praxis zu nutzen – ganz zu schweigen von 14 weiteren Jahren Erfahrung meinerseits.

Ich habe das Buch komplett umstrukturiert, um eine schrittweise Einführung zu ermöglichen und die reale Nutzung von Agilität durch Teams besser widerzuspiegeln. Die Prinzipien und Anpassungen, die in Teil III der ersten Auflage erläutert wurden, sind auf die Praktiken verteilt worden, um sie deutlicher hervorzuheben und zugänglicher zu machen, und ich habe jede Praktik mit Vorschlägen für Experimente erweitert.

Zu den bemerkenswerten Ergänzungen gehören:

Ein detaillierter Leitfaden zur Einführung von Agilität und zur Anpassung an die Bedürfnisse Ihres Unternehmens, basierend auf dem

Agile Fluency

2

-Modell, das ich zusammen mit Diana Larsen entwickelt habe.

Ein neues Kapitel über agile Skalierung, das auf meiner Erfahrung bei der Unterstützung großer und kleiner Unternehmen basiert.

Ein neues Kapitel zu DevOps mit neuen Inhalten über die Zusammenarbeit mit den Bereichen Betrieb und Sicherheit sowie von DevOps inspirierte Aktualisierungen im gesamten restlichen Buch.

Anleitungen für den Einsatz von Agilität in Teams, die remote arbeiten; viele neue Praktiken, Geschichten und Ideen und zu viele weitere Verbesserungen und Änderungen, um sie hier alle aufzuführen.

Für wen dieses Buch bestimmt ist

Dieses Buch richtet sich an alle, die in einem agilen Team arbeiten oder hoffen, dies in Zukunft zu tun. Dazu gehören natürlich Programmiererinnen, aber auch Manager, Führungskräfte, Domänenexperten, Tester, Produktmanager, Projektmanagerinnen, Architekten, Betriebsleiter, Sicherheitsexperten, Designer und Business-Analysten. Agile Teams sind funktionsübergreifend; dieses Buch spiegelt diese Tatsache wider.

Das Buch ist so angelegt, dass es sowohl als Nachschlagewerk zu verwenden ist als auch von vorne bis hinten gelesen werden kann. Jede Praktik in Teil II bis Teil IV ist so gestaltet, dass sie für sich allein gelesen werden kann. Die Kästen »Verwandte Themen« und die Hyperlinks in der E-Book-Ausgabe helfen Ihnen beim Nachschlagen. Die gedruckte Ausgabe ist außerdem so konzipiert, dass Sie sie in die Hand nehmen und durchblättern können. Blättern Sie durch das Buch und halten Sie inne, um tiefer einzusteigen, wenn eine Aussage Ihre Aufmerksamkeit erregt.

Wenn Sie ein Manager oder eine Führungskraft sind und verstehen möchten, wie Agilität in Ihrem Unternehmen funktionieren kann oder sollte, lesen Sie Teil I. Wenn Sie ein Manager auf Teamebene sind, lesen Sie auch im Abschnitt »Management« auf Seite 382 und möglicherweise die anderen Praktiken in Kapitel 10.

Wenn Sie als Teammitglied oder Manager daran interessiert sind, Agilität in Ihrem Unternehmen einzuführen, oder die Art und Weise, wie Agilität in Ihrem Unternehmen praktiziert wird, zu verbessern, lesen Sie das gesamte Buch von Anfang bis Ende. Teil I wird Ihnen helfen zu verstehen, wie Sie agile Ideen einführen können. Der Rest des Buches unterstützt Sie dabei, zu verstehen, wie Sie Agilität in die Praxis umsetzen können.

Wenn Sie Teil eines agilen Teams sind und nur genug lernen wollen, um Ihre Arbeit zu erledigen, können Sie sich auf die Praktiken in Teil II und Teil III konzentrieren. Beginnen Sie mit Kapitel 1, um sich einen Überblick zu verschaffen, und lesen Sie dann die Praktiken durch, die Ihr Team verwendet. Wenn Ihr Team Praktiken anwendet, die nicht im Inhaltsverzeichnis aufgeführt sind, sehen Sie im Index nach. Sie könnten unter einem anderen Namen aufgeführt sein.

Wenn Sie nicht Teil eines agilen Teams sind, aber mit einem solchen zusammenarbeiten, bitten Sie die Teammitglieder um Vorschläge, was Sie lesen sollten. Produktmanager, Product Owner und Designer sollten mit Kapitel 8 und dem Abschnitt »Zweck« auf Seite 145 beginnen. Wenn Sie aus den Bereichen Sicherheit und Betrieb kommen: Lesen Sie die Abschnitte »Für den Betrieb bauen« auf Seite 589, »Aufdecken blinder Flecken« auf Seite 636 und »Vorfallanalyse« auf Seite 644. Für Tester bietet sich insbesondere Kapitel 16 an.

Wenn Sie einfach nur neugierig auf die agile Entwicklung sind, beginnen Sie mit der Lektüre von Kapitel 1. Werfen Sie danach einen Blick auf Teil II, Teil III und Teil IV. Starten Sie mit den Praktiken, die Ihnen am interessantesten erscheinen. Sie können sie in beliebiger Reihenfolge lesen.

Über die Gastautorinnen und den Gastautor

Ich bin in der glücklichen Lage, dass ich mehrere namhafte Mitstreiter und Mitstreiterinnen für diese Auflage gewinnen konnte. Gitte Klitgaard hat den Abschnitt »Sicherheit« auf Seite 134 geschrieben, in dem sie das Thema der psychologischen Sicherheit fachkundig behandelt. Diana Larsen hat die Abschnitte »Teamdynamik« auf Seite 408 und »Beseitigung von Hindernissen« auf Seite 425 verfasst und bringt damit ihre jahrzehntelange Erfahrung in der Organisationsund Teamentwicklung ein. Shane Warden, mein Co-Autor der ersten Auflage, konnte kein neues Material zu dieser Auflage beisteuern, aber er blieb ein wertvoller Gesprächspartner und unsere Arbeit an der ersten Auflage bildete die Grundlage für diese Auflage.

Gitte Klitgaard

Gitte Klitgaard ist Agile Coach, Trainerin und Mentorin mit dem Schwerpunkt, Organisationen bei der Einführung von psychologischer Sicherheit, Verantwortung und Verantwortlichkeit zu helfen. Gitte ist authentisch; sie bringt die Dinge auf den Punkt und hilft den Menschen, zu sich selbst zu finden und dadurch erfolgreich zu sein.

Zu ihren Beiträgen in der Community gehören die Organisation von Coach-Camps und Vorträge auf Konferenzen, bei denen sie Themen wie psychische Gesundheit und psychologische Sicherheit hervorhebt und zugänglich macht. Sie schafft sichere und respektvolle Umgebungen am Arbeitsplatz und darüber hinaus. Sie hört den leiseren Stimmen und Minderheitengruppen zu und engagiert sich für sie.

In ihrer Freizeit sammelt Gitte LEGO und Yodas und hält Kontakt zum Freundeskreis aus der ganzen Welt, darunter einige Personen, die sie als ihre zweite Familie betrachtet.

Gitte ist Inhaberin von Native Wired und hat den Wandel bei Unternehmen wie LEGO, Spotify und Mentimeter vorangetrieben.

Diana Larsen

Seit über 20 Jahren trägt Diana Larsen zu den Grundlagen und Erweiterungen des agilen Denkens und zur Praxis der Bildung und Befähigung qualifizierter Teams bei. Diana Larsen ist Co-Autorin von Agile Retrospectives, Liftoff, 2nd ed. und Five Rules for Accelerated Learning, zwei neuen Büchern, die derzeit in Arbeit sind, sowie vom E-Book The Agile Fluency Model: A Brief Guide to Success with Agile. Als verantwortlicher Coach, Beraterin, Moderatorin, Sprecherin und Mentorin führt sie ihre Beiträge fort und wird ihrem Titel »Chief Connector« des Agile Fluency-Projekts gerecht. Diana lebt in Portland an der nördlichen Westküste der USA.

Shane Warden

Shane Warden ist ein führender Ingenieur und Autor, insbesondere der Co-Autor von The Art of Agile Development (1. Auflage) und Masterminds of Programming. Wenn er nicht arbeitet, hilft er dabei, Tieren ein gutes Zuhause zu geben.

In diesem Buch verwendete Konventionen

Zielgruppe

In den Kästchen für die Zielgruppe wird die Zielgruppe für jede agile Praktik angegeben.

In diesem Buch werden die folgenden typografischen Konventionen verwendet:

Kursiv

Kennzeichnet neue Begriffe, URLs, E-Mail-Adressen, Dateinamen und Dateierweiterungen.

Nichtproportionale Schrift

Wird für Programmlistings sowie innerhalb von Absätzen verwendet, um auf Programmelemente wie Variablen- oder Funktionsnamen, Datenbanken, Datentypen, Umgebungsvariablen, Anweisungen und Schlüsselwörter zu verweisen.

Hinweis-Kästen heben wichtige Begriffe hervor.

Nichtproportionale Schrift fett

Zeigt Codeergänzungen in laufenden Codebeispielen an.

Nichtproportionale Schrift durchgestrichen Stellt Codelöschungen in laufenden Codebeispielen dar.

Verwandte Themen

Diese Kästen verweisen auf verwandte Praktiken.

Codebeispiele verwenden

Zusätzliches Material steht unter https://www.jamesshore.com/v2/books/aoad2 zum Download bereit.

Bitte senden Sie eine E-Mail an [email protected], wenn Sie eine technische Frage oder ein Problem bei der Verwendung des Materials haben.

Dieses Buch soll Ihnen helfen, Ihre Arbeit zu erledigen. Wenn in diesem Buch Beispielcode angeboten wird, dürfen Sie diesen in Ihren Programmen und Ihrer Dokumentation verwenden. Sie müssen uns nicht um Erlaubnis bitten, es sei denn, Sie reproduzieren einen wesentlichen Teil des Codes. Wenn Sie zum Beispiel ein Programm schreiben, das mehrere Codeabschnitte aus diesem Buch verwendet, benötigen Sie keine Erlaubnis. Der Verkauf oder die Verbreitung von Beispielen aus Büchern aus dem dpunkt.verlag erfordert jedoch eine Genehmigung. Die Beantwortung einer Frage durch Zitieren dieses Buches und von Beispielcode erfordert keine Erlaubnis. Das Einbinden eines bedeutenden Teils des Beispielcodes aus diesem Buch in die Dokumentation Ihres Produkts erfordert eine Genehmigung.

Wir freuen uns über eine Namensnennung, verlangen sie aber im Allgemeinen nicht. Eine Quellenangabe umfasst in der Regel den Titel, den Autor, den Verlag und die ISBN. Zum Beispiel: »Die Kunst der agilen Entwicklung von James Shore (dpunkt.verlag). Copyright 2023 dpunkt.verlag GmbH, ISBN (Print): 978-3-86490-860-6.«

Wenn Sie der Meinung sind, dass Ihre Verwendung von Codebeispielen nicht in den Bereich der fairen Nutzung oder der oben genannten Erlaubnis fällt, können Sie uns gerne unter [email protected] kontaktieren.

Danksagung

Dieses Buch sammelt Inspirationen aus zu vielen Quellen, um sie alle aufzuführen. Ich habe so viele wie möglich in diesem Buch erwähnt, aber zweifellos einige vergessen. (Bitte nehmen Sie meine Entschuldigung dafür an.) Ich möchte insbesondere Kent Beck, Ron Jeffries und Ward Cunningham für die Entwicklung von Extreme Programming danken, mit dem ich meine agile Reise begonnen habe. Alistair Cockburn und sein Software Roundtable waren ein wichtiger Wegweiser zu Beginn dieser Reise, ebenso wie die lebhaften Debatten und Diskussionen im C2-Wiki von Ward Cunningham. Vielen Dank auch an Diana Larsen, mit der ich seit vielen Jahren zusammenarbeite und deren Perspektive so gut mit meiner übereinstimmt und sie ergänzt. Und natürlich Martin Fowler, dessen nachdenkliche Schriften mich seit vielen Jahren inspirieren.

Die Unterstützung von O’Reilly für diese [englische] Ausgabe war geradezu vorbildlich. Ich schulde Gary O'Brien, meinem Entwicklungsredakteur, der mir ständig Feedback und Unterstützung gegeben hat, ein großes Dankeschön. Mein Dank gilt auch Melissa Duffield, die dem Buch zum Erfolg verholfen hat; Ryan Shaw, der mich davon überzeugt hat, dass es Zeit für eine zweite Auflage war; Deborah Baker, die die Early-Release-Ausgaben des Buches vorbereitet hat; Suzanne Huston, die dafür gesorgt hat, dass die Leute das Buch kennen; Nick Adams und dem Team von O’Reilly Tools, die die Produktionspipeline aufgebaut und sich um meine esoterischen und pingeligen Formatierungswünsche gekümmert haben; Christopher Faucher, der die Umwandlung vom »Rohmanuskript« zum »fertigen Buch« überwachte; Tonya Trybula und Stephanie English, die meine grammatikalischen Macken korrigierten; Kate Dullea, die meine handgezeichneten Skizzen in tatsächlich verständliche Abbildungen umwandelte; und Estalita Slivoskey, die dafür sorgte, dass Sie alles im Index finden können.

Apropos Feedback: Ein besonderer Dank geht an meine Reviewer. Das Review wurde offen durchgeführt, und Dutzende von Menschen haben über 700 Feedback-E-Mails beigesteuert. Fast alle waren aufschlussreich und nützlich, und sie haben zu einem besseren Buch geführt. Mein Dank gilt auch denjenigen, die auf meine speziellen Bitten um Feedback geantwortet haben. Insgesamt möchte ich mich bedanken bei Adrian Sutton, Anthony Williams, Avi Kessner, Bas Vodde, Benjamin Muskalla, Bill Wake, Brad Appleton, C. Keith Ray, C. J. Jameson, Christian Dywan, David Poole, Diana Larsen, Diego Fontdevila, Emily Bache, Erik Peterson, »Evan M«, Franz Amador, George Dinwiddie, Gojko Adzic, Jason Yip, Jeff Grigg, Jeff Patton, Jeffrey Palermo, Johan Aludden, Ken Pugh, Krishna Kumar, Liz Keogh, Luiza Nunes, Marcelo Lopez, Markus Gärtner, Martin Fowler, Michal Svoboda, Nicolas Paez, Paul Stephenson, Peter Graves, Reuven Yagel, Ricardo Mayerhofer, Ron Jeffries, Ron Quartel, Sarah Horan Van Treese, Steve Bement, Thomas J. Owens, Todd Little und Ward Cunningham.

Ein besonderer Dank geht an die Reviewer, die alles gegeben haben, um fast jeden Teil des Buches zu lesen und zu kommentieren: Bas Vodde, Bill Wake, Ken Pugh, Martin Fowler und Thomas J. Owens.

Die erste Auflage profitierte ebenfalls von einem offenen Begutachtungsverfahren, und diese Vorteile kamen auch dieser Auflage zugute. Vielen Dank an Adrian Howard, Adrian Sutton, Ann Barcomb, Andy Lester, Anthony Williams, Bas Vodde, Bill Caputo, Bob Corrick, Brad Appleton, Chris Wheeler, Clarke Ching, Daði Ingólfsson, Diana Larsen, Erik Petersen, George Dinwiddie, Ilja Preuß, Jason Yip, Jeff Olfert, Jeffrey Palermo, Jonathan Clarke, Keith Ray, Kevin Rutherford, Kim Gräsman, Lisa Crispin, Mark Waite, Nicholas Evans, Philippe Antras, Randy Coulman, Robert Schmitt, Ron Jeffries, Shane Duan, Tim Haughton und Tony Byrne für ihre ausführlichen Kommentare sowie an Brian Marick, Ken Pugh und Mark Streibeck für ihre Kommentare zum fertigen Entwurf.

Abschließend möchte ich mich noch einmal bei meiner Frau Neeru bedanken. Dieses Mal wusstest du, worauf du dich einlässt, und trotzdem hat deine Unterstützung nie nachgelassen. Ohne dich hätte ich es nicht geschafft.

Vorwort der Übersetzer

Die erste Auflage von The Art of Agile Development ist ein Klassiker und leider gab es keine deutsche Übersetzung. Als wir erfuhren, dass James Shore an der zweiten Auflage arbeitet, waren wir begeistert und dachten sofort, dass es dieses Sammelwerk agiler Praktiken leicht zugänglich in deutscher Sprache geben sollte. Wir sind als Übersetzerteam davon fasziniert, wie umfassend das Buch ist und wie dabei trotzdem in allen Kapiteln auf die Grundideen und Prinzipien von Agilität verwiesen wird.

Natürlich stellte sich uns bei der Übersetzung die Frage, wie wir mit Fachbegriffen umgehen sollten. Wir entschieden uns dafür, englische Wörter, die bereits im Duden aufgenommen wurden und die Bedeutung passend wiedergeben, nicht zu übersetzen. Beim ersten Auftreten eines solchen Begriffs im Buch erklären wir diesen auf Deutsch.

Beim Übersetzen vom Englischen ins Deutsche standen wir dann vor der Herausforderung, wie wir in unserer Übersetzung Geschlechter gleichberechtigt ansprechen. Im Austausch mit dem Verlag entschlossen wir uns, die geschlechtsspezifischen Rollen im Text immer mal wieder abzuwechseln, um keine Stereotypen zu bedienen.

Wir hoffen, es ist uns gelungen, unsere Begeisterung für das Original in die deutsche Fassung zu übertragen.

Wolf-Gideon Bleek und Tim MüllerHamburg, September 2022

Teil I

Agilität verbessern

1Was ist Agilität?

Agilität ist überall und paradoxerweise nirgendwo.

In den 20 Jahren, in denen die Agilität wie eine Dampfwalze in das Bewusstsein von Softwareentwicklern1 eingedrungen ist, stieg die Zahl der Unternehmen, die sich selbst »agil« nennen, beachtlich an. Gilt dasselbe auch für die Anzahl der Teams, die wirklich ein agiles Vorgehen für ihre Arbeit verwenden? Leider nicht. Der inflationär verwendete Begriff »Agilität« ist enorm erfolgreich. Die tatsächlichen Ideen hinter Agilität jedoch werden meistens ignoriert.

Das müssen wir ändern!

1.1Die Entstehung von Agilität

In den 1990er-Jahren schien sich die Softwareentwicklung in einer Krise zu befinden. Tatsächlich wurde genau dieser Begriff verwendet: »die Softwarekrise«. Softwareprojekte überschritten ihre Budgets, waren verspätet und erfüllten nicht die an sie gestellten Anforderungen. Nach dem oft zitierten und ominös benannten »CHAOS Report« wurde nahezu ein Drittel der Projekte komplett abgebrochen [Standish 1994].

Agilität war nicht im Entferntesten eine Antwort auf diese Krise. Agilität war eine Antwort auf die Antwort.

Um die Softwareentwicklung unter Kontrolle zu bringen, hatten große Organisationen sehr detaillierte Prozesse definiert, die genau beschrieben, wie Software erstellt werden sollte. Alles wurde streng kontrolliert, damit (zumindest theoretisch) keine Fehler gemacht werden konnten.

Zuerst würden Business-Analysten verschiedene Stakeholder2 befragen, um die Anforderungen an das System zu dokumentieren. Im Anschluss würden Softwarearchitektinnen die Systemanforderungen lesen und mithilfe detaillierter Dokumentation sowohl den Entwurf der Komponenten als auch ihre Beziehung zueinander spezifizieren. Dann würden die Programmiererinnen diese Entwurfsdokumente in Quellcode umwandeln. In einigen Unternehmen wurde dies als eine Arbeit betrachtet, die wenig Fähigkeiten erfordert – also lediglich als eine mechanische Übersetzungsübung.

In der Zwischenzeit würden Fachleute aus der Testabteilung anhand derselben Dokumente Ablaufpläne für den Test anfertigen, damit nach der Programmierung Heerscharen von Testern das Programm manuell überprüfen und Abweichungen als Fehler dokumentieren können. Nach jeder Phase dieses Ablaufplans würden die einzelnen Schritte aufmerksam dokumentiert, überprüft und unterschrieben werden.

Ein solches auf Phasen basierendes Vorgehensmodell wurde »Wasserfallmodell« oder auch »Stage-Gate-Modell« genannt.3 Wenn das für Sie wie ein vorgeschobenes Argument klingt, nun ja, schätzen Sie sich glücklich. Nicht jedes Unternehmen benutzte in der 90er-Jahren solch einen auf Dokumenten und Phasen basierenden Prozess. Auf diese Art zu arbeiten, wurde jedoch als logisch und vernünftig angesehen. Natürlich sollten wir Anforderungen definieren, entwerfen, implementieren und testen. Natürlich sollten wir jede Phase dokumentieren. So funktionierte Entwicklung und wie sollten wir auch sonst erfolgreich sein?

1.2Aus der Krise geboren

Große Unternehmen haben ihre Prozesse bis ins kleinste Detail definiert. Rollen, Verantwortlichkeiten, Dokumentenvorlagen, Modellierungssprachen, Change Control Boards, die über Anpassungen von Anforderungen berieten, … jeder Aspekt im Ablauf der Entwicklung wurde streng definiert und überprüft. Wenn ein Projekt nicht erfolgreich war – und nach dem CHAOS Report war dies bei weniger als einem Sechstel der Fall –, lag es daran, dass die Prozessbeschreibung mehr Details brauchte, mehr Dokumente, mehr Freigaben. Daraus resultierte ein riesiger Berg an Dokumentation. Martin Fowler nannte es »Der große Donnerschlag« (»The Almighty Thud«) [Fowler 1997].

Dies war keine schöne Art zu arbeiten: bürokratisch und nicht den Menschen gerecht. Es schien, als hätten Fähigkeiten weniger Bedeutung als die Einhaltung von Prozessen. Und in der Programmierung zu arbeiten, fühlte sich an, als seien wir ein austauschbares Zahnrad in einer anonymen Maschine. Und es funktionierte nicht einmal besonders gut.

Also entwickelten verschiedene Personen Methoden für die Softwareentwicklung, die einfacher und schlanker waren und weniger Vorgaben machten. Diese wurden im Gegensatz zu dem schwergewichtigen Vorgehensmodell großer Unternehmen als »leichtgewichtige Methoden« bezeichnet. Diese neuen Methoden hatten Namen wie »Adaptive Software Development«, »Crystal«, »Feature-Driven Development«, »Dynamic Systems Development Method«, »Extreme Programming« und »Scrum«.

In den späten 90er-Jahren erregten diese Methoden starke Aufmerksamkeit. Insbesondere Extreme Programming führte zu einem explosionsartigen Anstieg des Interesses unter Programmierern. Im Jahr 2001 trafen sich 17 Befürworter dieser leichtgewichtigen Methoden in einem Skigebiet in Utah, um zu diskutieren, wie sie ihre Bemühungen vereinheitlichen könnten.

1.3Das Manifest für Agile Softwareentwicklung

Alistair Cockburn sagte später: »Ich persönlich habe nicht erwartet, dass diese Gruppe [von Menschen] sich jemals auf etwas Wesentliches einigen würde.«

Und tatsächlich erreichten sie nach zwei Tagen nur zwei Dinge: den Namen »Agilität« und eine Angabe von vier Werten (siehe Abb. 1–1). In den darauffolgenden zwölf Monaten erarbeiteten sie per Mail zwölf begleitende Prinzipien (siehe Abb. 1–2) [Beck 2001].

Das war das Agile Manifest. Es hat die Welt verändert. Oder mit Bezug auf die Aussage von Alistair Cockburn oben: Sie haben sich nach zwei Tagen auf wesentliche Dinge einigen können.4

Manifest für Agile Softwareentwicklung

Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

Individuen und Interaktionen mehr als Prozesse und WerkzeugeFunktionierende Software mehr als umfassende DokumentationZusammenarbeit mit dem Kunden mehr als VertragsverhandlungReagieren auf Veränderung mehr als das Befolgen eines Plans

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.

Kent Beck

Mike Beedle

Arie van Bennekum

Alistair Cockburn

Ward Cunningham

Martin Fowler

James Grenning

Jim Highsmith

Andrew Hunt

Ron Jeffries Jon

Kern

Brian Marick

Robert C. Martin

Steve Mellor Ken

Schwaber Jeff

Sutherland Dave

Thomas

Abb. 1–1Agile Werte5

Aber es gab nicht die eine agile Methode. Es gab sie nie und es wird sie nie geben. Agilität besteht aus drei Dingen: dem Namen, den Werten und den Prinzipien. Mehr gibt es nicht. Es ist nicht etwas, was Sie tun können, sondern eine Philosophie. Eine Art, über Softwareentwicklung zu denken. Wir können Agilität nicht »benutzen« oder »machen« … wir können nur agil sein oder eben nicht. Wenn das Team die Philosophie von Agilität verkörpert, ist es agil. Wenn es das nicht tut, dann ist es nicht agil.

Wenn das Team die Philosophie von Agilität verkörpert, ist es agil. Wenn es das nicht tut, dann ist es nicht agil.

1.4Die Essenz von Agilität

Martin Fowler hat Karriere gemacht, indem er für komplizierte Themen der Softwareentwicklung gut durchdachte und ausgewogene Erklärungen gibt. Seine Erklärung für »Die Essenz von agiler Softwareentwicklung« ist eine der besten:

Agile Entwicklung ist eher adaptiv als vorausschauend; orientiert sich eher an Menschen als an Prozessen6.

– Martin Fowler

Prinzipien hinter dem Agilen Manifest

Wir folgen diesen Prinzipien:

Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.

Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.

Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.

Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.

Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen, und vertraue darauf, dass sie die Aufgabe erledigen.

Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.

Funktionierende Software ist das wichtigste Fortschrittsmaß.

Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.

Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.

Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell.

Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.

In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann, und passt sein Verhalten entsprechend an.

Abb. 1–2Agile Prinzipien

Eher adaptiv als vorausschauend

Erinnern Sie sich an den »CHAOS Report«, der besagt, dass nur ein Sechstel aller Softwareprojekte erfolgreich ist? Der Report hatte eine sehr genaue Definition von Erfolg:

Erfolgreich abgeschlossen

Das Projekt wurde rechtzeitig und ohne Kostenüberschreitung sowie mit dem ursprünglich geforderten Funktionsumfang abgeschlossen.

Teilweise erfolgreich

Das Projekt wurde abgeschlossen, es kam jedoch zu Kosten- und Zeitüberschreitungen oder es wurde nicht der vollständig geplante Funktionsumfang erreicht.

Nicht erfolgreich

Das Projekt wurde abgebrochen oder niemals eingesetzt.

Diese Definitionen beschreiben das Mindset der Vorhersagbarkeit perfekt. Es geht bei allen Begriffen um die Einhaltung eines Plans. Hielten wir uns an die Versprechen, waren wir erfolgreich. Konnten wir die Versprechen nicht einhalten, waren wir es eben nicht, so einfach ist das.

Auf den ersten Blick ergibt das einen Sinn. Aber schauen Sie genauer hin. Es fehlt etwas. Ryan Nelson hat es im CIO Magazine geschrieben [Nelson 2006]:

Projekte, die die klassischen Kriterien für Erfolg – innerhalb der Zeit, des Budgets und der Spezifikationen zu sein – erreichen, können trotzdem Fehlschläge sein, wenn sie die Bedürfnisse der Benutzergruppe nicht treffen oder keinen Mehrwert zum Unternehmen beitragen. … In ähnlicher Weise können sich Projekte, die nach klassischen IT-Kennzahlen Fehlschläge sind, als Erfolg herausstellen. Dies ist der Fall, wenn sie trotz Nichteinhaltung von Zeit, Budget oder Spezifikation die Bedürfnisse ihrer Benutzergruppe treffen oder einen unerwarteten Mehrwert liefern.

Agile Teams bewerten ihren Erfolg anhand des Werts, den sie liefern. Nicht daran, ob sie einen Plan einhalten. Faktisch halten echte agile Teams immer danach Ausschau, den zu liefernden Wert zu maximieren, indem sie ihre Pläne anpassen.

Agile Teams bewerten ihren Erfolg anhand des Werts, den sie liefern. Nicht daran, ob sie einen Plan einhalten.

Schauen Sie noch einmal zurück auf das Agile Manifest (siehe Abb. 1–1 und Abb. 1–2) und nehmen sich einen Moment Zeit, um die agilen Werte und Prinzipien wirklich zu studieren. Wie viele von ihnen beziehen sich darauf, wertvolle Software zu liefern und anhand von Feedback anzupassen?

Orientiert sich eher an Menschen als an Prozessen

Schwergewichtige Prozesse versuchen, Fehler zu vermeiden, indem sie sorgfältig jeden Aspekt der Softwareentwicklung definieren. Durch das Einbringen von Intelligenz (»Smarts«) in den Prozess wurden individuelle Fähigkeiten weniger wichtig. In der Theorie könnten Sie den gleichen Prozess immer wieder mit unterschiedlichen Individuen anwenden und dabei dieselben Ergebnisse erreichen. (Wenn ich so darüber nachdenke, sind sie irgendwie zu denselben Ergebnissen gekommen. Nur nicht zu den Ergebnissen, die sie erhofft hatten.)

Agilität besagt, dass Individuen der wichtigste Faktor für den Erfolg in der Softwareentwicklung sind. Nicht nur ihre Fähigkeiten, sondern ihr gesamtes Wesen. Dazu zählt, wie gut sie als Team zusammenarbeiten, wie viele Ablenkungen ihnen begegnen und wie sicher sie sich fühlen, ihre Meinung zu äußern und zu vertreten und zu guter Letzt, ob sie durch ihre Arbeit motiviert sind.

Agilität besagt, dass Individuen der wichtigste Faktor für den Erfolg in der Softwareentwicklung sind.

Agile Teams haben einen Prozess – jedes Team hat ihn, selbst wenn er implizit ist –, aber der Prozess steht im Dienst der Individuen, nicht andersherum. Agile Teams sind für ihren eigenen Prozess verantwortlich und wenn sie einen besseren Weg entdecken, ihrer Arbeit nachzugehen, dann folgen sie ihm.

Schauen Sie noch mal auf das Agile Manifest (siehe Abb. 1–1 und Abb. 1–2). Welche Werte und Prinzipien beziehen sich darauf, Individuen an die erste Stelle zu setzen?

1.5Warum Agilität gewonnen hat

In den ersten zehn Jahren nach Veröffentlichung des Manifests erlebte Agilität enorm viel Kritik. Das Vorgehen sei »nicht diszipliniert« und würde »niemals funktionieren«. Weitere zehn Jahre später sind die kritischen Stimmen verstummt. Agilität war überall, zumindest dem Namen nach vertreten. Schwerfällige Wasserfallmethoden waren praktisch tot und jüngere Programmiererinnen können sich schwer vorstellen, dass irgendjemand jemals so gearbeitet hat.

Es ist nicht so, dass phasenbasierte Verfahren von Natur aus fehlerhaft sind. Sie haben sicherlich ihre Schwächen, doch wenn sie schlank sind und in einer gut verstandenen Domäne Verwendung finden, können sie funktionieren. Das Problem waren die schwergewichtigen Ansätze großer Unternehmen. Ironischerweise haben die Prozesse, die Probleme verhindern sollten, viele dieser Probleme ausgelöst.

Es ist schwierig, sich vorzustellen, wie Software funktionieren wird, bevor wir sie tatsächlich benutzen. Noch schwieriger ist es, wirklich jede Sache zu bedenken, die die Software können muss. Dies gilt umso mehr für Menschen, die nicht aktiv an der Softwareentwicklung beteiligt sind. Deshalb ist es entscheidend, so schnell wie möglich laufende Software zu den Nutzerinnen zu bringen. Wir brauchen die Rückmeldung darüber, was noch fehlt oder was nicht funktioniert. Danach passen wir auf der Grundlage der gewonnenen Erkenntnisse unsere Pläne an. Wie es im Agilen Manifest nachzulesen ist: Funktionierende Software ist das wichtigste Fortschrittsmaß. Lernen und das Reagieren auf Veränderungen sind der Kern von Agilität.

Lernen und das Reagieren auf Veränderungen sind der Kern von Agilität.

Bei diesen schwergewichtigen Prozessen wurde ein so großer Wert auf Kontrolle, Dokumentation und Freigaben gelegt, dass enorme Verzögerungen und ein hoher Overhead entstanden. Mit solchen Prozessen brauchte es Jahre, um funktionierende Software zu entwickeln, und bis kurz vor Projektende gab es noch nichts Konkretes vorzuweisen. Anstatt Veränderungen willkommen zu heißen, wurde aktiv daran gearbeitet, Veränderungen zu verhindern. Tatsächlich gab es sogar einen Bestandteil des Prozesses, das sogenannte Change Control Board, dessen Hauptaufgabe darin bestand, Änderungsanträge abzulehnen. (Oder, genauer gesagt: »Ja, aber das wird Sie etwas kosten.«)

All das führte zu Projekten, die sich jahrelang im Status der Entwicklung befanden, bevor sie etwas vorzuweisen hatten. Als sie es dann konnten, war es zu spät oder zu teuer, um noch Änderungen vorzunehmen. Schließlich lieferten sie Software aus, die nicht das tat, was der Kunde brauchte.

Ein typischer kostspieliger Fehler

Am 3. Februar 2005 erschien Robert S. Mueller III, Direktor der wichtigsten innerstaatlichen Sicherheitsbehörde der Vereinigten Staaten (Federal Bureau of Investigation, FBI) vor einem Untersuchungsausschuss des Senats, um zu erklären, wie das FBI es geschafft hatte, 104,5 Millionen Dollar7 zu verschwenden.

Doch wie kam es dazu, dass er sich dieser unkomfortablen Situation stellen musste? Im Juni 2001 hatte das FBI das Projekt VCF gestartet, dessen Aufgabe es war, die Verwaltungssoftware für Kriminalfälle der Behörde abzulösen. Vier Jahre später wurde das Projekt abgebrochen. Die Gesamtkosten beliefen sich bis dahin auf 170 Millionen Dollar, von denen 104,5 Millionen unwiederbringlich verloren waren.

Der Zeitplan für das Projekt VCF erzählt eine nur allzu bekannte Geschichte. Das Projekt wurde im Juni 2001 begonnen. Siebzehn Monate später, im November 2002, waren »solide Anforderungen« festgelegt worden. Ein Jahr später, im Dezember 2003, wurde die Software ausgeliefert. Allerdings entdeckte das FBI »sofort eine Reihe von Fehlern, die die Software unbrauchbar machten«. Der Dienstleister, der die Software gebaut hatte, erklärte sich bereit, die Fehler zu beheben, jedoch nur zu Kosten von zusätzlichen 56 Millionen Dollar und einem weiteren Jahr Entwicklungszeit. Letztendlich verzichtete das FBI darauf, die Fehler zu beheben, und jahrelange Arbeit wurde damit zunichtegemacht.

Auch wenn es eine Vielzahl von agilen Methoden gibt und es bei einigen eher darum geht, einen populären Namen zu verwenden als der dahinter stehenden Philosophie zu folgen, haben sie alle etwas gemeinsam: Sie konzentrieren sich darauf, Fortschritt sichtbar zu machen und Stakeholdern die Möglichkeit zu bieten, während des Prozesses Änderungen vorzunehmen. Das scheint eine Kleinigkeit zu sein, tatsächlich ist es aber unglaublich wirkungsvoll. Es ist der Grund, weshalb wir nichts mehr von der Softwarekrise hören. Softwareprojekte sind weiterhin verspätet und Kosten werden überschritten. Aber agile Teams zeigen ihren Fortschritt anhand von laufender Software und nicht anhand von Dokumenten, und zwar von Beginn an. Und das ist ein gigantischer Unterschied.

Agile Teams zeigen ihren Fortschritt anhand von laufender Software und nicht anhand von Dokumenten.

Agilität ist mehr, als nur für Sichtbarkeit zu sorgen. Doch diese eine Sache reichte aus, damit alle agil sein wollten.

1.6Warum Agilität funktioniert

Der erste durchschlagende Erfolg von Agilität war Extreme Programming (XP), eine Methode, die darauf ausgerichtet ist, Veränderungen zu begrüßen. Das ursprüngliche Motto lautete »Embrace Change«. XP vermischte eine gesunde Dosis davon, über Softwareentwicklung zu philosophieren, mit einer pragmatischen Betonung auf Veränderung. Wie im Vorwort des ersten XP-Buches zu lesen ist:

Kurz gesagt, verspricht XP, das Projektrisiko zu verringern, die Reaktionsfähigkeit auf geschäftliche Veränderungen zu verbessern, die Produktivität während der gesamten Lebensdauer eines Systems zu erhöhen und den Spaß an der Softwareentwicklung in Teams zu steigern – und das alles gleichzeitig. Wirklich. Hört auf zu lachen. [Beck 2000] (Übersetzung aus [Wolf et al. 2005])

–Extreme Programming Explained, 1. Auflage

Einige Leute lachten zwar, doch andere probierten es aus und stellten fest, dass XP – im Gegensatz zur gängigen Vorstellung darüber, wie Softwareentwicklung funktionieren sollte – wirklich seine Versprechen hielt. So kam es, dass sich XP trotz des Gelächters weiter verbreitete, und damit auch die Agilität.

XP war das ursprüngliche Aushängeschild von Agilität und lieferte das Gerüst für die Ideen und Terminologie, die noch heute verwendet werden. Doch die Stärke der agilen Community ist es, dass sie schon immer ein großer, bunter Haufen ist. Agilität ist nicht auf eine bestimmte Methode beschränkt, ständig erweitert sie sich, um neue Menschen und Ideen einzubeziehen. Lean Software Development, Scrum, Kanban, Lean Startup, DevOps und viele andere Methoden haben zu dem beigetragen, was wir heute als »Agilität« bezeichnen.

Werden die Ideen dieser Methoden in Kategorien aufteilt, entstehen fünf Kernkonzepte:

Vertrauen Sie auf Individuen

.Entwickeln Sie Prozesse, die auf die Bedürfnisse von Menschen Rücksicht nehmen. Legen Sie Entscheidungen in die Hände derer, die für diese Entscheidung am besten qualifiziert sind. Bauen Sie die Grundlage Ihrer Arbeit auf gesunden, kooperativen Beziehungen auf.

Liefern Sie Wert

.Holen Sie Feedback ein, experimentieren Sie und passen Sie Ihre Pläne an. Der Fokus sollte darauf liegen, Wert zu liefern. Verstehen Sie teilweise erledigte Arbeit als Kosten und nicht als Vorteil. Liefern Sie regelmäßig.

Vermeiden Sie Verschwendung

.Gehen Sie in kleinen, umkehrbaren Schritten vor. Nehmen Sie die Möglichkeit des Scheiterns in Kauf und gestalten Sie Ihre Pläne so, dass sie möglichst schnell scheitern. Maximieren Sie den Anteil nicht getaner Arbeit und geben Sie Durchsatz eine höhere Priorität als Effizienz.

Streben Sie nach technischer Exzellenz

.Ermöglichen Sie Agilität durch technische Qualität. Orientieren Sie sich beim Entwurf an dem, was bekannt ist, und nicht an dem, was angenommen wird. Starten Sie leichtgewichtig und erhöhen Sie die Komplexität nur, wenn es der tatsächliche Bedarf erfordert. Bauen Sie Systeme so, dass sie leicht erweiterbar sind – auch oder insbesondere in unvorhergesehene Richtungen.

Verbessern Sie Ihren Prozess

.Experimentieren Sie mit neuen Ideen. Funktionierende Ideen werden feinjustiert oder angepasst. Gehen Sie niemals davon aus, dass der etablierte, populäre Weg der beste für Sie ist.

Die Definition von Agilität ist im Agilen Manifest beschrieben. Dieses Manifest ist jedoch nur der Startpunkt. Agilität funktioniert, weil Menschen dafür sorgen, dass sie funktioniert. Sie nehmen die Ideen, die hinter Agilität stehen, denken sie weiter und passen sie auf die eigene Situation an. Und sie hören niemals mit dem Verbessern auf.

Agilität funktioniert, weil Menschen dafür sorgen, dass sie funktioniert.

1.7Warum Agilität scheitert

Agilität startete als eine Basisbewegung, vor allem getragen von Softwareentwicklern, die sich bessere Ergebnisse und eine höhere Lebensqualität wünschten. Als der Erfolg zunahm, veränderte sich die Dynamik von Agilität von den zugrunde liegenden Ideen zu einem Hype. Anstatt zu sagen: »Lasst uns bessere Ergebnisse erzielen, indem wir unsere Pläne anpassen und Individuen in den Mittelpunkt stellen«, sprachen die Führungspersonen der Unternehmen davon: »Alle reden über Agilität. Bringt mir etwas davon.«

Das Problem ist, dass es die eine Agilität, die gebracht werden könnte, nicht gibt. Es gibt nur eine Anhäufung von Ideen und spezifische agile Ansätze wie Extreme Programming und Scrum, die aufzeigen, wie Agilität eingesetzt werden kann. Mit der zugrunde liegenden Philosophie müssen wir uns trotzdem auseinandersetzen.

Vielen Organisationen ist diese zugrunde liegende Philosophie, Pläne anzupassen und Individuen in den Mittelpunkt zu stellen, sehr fremd.

Die Cargo-Kulte

Die Geschichte erzählt davon, dass in den 1940er-Jahren amerikanische Soldaten auf einer abgelegenen Insel landeten.8 Die Inselbewohner waren noch nie zuvor mit der modernen Zivilisation in Kontakt gekommen und waren erstaunt über die Männer und Materialien, die die Streitkräfte auf die Insel brachten. Sie beobachteten, wie die Truppen eine Landebahn und einen Tower errichteten, Kopfhörer aufsetzten und daraufhin metallene Vögel mit wertvoller Fracht vom Himmel schwebten. Als die metallenen Vögel landeten, wurde die wertvolle Fracht teilweise an alle Inselbewohner verteilt, was Wohlstand und Komfort brachte.

Eines Tages verließen die Truppen die Insel und die metallenen Vögel blieben aus. Die Inselbewohner vermissten nun ihre wertvolle Fracht und bauten ihre eigene Landebahn aus geflochtenem Bambus. Sie konstruierten eine hohe Plattform, ließen ihren Häuptling darauf stehen und Kokosnüsse tragen, die so geschnitzt waren, dass sie wie Kopfhörer aussahen. Doch trotz aller Bemühungen kehrten die großen Metallvögel nie zurück.

Die Tragödie des Cargo-Kults besteht darin, an den oberflächlichen, äußerlichen Anzeichen einer Idee festzuhalten, ohne zu wissen, wie die Idee tatsächlich funktioniert. In der Geschichte haben die Inselbewohner alle Elemente von Frachtabwürfen nachgebaut – die Landebahn, den Tower und die Kopfhörer –, aber sie haben nicht verstanden, welche umfangreiche Infrastruktur benötigt wird, um die Ankunft eines Flugzeugs zu ermöglichen.

Die gleiche Tragödie ereignet sich bei Agilität. Der Wunsch der Menschen ist die Fracht von Agilität: bessere Ergebnisse, mehr Sichtbarkeit, weniger geschäftsrelevante Fehler. Doch sie verstehen die dahinter liegende Philosophie nicht und selbst wenn sie sie verstünden, würden sie ihr oft nicht zustimmen. Sie wollen Agilität kaufen, aber eine Idee können Sie nicht kaufen.

Was sie kaufen können, sind die äußerlichen Anzeichen von Agilität: Standup-Meetings, Storys, Werkzeuge, Zertifizierungen! Es gibt viele Dinge mit dem Aufkleber Agilität und viele Menschen, die darauf aus sind, sie Ihnen zu verkaufen. Häufig wird das Ganze als »unternehmenstauglich« verkauft, als ein Weg, um Sorgen bezüglich Veränderungen zu beschwichtigen. Unbequeme Ideen wie »adaptives Planen« und »Menschen stehen im Mittelpunkt« werden ignoriert.

Und so bekommt man einen Cargo-Kult, d.h. Aktivitäten, aber keine Ergebnisse. Es fehlt die Agilität.

»In meiner alten Firma verschwendeten sie eine Menge Arbeitsstunden in Besprechungen.«

»[Agilität] hat einem kompletten Team (über 30 Leute) den Job gekostet, weil es fast ein Jahr lang so gut wie nichts produziert hat.«

»Das Einzige, was [Agilität] bedeutet, ist, dass Entwicklerinnen im Stich gelassen werden, wenn sich das Projekt ändert … und das einen Tag vor Auslieferung.«

– Echte Kommentare über Agilität aus dem Internet

Den Namen Agilität finden wir überall, die zugrunde liegenden Ideen nicht. Agilität ist zu einem Selbstläufer geworden: Für viele ist die einzige Form von Agilität, die sie kennen, Cargo-Kult-Agilität.

Es ist an der Zeit, diesen Umstand zu ändern. Im weiteren Verlauf des Buches zeige ich Ihnen, wie Sie die Ideen von Agilität tatsächlich in die Praxis umsetzen können. Passen Sie auf die Cargo-Kult-Agilisten auf, die das Buch unterwandert haben. (Sie finden sie auch unter dem Stichwort Cargo-Kult im Index.) Sie zeigen Ihnen, was Sie nicht tun sollten.

Sind Sie bereit? Dann lassen Sie uns loslegen.

2Wie können wir agil sein?

Wie kommen wir von der Ansammlung agiler Ideen zu tatsächlich funktionierenden agilen Teams?

Durch Praxis. Ganz viel Praxis.

2.1Agilität praktizieren

Jedes Team hat seine Art zu arbeiten – einen Prozess bzw. eine Methode –, der es folgt, selbst wenn es nicht formell aufgeschrieben wurde. Diese Methode steht für eine zugrunde liegende Philosophie der Softwareentwicklung, obwohl diese Philosophie selten artikuliert wird und nicht notwendigerweise in sich konsistent sein muss.

Um agil zu sein, müssen wir unseren Prozess so anpassen, dass er die agile Philosophie widerspiegelt. Das ist gleichzeitig einfacher und schwieriger, als es sich anhört. Es ist einfach, weil wir in den meisten Fällen mit einer der agilen Standardmethoden anfangen können, wie beispielsweise mit der in diesem Buch vorgestellten. Und es ist schwierig, weil wir unsere Arbeitsweise anpassen müssen und das bedeutet, viele Gewohnheiten zu ändern.

Um agil zu sein, müssen wir unseren Prozess so anpassen, dass er die agile Philosophie widerspiegelt.

Die agile Community nennt diese Gewohnheiten Praktiken. Ein Großteil dieses Buches ist ihnen gewidmet. Dazu zählen Dinge wie Planungsmeetings, automatische Builds und Stakeholder-Demos. Die meisten Praktiken kennen wir seit Jahrzehnten. Agile Methoden kombinieren sie jedoch auf einzigartige Weise, indem sie die Dinge betonen, die die agile Philosophie unterstützen, den Rest verwerfen und ein paar neue Ideen einbringen. Im Ergebnis entsteht ein schlankes, leistungsstarkes und sich selbst verstärkendes Paket.

Agile Praktiken dienen häufig zwei oder sogar drei Zwecken, indem sie mehrere Herausforderungen gleichzeitig lösen und sich gegenseitig auf clevere und überraschende Weise unterstützen. Wir können erst ein tieferes Verständnis einer agilen Methode erlangen, wenn wir sie bereits einige Zeit im Einsatz gesehen haben.

Es ist deswegen empfehlenswert, mit einer agilen Methode so zu starten, wie sie beispielsweise in einem Buch beschrieben wird, selbst wenn es verführerisch ist, sie gleich am Anfang an eigene Bedürfnisse anzupassen. Die Praktiken, mit denen wir uns am wenigsten auskennen, sind diejenigen, die wir am ehesten weglassen wollen. Aber es sind genau diejenigen, die wir am meisten brauchen, wenn wir wirklich agil werden wollen. Diese Praktiken verlangen von uns die größte Anpassung unserer Philosophie.

2.2Der Weg zur Meisterschaft

Um die Kunst der agilen Entwicklung zu meistern, brauchen wir praktische Erfahrungen bei der Anwendung einer klar definierten agilen Methode. Starten Sie mit Ihrem Vorgehen genau so, wie es in einem Buch beschrieben ist. Setzen Sie das Vorgehen, und zwar das vollständige Vorgehen, in der Praxis um und verbringen Sie mehrere Monate damit, die Umsetzung zu verfeinern und ein besseres Verständnis über die Wirkzusammenhänge zu entwickeln. Erst dann beginnen Sie damit, die Methode anzupassen. Wählen Sie dazu einen Bereich aus, der nicht rund läuft, entwickeln Sie einen begründeten Alternativvorschlag und wiederholen Sie den Vorgang.

Dieses Buch ist genau diesem Zweck gewidmet. Es enthält eine kuratierte Sammlung agiler Praktiken, die sich in der realen Welt bewährt haben. Um diese zu nutzen, um damit die Kunst der agilen Entwicklung zu meistern – oder einfach nur, um agile Praktiken erfolgreicher einzusetzen –, gehen Sie wie folgt vor:

Wählen Sie eine Gruppe von agilen Ideen aus, die Sie meistern möchten.

Kapitel 3

wird Ihnen bei der Entscheidung helfen.

Benutzen Sie so viele der korrespondierenden Praktiken wie möglich. Diese sind in

Teil II

bis

Teil IV

des Buches beschrieben. Agile Praktiken sind selbstverstärkend, deshalb ist es am besten, wenn Sie sie alle zusammen anwenden.

Wenden Sie die Praktiken rigoros und konsequent an. Falls eine Praktik nicht funktioniert, versuchen Sie, exakt nach der Beschreibung der Praktik vorzugehen. Teams, die sich neu mit agilen Methoden beschäftigen, tendieren dazu, die Praktiken nicht vollständig anzuwenden. Gehen Sie davon aus, dass es zwei bis drei Monate dauern wird, bis sich alle mit diesen Praktiken wohlfühlen, und weitere zwei bis sechs Monate, bis sie in Fleisch und Blut übergegangen sind.

Wenn Sie sich sicher sind, dass Sie die Praktiken richtig anwenden – auch hierfür sollten Sie mehrere Monate einrechnen –, beginnen Sie mit Veränderungen zu experimentieren. Jede Praktik in diesem Buch enthält einen Abschnitt, in dem erläutert wird, wie sie funktioniert und wie sie angepasst werden kann. Beobachten Sie jedes Mal, wenn Sie eine Änderung vornehmen, was passiert, und nehmen Sie weitere Verbesserungen vor.

Es gibt keinen abschließenden Schritt. Agile Softwareentwicklung ist ein kontinuierlicher Prozess des Lernens und der Verbesserung. Hören Sie niemals damit auf, zu üben, zu experimentieren und sich weiterzuentwickeln.

Abbildung 2–1 veranschaulicht den Prozess. Befolgen Sie zuerst die Regeln, dann können Sie die Regeln brechen und schließlich lassen Sie die Regeln hinter sich.1

2.3Wie es losgeht

Ihre ersten Schritte hängen davon ab, was Sie erreichen möchten. Werden Sie in ein bestehendes agiles Team kommen, Agilität in einem oder mehreren Teams einführen oder Ihre bestehenden agilen Teams verbessern?

In ein agiles Team kommen

Wenn Sie vorhaben, einem bestehenden agilen Team beizutreten, oder einfach nur mehr darüber wissen möchten, wie Agilität in der Praxis funktioniert, dann können Sie vorblättern zu den Teilen II bis IV des Buches. Jeder Teil beginnt mit einer Geschichte »Ein Tag im Leben«, die beschreibt, wie Agilität aussehen kann. Jedes agile Team ist anders und deswegen wird das Team, in das Sie kommen, nicht genau gleich sein, aber die Geschichten geben Ihnen eine gute Vorstellung davon, was Sie erwartet.

Nach dem Lesen der Geschichten können Sie zu den Praktiken wechseln, die Sie interessieren. Jede ist so geschrieben, dass sie für sich allein als Referenzbeschreibung steht. Falls Ihr Team eine Praktik verwendet, die nicht im Inhaltsverzeichnis aufgeführt ist, dann suchen Sie im Index. Es kann sein, dass sie unter einem anderen Namen zu finden ist.

Abb. 2–1Der Weg zur Meisterschaft

Agilität einführen

Wenn Sie Ihre Organisation darin unterstützen, agile Teams aufzubauen, oder diese überzeugen möchten, das zu tun, dann helfen die übrigen Kapitel des Teils I dabei, loszulegen. Benutzen Sie die folgende Checkliste, um den Überblick zu bewahren.

Stellen Sie zunächst sicher, dass Agilität für Ihre Organisation eine gute Wahl ist:

Wählen Sie eine Herangehensweise für Agilität, die Ihre Organisation unterstützen kann (siehe

Kap. 3

).

Bestimmen Sie, was Ihre Organisation braucht, damit Agilität erfolgreich eingeführt wird (siehe

Kap. 4

).

Besorgen Sie sich die Erlaubnis, Agilität auszuprobieren (siehe

Kap. 5

).

Falls Sie mehrere Teams haben, überlegen Sie sich, wie Sie Ihr Vorgehen skalieren (siehe

Kap. 6

).

In den Wochen, bevor ein Team Agilität ausprobiert:

Legen Sie fest, wer der Coach bzw. die Coaches für das Team sein werden, und bestimmen Sie mindestens eine Person, die als Produktmanagerin des Teams fungieren wird (siehe Abschnitt

»Komplettes Team« auf Seite 94

).

Sorgen Sie dafür, dass sich die Produktmanagerin des Teams mit dem Hauptsponsor des Teams und den wichtigsten Stakeholdern trifft, um eine Zielsetzung zu entwerfen (siehe Abschnitt

»Zweck« auf Seite 145

).