Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.
- Herausgeber: Carl Hanser Verlag GmbH & Co. KG
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Deutsch
- Veröffentlichungsjahr: 2023
- Warum brauchen agil entwickelte IT-Projekte einen anderen Vertragsrahmen als Projekte nach der Wasserfallmethode?
- Wie ein partnerschaftliches Miteinander zu größeren Projekterfolgen führt
- Erfahren Sie, wie Sie Schritt für Schritt einen agilen Festpreisvertrag ausarbeiten, verhandeln und umsetzen
- Nutzen Sie die Vertragsvorlage als Anregung für Ihre eigenen agilen Festpreisverträge
- Reale Beispiele aus der Praxis illustrieren den Weg zum passenden Vertrag
- Ihr exklusiver Vorteil: E-Book inside beim Kauf des gedruckten Buches
Agiles Arbeiten ist in der Softwareentwicklung eine Selbstverständlichkeit und selbst Großkonzerne definieren im Zuge von Digitalisierungsinitiativen die Rahmenbedingungen ihrer Produktentwicklung neu. Sich mit den vertraglichen Bedingungen zwischen Kunden und Lieferanten unter agilen Vorzeichen auseinanderzusetzen, ist für den Projekterfolg ausschlaggebend und angesichts hochdynamischer Marktsituationen notwendiger denn je. Schließlich ist konstruktive Zusammenarbeit das maßgebliche Prinzip agiler Methoden und genau das wird von traditionellen Vertragsformen oft verhindert.
Agile IT-Projekte brauchen Verträge, die den Spagat zwischen festem Kostenrahmen und agiler Entwicklung – etwa mit Scrum – schaffen.
Der agile Festpreis balanciert die Interessen von Anbieter und Kunde und formt ein kooperatives Modell, indem er Grundsätze der Zusammenarbeit und Flexibilität in der Ausgestaltung von Anforderungen bestmöglich vereint.
Die 4. Auflage enthält neue Erfahrungsberichte und wurde um weitere Aspekte des Verhandelns sowie neue Praxisbeispiele ergänzt. Kunden, Lieferanten und Einkäufern bietet dieses Buch Best Practices, Vertragsvorlagen und Argumentarien.
AUS DEM INHALT //
- Wie der Agile Festpreisvertrag Sicherheit und Flexibilität vereinbart
- Die 6 Schritte zum neuen Vertragsmodell
- Muster für einen Agilen Festpreisvertrag
- Ausschreibung und Preisfindung
- Vor- und Nachteile verschiedener Vertragsformen
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 514
Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:
Ähnliche
Stimmen zu diesem Buch
„Interessant und notwendig für IT-Manager und IT-Juristen!“
Dipl.-Ing. Dr. iur. Dr. techn. Walter J. Jaburek, Allgemein beeideter und gerichtlich zertifizierter Sachverständiger für Informationstechnik und Telekommunikation, EDV-Vertragsberatung, Streitschlichtung, Sworn in expert on information technology and telecommunications, Expert on EDP-Contracts and EDP-Mediation
„Die positiven Aspekte der Agilität in Softwareentwicklungsprojekten vollständig in Kunden-Lieferanten-Verhältnissen zu etablieren, ist nach wie vor eine Herausforderung. Gerade in stark strukturierten Unternehmensorganisationen gilt es, die verschiedenen beteiligten Unternehmenseinheiten wie Fachabteilungen, Einkauf und IT überzeugend zusammenzubringen und den teils unterschiedlichen Zielvorstellungen gerecht zu werden. Für mich schließt das Buch genau die noch bestehenden Lücken und stellt sowohl einen methodisch ausgereiften und vollständigen Ansatz als auch wertvolle Praxiserfahrungen und beispielhafte Vorlagen vor. Zugleich räumt es fachlich fundiert und angenehm zu lesen mit einigen Vorurteilen zur vermeintlich optimalen Wasserfallmethodik und zur Agilität auf. Von der beschriebenen Methodik profitieren alle: der Lieferant und ganz besonders der Kunde solcher Projekte. Eine höhere Erfolgsrate von Projekten, nachhaltige und partnerschaftliche Arbeitsweisen sind letztendlich für alle ein Gewinn. Darüber hinaus gibt mir das Buch als Projektleiter weitere wertvolle Impulse, um die positiven Erfahrungen der Agilität auch außerhalb von reinen Implementierungsprojekten zu etablieren.“
Steffen Kießling, Manager Product Lifecycle Management, Bearing Point
„Agile Softwareentwicklungsmethoden sind in den letzten Jahren zum De-facto-Standard geworden. Durch sie ist die Entwicklung besser steuerbar, die Transparenz wird höher und man kann schnell auf Unvorhergesehenes reagieren. Interessanterweise werden viele Projekte aber nur ‚verdeckt’ agil entwickelt, während der zugrunde liegende Vertrag klassisch gestaltet ist, oft als Fixpreis mit fixem Scope. Ein Grund dafür ist, dass der Verkauf des Auftragnehmers und der Einkauf des Auftraggebers das Vertragswerk oft weitgehend losgelöst im Vorfeld der Projektabwicklung aushandeln, unter der Annahme, ein weitgehend spezifizierbares Werk zu einem vorab berechenbaren Preis einzukaufen. Dadurch wird das Potenzial eines agilen Vorgehens für beide Seiten gar nicht ausgeschöpft. Das vorliegende Buch sollte darum vor allem für Einkäufer und Verkäufer von Softwareprojekten eine Pflichtlektüre sein, um Projekte wirklich durchgehend ‚end to end’ agil abwickeln zu können. Auf der Basis eines Kooperationsmodells, für dessen Vertragswerk dieses Buch die passenden Hintergründe und Vorlagen beschreibt. Die Anwendung dieser Vorgehensweisen liefert für beide Seiten einen entscheidenden Wettbewerbsvorteil gegenüber dem (noch) De-facto-Standard der Vertragsgestaltung.“
Dr. Stefan Klein, Leiter Entwicklung, Infonova
Andreas OpeltBoris GlogerWolfgang PfarlRalf Mittermayr
Der agile Festpreis
Leitfaden für wirklich erfolgreiche IT-Projekt-Verträge
4., überarbeitete Auflage
Dr. Andreas Opelt, Managing Director Sales, Saubermacher AGKontakt: [email protected]
Boris Gloger, Gründer und Geschäftsführer borisgloger consulting GmbHKontakt: [email protected]
Dr. Wolfgang Pfarl, Sprecher der Geschäftsführung Post.Wertlogistik GmbHKontakt: [email protected]
Ralf Mittermayr, Vorstand der Saubermacher AGKontakt: [email protected]
Alle in diesem Werk enthaltenen Informationen, Verfahren und Darstellungen wurden nach bestem Wissen zusammengestellt und mit Sorgfalt geprüft und getestet. Dennoch sind Fehler nicht ganz auszuschließen. Aus diesem Grund sind die im vorliegenden Werk enthaltenen Informationen mit keiner Verpflichtung oder Garantie irgendeiner Art verbunden. Autoren und Verlag übernehmen infolgedessen keine Verantwortung und werden keine daraus folgende oder sonstige Haftung übernehmen, die auf irgendeine Weise aus der Benutzung dieser Informationen – oder Teilen davon – entsteht.Ebenso wenig übernehmen Autoren und Verlag die Gewähr dafür, dass die beschriebenen Verfahren usw. frei von Schutzrechten Dritter sind. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt also auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benützt werden dürften.
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.
Dieses Werk ist urheberrechtlich geschützt.Alle Rechte, auch die der Übersetzung, des Nachdruckes und der Vervielfältigung des Werkes, oder Teilen daraus, vorbehalten. Kein Teil des Werkes darf ohne schriftliche Einwilligung des Verlages in irgendeiner Form (Fotokopie, Mikrofilm oder einem anderen Verfahren), auch nicht für Zwecke der Unterrichtsgestaltung – mit Ausnahme der in den §§ 53, 54 URG genannten Sonderfälle –, reproduziert oder unter Verwendung elektronischer Systeme verarbeitet, vervielfältigt oder verbreitet werden.
© 2023 Carl Hanser Verlag München, www.hanser-fachbuch.deLektorat: Brigitte Bauer-SchiewekCoverkonzept: Marc Müller-Bremer, www.rebranding.de, MünchenCovergestaltung: Max KostopoulosTitelmotiv: © stock.adobe.com/FotoDesignPPSatz: Eberl & Koesel Studio, Kempten
Print-ISBN: 978-3-446-47397-3E-Book-ISBN: 978-3-446-47473-4E-Pub-ISBN: 978-3-446-47660-8
Inhalt
Titelei
Impressum
Inhalt
Vorwort
Danksagungen
Die Autoren
1 Agilität – was ist das?
1.1 Die Lösung – agil Arbeiten
1.2 Agile Entwicklung am Beispiel Scrum
1.2.1 Organisationsprinzipien und Rollen
1.2.2 Das Prozessmodell
1.2.3 Schätzen in Scrum
1.3 Agilität aus Sicht des Einkäufers
1.4 Agilität aus Sicht des Verkäufers
1.5 Die zwölf Prinzipien agiler Softwareentwicklung
2 Das fehlende Teil im Puzzle: der Agile Festpreisvertrag
2.1 Die Probleme herkömmlicher Festpreisverträge
2.2 Die Probleme von Time & Material-Verträgen
2.3 Etwas Neues: der Agile Festpreisvertrag
3 Was ist der Agile Festpreisvertrag?
3.1 Bisherige Ansätze
3.2 Der Agile Festpreisvertrag
3.2.1 Schritt 0 – Vorbereitung für ein gemeinsames Verständnis
3.2.2 Schritt 1 – Definition des Vertragsgegenstands
3.2.3 Schritt 2 – Detailspezifikation einer exemplarischen Menge an Referenz-User-Stories
3.2.4 Schritt 3 – Workshop zum Gesamtscope
3.2.5 Schritt 4 – Riskshare, Checkpoint-Phase und Ausstiegspunkte
3.2.6 Schritt 5 – Vereinbarung zur Scope-Governance
3.2.7 Schritt 6 – wie das Kooperationsmodell zum Motivationsmodell wird
3.2.8 Keine Mehrkosten durch den Agilen Festpreis
4 Muster für einen Agilen Festpreisvertrag
Vertrag über das Softwareprojekt
Appendix A: Kommerzielle Vereinbarungen
Appendix B: Technischer Umfang und Prozess
Appendix C: 12 Prinzipien der Kooperation
Appendix D: Qualitätsstandards und Definition of Done
5 Ausschreibung und Preisfindung für Projekte nach Agilen Festpreisverträgen
5.1 Was wird beim Agilen Festpreisvertrag ausgeschrieben?
5.2 Anforderungen an Ausschreibung und Umsetzung
5.2.1 Wettbewerb
5.2.2 Vergleichbarkeit und Transparenz
5.3 Schritte einer Ausschreibung mit Fokus auf den Agilen Festpreis
5.3.1 Interne Abstimmung
5.3.2 Vorbereitung der Ausschreibung
5.3.3 Ausschreibung
5.3.4 Zuschlag
5.3.5 Preisoptimierungsoptionen
5.3.6 Projekt- und Vertragsmanagement
6 Besondere Anforderungen an den rechtlichen Rahmen beim Agilen Festpreisvertrag
6.1 Bewegliches System
6.2 Gewährleistung und Schadensersatz
6.3 Zeitplan und Meilensteine
6.4 Eskalationspfad
7 Verhandlungsstrategie und Verhandlungstaktik
7.1 Zielstellung des Auftraggebers
7.2 Zielstellung des Auftragnehmers
7.3 Ziele und Bonifikation der involvierten Personen
7.4 Strategie für das Projekt und die Verhandlung
7.5 Taktik für die Verhandlung
7.6 Preisfindung
7.7 Abschluss der Verhandlung und Projekt-Steerings
8 Vor- und Nachteile Agiler Festpreisvertrage
8.1 Detailbetrachtung der Vor- und Nachteile
8.1.1 Budgetsicherheit
8.1.2 Anforderungsflexibilität
8.1.3 Detaillierte Anforderungen
8.1.4 Verhandlungsaufwand
8.1.5 Schätzsicherheit
8.1.6 Qualitätsrisiko
8.1.7 Preisüberhöhungstendenz
8.1.8 Chance auf Auftragserteilung
8.1.9 Kostenrisiko
8.1.10 Auftragssicherheit
8.1.11 Abnahmeaufwand
8.1.12 Kalkulationstransparenz
8.1.13 Fortschrittstransparenz
8.1.14 Permanentes Regulativ
8.1.15 Absicherung der Investitionen
8.1.16 Frühzeitiges Erkennen von Problemen
8.2 Zusammenfassung und Überblick
9 Toolbox für Agile Festpreisverträge
9.1 Vor der Verhandlung: Mit Argumenten Interesse wecken
9.2 Probleme des Gegenübers erkennen
9.3 Eine gemeinsame Sprache und gemeinsame Erfahrungen etablieren
9.4 Feature Shoot-out
9.5 Das Black-Swan-Szenario
9.6 Workshop zum Vertrags-Setup
9.7 Reports und Metriken
9.7.1 KISS Backlog View
9.7.2 Fokussieren: Es gibt ein Ziel!
9.8 Der Agile Festpreis für Großprojekte
10 Beispiele aus der Praxis
10.1 Beispiel 1: Entwicklung eines innovativen Produkts
10.1.1 Ausgangssituation
10.1.2 Vorgehen
10.1.3 Kritische Situationen
10.1.4 Projektabschluss
10.2 Beispiel 2: Entwicklung eines innovativen Produkts
10.2.1 Hintergründe zur Auswahl des Agilen Festpreises als Basis-Vertragsmodell
10.2.2 Ausgangssituation
10.2.3 Ausschreibungsphase
10.2.4 Verhandlungsphase
10.2.5 Spezielle Regelungen im Vertrag
10.2.6 Projektverlauf und Vorgehen
10.2.7 Kritische Erfolgsfaktoren
10.2.8 Resümee und Zusammenfassung
10.3 Beispiel 3: Softwareintegration in einem Migrationsprojekt
10.3.1 Ausgangssituation
10.3.2 Vertrag und Vorgehen nach herkömmlicher Methodik
10.3.2.1 Ausschreibungsphase
10.3.2.2 Verhandlung
10.3.2.3 Der herkömmliche Festpreisvertrag
10.3.2.4 Projektverlauf, die Teams und kritische Situationen
10.3.2.5 Projektabschluss
10.3.3 Vorgehen nach dem Agilen Festpreisvertrag
10.3.3.1 Ausschreibungsphase
10.3.3.2 Verhandlung
10.3.3.3 Projektverlauf, die Teams und kritische Situationen
10.3.3.4 Projektabschluss
10.3.3.5 Resümee
10.4 Beispiel 4: Entwicklung eines Softwareprodukts
10.4.1 Ausgangssituation
10.4.2 Vertrag und Vorgehen nach dem herkömmlichen Festpreisvertrag
10.4.2.1 Ausschreibungsphase beim Festpreisprojekt
10.4.2.2 Verhandlung
10.4.2.3 Der herkömmliche Festpreisvertrag
10.4.2.4 Projektverlauf, die Teams und kritische Situationen
10.4.2.5 Projektabschluss
10.4.3 Vertrag und Vorgehen auf Basis von Time & Material
10.4.3.1 Ausschreibungsphase
10.4.3.2 Verhandlung
10.4.3.3 Der Time & Material-Vertrag
10.4.3.4 Projektverlauf, die Teams und kritische Situationen
10.4.3.5 Projektabschluss
10.4.4 Vorgehen nach dem Agilen Festpreisvertrag
10.4.4.1 Ausschreibungsphase
10.4.4.2 Verhandlung
10.4.4.3 Der Agile Festpreisvertrag
10.4.4.4 Projektverlauf, die Teams und kritische Situationen
10.4.4.5 Projektabschluss
10.4.5 Resümee
11 Fragen und Antworten
12 Schlusswort
13 Literatur
Wir brauchen eine Antwort auf die Frage: „Wie kann man für agil durchgeführte Projekte einen Vertragsrahmen schaffen, der Einkäufern, Verkäufern und Projektmanagern die nötige Sicherheit gibt?“ Agile Methoden der Softwareentwicklung – und darunter vor allem Scrum – haben sich de facto durchgesetzt. Doch immer wieder steht sowohl bei Anbietern als auch bei Einkäufern agiler Softwareentwicklung die Frage im Raum, wie man aus der Falle des Festpreises ohne die Nachteile von Time & Material herauskommt. Wie kann man agile Softwareentwicklung einkaufen oder verkaufen? Unsere Antwort darauf findet sich in diesem Buch:
Der Agile Festpreis erklärt die vertraglichen Beziehungen zwischen Kunden und Lieferanten in agilen IT-Projekten.
Wir bringen einige Jahre an Erfahrung in IT-Projekten, der Arbeit mit Teams und der Gestaltung von Verträgen mit und haben die Herausforderungen unserer Kunden aus verschiedenen Blickwinkeln erlebt. Aus der Sicht des Projektleiters, Key Account Managers, Verhandlungsführers und Top-Managements des Lieferanten, aus der Perspektive des Einkaufs und Top-Managements des Kunden oder als Coach für die Projektumsetzung haben wir oft und intensiv über die Art der Umsetzung, über die Leistungsbeschreibung, den vertraglichen Rahmen und die Ausschreibung diskutiert. Wir kennen die Tücken traditioneller IT-Projekte nach der Wasserfallmethode und wir erleben seit einigen Jahren, wie agile Managementframeworks diese Tücken sichtbar machen und gleichzeitig neue, erfolgreiche Wege aufzeigen.
Die Definition des Leistungsgegenstands bis ins Detail – und das gleich zu Projektbeginn – ist bei Aufträgen im Rahmen von herkömmlichen Festpreisverträgen eine der größten Herausforderungen. Alternativ wich man bisher meist auf einen Time & Material-Auftrag aus – ein praktikabler Weg, um zum Beispiel bei einer Projektabwicklung nach Scrum das Maximum an Vorteilen herauszuholen. Bei IT-Projekten geht es aber leider nicht nur darum, dass sich eine Entwicklungsabteilung mit der Arbeitsweise wohlfühlt, es müssen auch noch andere Anforderungen berücksichtigt werden. So ist es auf Kundenseite meistens nötig, die Kosten in der Business-Case-Analyse zu fixieren, um das interne „Go“ zu bekommen. Wird dabei nach Time & Material beauftragt, muss man also viel eigenes Risiko auf sich nehmen.
Jochen Rosen, damaliger CIO der A1 Telekom Austria AG, sagte kurz nach der Entwicklung dieses Vertragsmodells in einem Gespräch mit uns im April 2012 zur Problematik herkömmlicher Vertragstypen in agilen Projekten:
„Die Unternehmen haben in den vergangenen Jahren die positiven Aspekte der agilen Entwicklung und Projektvorgehensweise zu schätzen gelernt und nutzen aktiv die impliziten Vorteile für Endkunden, Fachbereichsorganisationen und die IT-Organisation. Herkömmliche Umsetzungen nach Scrum basierten dabei meist auf Time & Material-ähnlichen Verträgen. Das Supply Chain Management, Accounting und die IT-Organisation standen dadurch immer wieder vor der Herausforderung, die Kleinteiligkeit der Vorgehensweise und die signifikanten Funktionserweiterungen, die erreicht wurden, entsprechend kapitalisierbar (CAPEX) darzustellen. Der Agile Festpreis, der einen Festpreis zu einem großen Werk darlegt und eben nur den genauen Detailumfang noch nicht beschrieben hat, kann hier die Lösung sein, damit Scrum auch bei diesen großen IT-Projekten Einzug hält!“
Mit dem „Agilen Festpreis“ führten wir bereits 2012 einen neuen Begriff in die Welt der IT-Verträge ein, der sich nun in gewissen Bereichen etabliert hat. Der Agile Festpreis löst den vermeintlichen Widerspruch zwischen Festpreis und agiler Entwicklung auf Basis eines passenden kommerziell-rechtlichen Rahmens. Diese Evolution des herkömmlichen Festpreisvertrags werden wir in den folgenden Kapiteln detailliert diskutieren und mit praxisnahen Beispielen erläutern.
Damit wollen wir uns einen Schritt weiter bewegen, als es bisher in der Literatur mit der Darstellung von Verträgen für Scrum oder Festpreise zum Beispiel mit Function Points passiert ist. Dieses Buch soll den gesamten Rahmen und die meisten – es wäre vermessen zu sagen: „alle“ – Probleme beschreiben, die es bei großen IT-Projekten gibt. Dabei soll jeder auf seine Rechnung kommen. IT-Einkäufer werden im Laufe der Kapitel erkennen, welche tragende Rolle sie für das Gelingen eines IT-Projekts spielen. Wir versuchen, auch für das Top-Management darzustellen, warum der Preis in einem agilen Projekt trotzdem fixiert werden kann und der Umfang des Projekts nicht aus dem Ruder läuft. Da jedes IT-Projekt anders ist, versuchen wir, mit einigen kurzen Beispielen und zwei sehr umfangreichen Darstellungen am Ende des Buchs die Anwendung in der Praxis darzustellen.
Dieses Buch haben wir geschrieben, weil wir es den Softwareentwicklungsteams, den Einkäufern und den Lieferanten einfacher machen wollen, damit IT-Projekte in Zukunft ihr gesamtes Erfolgspotenzial ausschöpfen können. Mit dem Agilen Festpreis wollen wir Ihnen ein Instrument anbieten, mit dem Sie in Ihrer Organisation die Voraussetzungen für das Gelingen schaffen können.
Für die vierte Auflage dieses Buchs haben wir die Erkenntnisse, welche sich bei uns weiterentwickelt haben, in das Buch einfließen lassen, aber vor allem von dort, wo dieses neue Prinzip des Agilen Festpreis Vertrags Einzug gehalten hat – aus der Praxis –, weitere Stimmen und Kommentare eingefangen, um sie den LeserInnen zur Verfügung zu stellen. Seit der ersten Auflage des Buchs hat sich ein Vorgehen, welches sich an die Prinzipien in diesem Buch hält oder zumindest stark anlehnt, bei vielen Kunden und Lieferanten etabliert und zu erfolgreicheren Projekten geführt. Diese neue Auflage nimmt auch zum ersten Mal dazu Stellung, wie dieser Vertrag aus Sicht der Aktivierung von Projekten im Rahmen der Bilanzierung zu bewerten ist – ein nicht unwichtiger Aspekt, den die Projektumsetzer oft erst zu spät bedenken.
Wir denken, dass speziell in der aktuellen Entwicklung eines immer schwierigeren Arbeitsmarktes die Talente noch weniger Motivation aufweisen, in den alten von Spannungen geprägten Lieferprozessen und Vertragskonstrukten zu arbeiten. Insofern geben wir dem Thema heute noch mehr an Aktualität denn je! Viel Spaß beim selbst Entdecken dieser alternativen Methode!
Andreas Opelt, Boris Gloger, Wolfgang Pfarl, Ralf Mittermayr
Wien und Graz, Herbst 2022
Neben einem ausgefüllten Arbeitstag, Familienleben, Hausbau, Geschäftsreisen und Vorträgen in kurzer Zeit ein Buch zu schreiben, ist eine ganz schöne Herausforderung. Dass wir trotzdem rechtzeitig den Zieleinlauf geschafft haben, verdanken wir der Unterstützung vieler Menschen, die uns zwar nicht die ganze Arbeit abnehmen konnten, aber sie zumindest erleichtert haben.
Wir bedanken uns bei folgenden Kollegen, Kunden, Managern und Experten: Dr. Dr. Walter J. Jaburek, DI Jochen Rosen, Mag. Birgit Gruber, Dr. Stefan Klein, Stefan Friedl, Jörg Steinbauer, Steffen Kiesling und Alexander Krzepinski, die mit ihren Reviews des Manuskripts unsere Überlegungen zu einzelnen Punkten kritisch hinterfragt und damit geschärft haben. Ihre Anmerkungen und Anregungen haben die Qualität des Buchs weiter gehoben. Außerdem haben sie uns jedes Mal aufs Neue davon überzeugt, wie dringend nötig ein Buch zu diesem Thema ist. Diese Aufmunterungen und positiven Worte haben uns durch die Phasen geholfen, in denen es um die Motivation nicht so gut bestellt war.
Die Grafiken wurden in gewohnter Effektivität von unserem Lieblingsgrafiker Max Lacher erstellt. Besuchen Sie selbst einmal illformation.net! Herzlichen Dank!
Dolores Omann hat mit viel Geduld und Kreativität unsere „spannenden“ Satzkonstruktionen entwirrt und verständlich formuliert. Ohne diese Hilfe wäre dieses Buch nie in dieser Prägnanz erschienen.
Außerdem bedanken wir uns für die wertvollen Diskussionen und Beiträge zum Thema Agile Softwareentwicklung und Agiler Festpreisvertrag bei Horst Mooshandl, Elmar Grasser, Gerald Haidl, Helmut Legat, Markus Hajszan-Meister, Heinz Zechner, Brigitte Cziglar-Benko-Eibel, Christoph Stromberger und Willibald Erhart. Sie beschäftigen sich seit Jahren in unterschiedlichen Bereichen mit diesem Thema und haben uns mit ihren Einschätzungen und Statements wertvolle Inputs für dieses Buch geliefert.
Ein herzliches Dankeschön geht natürlich nach München an Kristin Rothe, Brigitte Bauer-Schiewek und Irene Weilhart vom Carl Hanser Verlag. Sie haben die Entstehung dieses Buchs ermöglicht und vorangetrieben.
Ein herzliches Dankeschön auch an den Verlag Computer und Recht, der für die Recherche einige Ausgaben der Zeitschriften unentgeltlich zur Verfügung gestellt hat.
Der Grundsatz der agilen Teamarbeit lautet: Ein Kopf allein kann nie so gute Lösungen erarbeiten wie ein Team! In diesem Sinne bedanken wir uns bei den Teams von Infonova/Bearingpoint und borisgloger consulting, die seit Jahren das Thema Scrum und Agilität leben und vermitteln. Die Erfolge ihrer Arbeit sind mit ein Grund, warum ein Buch über den Agilen Festpreisvertrag überhaupt notwendig geworden ist.
Ohne den Rückhalt und die Geduld unserer Partner, Familien und Freunde hätten wir nie die Kraft und Zeit aufgebracht, Dutzende Wochenenden und Nächte mit der Ausarbeitung dieses Buchs zu verbringen. Danke!
Dr. Andreas Opelt konnte in seiner Karriere agile Methoden aus der Sicht des Entwicklers, Vertriebsleiters, Geschäftsführers und Vorstands kennenlernen sowie die unterschiedlichsten Herausforderungen bei der Umsetzung einer Vielzahl von (IT-)Projekten studieren. Seit 2019 ist er im Vorstand der Saubermacher Dienstleistungs AG.
Boris Gloger zählt weltweit zu den Scrum-Pionieren. Er entwickelt die Praktiken stets weiter und begleitet mit seinem Team von borisgloger consulting mit Sitz in Baden-Baden und Wien agile Unternehmenstransformationen.
Dr. Wolfgang Pfarl, LL. M., Jurist, hat als Leiter des Strategischen und Operativen Einkaufs unter anderem den IT-Einkauf der Österreichischen Post AG verantwortet und ist heute in der Geschäftsführung eines führenden Logistikunternehmens. Er hat langjährige Erfahrung in der TK- und IT-Branche im Bereich Einkauf und war mehrere Jahre als Lektor für Fachhochschulen tätig.
Ralf Mittermayr hat sich nach dem Abschluss des Studiums der Telematik-Wirtschaft an der Technischen Universität Graz auf die Konzeptionierung und Lieferung komplexer Softwarelösungen in der Banken-, Telekom- und Versorgerindustrie spezialisiert. Er war von 2005 bis 2013 Partner bei BearingPoint und ist seit 2014 im Vorstand und seit 2019 CEO der Saubermacher Dienstleistungs AG.
Das Problem
Tesla, Haier (der weltweit größte Hersteller von Waschmaschinen, Spülmaschinen etc.), Daimler und Handelskonzerne wie Otto, sie alle setzen auf agiles Arbeiten. Agiles Arbeiten entstand aus dem Bestreben von Software-Entwicklern in den 1990er-Jahren, möglichst schnell zu erfolgreichen Produkten zu kommen. Entstanden sind aus diesem Ansinnen mittlerweile viele Varianten erfolgreicher agiler Managementframeworks. Ihnen ist allen zu eigen, dass sie Variabilität während der Projekt- und/oder Entwicklungslaufzeit zulassen, es möglichst vermeiden, zu viel Arbeit vorab zu definieren, und sich immer wieder versichern, ob das Projekt- oder die Produktentwicklung noch immer das liefert, was gewünscht ist.
Obwohl wir hier ein Buch über Verträge für erfolgreiche IT-Projekte schreiben und auch diesen Fokus halten, möchten wir vorausschicken, dass die Ideen in diesem Buch natürlich für jedes Projekt genutzt werden können. Es ist im Grunde egal, welche Art von Projekt Sie mit agilen Methoden durchführen wollen: Mega- oder sogar Giga-Projekte, Raketen wie SpaceX bauen oder mit agilen Arbeiten die Verwaltungen effektiver arbeiten lassen.
Agile Methoden haben sich durchgesetzt – bei der Organisation von IT-Projekten sind sie zum Standard geworden. Selbst Start-ups werden heute mit agilen Management Frameworks, Lean Start Up und dem Framework Objectives and Key Results gemanagt. Große Organisationen setzen gleichzeitig auf Frameworks wie das Scaled Agile Framework oder andere Skalierungsverfahren wie MyScaled Agile.
Doch noch immer gibt es eine Schwachstelle beim agilen Arbeiten: die Zusammenarbeit von agilen Software-Dienstleistern mit den Fachbereichen großer Organisationen. Noch immer stehen viele Organisationen vor großen Fragezeichen, wenn es darum geht, Software-Entwicklung einzukaufen. Einerseits fällt es den Entwicklungsfirmen schwer, einen Preis für die Leistungen abzugeben, andererseits wollen die Fachbereiche, die nicht genau wissen können, was sie brauchen, agil arbeiten. Es klingt bestechend, während des Projekts auf Änderungen in den Anforderungen reagieren zu können.
Die immer schneller voranschreitende Digitalisierung erreicht jeden Industrie- und Arbeitsbereich. Ob wir es Industrie 4.0, oder Mobile first und 5G nennen, in fast allen Kontexten ist der Schlüssel zur Produktivitätssteigerung Software. Es entstehen dabei nicht immer neue Geschäftsmodelle, doch alle Prozesse werden in Zukunft digitalisiert werden.
Oft gelingt es, mit Standardsoftware und Software-As-a-Service-Lösungen auszukommen, doch gerade große Unternehmen kommen nicht umhin, sich auch diese Services anpassen zu lassen.
Daher ist es essenziell, dass Softwareprojekte das liefern, was gebraucht wird – und zwar rechtzeitig und in großen Mengen. Nach wie vor ist aber immer wieder von Projektdebakeln zu lesen: So stoppte die deutsche Agentur für Arbeit im Februar 2017 das Softwareprojekt ROBASO, in das bereits 60 Millionen Euro geflossen waren.1 Die beauftragte Software konnte der Komplexität der Kundenanliegen nicht gerecht werden. Neue Software werde nun „in überschaubaren Stufen mit begleitenden Anwendertests in der Praxis“ entwickelt. Sicher haben die Beteiligten auf beiden Seiten vor Beginn des Projekts intensiv miteinander geredet, Lastenhefte geschrieben und wasserdichte Verträge aufgesetzt. Doch was bringt das?
Tatsache ist: Softwareprojekte werden immer komplexer, denn es sind immer mehr Menschen und immer mehr Dienstleister involviert, obwohl viele Firmen dazu übergehen, Software-Entwickler in großer Zahl einzustellen. Doch der Bedarf ist so groß, dass viele Unternehmen entweder keine Entwickler bekommen oder schlicht nicht das Know-how haben, Software-Entwicklungsteams auszusteuern. Sie sind auf Dienstleister angewiesen, die für sie die benötigte Software entwickeln – und am Ende diese Software dann auch betreiben.
Agile Management-Frameworks wie Scrum oder Kanban, Design Thinking, Lean Start Up und Objectives and Key Results sind daher das Mittel der Wahl, um diese Projekte zu realisieren, und sie sind aus der Welt des neuen Arbeitens nicht mehr wegzudenken. Sie eignen sich dabei nicht nur für die Softwareentwicklung, sondern können domänenunabhängig eingesetzt werden, wie oben bereits erwähnt.
Wir erleben heute, dass auch Unternehmensprozesse, die zunächst einmal nichts mit den Projekten selbst zu tun haben – also strategischer Einkauf, Key Account Management, Demand Management, Entwicklung und Betrieb, ja HR und Marketing, selbst Sales und das Arbeiten in Call Centern – heute nach agilen Managementprinzipien geführt werden
Das heißt, jede Einkaufsabteilung und jede Verkaufsabteilung bei Software-Entwicklern müssen sich heute die Frage stellen: Wie kann man agile Projektdienstleister einkaufen? Wie können Verträge aussehen, die beiden Seiten die Sicherheit geben, dass einerseits nur bezahlt wird, was geliefert wurde, andererseits aber auch bezahlt wird, was geliefert wird.
Die kommerziell-rechtlichen Vereinbarungen mit Lieferanten und Partnern sind daher ein wesentlicher Teil dieser Rahmenbedingungen. Sie schaffen die Voraussetzungen dafür, dass die Leistungsträger in der Produktentwicklung ihre Aufgabe, „schnell Produkte zu produzieren“, effektiv erledigen können.
Nicht aufzuhalten
Der US-amerikanische Softwarehersteller VersionOne erhebt regelmäßig, wie weit verbreitet agile Methoden sind. Was lässt sich aus der „State of Agile Survey 2016“ ablesen, also aus den Antworten von mehr als 3800 weltweit verstreuten Umfrageteilnehmern aus der Softwareentwicklung?
Bereits 95 Prozent der Befragten geben an, in ihrer Organisation agil zu arbeiten. Fünf Jahre zuvor waren es etwas mehr als die Hälfte der Befragten.
Fast zwei Drittel der Umfrageteilnehmer gaben an, dass eine schnellere Produktlieferung bzw. Projektfertigstellung der Hauptgrund dafür sei, agil zu arbeiten.
43 Prozent der Interviewten gaben an, dass ihre Unternehmen mehr als die Hälfte der Projekte agil abwickeln.
Die Time-to-Market hat sich für 80 Prozent der Teilnehmer durch das agile Vorgehen deutlich verbessert.
Höhere Produktivität ist aus Sicht der Befragten einer der wesentlichsten Vorteile (85 Prozent). Den noch größeren Vorteil sehen sie aber darin, dass sich ändernde Kundenanforderungen bzw. Prioritäten besser gehandhabt werden können (87 Prozent) und der Projektfortschritt sichtbarer wird (84 Prozent).
Nicht nur die Mitarbeiter in den Teams verlieren zusehends ihre Scheu vor der Agilität. Auch das Management steht – trotz einer gewissen Furcht vor Skalierung, rechtlichen Vorschriften und mangelnder Dokumentation – den agilen Ansätzen immer offener gegenüber. In zwei Drittel der Fälle ging die Initiative sogar vom Management aus. Spannend ist die Erkenntnis, dass trotz der wachsenden Unterstützung durch das Management die größte Hürde bei der Umstellung auf „Agile“ nicht die Methodenkenntnis ist, sondern die interne Unternehmenskultur.
Wir sind der Meinung, dass speziell die fehlende organisatorische Einbettung, aber auch fehlende Ausschreibungs- und Vertragskonstrukte Gründe dafür sind, warum die Verbreitung innerhalb der Unternehmen nicht noch dramatischer ausfällt. So beobachten wir zum Beispiel, dass Individualentwicklungen öfter agil durchgeführt werden und im Gegensatz dazu Integrationsprojekte von Standardsoftware oft noch traditionell geliefert werden.
Damit agil Projekten gearbeitet werden kann, müssen viele Faktoren zusammenspielen. Alle Beteiligten benötigen ein Grundverständnis dafür, worum es bei agilem Arbeiten und agilem Management geht. Dabei zeigt sich dann an anderer Stelle, dass die Methodenkenntnis über agile Frameworks nicht ausreicht, denn es verändern sich Entscheidungsstrukturen und selbst die Rolle von Auftraggebern verändert sich. Daher sind in einem Projekt oft die interne Unternehmenskultur und die Änderung der internen Prozesse die größten Hürden bei der Umstellung auf das agile Modell.
Natürlich ändert sich die Unternehmenskultur nicht von heute auf morgen. Situationen wie die folgende sind daher bezeichnend: In einem unserer Projekte hat sich das Top-Management eines weltweit tätigen Konzerns dazu entschlossen, agile Entwicklungspraktiken einzusetzen. So weit, so gut. Denn oft genug ist gerade das Management am schwersten davon zu überzeugen, dass eine zum Großteil selbstorganisierte und selbstverantwortliche Arbeitsweise mit trotzdem klarer Zielstellung ganz enorme Produktivitätssprünge mit sich bringt. Allerdings stießen in diesem Fall die Mitarbeiter, die diesen Auftrag des Top-Managements erfüllen wollten, an die Grenzen der Kultur der Einkaufsabteilung. Die wollte nämlich keineswegs zulassen, dass Verträge mit Anbietern zumindest annähernd nach einem agilen Modell geschlossen wurden. Bei dieser Reaktion stellt sich Mitarbeitern sofort die Frage, ob der agile Ansatz für Ausschreibungen überhaupt Zukunft hat und im Konzern gelebt werden kann. Wie erfolgreich das agile Modell mit dem Lieferanten umgesetzt wird, hängt also sowohl von einem Lieferanten ab, der tatsächlich auch agil liefern kann, als auch von der Bereitschaft, im eigenen Haus anders auf Projekte und das eigene Involviertsein zu schauen und das eigene Verhalten zu verändern. Mittlerweile hat dieses Unternehmen übrigens mit dem Einkauf neue Möglichkeiten erarbeitet, um agile Projekte durchführen zu können.
Traditionelle Prozesse stehen neuen Anforderungen im Weg
Einkaufs- und Verkaufsprozesse sind bis dato meist an den traditionellen wasserfallbasierten Prozessmodellen der Projektdurchführung und Produktentwicklung ausgerichtet. Das gilt sogar für Organisationen, die bereits seit Jahren agil arbeiten. Denn oft ist die eigentliche Lieferung sogar bereits gut agil unterwegs, doch die Rahmenprozesse engen diese Entwicklungen ein und lassen daher echte Innovationen nur bedingt zu.
Das wissen viele IT-Dienstleister und sie arbeiten damit. So sind Vergabeverfahren vieler Organisationen zwar scheinbar darauf ausgerichtet, nicht nur den günstigsten Anbieter zu wählen – in der Praxis gewinnt dennoch fast immer der Anbieter mit dem günstigsten Preis. Das führt dann dazu, dass anschließend gerade die Argumente des agilen Arbeitens gegen den Kunden eingesetzt werden. Natürlich wehren sich die Einkäufer großer Organisationen dagegen und kreieren Abwehrstrategien mit neuen Prozessen und neuen, härteren Verträgen und noch ausgeklügelteren Ideen. Doch es nützt in der Regel alles nichts – die Auswahlverfahren werden nur immer teurer. Wenn es helfen würde, spräche ja nichts dagegen – aber leider bleibt der Projekterfolg schlussendlich oft aus.
Dramatisch ist nun, dass einige unangenehme Tatsachen zum Thema Projekterfolg gerade im IT-Umfeld schon seit Jahrzehnten bekannt sind:
1. Neue Produkte werden nicht wasserfallbasiert entwickelt, effektive Projekte nicht wasserfallbasiert abgewickelt. Das haben Nonaka und Takeuchi bereits 1986 gezeigt (Takeuchi und Nonaka 1986).
2. Selbst Winston Royce, Schöpfer des Wasserfallmodells, sagte, dass der von ihm skizzierte Prozess so nicht funktioniert und mindestens zwei Mal durchgeführt werden müsse (Royce 1970).
3. Untersuchungen der NASA haben 1996 die Aussagen des Softwareingenieurs Barry Boehm aus den 1980er-Jahren bestätigt, dass eine Schätzung, die zu Beginn des Projektlebenszyklus (also noch vor der Anforderungsphase) vorgenommen wurde, im Durchschnitt mit einem Unsicherheitsfaktor von 4 belastet ist (Boehm 1981). So kann zum Beispiel die „tatsächlich“ benötigte Zeit eines Projekts viermal so lang oder auch nur ein Viertel so lang sein wie ursprünglich geschätzt.
Vor allem in großen Organisationen kommt noch eine weitere Rahmenbedingung für das Aufsetzen von Verträgen mit IT-Dienstleistern zum Tragen, die sich negativ auf die Produktivität von Softwareentwicklungsprojekten auswirkt: Für Projekte gibt es Budgets. In der Regel müssen diese Budgets sehr früh vergeben werden – oft sogar ein Jahr, bevor das Projekt starten soll. Fachabteilungen definieren also bereits, wie viel Geld ausgegeben werden darf, ohne dabei zu wissen, welches Projektziel das Unternehmen tatsächlich verfolgt. Da noch niemand wissen kann, was in zwölf Monaten konkret angefordert werden soll, wird möglichst umfangreich definiert. Und so werden Funktionalitäten angefragt, die von den Dienstleistern bewertet und mit einem Preis versehen werden. Das erweitert den Umfang des Projekts und das einmal grob geschätzte Projekt wird unversehens teurer.
Einkäufer, Verkäufer, Fachbereiche – alle tun sie ihr Bestes, damit die Projektkosten nicht aus dem Ruder laufen und Zeitpläne eingehalten werden. Doch die Regel ist, dass trotz all dieser Bemühungen mehr als 60 Prozent aller IT-Projekte scheitern. Viele große IT-Projekte überziehen ihre Budgets um bis zu 400 Prozent und liefern dabei nur ein Viertel der gewünschten Funktionalität. Solche „Black Swans“ können Unternehmen ruinieren, wie es Bent Flyvbjerg und Alexander Budzier in der Harvard Business Review vom September 2011 schreiben (Flyvbjerg und Budzier 2011). Der Begriff „Black Swan“ wurde übrigens vom Finanzmathematiker Nassim Nicholas Taleb geprägt. Mit ihm beschreibt er – positive wie negative – Ereignisse mit großen Auswirkungen, die selten und nicht vorhersehbar sind, rückblickend gesehen dennoch nicht unwahrscheinlich waren.
Zu den Details hinter den Analysen und Fakten über IT-Projekte gibt es annähernd so viele Diskussionen wie zum Erfolg von IT-Projekten selbst. Unterm Strich sind aber alle Studien einer Meinung. Machen wir eine kleine Tour d’Horizon der unangenehmen Ergebnisse.
Die Standish Group sammelt Informationen zu IT-Projekten und deren Problemen und veröffentlicht regelmäßig den Chaos Report. Ein Projekt wird als erfolgreich definiert, wenn Budget und Zeit eingehalten und die benötigten Features und Funktionen umgesetzt wurden. Kritische Stimmen vermissen bei dieser Betrachtung Parameter wie Qualität, Risiko und Kundenzufriedenheit. Wichtiger als solche Haarspaltereien ist aber, wie sich der gemessene Projekterfolg in den letzten Jahren entwickelt hat.
Tabelle 1.1 Ergebnisse des Chaos Reports 1994–2012
Zwar hat sich die Situation im Verlauf der letzten 21 Jahre deutlich verbessert. Noch immer liegt der Prozentsatz der erfolgreichen Projekte aber deutlich unter 50 Prozent (Standish Group 2015). Was sind laut Studie die Faktoren für erfolgreiche IT-Projekte?
a) Intensives Einbinden von Benutzern
b) Top Management Sponsorship des Projekts
c) Optimierung (Priorisierung) und fähige Projektmitarbeiter
Umgekehrt formuliert bzw. mit den Hauptgründen des Scheiterns des Chaos Reports kombiniert, würde die Hitliste der Stolpersteine so lauten:
d) Fehlende Zusammenarbeit
e) Unwissen über den Vertragsgegenstand – der Kunde weiß nicht, was er eigentlich will, oder er hat die falschen Ressourcen im Projekt eingesetzt.
f) Das, was man zum Teil noch gar nicht weiß, wird dementsprechend unvollständig oder fehlerhaft beschrieben.
Allerdings muss man sich auch ansehen, wie sich die erfolgreichen 29 Prozent zusammensetzen. Nur 11 Prozent der Projekte, die nach der Wasserfallmethode abgewickelt wurden, waren erfolgreich, im Gegensatz zu 39 Prozent bei den agilen Projekten. Mit anderen Worten: Die Wahrscheinlichkeit, dass Ihr Projekt erfolgreich sein wird, ist bei agilem Vorgehen mehr als dreimal so hoch!
Unangenehme Erkenntnisse über den Projekterfolg finden sich auch in einer Studie der TU München (Wildemann 2006): Nur knapp die Hälfte aller IT-Vorhaben des untersuchten Zeitraums waren erfolgreich. Entweder dauerten die Projekte länger als geplant, kosteten wesentlich mehr oder es kam am Ende ein ganz anderes Ergebnis heraus. Andere Projekte mussten sogar abgebrochen und die Kosten entsprechend abgeschrieben werden. Der renommierte IT-Sachverständige Dr. Walter Jaburek (allgemein beeideter und gerichtlich zertifizierter Sachverständiger für Informationstechnik und Telekommunikation) meinte dazu in einem Interview, das wir mit ihm führten:
„Hier ist meine Erfahrung deckungsgleich mit der Studie der Standish Group: Die meisten Projekte dauern dreimal so lange wie geplant, kosten daher auch etwa 2,8-mal so viel wie geplant und bringen dann 70 bis 80 Prozent der geplanten Funktionalität. Der Vertrag und das Verhandlungsgeschick entscheiden dann, wer die 180 Prozent zahlt bzw. trägt.“
Assure Consulting hat im Jahr 2007 veröffentlicht, dass die meisten IT-Projekte an unklaren Zielen, unrealistischen Zeitvorgaben und fehlender Abstimmung der Projektbeteiligten scheitern (Assure Consulting 2007).
Die Berater von Roland Berger kommen in einer Studie zu der Erkenntnis, dass 20 Prozent aller IT-Projekte abgebrochen werden (Roland Berger Strategy Consultants 2008). Jedes zweite Projekt überschreitet den vereinbarten Zeitrahmen oder wird teurer als geplant. Essenziell ist der Hinweis, dass die Wahrscheinlichkeit des Scheiterns mit der Dauer und Komplexität von Projekten steigt.
Diverse Studien und die Erfahrung von Experten geben Anlass zu der Vermutung, dass sich die Anforderungen an IT-Projekte um bis zu drei Prozent pro Monat ändern. Worauf außerdem in der Literatur immer wieder verwiesen wird: Die Anforderungen an eine Softwarelösung können nicht deterministisch beschrieben werden.
Vielleicht erleben Sie in Ihrer eigenen täglichen Praxis auch, dass IT-Projekte oft einen Schritt vorwärts und zwei zurück machen. Möglicherweise liegt es an einem oder mehreren der folgenden Gründe:
Die Benutzer werden nicht einbezogen.
Es gibt keine einfache, klare Vision, die das Projektziel beschreibt.
Es gibt nur wenig Teamarbeit.
Die Projekte werden immer komplexer.
Die in einem Projekt eingesetzten Technologien werden immer vielseitiger.
Systeme sind immer stärker verteilt.
Eine funktionale und transparente Fortschrittskontrolle ist oft nicht möglich.
Probleme sind selbst für Experten auf allen Seiten (Lieferant, Berater, Kunde) oft schwer vorherzusehen.
Die Planung der Projekte ist sehr komplex, manchmal fast unmöglich.
Das Wissen ist schlecht verteilt.
Das ist eine immense Verschwendung von Ressourcen, Zeit, Geld und Kreativität. Wir alle – Kunden wie Dienstleister – müssen aufhören, IT-Projekte ineffektiv zu gestalten und eine schlechte Qualität zu liefern.
Die Lösung: Wir müssen – nicht nur bei Software- oder IT-Projekten – agil arbeiten, das heißt iterativ und inkrementell, teambasiert, den Kunden im Fokus, und bei großen Projekten müssen wir auf die Selbstorganisation von Netzwerken setzen. Das Ziel muss sein, schnell und zuverlässig funktionierende Software zu liefern, die unsere Bedürfnisse, damit sind die des Kunden und des Users und die aller anderen Stakeholder gemeint, erfüllt.
Ein Anspruch, der nicht so weit hergeholt ist, denn einige Softwareentwickler haben sich schon in den 1990er-Jahren daran gemacht, die Softwareentwicklung zu entrümpeln. Sie haben nicht funktionierende Management- und Vorgehensmodelle ignoriert und neue geschaffen, weil sie wieder sinnvoll arbeiten wollten – der Leidensdruck war einfach schon zu groß. Sie überlegten, wie ein neues Projektmanagement und neue Entwicklungsmethoden aussehen sollten, damit Teams gemeinsam mit ihren Projektmanagern kontinuierlich liefern können. Die folgenden Seiten sollen Ihnen dabei helfen, ein erstes Bild darüber, nach welchen Prinzipien anders gearbeitet wird, zu gewinnen, und sie sollen Ihnen Lust auf mehr machen.
1.1Die Lösung – agil ArbeitenUm exemplarisch aufzuzeigen, an welchen Stellen Umdenkprozesse in den Einkaufs- und Verkaufsprozessen stattfinden müssen und wie sich das auf die Vertragsgestaltung auswirkt, orientieren wir uns in in dieser Auflage des Buchs nicht mehr am gängigsten agilen Management-Framework Scrum, sondern wir zeigen die Prinzipien auf, die in Ihrem Projekt erfüllt werden müssten, um erfolgreich zu sein.
Beginnen wir unsere Reise durch die agile Vertragsgestaltung daher wieder am Ursprung – beim Agile Manifesto. Wir sind der Meinung, dass Sie dieses kurz einmal zur Kenntnis nehmen sollten, um später zu verstehen, wieso wir bei der Darstellung des agilen Festpreises so auf die Präambel des Vertrags drängen.
Agile Manifesto
Wir zeigen bessere Wege auf, um Software zu entwickeln, indem wir es selbst tun und auch anderen dabei helfen.
Durch unsere Arbeit haben wir folgende Werte zu schätzen gelernt:
Individuen und Interaktionen mehr als Prozesse und Werkzeuge.
Funktionierende Software mehr als umfassende Dokumentation.
Zusammenarbeit mit den Kunden mehr als Vertragsverhandlungen.
Reagieren auf Veränderung mehr als das Befolgen eines Plans.
Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, messen wir den Dingen auf der linken Seite größeren Wert bei.
(http://www.agilemanifesto.org; Übersetzung der Verfasser)
Was bedeuten diese Werte in der Zusammenarbeit zwischen Kunden und Lieferanten, wenn man den Werten auf der linken Seite einen höheren Wert beimisst?
Individuen und Interaktionen mehr als Prozesse und Werkzeuge
1. Wie oft erleben Sie, dass man nur einmal hätte miteinander reden müssen, um Wege abzukürzen, effektiver miteinander zu arbeiten und schneller ans Ziel zu kommen?
2. Wie oft erleben Sie, dass die Ihnen zur Verfügung stehenden Prozesse Ihre Arbeit eher behindern, als sie zu erleichtern?
Agile Projektteams setzen auf das miteinander Kommunizieren und die deutliche transparente Fortschritts-, aber auch Problemkommunikation. Kurz gesagt, es geht um das ständige miteinander Reden und das sich ständig Austauschen.
Unser Tipp: Nehmen Sie die Aussage des Satzes so, wie sie dort steht. Man geht davon aus, dass Menschen nur erfolgreich sind, wenn sie miteinander reden. Und zwar innerhalb von Prozessen, die hilfreich sind, und durch Tools unterstützt, die Ihnen tatsächlich dabei helfen, produktiv zu arbeiten.
Es gilt aber auch: Es muss gestattet sein, existierende Prozesse zu hinterfragen und möglicherweise Prozesse auszusetzen, damit etwas Neues, etwas anderes entstehen kann.
Funktionierende Software mehr als umfassende Dokumentation
Dokumentieren Sie gerne? Schreiben Sie gerne Berichte und notieren Sie leidenschaftlich gerne, was passiert ist? Wie viele Dokumente und dazugehörende Prozesse in Ihrem Unternehmen sind nicht aktuell, weil sie nur für den Aktenschrank geschrieben wurden?
Und machen wir uns nichts vor: Gerade in der Softwareentwicklung werden viele, sehr viele Seiten Dokumentation produziert. Allerdings bewirken sie nicht automatisch, dass gute oder bessere Software geschrieben wird.
Sehr viele Menschen, allen voran Softwareentwickler, sehen Dokumentation als ein nutzloses Nebenprodukt, das ihnen nicht zwangsläufig dabei hilft, ihre Arbeit sinnvoll zu machen – denn sie tut es tatsächlich nicht.
Dokumentation ist nur dann sinnvoll, wenn ein anderer Mensch seine Arbeit im Anschluss schneller und effizienter erledigen kann.
Es gibt eine Form von Dokumentation, die wir alle für sinnvoll halten, ja die sogar als wichtige Kommunikation notwendig ist, zum Beispiel Arztbriefe oder die Baupläne eines Architekten.
In der Softwareentwicklung ist eine Dokumentation sehr sinnvoll, die es dem Kunden erlaubt, die Arbeiten an seinem Softwareinkrement an einen anderen Dienstleister weiterzugeben, wenn die Beziehungen zum ersten Dienstleister abgekühlt sind oder dieser Dienstleister beschließt, ein Produkt aufzulassen. Diese Dokumentation stellt sicher, dass Menschen weitermachen können, wo andere aufgehört haben.
Deshalb: Dokumentation, die notwendig ist, muss geschrieben werden. Und zwar vom Scrum-Team selbst oder in einer großen Entwicklungsabteilung von den Support-Teams, die die Scrum-Teams dabei unterstützen.
Was will dieser Satz des Agile Manifesto sagen? Am Ende darf der Projekterfolg nicht nur daran gemessen werden, ob der Bauplan erstellt wurde oder die Diagnose des Arztes vorliegt. Das Dokument ist nicht das Produkt. Also misst sich auch der Produkterfolg nicht daran, ob die laut Prozess korrekten Dokumente geschrieben wurden.
Agile Projekte messen ihren Fortschritt ausschließlich am Umfang und an der Qualität der gelieferten Software.
Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlungen
Die nächste Falle: Nein, dieses Prinzip bedeutet nicht, dass keine Verträge geschlossen oder ausgehandelt werden sollen. Wir verstehen dieses Prinzip so: Natürlich benötigt man Verträge. Gemeinsam klar und deutlich festzulegen, wie man miteinander arbeiten will, ist sinnvoll. Zu regeln, wie die Bezahlung ablaufen soll, wie viel gezahlt werden soll, darüber nachzudenken, was passiert, wenn eine der Parteien nicht mehr so mitarbeitet, wie man ursprünglich wollte – all das muss durchdacht werden.
Doch selbst der beste Vertrag muss nicht dazu führen, dass man auch gemeinsam am Projekterfolg Teil hat. Gerade in der Softwareindustrie werden IT- und Softwareentwicklungsabteilungen gerne als Dienstleister gesehen. Auch die Lieferanten von Software werden klassisch in die Ecke des Dienstleisters gestellt – und dort bleiben sie stehen, mit zu wenigen Informationen, um ihre Arbeit zielgerichtet und erfolgreich durchzuführen. Allerdings zeigt sich in der Softwareentwicklung seit Jahren, dass nur jene Projekte erfolgreich verlaufen, bei denen die, die eine Software schreiben, und die, die das Produkt haben wollen, eng zusammenarbeiten. Immer wieder wird deutlich, dass Kunden die Produkte, die sie wirklich brauchen, nur bekommen, wenn sie sich einbringen und aktiv mitwirken. Wenn sie während des Projekts als Ansprechpartner zur Verfügung stehen. Die Funktionalitäten, die ihnen das Arbeiten erleichtern, erhalten sie dann, wenn sie den Softwareentwicklungsteams zur Seite stehen. Aus unserer eigenen Erfahrung können wir sagen: Wenn sich die Vertragspartner verstehen und gemeinsam Erfolg haben wollen, dann ist die Wahrscheinlichkeit extrem hoch, dass das gelieferte Produkt zufriedenstellend ist. Somit ist es wichtig, die Mitwirkungspflichten des Auftraggebers umfassend zu beschreiben und den kooperativen Ansatz zu unterstreichen, ohne dem Auftragnehmer die Verantwortung für die Qualität zu nehmen.
Stichwort Respekt: Das oben Gesagte weist darauf hin, was dieses Prinzip aussagen will. Wir gehen respektvoll miteinander um. Der Kunde versucht nicht, den Dienstleister auszuquetschen, und der Dienstleister will den Kunden nicht über den Tisch ziehen.
Mitch Lacey, Agile Practitioner und Consultant, erzählte bei der Agile Tour 2011 in Wien die folgende Geschichte über ein Gespräch zwischen Kunde und Lieferant: Der Kunde kam zu ihm und erklärte etwa eine halbe Stunde sein Projekt. Im Anschluss wollte er wissen, was denn so etwas kosten könnte. Daraufhin sagte Mitch: „Ich werde Ihnen diese Frage nicht beantworten, weil Sie von mir eine professionelle Antwort erwarten sollten. Nach 30 Minuten habe ich nicht genügend Informationen, um irgendeine sinnvolle Aussage treffen zu können. Das wäre absolut unprofessionell. Ich mache Ihnen einen anderen Vorschlag: Sie arbeiten zwei Wochen mit uns, und wenn Ihnen gefällt, was Sie bekommen, dann bezahlen Sie diese zwei Wochen. Wenn nicht, dann nicht. Und so machen wir das immer weiter. Sie zahlen immer, wenn Ihnen die Arbeit, die wir liefern, gefällt. Sie könnten dieses Prinzip nun ausnutzen, da wir die Funktionalität, die Ihnen nicht gefällt und die Sie nicht bezahlen, natürlich nicht wieder ausbauen können. Neue Funktionalität wird ja auf gelieferter Funktionalität aufgebaut. In diesem Fall würden Sie die Entwicklung der ersten zwei Wochen zahlen, dann zahlen Sie die nächsten zwei Wochen nicht, dann zahlen Sie wieder und so weiter. Das würde zwar Ihre Kosten halbieren und am Ende hätten Sie das fertige Produkt mit allen Funktionalitäten zu den halben Kosten. Wir würden in diesem Falle aber bemerken, dass Sie nicht fair mit uns umgehen. Und dann würden wir die Arbeit einstellen.“
Dieser Umgang mit einem Kunden, den man noch nicht kennt, minimiert das Risiko. Gleichzeitig ist er eine erfolgreiche Praktik, um von einer Vertrauensbasis aus zu starten und reagieren zu können, wenn das Vertrauen enttäuscht wird (dieses Prinzip nennt sich Tit for Tat-Strategie). Das Schöne an agilen Projekten ist, dass am Ende nur das zählt, was tatsächlich herauskommt. Das ist übrigens ein erster Hinweis darauf, wie Verträge gestaltet sein sollten: Als Ergebnis wird erwartet, dass die Software geliefert wird, und nicht, ob Zwischenschritte erzeugt wurden.
Reagieren auf Veränderungen mehr als das Befolgen eines Plans
Sofort springt die Aufmerksamkeit auf das letzte Wort dieses Satzes: Plan. Dieses Wertepaar wird von vielen so ausgelegt, als gäbe es bei agilen Projekten und bei der agilen Produktentwicklung keine Pläne. Als gäbe es nur das Chaos: Niemand weiß, was man bekommt, und niemand kann sagen, wie kostspielig das Projekt oder das Produkt sein wird.
Diese Interpretation ist selbstverständlich falsch. Bei agilen Projekten wird sogar noch öfter und konkreter geplant als bei traditionellen Verfahren. Insgesamt nämlich auf fünf Ebenen:
Auf der Ebene der Vision
Auf der Ebene der Roadmap
Auf der Ebene des Release
Auf der Ebene des Sprints/der Iteration
Auf der Ebene der täglichen Arbeit
Agile Methodiker haben dafür unzählige Planungsverfahren und Tools entwickelt. Es beginnt mit klaren Vorstellungen darüber, wie man eine Vision erzeugt und wie man daraus Release-Pläne macht. Es gibt konkrete Handlungsanweisungen dafür, wie ein Sprint Planning abzuhalten ist und vieles mehr.
Auf allen Ebenen ist den Beteiligten klar, dass jede dieser Planungsaktivitäten iterativ wiederholt werden und der Plan kontinuierlich angepasst werden muss. Das Entwicklungsteam plant jeden Tag, um gemeinsam das Sprint-Ziel zu erreichen. Während des Sprints sprechen Entwicklungsteam und Product Owner darüber (oder anders ausgedrückt: sie planen gemeinsam), wie der nächste Sprint durchgeführt wird. Zu Beginn eines Release sprechen Scrum-Team und Kunden darüber, was in dem nun anstehenden Release produziert werden soll. Der Product Owner und die Kunden reden während des gerade laufenden Release darüber, wie das Produkt auf längere Sicht weiterentwickelt werden soll: Product Roadmap und die Vision des Produkts werden am Markt überprüft und gegebenenfalls wird gemeinsam eine tragfähigere Vision für das Produkt generiert. Der gesamte Planungsprozess ist dabei im Idealfall sehr transparent.
Für jeden dieser Planungsprozesse gibt es eigene Visualisierungstechniken und Moderationsmethoden, um den kommunikativen Prozess zwischen den Parteien möglichst effektiv zu gestalten. Keinen Plan haben? Das geht auch in der agilen Entwicklung nicht.
Scrum und seine Derivate (Kanban, SAFe, OKR oder Lean Start Up) sind heute die De-facto-Standards in der (agilen) Softwareentwicklung. In den letzten Jahren haben sie sich aus einer (agilen) Projektmanagementmethode zu einem neuen Verständnis darüber entwickelt, wie man dysfunktional arbeitende Teams, Abteilungen, ganze Organisationseinheiten und Unternehmen agil und lean managt.
Oft wird Scrum oder Kanban zunächst auf Team- oder Projektebene als Projektmanagementmethode eingesetzt. Einige Unternehmen gehen doch einen Schritt weiter, hier wird im Laufe der Zeit die gesamte Organisation in eine agile Organisation überführt.
Obwohl dieser Gedanke für dieses Buch zu weit führt: Die agilen Methoden sind mehr als nur Tools innerhalb der existierenden Management-Modelle. Es sind vielmehr Managementwerkzeuge, mit denen Organisationen schnell gute Software liefern können. (Tabelle 1.2).
Tabelle 1.2 Agile Entwicklungsmethoden innerhalb agiler Frameworks
Agile Entwicklungsmethoden
Agile (Management-/Prozess-) Frameworks
Adaptive Software Development
Agiles Datawarehousing
Crystal
Dynamic System Development Method
Scrum
Extreme Programming
und
Feature Driven Development
Kanban
Software-Expedition
Universal Application
Usability Driven Development
Bei Scrum gibt es wenige Prinzipien und sehr wenige Regeln – allerdings Prinzipien, die verstanden, und Regeln, die konsequent eingehalten werden. Ganz im Sinne des Agile Manifesto liegt Scrum ein klares Wertesystem zugrunde. Ein wichtiger Wert ist Respekt: Jeder einzelne Beteiligte wird als mündiges Teammitglied wahrgenommen und respektiert.
Eine der wichtigsten Ideen von Scrum ist es, Teams Freiräume zu verschaffen, damit sich die Talente der Teammitglieder entfalten können und Spaß am produktiven Schaffen entsteht. Scrum gibt in dieser Interpretation dem Einzelnen im Team die Kompetenzen zurück, die er für das Übernehmen von Verantwortung benötigt.
Die Missverständnisse
Die agilen Management-Frameworks basieren auf dem sinnvollen Zusammenspiel von Regeln, Disziplin und Eigenverantwortlichkeit. Mitdenken dürfen und sollen, einander helfen und das eigene Wissen nicht nur nutzen, um selbst zu glänzen – das steht dahinter.
Die agilen Frameworks schreiben nicht vor, wie genau zu arbeiten ist. Manager können anhand dieses Management-Frameworks aber erkennen, worauf sie bei der Entwicklung von Software mit externen oder internen Dienstleistern achten sollten. Dazu sollten sie sich zuvor über einige Missverständnisse im Klaren sein, die der effektiven Arbeit mit Scrum in die Quere kommen können. Dass Scrum oder Kanban Entwicklungsmethoden seien, ist dabei eines der gängigsten Missverständnisse. Dass Scrum den Mitarbeitern uneingeschränkte Freiheiten lässt, ist das andere große Missverständnis. Und dann gibt es noch einige andere:
1. In Scrum wird nur kurzfristig gedacht und daher nicht geplant. Wir haben es bereits im Kontext der Prinzipien des Agile Manifesto gesehen: In Scrum wird konsequent geplant. Im Wesentlichen passiert das auf drei Ebenen: auf Tagesebene (Daily Scrum), auf Sprint-Ebene (Sprint Planning) und auf Release-Ebene (Release Planning). Scrum folgt dem Deming Cycle, dessen Grundgedanke die kontinuierliche Verbesserung und damit die permanente Planung nach dem Motto Plan-Do-Check-Act ist (Deming 1982).
2. Scrum fördert unprofessionelles Arbeiten. Diese Meinung hat ihre Berechtigung, wenn Freiheit in der Problemlösung als Bedrohung empfunden wird und zentimeterdicke Dokumentationen als Qualitätskriterium für gute Software betrachtet werden. Scrum setzt die Kreativität des Teams frei und schreibt daher keine Wege vor, wie ein Problem zu lösen ist. In den Sprint Plannings wird aber genau festgelegt, was am Ende eines Sprints vorhanden sein muss. Und wenn dazu eine Dokumentation gehört, gibt es am Ende des Sprints auch eine Dokumentation. Scrum legt unprofessionelles Arbeiten schonungslos offen, denn durch das Daily Scrum wird die unprofessionelle Arbeit einzelner Entwickler für alle Teammitglieder sichtbar.
3. Agile Methoden und Scrum sind nicht diszipliniert. Agile Prozesse sind in ihrer Durchführung sehr konsequent, weil permanent das Ergebnis der eigenen Handlungen sichtbar und spürbar wird. Disziplin geht in Scrum so weit, dass jedes Meeting auf die Minute pünktlich beginnt, und wer dann nicht da ist, bleibt auch draußen.
4. Produktentwicklung statt Projektmanagement. Scrum, Kanban oder sogar SAFe, diese Frameworks sehen für viele so aus, als wären es Projektmanagementmethoden – sie sind es aber nicht.
5. Bei Scrum geht es nicht darum, ein im Vorhinein definiertes Projektergebnis zu liefern. Es geht vielmehr darum, einen kontinuierlichen Strom von Produktteilen zu liefern. Zusammen ergeben diese ein Gesamtprodukt mit sehr viel Funktionalität. Scrum-Teams entwickeln Produkte, indem sie aktuelle Veränderungen ständig einbeziehen. Dieser Strom der Produktteile passt sich also laufend der Zukunft an und daher wird immer genau geliefert, was nützlich ist und gebraucht wird. Durch die Vorgabe von Scrum, dass am Ende jedes Sprints einsetzbare Software entstanden sein muss, entstehen laufend Zwischenprodukte, die nutzbar, da komplett sind. Das Prinzip der Zwischenprodukte ermöglicht es, risikofreier zu starten und den Fortschritt eines Projekts basierend auf den bereits gelieferten Produktteilen zu messen. Hier liegt der eigentliche Grund, warum agile Softwareentwicklungsprojekte mit klassischen Vertragskonzepten nicht konform gehen. Es wird ständig etwas geliefert – das sehen klassische Projektmanagementmethoden so nicht vor.
Scrum ist daher ein Management-Framework, um Produkte zu entwickeln, aber keine Projektmanagementmethode. Daher gilt auch:
6. Product Owner statt Projektmanager. Das Wort „Projektmanager“ existiert in Scrum nicht. Ein Product Owner ist ein Produktvisionär, der dem Team die Produktidee so vermitteln kann, dass sie die Teammitglieder zur Produktivität anspornt. Der Product Owner ist für den finanziellen Erfolg des Produkts verantwortlich. Er managt kein Projekt, er hat auch andere Aufgaben als die eines Projektmanagers.
Zusammenfassend: Management-Framework statt Entwicklungsmethode
Scrum macht keine Vorschriften zu der Art und Weise, wie gearbeitet werden soll, legt aber die Rollen und Verantwortlichkeiten sehr klar fest. Es werden auch sehr eindeutige Grenzen für die Entwicklung definiert. Das Prinzip der Timebox erzeugt nicht nur kreativen Druck, sondern die Sicherheit, die für die Entwicklung von Selbstorganisation notwendig ist.
Die Werte von Scrum
Es wurde schon recht deutlich, dass das Menschenbild im Agile Manifesto und damit in Scrum ein völlig anderes ist als das eines Befehlsempfängers und kontrollierten Erfüllungsgehilfen, der stur nach einem Schema arbeitet. In Scrum gehen wir davon aus, dass geistig arbeitende Menschen ein prinzipielles Interesse daran haben, ihre Ideen einzubringen, Dinge zu verbessern oder überhaupt Neues zu entwickeln (siehe dazu auch die X- und Y-Theorie von Douglas McGregor).
Die Vertreter, die Scrum propagieren, sind der Meinung, dass wir erwachsene Menschen und damit erst einmal grundsätzlich verantwortlich für unser eigenes Handeln sind. In Scrum glauben wir und wissen wir, dass Menschen alles geben, wenn sie von einer Vision fasziniert sind. Commitment, Fokus, Offenheit, Mut und Respekt sind daher Werte, die Scrum und dem Denken der mit Scrum arbeitenden Menschen zugrunde liegen (sollten).
1.2.1Organisationsprinzipien und RollenKundenfokus, Kundenfokus und noch einmal Kundenfokus. Zunächst: Wir unterscheiden zwischen Kunden und User. Der Kunde ist der Auftraggeber, also der, der zahlt. Der User oder Anwender ist der, der das Produkt nutzt. Doch im Allgemeinen spricht man von Kundenfokus in der agilen Welt, daher nutzen wir das auch synonym an dieser Stelle, zumal es für die Aussage dieses Buchs aufs Gleiche herauskommt. Wir wollen etwas liefern, das für den Kunden/User von Wert ist: Dabei kann Wert ganz unterschiedlich definiert sein. Für den einen bedeutet es, dass die Arbeit leichter geht oder dass Zeit eingespart wird. Für den anderen, dass konkret Geld damit verdient wird oder dass etwas nicht vergessen wird. Entscheidend an diesem Fokus ist, dass agile Projekte und damit auch die Verträge, genau das berücksichtigen sollten: Also wie gelingt es, möglichst nur das zu entwickeln, was tatsächlich auch genutzt wird. Gerade bei großen Projekten wird oft eine bereits existierende Software ersetzt und dann soll genau das Gleiche wieder möglich sein und noch viel mehr. Doch genau dieses Vorgehen ist unnötig. Apple-Produkte zeigen es immer wieder: Wozu eine Kopfhörerbuchse am Rechner, wenn sowieso mit Bluetooth-Kopfhörern gearbeitet werden wird?
Kleine, selbstorganisierte und multidiziplinäre Teams. Ein Scrum-Team besteht im Idealfall aus sieben Personen: dem ScrumMaster, dem Product Owner und den fünf Personen des Entwicklungsteams. Die Mitglieder des Entwicklungsteams ziehen sich nicht auf ihr Spezialistentum zurück, sondern sind in der Lage, verschiedene Arbeiten im Arbeitsprozess durchzuführen (sogenannte T-Shaped Personen – siehe dazu zum Beispiel Reinertsen 2009). Das bedeutet, dass sie ihr Wissen untereinander austauschen, in unterschiedlichen Kombinationen einsetzen und keine Scheu vor Aufgaben haben, die nicht direkt ihren Kernkompetenzen entsprechen. Sie organisieren ihre Aufgaben vollständig selbst. Noch besser sind Teams, die sich sogar aus verschiedenen Fachdisziplinen zusammensetzen, also tatsächlich den gesamten Problemraum des zu entwickelnden Produkts abdecken.
Arbeiten nach dem Pull-Prinzip. Das Team kann als einzige Instanz entscheiden, wie viel Arbeit und Produktteile es innerhalb eines Sprints liefern kann. Das Team hat die Kontrolle darüber, was es zu tun bekommt, indem es Arbeit „zieht“, sobald es Kapazität dafür hat. In größeren Projekten, in denen mehr als ein Team eingesetzt wird, wählen die Teams die für sie passenden Funktionen aus. Das heißt, sie bestimmen selbst, an was sie arbeiten. Es zeigt sich in jedem Experiment und auch in der Praxis: Gelingt es einer Organisation, tatsächlich das Prinzip einzuhalten, dass nur die Teams bestimmen, wie viel sie arbeiten, sind diese Teams (bei gleichen äußeren Faktoren) effektiver, d. h. produktiver als Teams, die nicht selbst über ihre Arbeitslast bestimmen können.
Intervalle mit klaren zeitlichen Grenzen (Timebox). Das Team bekommt herausfordernde Ziele, die zu Intervallen mit klaren zeitlichen Vorgaben konkretisiert werden. Alle Aktionen werden zeitlich beschränkt und es wird ein Ergebnis verlangt. Das erzeugt klare Rahmenbedingungen. Das steht keinesfalls im Widerspruch zum gerade oben Gesagten: Es ist so, dass die Teams natürlich diese Ziele innerhalb der Intervalle mitbestimmen. Es kommt zu einer gemeinsamen Vereinbarung, was innerhalb des Zeitintervalls zu liefern ist. Dies darf gerne auch fordernd oder anstrengend sein, solange alle Teammitglieder gemeinsam entschieden haben.
Nutzbare Business-Funktionalität – Potential Shippable Code. Wie oben beschrieben, gemessen wird der Fortschrift des Projekts an der Anzahl der gelieferten Funktionalitäten oder daran, dass weniger Fehler in der Software vorhanden sind als am Anfang des Projekts oder dass die entwickelte Applikation schneller läuft. Auch andere Fortschrittsparameter sind vorstellbar, doch sie müssen immer abzählbar sein. Anders ausgedrückt, am Ende jedes Zeitintervalls muss das Team eine Lieferung erbringen. Und ja – diese Lieferung muss den Standards, Richtlinien und Vorgaben des Projekts genügen. Das sind zum Beispiel Compliance-Anforderungen oder Richtlinien der Firma oder technische Vorgaben oder auch die Vorgaben zur Usability oder Performance.
Die Rollen
Die Stärken von Scrum oder SAFe liegen in der klaren Zuordnung und Trennung der Verantwortlichkeiten von ScrumMaster, Product Owner und des Entwicklungs-Teams. Um das Umfeld eines Teams bzw. einer Organisation gedanklich stärker mit einzubeziehen, fügen wir in der Praxis auch den Kunden, den Endbenutzer und den Manager als Rollen hinzu.
Das Entwicklungsteam – die Lieferanten. Das Entwicklungsteam liefert das Produkt bzw. die Produktteile. Es managt seine Angelegenheiten selbst und ist autorisiert, alles Zielführende zu tun, um das angestrebte Ergebnis zu erreichen. Gleichzeitig muss es die Standards und Prozesse der Organisation einhalten. Das Team steuert selbst die Arbeitsmenge, die es bewältigen kann. Dafür trägt es aber auch die Verantwortung für die Qualität der Lieferung. Hier ist es wichtig, zu verstehen, dass es in großen und komplexeren Umfeldern natürlich vorkommt, dass die Entwicklungsteams aus unterschiedlichen Organisationen kommen können und/oder an unterschiedlichen Standorten sein können. Das erhöht zwar die Komplexität innerhalb des Teams und erschwert oft das gemeinsame Verständnis und damit das gemeinsame Liefern, jedoch ist das am Ende ein eher organisatorisch-technisches Problem, das sich aus unserer Erfahrung immer lösen lässt.
Der Product Owner – der Visionär. Der Product Owner lenkt die Produktentwicklung und ist verantwortlich dafür, dass das Team die gewünschten Funktionalitäten in der richtigen Reihenfolge erstellt. Er oder sie sorgt dafür, dass die Projektergebnisse den finanziellen Aufwand für das Projekt rechtfertigen. Mit dem Team arbeitet der Product Owner auf täglicher Basis, er trifft zeitnah die notwendigen Entscheidungen und arbeitet kontinuierlich am Product Backlog und dem Release-Plan. Der Product Owner in modernen agilen Implementierungen ist nicht mehr das sogenannte „wringable neck“, er weiß und verantwortet also alles. Vielmehr ist seine Verantwortung darauf gerichtet, das gesamte Projektteam in die Organisation hinein zu vertreten, statt genau zu sagen, was es zu liefern hat.
Der ScrumMaster – der Change Agent. Der ScrumMaster unterstützt das Scrum-Team, die vereinbarten Ziele des Projekts und damit auch die jeweiligen Iterationsziele zu erreichen. Er arbeitet daran, dass alle Schwierigkeiten, Blockaden und Probleme, die das Scrum-Team aufhalten, gelöst werden. Er oder sie ist keine klassische weisungsbefugte Führungkraft, dennoch führt sie das gesamte Scrum-Team. Sie sorgt neben der Einhaltung des Scrum-Prozesses dafür, dass das Scrum-Team von Iteration zu Iteration produktiver und leistungsfähiger wird. Die Rolle des ScrumMaster besteht darin, alle am Projekt beteiligten Personen zu schulen, Blockaden zu finden und sie aufzulösen, das Scrum-Team auf Kurs zu halten und auch gegen die Übergriffe der Organisation zu schützen. Entscheidend zu verstehen: Diese Rolle beschränkt sich nicht darauf, innerhalb des Scrum-Teams zu arbeiten, sondern auch darauf, die organisationalen Rahmenbedingungen für das Scrum-Team zu verändern
Der Manager – der Bereitsteller. Das Management der Organisation vertritt die Bedürfnisse der jeweiligen Abteilungen an das Projekt und stellt den organisationalen Rahmen, innerhalb dessen das Projekt abläuft. Es schafft damit den Rahmen, in dem sich das Scrum-Team – das Development-Team, der Product Owner und der ScrumMaster – bewegt. Oft wendet sich der ScrumMaster an Vertreter des Managements, damit die vom ScrumMaster identifizierten Probleme behoben werden können.
Der Kunde – der Finanzierer. Der Kunde ist Anforderer des Projekts, er kauft es oder hat es in Auftrag gegeben. Typischerweise sind das Executive Manager in Organisationen, die Softwareentwicklung bei externen Firmen einkaufen. In einem internen Projektentwicklungsteam ist der Budgetverantwortliche in der Rolle des Kunden. Es kann aber auch eine externe Abteilung sein, für die das Scrum-Team in der Folge liefert. Oft liefert der Kunde auch die Beweggründe für das Projekt, ohne die jeweiligen Einzelheiten nennen zu können.
Der User – der Nutzer. Der Anwender des Produkts ist eine wesentliche Informationsquelle für das Scrum-Team. Er ist es, der später die „Usable Software“ benutzen wird. Daher bezieht das Scrum-Team den Anwender in die Produktentwicklung mit ein. Beim Sprint Planning definiert er gemeinsam mit dem Product Owner die Anforderungen. Später wird er als Anwender mit dem Team daran arbeiten, die Anwendung nutzbar zu machen. Der Anwender ist integraler Bestandteil des Projekts, obwohl er oder sie nur in einer nutzenden, also wenig gestaltenden Rolle in Erscheinung tritt.
1.2.2Das ProzessmodellDas Prozessmodell von Scrum steckt den Rahmen ab, in dem alle Aktivitäten der Produktentwicklung ablaufen. Neben den sechs Rollen besteht der Scrum-Prozess aus sechs Meetings und diversen Artefakten:
Rollen
Meetings
Artefakte
Team
Estimation Meeting
Product Vision
Product Owner
Sprint Planning 1
Product Backlog Item (Story)
ScrumMaster
Sprint Planning 2
Product Backlog (Liste der Stories)
Manager
Daily Scrum
Sprint Goal
Kunde
Estimation Meeting
Selected Product Backlog
User
Sprint Review
Aufgaben/Tasks
Sprint Retrospektive
Sprint Backlog
Release Plan
Impediment Backlog
Produktinkrement – Usable Software
Definition of Done
Burndown Chart
Eine Schwäche traditioneller Entwicklungsmethoden ist, dass sie Kunden und Entwickler separieren. Das kommt einer Trennung von strategischer und taktisch-operativer Ebene gleich. Das Team weiß dann lediglich, dass es etwas tun soll, aber nicht, warum es etwas tun soll. Die Kenntnis des „Warum“ ist aber eine wesentliche Hintergrundinformation, um innovative Problemlösungsansätze entwickeln zu können. Softwareentwickler sind meistens ausschließlich auf ihre Arbeit fokussiert und blenden mittel- bis langfristige geschäftliche Aspekte, die ihre Arbeit hat und haben muss, weitgehend aus. Scrum bezieht die Entwickler, das Development-Team, hingegen auf zwei Arten direkt in strategische Überlegungen mit ein und dadurch beginnen sie zu verstehen, in welchem Zusammenhang ihre Arbeit mit Erfolg oder Misserfolg ihres Arbeitgebers und dessen Kunden steht.
Zum einen entwickelt der Product Owner eine Produktvision für das Projekt – alleine oder gleich gemeinsam mit dem Team.
Zum anderen wird das Team in weiterer Folge immer in die strategische Planung einbezogen. In diese zwei Teilstrategien spielen übergeordnete Strategien mit hinein: die Produktlinienstrategie und die Organisationsstrategie.
Strategisches Planen dient zur Vorausschau, zur Einschätzung, ob ein Vorhaben gelingen kann, und der Entscheidung, welches Vorgehen zur Zielerreichung führen wird.
Auf den Punkt gebracht planen wir
auf der strategischen Ebene die Ziele, die wir erreichen wollen, und
auf der taktischen Ebene die Aktionen, die nötig sind, um die Ziele zu erreichen.
Scrum auf strategischer Ebene
Die Produktvision. Am Anfang steht die Person mit einer Produktidee, die häufig vom Kunden eingebracht wird. Aus dieser Produktidee entwickelt der Product Owner die Produktvision. Er oder sie bearbeitet diese Idee so lange, bis es eine Produktvision gibt. Oft ist es so, dass die Produktvision bereits einen Hinweis auf das grundlegende Feature und damit den Grund für das Projekt und die neue Applikation liefert.
Product Backlog. Der Product Owner erarbeitet mithilfe der Teammitglieder die Produktfunktionalitäten (Product Backlog Items). Diese werden in einer sehr einfachen Form notiert: den User Stories. Eine Story ist ein kurzer Satz, der einen Teil einer Funktionalität in einer besonderen Weise repräsentiert, die von Mike Cohn stammt und in seinem Buch „User Stories Applied“ (Cohn 2004) beschrieben ist. Er hat die folgende Struktur für User Stories eingeführt:
Als Anwender mit der Rolle
benötige ich eine Funktionalität,
damit ich den Nutzen bekomme.
Beispiel: Als Bankkunde benötige ich die Möglichkeit, mich zu identifizieren, damit ich meine Kundendaten abrufen kann.
Alle User Stories werden in eine Liste eingetragen: das Product Backlog. Es gibt viele verschiedene Varianten, wie dieses Product Backlog zusammengetragen wird. Erfahrene Teams entwickeln die User Stories, statt es dem Product Owner zu überlassen, die User Stories zu formulieren.
Eine Reihenfolge herstellen. Der Product Owner bringt die Product Backlog Items in dieser Liste in eine Reihenfolge, die sich aus dem zu erwartenden finanziellen Gewinn der jeweiligen Funktionalitäten ergibt (http://www.scrum.org/scrumguides).
Estimation Meeting oder Refinement Meeting. Als Nächstes muss jedes Product Backlog Item auf seine Größe geschätzt werden. Die Schätzung wird von den Teammitgliedern durchgeführt. Ein Scrum-Team besteht aus allen Personen, die notwendig sind, um die Backlog Items in Software zu verwandeln, die ausgeliefert werden kann. Die Teammitglieder schätzen also den Umfang jedes zu liefernden Product Backlog Items und teilen das Ergebnis dem Product Owner mit. Neben dieser Einschätzung werden User Stories umgeschrieben, verfeinert oder verworfen. Oft kommen durch die Beschäftigung auch neue Stories hinzu.
Geschätztes und priorisiertes Product Backlog. Das Product Backlog ist in diesem Meeting komplett oder teilweise geschätzt. Alle Teammitglieder haben eine Vorstellung davon, wie das gewünschte Produkt aussehen soll, und der Product Owner hat eine erste Vorstellung davon, wie umfangreich das Produkt ist.
