Agile Verträge E-Book

Fritz-Ulli Pieper

• Herausgeber: dpunkt.verlag
• Kategorie: Fachliteratur
• Sprache: Deutsch
• Veröffentlichungsjahr: 2017

Seitenzahl: 209

Beschreibung

Agile Softwareentwicklung ist in vielen Bereichen längst zum Status quo geworden. Dabei existiert häufig ein Auftraggeber-Auftragnehmer-Verhältnis, das vertraglich geregelt werden muss. Die Autoren beschreiben die vertragsrechtlichen Grundlagen bei agiler Entwicklung, die verschiedenen Varianten der Vertragsgestaltung sowie die einzelnen Vertragsformen mit ihren Eigenschaften, Funktionsweisen, Vorteilen und Risiken, wobei auch eine formalrechtliche Einordnung vorgenommen wird. Dabei wird insbesondere zwischen klassischen kostenorientierten Verträgen und nutzenorientierten Verträgen unterschieden. Im Einzelnen werden behandelt: - Schätzung, Planung und Controlling bei agiler Entwicklung - Festpreisverträge in den unterschiedlichen Ausprägungen: vom klassischen Festpreis bis hin zum agilen Festpreis (Money for Nothing, Change for Free) - Verträge mit Bezahlung nach Aufwand: neben dem reinen Time & Material-Vertrag auch Varianten wie Design to Cost und die Bezahlung nach Produktivität - Bezahlung pro Sprint: vom Festpreis je Sprint bis hin zu Modellen, in denen der Auftraggeber die Software nur bei Gefallen bezahlt (Pay what you get) - Nutzenorientierte Verträge, bei denen sich die Bezahlung am generierten Nutzen orientiert: Proviant & Prämie, Profit-Sharing, Pay per Use Dieses Buch richtet sich an diejenigen, die mit der Vertragsgestaltung für agile Entwicklungsprojekte befasst sind. Es verschafft den inhaltlich Verantwortlichen einen Einblick in die juristischen Hintergründe und gibt einen Überblick über die verschiedenen Möglichkeiten der Vertragsgestaltung.

Leseprobe

Fritz-Ulli Pieper ist Rechtsanwalt und Mitglied der Praxisgruppe »Technologie, Medien & Telekommunikation« bei der internationalen Wirtschaftskanzlei Taylor Wessing in Düsseldorf. Er berät nationale und internationale Mandanten in allen Belangen zum IT-, TK- und Datenschutzrecht mit besonderem Fokus auf das IT-Vertragsrecht. Er ist Absolvent des Masterstudiengangs »Medienrecht und Medienwirtschaft« der TH Köln, Redakteur und Kernteammitglied des Juraportals »Telemedicus – Recht der Informationsgesellschaft« sowie Herausgeber des Blogs nerdrecht.de und regelmäßig mit der Gestaltung komplexer Softwareverträge unter Berücksichtigung agiler Methoden befasst.

Dipl.-Inform. Stefan Roock zählt zu den Urgesteinen agiler Softwareentwicklung in Deutschland und arbeitet heute als Geschäftsführer und Management-Consultant bei der it-agile GmbH, die er 2005 mitgründete.

Bereits 1999 arbeitete Stefan Roock mit Extreme Programming. In der Folge machte er Erfahrungen mit den anderen agilen Ansätzen wie Scrum, Feature Driven Development und Kanban. Er hat dabei an agilen Vertragsgestaltungen aus Auftraggeber- und aus Dienstleistersicht mitgewirkt. Heute berät er Unternehmen bei agilen Veränderungsprozessen, zu denen auch immer wieder die Vertragsgestaltung gehört.

Fritz-Ulli Pieper · Stefan Roock

Agile Verträge

Vertragsgestaltung bei agiler Entwicklung für Projektverantwortliche

Fritz-Ulli Pieper

[email protected]

Stefan [email protected]

Lektorat: Christa Preisendanz

Copy-Editing: Ursula Zimpfer, Herrenberg

Satz: Nadine Thiele

Herstellung: Susanne Bröckelmann

Illustrationen: Henning Wolf, Stefan Roock und Claudia Leschik

Umschlaggestaltung: Helmut Kraus, www.exclam.de

Druck und Bindung: M.P. Media-Print Informationstechnologie GmbH, 33100 Paderborn

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-400-4

PDF

978-3-96088-169-8

ePub

978-3-96088-170-4

mobi

978-3-96088-171-1

1. Auflage 2017

Copyright © 2017 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Vorwort

Agile Softwareentwicklung hat in den letzten 15 Jahren eine deutliche Verbreitung in der Praxis erlangt. In den Anfangsjahren wurde agil primär im eigenen Haus entwickelt. Das E-Business gehörte dann zu den ersten Branchen, die sich vollständig der agilen Entwicklung verschrieben. Die eigenen Entwicklungsteams setzen Scrum sowie Extreme Programming und inzwischen auch Kanban ein.

Durch die immer weitere Verbreitung agiler Ansätze sind diese längst auch in den Unternehmen angekommen, die ihre Software nicht selbst entwickeln, sondern von Partnern entwickeln lassen. Damit bekommt die Frage der Vertragsgestaltung eine immer größere Bedeutung. Es wird relativ schnell klar, dass ein klassischer Festpreisvertrag mit vorab festgelegtem Funktionsumfang nicht besonders gut mit agiler Entwicklung harmoniert. Vielen erscheint dann eine Entwicklung nach Aufwand (Time & Material) als einzige Alternative. Das ist allerdings keineswegs so. Es gibt viele weitere Vertragsmodelle1. Einige sind schlicht Varianten des Festpreises oder der Entwicklung nach Aufwand. Andere gehen völlig neue Wege.

Dieses Buch diskutiert relevante Fragen der Vertragsgestaltung aus Sicht derjenigen, die agil entwickeln wollen, und stellt eine ganze Reihe möglicher Vertragsmodelle gegenüber. Dabei werden die jeweiligen Charakteristika diskutiert, die es erleichtern sollten, das passende Modell für den eigenen Kontext zu finden. Dabei erhebt dieses Buch keineswegs den Anspruch, das Thema Vertragsgestaltung abschließend zu behandeln. Die vorgestellten Vertragsmodelle können zur Inspiration dienen. Zusammen mit einschlägig erfahrenen Juristen sollten die relevanten rechtlichen Fragen diskutiert und geeignet im Vertrag abgebildet werden.

Insbesondere gilt für die dargestellten Praxisverträge, dass diese über mehrere Iterationen in der Praxis überarbeitet wurden. Nicht in jede Überarbeitung waren Juristen involviert. Wir raten daher davon ab, diese ohne juristischen Beistand 1:1 in den eigenen Vertrag zu übernehmen.

Zielgruppen

Das Buch richtet sich an diejenigen, die mit der Vertragsgestaltung für agile Entwicklungsprojekte befasst sind. Es verschafft den inhaltlich Verantwortlichen einen Einblick in die juristischen Hintergründe und gibt einen Überblick über die verschiedenen Möglichkeiten der Vertragsgestaltung.

Für Juristen können die Vertragsmodelle relevant sein, weil sie Aspekte adressieren, die aus Sicht der inhaltlich Verantwortlichen relevant sind.

So kann dieses Buch einen Beitrag dazu liefern, dass inhaltlich Verantwortliche und Juristen eine gemeinsame Sprache finden und Verträge formulieren, die den verschiedenen Interessen gerecht werden.

Danksagung

Dieses Buch existiert nur, weil neben den Autoren viele andere Menschen auf die eine oder andere Art mitgewirkt haben. Ohne Anspruch auf Vollständigkeit:

Christa Preisendanz vom dpunkt.verlag hat mich (Stefan) angestachelt, dieses Buch zu schreiben. Sie hat als Lektorin den Prozess der Buchentstehung wie gewohnt professionell und liebevoll begleitet.

Ich (Stefan) war der Meinung, dass juristischer Beistand dem Buch guttun würde. Wolfgang Wiedenroth hat mich dann mit Fritz zusammengebracht, und wir beschlossen, das Buchprojekt in Angriff zu nehmen.

Henning Wolf hat den Kontakt zu mehreren Unternehmen hergestellt, die ihre Verträge agiler gestaltet haben. So erhielten wir zusätzliche Inspirationen und Praxisbeispiele.

André Schnackenburg danken wir für die offene Darstellung seiner Erfahrungen aus dem Behördenumfeld.

Für Feedback und Anregungen danken wir Andreas Broeker, Bernd Schmid, Urs Reupke und Holger Tewis.

Außerdem danken wir den anonymen Reviewern des dpunkt.verlags für das wertvolle Feedback zu ersten Versionen dieses Buches. Namentlich bekannt sind uns Johannes Bergsmann, Ralph Miarka, Sven Röpstorff, Andreas Rüping, Jan Schnedler und Stephan Trahasch.

Und nicht zuletzt basiert das Buch zum Großteil auf Erfahrungen, die it-agile-Kollegen in den letzten 15 Jahren mit und bei Kunden gesammelt haben.

Fritz-Ulli Pieper, Stefan Roock

Düsseldorf, Hamburg, im Februar 2017

1.Einige skizziert Alistair Cockburn sehr knapp auf http://alistair.cockburn.us/Agile+Contracts.

Überblick über das Buch

Das Buch beginnt mit einer Einführung in agile Softwareentwicklung und dem dahinter stehenden Mindset (Kap. 1). Praktiker agiler Softwareentwicklung können dieses Kapitel getrost überspringen. Für Einkäufer und Juristen schafft das Kapitel die Grundlage zur Agilität, die für das Verständnis dieses Buches notwendig ist.

Kapitel 2 schafft einen Überblick zur Vertragsgestaltung für agile Softwareentwicklung. Es diskutiert das »Warum« der Verträge und klärt, welche »Warums« für agile Softwareentwicklung valide sind und welche gegen das agile Mindset verstoßen. Wir diskutieren, welche Aspekte der agilen Entwicklung wie in Verträgen abgebildet werden sollten. Auf dieser Basis wird eine Übersicht über verschiedene mögliche Vertragsformen gegeben. Dabei unterscheiden wir insbesondere klassische kostenorientierte Verträge (Time & Material, Festpreis) und nutzenorientierte Verträge (Profit-Sharing).

Danach führt Kapitel 3 in die formaljuristischen Grundlagen der Vertragsgestaltung ein. Juristen können dieses Kapitel überspringen. Insbesondere für Praktiker agiler Softwareentwicklung schafft das Kapitel hingegen die notwendige Grundlage, um die weiteren Kapitel verstehen zu können.

Für kostenorientierte Verträge spielen die Aufwände/Kosten natürlich eine wichtige Rolle. Wir diskutieren daher in Kapitel 4, wie Schätzung, Planung und Controlling bei agiler Entwicklung stattfindet. In diesem Zusammenhang spielen Möglichkeiten und Grenzen der Releaseplanung bei agiler Entwicklung eine wichtige Rolle.

Ab Kapitel 5 stellen wir die einzelnen Vertragsformen detailliert dar. Wir zeigen, was die Vertragsformen für die Praxis bedeuten und welche juristischen Aspekte zu beachten sind.

In Kapitel 5 beschäftigen wir uns mit Festpreisverträgen in den unterschiedlichen Ausprägungen, beginnend vom klassischen Festpreis bis hin zum agilen Festpreis (Money for Nothing, Change for Free).

Verträge mit Bezahlung nach Aufwand (Time & Material) sind Gegenstand von Kapitel 6. Neben dem reinen Time & Material-Vertrag sehen wir uns weitere Varianten an, z.B. die Bezahlung nach Produktivität.

Naheliegend sind Bezahlungen je Sprint. In Kapitel 7 werden solche Vertragsmodelle thematisiert, beginnend vom Festpreis je Sprint bis hin zu Modellen, in denen der Auftraggeber die Software nur bei Gefallen bezahlt.

Schließlich kommen wir in Kapitel 8 zu nutzenorientierten Verträgen, bei denen sich die Bezahlung am generierten Nutzen orientiert.

In Kapitel 9 fassen wir nochmal die Kernaussagen dieses Buches zusammen und geben einen Ausblick, wie sich das Vertragsthema rund um agile Entwicklung unserer Einschätzung nach entwickeln wird.

Bei der Darstellung von Agilität und Scrum haben wir uns besonders auf »Scrum – verstehen und erfolgreich einsetzen« von Stefan Roock und Henning Wolf gestützt und mit freundlicher Genehmigung des dpunkt.verlags Texte wiederverwendet (siehe [Roock & Wolf 2015]).

Inhaltsübersicht

1

Einführung in agile Softwareentwicklung

2

Verträge für agile Softwareentwicklung

3

Juristische Grundlagen

4

Schätzung und Planung

5

Festpreisverträge

6

Time & Material

7

Bezahlung pro Sprint

8

Nutzenorientierte Verträge

9

Zusammenfassung und Ausblick

Anhang

Literatur

Index

Inhaltsverzeichnis

1Einführung in agile Softwareentwicklung

1.1Das Agile Manifest

1.2Scrum-Ablauf

1.3Die Rollen

1.3.1Product Owner

1.3.2Entwicklungsteam

1.3.3Scrum Master

1.3.4Scrum-Team

1.3.5Kein Projektleiter in Scrum

1.4Meetings

1.4.1Sprint-Planung

1.4.2Daily Scrum

1.4.3Sprint-Review

1.4.4Sprint-Retrospektive

1.5Der Sprint

1.6Artefakte

1.6.1Product Backlog

1.6.2Sprint Backlog

1.6.3Lieferbares Produktinkrement

1.7Prinzipien

1.7.1Autonomes und cross-funktionales Team

1.7.2Inspect & Adapt (auch: empirisches Management)

1.7.3Timeboxing

1.7.4Return on Investment (ROI)

1.7.5Qualität einbauen

1.7.6Pull

1.7.7Chronisch unterspezifiziert

1.8Vorteile agiler Entwicklung

1.8.1Kürzere Time to Market

1.8.2Höhere Qualität

1.8.3Größere Effizienz

1.8.4Mehr Innovation

1.8.5Zufriedenere Mitarbeiter

1.9Das Kapitel in Stichpunkten

2Verträge für agile Softwareentwicklung

2.1Eignung agiler Ansätze

2.2Zweck von Verträgen für die Softwareentwicklung

2.2.1Wasserfallartiges Vorgehen

2.2.2Kaum Risikominimierung durch Festpreis

2.2.3Preis ist ein ungünstiges Auswahlkriterium

2.3Vertragsgestaltung für agile Entwicklung

2.3.1Unvollständige Funktionsbeschreibung

2.3.2Gemeinsames Verständnis

2.3.3Kooperative Problemlösung

2.3.4Rollen

2.3.5Meetings

2.3.6Artefakte

2.3.7Klauseln für agile Entwicklung im Vertrag

2.3.8Wie viel Vertrag?

2.3.9Beispielvertrag

2.4Vertragsformen

2.4.1Üblich: Festpreis oder Time & Material

2.4.2Probleme mit Festpreisverträgen

2.4.3Probleme mit Aufwandsprojekten

2.4.4Alternative Vertragsformen

2.5Das Kapitel in Stichpunkten

3Juristische Grundlagen

3.1Softwarevertragsrecht

3.1.1Vertragsrechtlichtliche Grundlagen

3.1.2Wichtige Vertragstypen im Softwarevertragsrecht

3.1.3Warum »vertragstypologische Einordnung«?

3.1.4Zwischenfazit

3.2Agiler Vertrag – agile Vertragsgestaltung

3.3Besonderheiten agiler Vorgehensweisen und rechtliche Auswirkungen

3.3.1Softwaretypische Interessenlage

3.3.2Agiles Mindset in Vertragsform gießen

3.3.3Vertragliche Einordnung bei agiler Softwareentwicklung

3.3.4Vertragsinhalte bei agilen Verträgen

3.4Überblick zu den einzelnen Vertragsformen

3.4.1Festpreisverträge

3.4.2Time & Material

3.4.3Bezahlung pro Sprint

3.4.4Nutzenorientierte Verträge

3.5Das Kapitel in Stichpunkten

4Schätzung und Planung

4.1Grundprinzipien agiler Schätzung

4.1.1Gewichtung mit Story Points

4.1.2Vorteile von Story Points

4.1.3Kritik an Story Points

4.2Releaseplanung

4.2.1Ermitteln der Velocity

4.3Release-Controlling

4.3.1Release-Burndown-Charts

4.4Das Warum der Releaseplanung

4.4.1Rendezvous-Planung

4.4.2Beispiel: Marketing

4.4.3Investitionsmanagement

4.5Das beste Releasemanagement ist Sprint-Management

4.6Das Kapitel in Stichpunkten

5Festpreisverträge

5.1Probleme mit Festpreisverträgen

5.1.1Drei Steuerungsgrößen: Funktionsumfang, Ressourcen, Zeit

5.1.2Grenzen der Planbarkeit

5.1.3Unternehmen müssen sich wandeln

5.1.4Interessenkonflikt zwischen Auftraggeber und Auftragnehmer

5.2Festpreis trotzdem mit agilen Techniken durchführen

5.2.1Aufwandsschätzung

5.2.2Schwächen der Planung identifizieren

5.2.3Change Requests

5.2.4Priorisierung der Features

5.2.5Vorteile agiler Techniken im Festpreis

5.2.6Erfahrungen

5.3Garantierter Maximalpreis

5.3.1Erfahrungen

5.4Garantierter Minimalumfang

5.5Agiler Festpreis

5.6Money for Nothing, Change for Free

5.6.1Erfahrungen

5.7Das Kapitel in Stichpunkten

6Time & Material

6.1Aufwandsprojekte: Time & Material

6.1.1Erfahrungen: Mindset

6.1.2Erfahrungen: Behörden

6.2Design to Cost

6.2.1Erfahrung: Entwicklung einer Webanwendung für eine Bank

6.3Bezahlung nach Produktivität

6.3.1Produktivität bewerten mit Function Points

6.3.2Erfahrung

6.4Das Kapitel in Stichpunkten

7Bezahlung pro Sprint

7.1Festpreis je Sprint

7.1.1Erfahrung: Behörden

7.2Pay what you get

7.2.1Erfahrungen

7.3Das Kapitel in Stichpunkten

8Nutzenorientierte Verträge

8.1Perspektivwechsel zu nutzenorientierten Verträgen

8.2Proviant & Prämie

8.2.1Mit Impact Maps Klarheit über den Nutzen schaffen

8.2.2Erfahrung: kritischer Termin

8.2.3Erfahrung: Behörde

8.3Profit-Sharing

8.3.1Erfahrungen

8.4Pay per Use

8.5Das Kapitel in Stichpunkten

9Zusammenfassung und Ausblick

9.1Kategorisierung der Vertragsformen

9.2Wiederkehrende Muster

9.3Ausblick

Anhang

Literatur

Index

1Einführung in agile Softwareentwicklung

Dieses Buch hat den Anspruch, generelle Aussagen über die Vertragsgestaltung für agile Entwicklung zu tätigen. Damit adressiert das Buch neben Scrum prinzipiell auch Kanban (siehe [Anderson 2010], [Burrows 2015]), Extreme Programming (siehe [Beck 2000]), Feature Driven Development (siehe [Palmer & Felsing 2002]), Crystal (siehe [Cockburn 2004]) etc.

In diesem Kapitel beschreiben wir neben den agilen Prinzipien das Scrum-Framework als den agilen Ansatz, der die größte Verbreitung erreicht hat. In den folgenden Abschnitten werden wir auch die Scrum-Nomenklatur verwenden (Sprint, Product Owner etc.). Die Übertragung auf andere agile Ansätze sollte problemlos möglich sein.

Wir diskutieren in diesem Kapitel außerdem, welche Vorteile durch agile Entwicklung erreicht werden können.

Dieses Kapitel richtet sich an Leser, die die Konzepte agiler Entwicklung und die Begrifflichkeiten von Scrum noch nicht kennen.

1.1Das Agile Manifest

Im Jahr 1997 veröffentlichte Ken Schwaber ein Paper mit dem Titel »SCRUM Development Process« auf der OOPSLA (siehe [Schwaber 1997]). Dieser Artikel war die erste veröffentlichte Beschreibung von Scrum für die Softwareentwicklung. Im Jahre 1999 erschien ein Artikel von Mike Beedle, Martine Devos, Yonat Sharon, Ken Schwaber und Jeff Sutherland auf der PLOP-Konferenz mit dem Titel »SCRUM: A Pattern Language for Hyperproductive Software Development« (siehe [Beedle et al. 1999]).

2000 brachte Kent Beck sein Buch »Extreme Programming Explained – Embrace Change« heraus (siehe [Beck 2000]) und begleitete die Markteinführung des Buches durch eine Reihe von Konferenzvorträgen. Extreme Programming (XP) nahm Grundgedanken von Scrum auf und ergänzte sie um Programmiertechniken, wie die testgetriebene Entwicklung und das Pair Programming. XP war für die damalige Zeit radikal und polarisierte: Der Großteil der Softwareentwicklungsbranche fand XP absurd oder utopisch. Eine kleine, aber sehr leidenschaftliche Gemeinschaft von Entwicklern sah darin jedoch einen notwendigen Paradigmenwechsel. Immer mehr Teams setzten XP erfolgreich ein, und das Interesse stieg immer weiter an. In diesem Zuge erlangte auch Scrum eine größere Bekanntheit. Die Community war sehr wissbegierig und experimentierfreudig und suchte stets nach neuen Inspirationen. So wurden weitere Ansätze mit ähnlichen Denkmodellen entdeckt oder entwickelt, wie z.B. Crystal (siehe [Cockburn 2004]) und Feature Driven Development (siehe [Palmer & Felsing 2002]).

Diese Ansätze wurden zunächst unter dem Sammelbegriff »leichtgewichtig« zusammengefasst. Im Jahre 2001 trafen sich einflussreiche Vertreter dieser »leichtgewichtigen« Ansätze (inkl. Ken Schwaber und Jeff Sutherland) in Snowbird und definierten das Agile Manifest, das gemeinsame Werte und Prinzipien festlegte (siehe [Agile Manifesto 2001]). Für die Werte wählten die Autoren Gegensatzpaare:

»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 Werkzeuge

Funktionierende Software mehr als umfassende Dokumentation

Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung

Reagieren 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.«

In klassischen Kontexten generieren die Dinge auf der rechten Seite subjektiv wahrgenommene Sicherheit. Wer sich an die Prozesse hält und die vorgeschriebenen Tools einsetzt, wer jede seiner Tätigkeiten haarklein dokumentiert, wer alle Eventualitäten in Verträgen berücksichtigt und wer sich an den Plan hält, kann bei Problemen nachweisen, dass er nicht Schuld war. Leider generieren wir auf diese Weise in komplexen dynamischen Märkten keinen Geschäftswert. In dynamischen Märkten brauchen wir die Flexibilität, die uns die Dinge auf der linken Seite geben.

Dieser Gegensatz erklärt zum Teil, warum die Einführung agiler Verfahren in der Praxis häufig so schwierig ist. Alle Beteiligten müssen ein Stück dieser »Sicherheit durch Statik« loslassen, um auf den Kunden und den Geschäftswert fokussieren zu können.

Ergänzt werden die vier Wertaussagen durch zwölf Prinzipien, die konkretisieren, wie die Werte sich auf die tägliche Arbeit auswirken:

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

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 Projekts 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.

Oder in einem Satz:

Agilität bedeutet:

Autonome Teams mit Business-Fokus, die ihren Prozess in Besitz und Verantwortung nehmen.

1.2Scrum-Ablauf

Scrum hat von den agilen Ansätzen in der Praxis die größte Verbreitung erlangt. Der generelle Ablauf von Scrum (Scrum-Flow) passt im Gegensatz zur Steuererklärung tatsächlich auf einen Bierdeckel. Den Beweis liefert Abbildung 1–11.

Abb. 1–1Der Scrum-Ablauf passt auf einen Bierdeckel.

Am Anfang steht eine Vision davon, was für ein Produkt eigentlich entstehen (oder was an einem vorhandenen Produkt geändert) werden soll. Aus der Vision werden konkrete Eigenschaften des Produkts abgeleitet, die der Product Owner im Product Backlog organisiert und priorisiert. Die Einträge im Product Backlog werden Product Backlog Items genannt. Der Product Owner ist für den wirtschaftlichen Erfolg des Produkts verantwortlich. Dieser Verantwortung folgend, wird er die Product Backlog Items im Product Backlog nach Geschäftswert priorisieren und sie in eine klare Reihenfolge bringen.

Die Entwicklung erfolgt bei Scrum in Iterationen fester und immer gleicher Länge, die Sprints heißen. Sprints sind maximal 30 Tage lang. Das Entwicklungsteamist für die Umsetzung der Product Backlog Items verantwortlich. Der Product Owner ist damit für das Was und das Entwicklungsteam für das Wie der Entwicklung verantwortlich.

Zu Beginn jedes Sprints führen Product Owner und Entwicklungsteam ein Sprint Planning (Sprint-Planung) durch, das der Scrum Master moderiert. In der Sprint-Planung wird festgelegt, welche Product Backlog Items in das Sprint Backlog übernommen werden und damit für diesen Sprint eingeplant werden. Dies erfolgt so, dass der Product Owner die Reihenfolge der Items vorgibt und das Entwicklungsteam entscheidet, wie viele Items in den Sprint passen.

Direkt nach der Sprint-Planung beginnt die Entwicklungsarbeit im Sprint, bei der das Entwicklungsteam sich selbst organisiert, also z.B. selbst entscheidet, welcher Entwickler als Nächstes welche Aufgabe angeht. Der Scrum Master unterstützt das Team bei der Selbstorganisation und sorgt dafür, dass Scrum effektiv angewendet wird. Dazu gehört unter anderem, dass der Scrum Master eine störungsfreie Umgebung schafft, in der das Entwicklungsteam fokussiert arbeiten kann.

Zur Abstimmung im Entwicklungsteam findet jeden Werktag während des Sprints das Daily Scrum statt. Im Daily Scrum trifft sich das Entwicklungsteam im Stehen für maximal 15 Minuten, um den Fortschritt im Sprint zu begutachten und die Arbeit im Team bis zum nächsten Daily Scrum zu organisieren.

Am Ende des Sprints liefert das Entwicklungsteam ein Produktinkrement ab. Das Produktinkrement soll auslieferbar sein (Shippable Product Increment). Es muss nicht zwingend ausgeliefert werden, muss aber die Qualität haben, dass es ausgeliefert werden könnte. Im Sprint-Review präsentiert das Entwicklungsteam die neuen Produkteigenschaften, um Transparenz über den Entwicklungsfortschritt zu schaffen und Feedback zum Produkt zu erhalten. Dazu sind neben dem Product Owner die relevanten Stakeholder (Kunden, Anwender, Management etc.) anwesend. Das Feedback der Stakeholder führt zu Änderungen am Product Backlog: Neue Einträge entstehen, existierende Einträge werden neu priorisiert oder aus dem Product Backlog entfernt.

Nach dem Sprint-Review findet die Sprint-Retrospektive statt, in der Scrum Master, Entwicklungsteam und Product Owner daran arbeiten, die Zusammenarbeit und den Prozess kontinuierlich zu verbessern.

Direkt nach einem Sprint beginnt der nächste Sprint. Es gibt bei Scrum keine Zeiten zwischen zwei Sprints. Auf die Sprint-Retrospektive eines Sprints folgt logisch betrachtet sofort die Planung des nächsten Sprints.

1.3Die Rollen

Scrum definiert die drei Scrum-Rollen Product Owner, Entwicklungsteam und Scrum Master.

1.3.1Product Owner

Der Product Owner ist für den (meist wirtschaftlichen) Erfolg des Produkts verantwortlich. Er kommt dieser Verantwortung in erster Linie dadurch nach, dass er den Produktnutzen durch die Priorisierung von Produkteigenschaften optimiert.

Zu seinen Aufgaben gehört laut Scrum Guide:

Produktwert und den Wert der Arbeit des Entwicklungsteams maximieren

Product Backlog pflegen

Klare Product Backlog Items formulieren

Product Backlog Items priorisieren/sortieren

Product Backlog sichtbar und transparent machen

Klarstellen, woran als Nächstes gearbeitet wird

Sicherstellen, dass das Entwicklungsteam die Product Backlog Items versteht

Der Product Owner soll eine Person sein und kein Komitee. Damit er seine Arbeit gut ausüben kann, muss er von der Organisation ermächtigt sein, Produktentscheidungen zu fällen. Nur so kann er unabhängig im Sinne des Produkts und seiner Wirtschaftlichkeit die besten Entscheidungen treffen.

1.3.2Entwicklungsteam

Das Entwicklungsteam besteht aus drei bis neun Mitgliedern. Es ist cross-funktional besetzt, enthält also alle Fähigkeiten (Skills), die nötig sind, um das Sprint Backlog in ein lieferbares Produktinkrement umzuwandeln. Insofern sind meist nicht nur Entwickler Teil des Entwicklungsteams, sondern auch andere Experten wie Tester, Designer oder Mitarbeiter aus dem Betrieb.

Die Hauptverantwortung des Entwicklungsteams besteht darin, ein technisch erfolgreiches und wartbares Produkt zu erstellen. In dieser Verantwortung muss und darf das Entwicklungsteam dem Wunsch des Product Owners nach mehr Backlog Items im Sprint widersprechen, wenn dadurch die Qualität leiden würde.

Das Entwicklungsteam organisiert sich und seine Arbeit selbst. Dabei sind alle gleich, es soll keine Titel und auch keine Subteams (die Entwickler, die Tester, die Frontend-Entwickler etc.) geben. Von der Selbstorganisation verspricht man sich bessere Entscheidungen, die die Qualität des Produkts auf Dauer gewährleisten. Natürlich wird es auch in Scrum-Entwicklungsteams Spezialisten mit besonderen Skills geben. Trotzdem wird die Verantwortung gemeinsam getragen.

Bei Überlastung des Product Owners übernimmt das Entwicklungsteam auch mal Aufgaben wie das Erstellen oder Verfeinern von Product Backlog Items.

1.3.3Scrum Master

Der Scrum Master sorgt für die erfolgreiche Anwendung von Scrum. Das bedeutet deutlich mehr, als nur den Zeigefinger zu erheben, wenn sich irgendwer nicht »Scrum-konform« verhält.

Konkret sieht der Scrum Guide folgende Aufgaben für den Scrum Master vor:

Er schützt das Scrum-Team vor unnötigen Einflüssen von außen.

Er moderiert bei Bedarf/Notwendigkeit die Meetings.

Er hilft dem Product Owner in methodischen Fragen.

Er coacht das Entwicklungsteam in Selbstorganisation und Cross-Funktionalität.

Er beseitigt Hindernisse (Impediments).

Er hilft der Organisation bei der Scrum-Einführung.

Er hilft anderen dabei, Scrum zu verstehen.

Er arbeitet an Organisationsveränderungen, die dem Team helfen, produktiver zu arbeiten.

Er arbeitet mit anderen Scrum Mastern zusammen, um die Effektivität von Scrum in der Organisation zu verbessern.

Der Scrum Master ist ein »Servant Leader« für das Scrum-Team: keiner, der formale Macht hat und die Ansagen macht, sondern einer, der sich ganz in den Dienst des Teams stellt und an dem arbeitet, was dem Team am meisten hilft.

1.3.4Scrum-Team

Der Scrum Guide kennt noch die Vereinigungsrolle Scrum-Team für Product Owner, Entwicklungsteam und Scrum Master. Dies macht insbesondere deutlich, dass die Scrum-Rollen nur gemeinsam ein erfolgreiches Produkt erstellen können. Insbesondere soll auch dem Eindruck entgegengewirkt werden, der Product Owner würde beim Entwicklungsteam etwas beauftragen und das Entwicklungsteam würde am Ende des Sprints »liefern wie bestellt«. Das Scrum-Team entwickelt gemeinsam und liefert gemeinsam ein wertvolles Produkt.

Scrum-Teams sollen möglichst unabhängig von anderen Teams sein. Größere Vorhaben können durchgeführt werden, indem mehrere Teams aufgesetzt werden, die sich untereinander koordinieren (siehe [Larman & Vodde 2015]).

1.3.5Kein Projektleiter in Scrum

Es gibt in Scrum-Teams keinen Projektleiter, der das Gesamtvorhaben in Arbeitspakete zerlegt und deren Umsetzung überwacht. Eine solche Rolle würde die Selbstorganisation des Entwicklungsteams erheblich behindern.

Die Aufgaben klassischer Projektleitung verteilen sich auf die Rollen Product Owner, Scrum Master und Entwicklungsteam. Man braucht in Scrum also immer noch Projektleitungstätigkeiten, aber keine Projektleiterrolle oder -position.

1.4Meetings

Scrum kennt vier Meetings: Sprint-Planung, Sprint-Review, Sprint-Retrospektive und Daily Scrum. Bei Bedarf kann sich ein Entwicklungsteam oder Scrum-Team natürlich auch zusätzlich im Sprint zusammensetzen und Dinge besprechen. Für das Funktionieren der Entwicklung nach Scrum sind aber keine weiteren Meetings notwendig.

1.4.1Sprint-Planung

Das Ziel der Sprint-Planung ist es, für den Sprint zwei Fragen zu beantworten:

Was werden wir inhaltlich in diesem Sprint tun (Product Backlog Items)?

Wie werden wir es tun (Plan für die Umsetzung)?

Die erste Frage wird im Wesentlichen durch die feste Reihenfolge der priorisierten Backlog Items vom Product Owner vorgegeben. Allerdings entscheidet das Entwicklungsteam, wie viele Items in den Sprint gezogen werden. So verhindert das Entwicklungsteam Überlastung und kann zuverlässig in hoher Qualität lieferbare Produktinkremente entwickeln. Methodisch schätzen dazu die meisten Teams spätestens im Sprint Backlog die anstehenden Product Backlog Items. So bekommen sie ein besseres Gefühl dafür, welche Menge an Product Backlog Items für den Sprint realistisch ist. Man spricht davon, dass das Entwicklungsteam eine Vorhersage (Forecast) abgibt, wie viel es schaffen kann. Diese Vorhersage mag nicht immer stimmen, aber Scrum-Teams sollten anstreben, dass ihre Vorhersagen meistens zutreffen. Angestrebt ist hier eine Verlässlichkeit ähnlich der Wettervorhersage: In der Regel sollte sie stimmen. Alle Beteiligten wissen aber, dass die Wettervorhersage mit Unwägbarkeiten behaftet ist, und niemand wird den Meteorologen dafür bestrafen, wenn die Vorhersage mal nicht stimmte.

Für die Schätzung, aber auch für die spätere Erledigung der Sprint Backlog Items und damit für die Beantwortung der Frage, wie die Product Backlog Items technisch umgesetzt werden, erstellt das Entwicklungsteam in der Sprint-Planung einen Plan. Viele Teams verwenden dazu einen Task-Breakdown für jedes in den Sprint gezogene Product Backlog Item. Wenn dieser Task-Breakdown vom gesamten Entwicklungsteam gemeinsam vorgenommen wird, erhöht sich seine Qualität, und die Wahrscheinlichkeit steigt, dass das Entwicklungsteam nichts Wesentliches übersehen hat.