Lesedauer: 7 Minuten
Inhalt
So gut wie jeder kennt einige gescheiterte oder stark aus dem Ruder gelaufene Großprojekte. Komplexe Vorhaben lassen sich in keiner Branche detailliert und sicher sequenziell planen.
Die Softwareindustrie entwickelte bereits um den Jahrtausendwechsel eine neue Managementmethode gegen dieses Missmanagement von Komplexität: Die agile Entwicklung. Diese agilen Ansätze setzen inzwischen auch viele Branchen jenseits der IT erfolgreich ein, wie das folgende Beispiel von Bosch und Tesla verdeutlicht.
Vor ca. zehn Jahren wollte Bosch auch Tesla beliefern. Die Anforderungen Teslas an seine Lieferanten waren allerdings grundsätzlich andere als im Rest der Autoindustrie: Die gesamte Partnerschaft basiert auf einem einseitigen Partnervertrag.
Wichtigstes Kriterium in einem Tesla Partnervertrag ist die Forderung, dass Änderungswünsche innerhalb einer Woche in Produktion umgesetzt sein müssen. Der Preis spielt zwar eine Rolle, ist aber dem Ziel der unglaublich schnellen Anpassungsfähigkeit untergeordnet. Bosch hat dafür einen neuen, agilen Bereich aufgebaut, bei dem das agile Arbeiten überraschend erfolgreich funktionierte. Das war der Ausgangspunkt für die agile Transformation des gesamten Bosch-Konzerns.
Im Kern geht es darum, sich nicht auf einen Plan zu fokussieren, sondern immer das erwünschte Ergebnis bzw. Ziel im Blick zu behalten und flexibel iterativ darauf hinzuarbeiten. Für Projektdienstleister bedeutet das, dass nicht einfach Entwicklungskapazität als Dienstleistung verkauft wird, sondern ein Produkt.
Für ein sinnvolles fixes Budget soll ein grob umrissenes, möglichst nutzbringendes Ergebnis entwickelt werden.
Prinzipien der agilen, partnerschaftlichen Lieferantenbeziehung
Nicht der konkrete Plan mit konkreten Umsetzungsinhalten bildet die Basis der Zusammenarbeit. Stattdessen ist Basis der Partnerschaft, aus der Produktvision ein möglichst gutes Produkt zu entwickeln.
Vertrauen
Selbstorganisierte Teams finden und entwickeln die besten Lösungen für komplexe Probleme. Dazu benötigen sie eine starke Produktvision als Leitstern, die nötigen Mittel und vor allem ein hohes Maß an gegenseitigem Vertrauen. Dieses Vertrauen führt dazu, dass Probleme und Risiken früh, offen und konstruktiv adressiert werden. Vertrauen im Team ist damit eine der wesentlichen Voraussetzungen für Innovation.
Da das Produktteam aus Mitgliedern des Auftraggebers und des Auftragnehmers bestehen sollte, ist auch zwischen diesen „Parteien“ Vertrauen entscheidend für Erfolg.
Häufiges Liefern einer nutzbaren Anwendung
Komplexe Vorhaben beruhen auf sehr vielen Annahmen. Sich diese Tatsache einzugestehen und die Vorgehensweise entsprechend experimentell zu gestalten ist ein weiteres wichtiges Erfolgsprinzip agiler Arbeitsweisen.
Da reales Feedback erst im realen Einsatz eines Produktes entsteht, liefern agile Teams schnell einen ersten nutzbaren Prototyp und verbessern diesen iterativ mit immer weiteren Prototypen, bis schließlich das vereinbarte Ergebnis in Form des Produktes vorliegt.
Deutlich wird dies am fiktiven Beispiel eines Luxusautos, das es so noch nicht gibt und das jetzt bestellt wird. Klassisch muss der Besteller warten, bis das Chassis entwickelt und gebaut ist, dann der Motor entwickelt, gebaut und eingesetzt ist, dann die Innenausstattung, die Karosserie etc. fertig ist. Nach langer Entwicklungszeit kommt der Besteller das erste Mal mit dem realen Produkt in Berührung und stellt evtl. fest, dass er sich das ganz anders vorgestellt hatte.
Agil wird dagegen erst ein Citan fertig gebaut und dann vom Besteller getestet. Dann wird auf Basis des Feedbacks eine A-Klasse weiterentwickelt und gebaut, diese wiederum getestet. Daraus entsteht eine C-Klasse, dann eine E-Klasse und schließlich eine S-Klasse, die bereits auf Anhieb keine Wünsche offenlässt.
Auf dem Weg dorthin werden die kleineren Schritte jeweils gemeinsam vom Besteller und den Entwicklern abgewogen und der Besteller kann die wirklich entscheidenden Punkte auf Kosten- Nutzenbasis priorisieren.
Schnelles Reagieren auf Veränderungen
Im Laufe der Produktentwicklung lernen alle Seiten ständig dazu. Wenn eine Vertrauenskultur herrscht, werden Risiken beim aktuellen Ansatz und Chancen durch eine Änderung der Vorgehensweise früh erkannt, konstruktiv diskutiert und schließlich werden die geeigneten Maßnahmen beherzt umgesetzt.
Dadurch managen agile Entwicklungen Risiken wesentlich effektiver und erreichen das angestrebte Ziel mit geringeren Kosten und höherem Nutzen in kürzerer Zeit.
Das Mission Statement - zentraler Bestandteil des Vertrages
Ein Mission Statement ist eher ein Leitbild als ein einfacher Auftrag.
Ein agiles Mission Statement gibt Richtung, Rahmen und Ziel eines Entwicklungsvorhabens vor. Das Mission Statement konzentriert sich damit stark am Warum.
Dagegen spielt das Wie, also der Umsetzungsplan hier keine Rolle. Deshalb eignet sich ein Mission Statement sehr gut als Vertragsgrundlage für eine agile Auftragsentwicklung eines Produktes.
Produktvision
Eine gute Produktvision beschreibt die angestrebte bessere Situation der Zielgruppe durch die Verwendung des Produktes. Diese Art von Vision vermittelt dem Produktteam den Sinn des Vorhabens und ist das wichtigste Motivationsinstrument.
Die Vision gibt dem Team auch in schwierigen Entscheidungssituation die Richtung für die zielführendste Option vor. Eine passende Vision für die Autobestellung wäre beispielsweise:
Das Fahrzeug gleitet sanft und kraftvoll an den bewundernd blickenden Passanten vorbei
Produktziele
Ziele präzisieren die Vision. Ein bestimmendes Ziel fokussiert die Entwicklung am besten. Mehr als drei Ziele verwässern die Ausrichtung. Zu viele Ziele sind kontraproduktiv.
Ich selbst verwende am liebsten das OKR-Modell, andere Ziel-Methoden sind genauso möglich. Ein „Objective“ (Ziel) mit entsprechenden „Key Results“ (Schlüsselergebnissen) könnte für das Beispiel Luxusauto so aussehen:
- Zwei VIP-Passagiere werden von einem Profifahrer sicher und hoch komfortabel in einem kraftvollen, elektrisch angetriebenen Fahrzeug innerhalb einer Großstadt befördert.
- Das Fahrzeug erfüllt die höchste aktuelle Widerstandsklasse für Sonderschutzfahrzeuge
- Die Reichweite nach WLTP beträgt mindestens 200 km.
- 60% der Teilnehmer einer repräsentativen Befragung von Passanten in einer Großstadt beurteilen das Fahrzeug als „Hingucker“ mit eher positiven Assoziationen.
- 80% der Zielgruppe bewertet das Ambiente als sehr gut geeignet für Gespräche zu zweit und individuelles Arbeiten beim Fahren.
Abgrenzung
Entwickler neigen im Laufe der Entwicklung gerne dazu, eine „eilerlegende Wollmilchsau“ anzustreben. Oder besonders lautstarke Stakeholder beeinflussen den Produktzuschnitt mit ihren persönlichen Vorlieben und Wünschen zu stark. Deshalb ist es hilfreich, evtl. mögliche Entwicklungsrichtungen, die nicht gewünscht sind, explizit auszuschließen:
- Die Anforderungen von Überlandfahrten außerhalb von Ballungsgebieten sind nicht relevant
- Mehr als zwei Passagiere werden nicht unterstützt. Ein zweiter Beifahrer vorne ist denkbar, aber nicht zwingend
Rahmenbedingungen
Das Team soll maximal autonom entwickeln und agieren können. Rahmenbedingungen vermitteln die nötigen Leitplanken, innerhalb deren sich das Team sicher selbständig bewegen kann und nicht gebremst oder behindert wird. Ohne klare Rahmenbindungen muss das Team zu oft Entscheidungen von oben absegnen lassen.
- Das Fahrzeug muss elektrisch aus Akkus betrieben werden.
- Das Fahrzeug muss auf mindestens 15 Jahre Lebensdauer ausgelegt sein.
- Die Herstellkosten in Kleinserie dürfen 250.000 € pro Fahrzeug nicht übersteigen.
- Ein erster Prototyp wird auf der XY-Messe in einem Jahr präsentiert.
Projekt-Initiierung
Im Vorfeld der Auftragsvergabe sollten die Voraussetzungen für den Projektstart gut vorbereitet werden. Dadurch kann das Projektteam dann direkt produktiv durchstarten.
Team festlegen
Welche Skills werden benötigt und wer kann diese beisteuern? Neben dieser Frage ist sehr zu empfehlen, dass das Produktmanagement, im agilen Umfeld oft als Product Owner (Team) bezeichnet, vom Auftraggeber gestellt wird. Durch eine integrale Einbindung ins Produktentwicklungsteam kann das Produktmanagement damit viele kleine Entscheidungen auf Basis von Lernerfahrungen im Fortschritt konstruktiv mit lenken.
Auf alle Fälle sollte eine klassische Lieferantenbeziehung mit dem Produktmanagement als „Befehlsgeber“ und dem externen Entwicklungsteam als „Ausführende“ vermieden werden.
Mission Statement gemeinsam festlegen
Das bereits weiter oben beschriebene, zentrale Mission Statement sollte vom wirtschaftlichen Verantwortlichen auf Auftraggeberseite wesentlich getrieben werden.
Das Ausarbeiten der Details und Formulierungen sollte allerdings gemeinsam mit dem Produktteam aus Produktmanagement, Entwicklung und evtl. weiterer Rollen erfolgen. Das ist zentral für ein gemeinsames Verständnis und ein tiefes Commitment zur Erreichung der Ziele.
Budget festlegen
Sind die Ziele der Initiative wirtschaftlich erreichbar? Um das zu klären, wird auf Basis des Mission Statements das Gesamtprojekt grob geplant. Dabei geht es vor allem darum, dass das geplante Produktteam die Gesamtkomplexität gut versteht. Auf der Basis wird dann aufgrund von Vergleichen mit ähnlich komplexen Vorhaben die voraussichtlich nötige Größenordnung für die Ressourcen ermittelt.
Durch Anpassung der Ziele und Rahmenbedingungen lässt sich das Budget evtl. reduzieren. Vorgaben wie „es darf nicht mehr als X kosten“ sollte der Auftraggeber auf keinen Fall in den Raum stellen. Dieser Ansatz führt regelmäßig zu großem Frust und mindestens wirtschaftlichem Desaster.
Die erste Iteration verbindlich planen
Der Übergang von der Vorbereitung der Produktentwicklung zur Produktdurchführung ist die Planung der ersten Iteration, agil oft Sprint genannt.
Dazu muss zuerst herausgearbeitet werden, was das Erste für die Nutzer wertvolle Inkrement sein soll. In unserem Beispiel wäre das ein auf das einfachste reduzierter Lieferwagen.
Die Dauer jeder Iteration sollte zwischen einer Woche und vier Wochen liegen. Je kürzer umso besser wird die Entwicklung später voranschreiten.
Dann wird gemeinsam geplant, was in der ersten Iteration die besten Aufgaben sind. Wenn irgend möglich sollte auch hier schon etwas herauskommen, das die künftigen Nutzer bereits interessiert.
Projekt-Durchführung
Das agile Projektmanagement ist iterativ. Zu Beginn jeder Iteration wird komplett neu geplant mit der Frage: Was ist das Wertvollste, das wir jetzt im Hinblick auf Vision und Ziel in der anstehenden Iteration entwickeln könnten? Dieses Thema wird gemeinsam als messbares Ziel definiert.
Am Ende der Iteration wird gemeinsam der Grad der Zielerreichung festgelegt. Das auftraggeberseitige Projektmanagement bestimmt anschließend den Grad der Zuversicht (Confidence-Level), mit dem das Gesamtziel erreicht wird.
Damit kommen Umsetzungsrisiken früh an die Oberfläche und es kann gegengesteuert werden. Verbessert sich die Situation nicht, sollte die Entwicklung abgebrochen werden. Ein Beispiel für diese Art der Steuerung zeigt die Skizze:
- Nach Iteration 1 ist die Zuversicht des Projektmanagements für das Gesamtprojekt unter 60%, der Projektstatus geht auf orange.
- Iteration 2 erreicht im positiven Fall ein sinnvolles Ziel sehr gut und das Projekt geht wieder auf grün und die Iteration 3 beginnt mit einem neuen Ziel
- Iteration 2 verfehlt im negativen Fall das neue Ziel wieder deutlich, die Zuversicht sinkt weiter. Jetzt sollte das Projekt entweder direkt oder spätestens nach einer weiteren Iteration ohne deutliche Verbesserung abgebrochen werden.
Der Grad der Zuversicht ist subjektiv, drückt aber das Vertrauen in die Partnerschaft aus. Ist dieses dauerhaft gestört, sollte die Partnerschaft umgehend beendet werden. Der Grad kann auch in Prozentwerten angegeben werden. Dann wäre beispielsweise 70% und mehr grün, 40-70% orange und alles darunter rot.
Projekt-Abschluss
Das Projekt hat ein initiales Budget und ein Ziel. Aber evtl. keinen festen Termin und auch keinen Umfang. Wann also ist das entwickelte Produkt gut genug?
Ein guter Indikator für einen erfolgreichen Projektabschluss ist häufig der Produktionsstart. Dazu muss weder das Ziel zu 100% erreicht sein noch das Budget komplett verbraucht sein. Der Auftraggeber ist einfach der Meinung, dass Qualität und Nutzen für einen wirtschaftlichen Start ausreichen.Ein anderer Indikator könnte beispielsweise bei 80% Zielerreichung liegen.
Jedenfalls sollte hier ein einfaches Kriterium festgelegt werden, damit es nicht zu den in klassischen Projekten üblichen „Nacharbeitspflichten“ im Rahmen einer eingeschränkten Abnahme des Lieferergebnisses kommt. Das widerspricht einer vertrauensvollen Partnerschaft im agilen Sinn.
Der Festpreis-Vertrag
Im Vertrag für eine agile Produktentwicklung durch einen externen Auftragnehmer sollte das bereits beschriebene Mission Statement die zentrale Grundlage bilden. Es sollte eben keine verpflichtende Liste von zu liefernden Komponenten oder Funktionen vorkommen.
- Budget
Aus einem fixen, sinnvoll gewählten Budget ergibt sich, mit welcher Personalstärke das Team für einen mehr oder weniger vorbestimmten Zeitraum konstant auf ein möglichst nützliches und wertvolles Produkt hinarbeitet. - AG <-> AN
Der zweite wichtige Part ist die Aufteilung der Verantwortung. Werden Entscheidungen im Produktteam aus Mitgliedern des Auftraggebers und Auftragnehmers im Konsens getroffen? Wie werden Entscheidungskonflikte gelöst, für die kein Konsens gefunden wird? - Risikomanagement
Der dritte Teil des Vertrages sollte das oben bei Projekt-Durchführung beschriebene Verfahren für das Risikomanagement und die Bedingungen für einen kontrollierten Projektabbruch festlegen. - Einbindung von Entscheidern
Soll noch ein Lenkungsausschuss einbezogen werden oder ist das zum Beispiel mit dem für die iterative agile Vorgehensweise üblichen Produkt-Demo und -Review-Meeting am Ende jeder Iteration ausreichend abgedeckt? - Erfolgskriterium
Schließlich sollte klar und einfach definiert sein, wann die Produktentwicklung erfolgreich abgeschlossen ist.
Fazit
Agiles Vorgehen und Auftragsentwicklung zum Festpreis müssen sich also nicht widersprechen. Entscheidend ist die Einsicht, dass für eine komplexe Produktentwicklung eine vertrauensvolle, transparente und risikobewusste Partnerschaft die beste Ausgangsvoraussetzung für eine erfolgreiche Produktentwicklung ist.
Viele erfolgreiche Beispiele auf diesem Fundament zeigen, dass ein agiler Festpreis kein fiktives Ideal darstellt, sondern ein Grundpfeiler erfolgreicher Digitalisierung ist.
