1. Warum sind Best Practices bei agilen Softwareprojekten in der Automobilbranche relevant?

Nach dem Prinzip „What goes around, comes around“ haben agile Projektmethoden in den letzten Jahren wieder vermehrt Einzug in die Automobilbranche gefunden. Während zu Beginn der 90er Jahre insbesondere die Produktion von Fahrzeugen selbst agil(er) ausgerichtet wurde, wird heutzutage die Softwareentwicklung immer stärker mittels agiler Projektmethoden umgesetzt. In Deutschland werden derzeit ca. 50 % aller Softwareprojekte agil umgesetzt (Quelle). Dabei war und ist die Projektmethode „Scrum“ die mit Abstand am meisten verwendete agile Projektmethode.

Um agile Projekte erfolgreich durchzuführen, bietet sich insbesondere für Unternehmen in der Automobilbranche – die derzeit vor besonderen Herausforderungen stehen – die Beachtung von sog. Best Practices an.

2. Was ist das Spannungsfeld in der Automobilbranche bei agilen Projekten?

Sowohl Automobilhersteller als auch -zulieferer stehen bei der Verwendung von agilen Projektmethoden im Rahmen von Softwareprojekten im Spannungsfeld aller großen Unternehmen: dieses folgt kumulativ aus der hierarchischen Personalstruktur und der unternehmensinternen Vorgabe nur etablierte Prozesse anzuwenden. Dies ist für die Ausgestaltung agiler Softwareprojekte nicht förderlich, da diese zumindest auf der Arbeitsebene flache Hierarchien und flexible, anpassungsoffene Prozesse erfordern.

Die Lösung für diesen Konflikt suchen Automobilhersteller oftmals in einem schematischen, hybriden Ansatz zwischen Wasserfallmethodik und agiler Projektmethodik, etwa in Form von speziellen AGB für agile Projekte. Während dies für sehr kleine Projekte oftmals funktioniert, dürfte dieser schematische, hybride Ansatz bei mittleren bis großen Projekten kaum Vorteile zu einem rein sequenziellen/wasserfallartigen Vorgehen haben, oftmals sogar zu einem vermehrten Scheitern von derartigen Softwareprojekten führen. Die Anwendung von agilen Projektemethoden wie von Scrum ist kein Selbstzweck. Sie sind nur vorteilhaft,, wenn bestimmte Rahmenbedingungen beachtet werden.

3. Wieso funktioniert „one-size-fits-all“ bei agilen Projektmethoden nicht?

Der größte und vermeidbarste Fehler dürfte es sein, ein und dasselbe Vertragswerk – etwa wie erwähnt in Form von speziellen AGB für agile Projekte – für alle agilen Softwareprojekte eines Unternehmens bereitzuhalten. Agile Projektmethoden und damit auch Scrum bilden einen Rahmen, der aber immer in Abhängigkeit von den konkreten Projektanforderungen angepasst werden muss. Das Vertrags-Set-up muss daher mindestens folgende drei Projekttypen/AGB-Sets abbilden:

• Sehr innovative, komplexe Projekte (das Ergebnis/der Erfolg kann kaum zu Beginn des Projekts abschließend bestimmt werden), bei denen größtenteils nur eine dienstvertragliche Umsetzung sinnvoll ist.
• Kaum innovative, dafür sehr komplizierte Projekte (das Ergebnis/der Erfolg kann zu Beginn des Projekts größtenteils bestimmt werden), bei denen sich eine werkvertragliche Umsetzung anbietet.
• Projekte von mittlerer Komplexität- und Kompliziertheit: Hier bietet sich oftmals eine werkvertragliche Erstellung des MVPs (d.h. des Mindestziels) und eine anschließende dienstvertragliche Umsetzung von besonderen Spezifikationen an.

Nahezu alle Jurisdiktionen kennen vergleichbare Unterscheidungen zwischen Vertragstypen, die entweder einen „Erfolg“ voraussetzen oder nur ein „Bemühen“ erfordern („Bemühen“ bedeutet, dass rechtlich gesehen nur eine Leistung geschuldet ist und nicht ein Ergebnis). Sofern für ein Unternehmen ein Vertragstyp als nicht passend erscheint, lassen sich damit verbundene Risiken oftmals sehr gut über entsprechende Vergütungsregelungen oder Ausstiegsregelungen abfangen.

• Bei einer dienstvertraglichen Ausrichtung etwa, kann dem Interesse des Auftraggebers an einer Budget-Kontrolle über ein Shard-Risk-Modell entsprochen werden, bei dem z.B. nach Überschreiten eines bestimmten Zieltermins die Vergütung des Auftragnehmers um einen gewissen Anteil reduziert wird.
• Umgekehrt kann den Interessen des Auftragnehmers im Hinblick auf eine jederzeitige Kündigungsmöglichkeit des Auftraggebers Rechnung getragen werden. Dies kann dadurch geschehen, dass etwa trotz Kündigung bereits geplante Ressourcen für einen bestimmten Zeitraum zu vergüten sind, auch wenn diese Arbeiten dann nicht mehr anfallen (die Ressourcen aber geblockt sind).

4. Wieso müssen Scrum-Form sowie Programmierungsspezifikationen bestimmt werden?

Wie erwähnt, handelt es sich bei agilen Projektmethoden nur um „Rahmenwerke“. Folglich hat jedes Unternehmen ein anderes Verständnis davon, wie etwa eine Softwareentwicklung im Scrum-Verfahren aussieht. Es ist daher ein Muss, dass in dem entsprechenden Vertrag/AGB das konkrete agile Projektvorgehen festgehalten wird (d.h. Konkretisierungen von Rollen, Artefakten und Ereignissen). Gerade Automobilhersteller werden eher hybride Formen der agilen Projektmethoden, die auch wasserfallartige Elemente enthalten, im Rahmen der Anwendung von Scrum vorsehen. Das ist per se nicht schlimm, muss dem Vertragspartner aber vorab hinreichend klar kommuniziert werden – wozu sich die vertraglichen Regelungen in der Regel am besten eignen.

Daneben ist es auch oftmals sinnvoll Spezifikationen bzgl. des Programmierungsvorgehens abzustimmen. Zum einen, weil dies im Rahmen einer werkvertraglichen Umsetzung auch den Erfolg spezifiziert, zum anderen, weil dies auch erhebliche Auswirkungen auf die Zeitplanung und das Budget haben kann. Es sollte vorab zumindest ein Grundmaß an gemeinsamem Verständnis bestehen, ob etwa „Pair Programming“ angedacht ist, welche Testings (z.B. Unit-, Integrations-, Systemtests) durchgeführt werden, in welcher Form Code Reviews erfolgen, usw. Werden unterschiedliche Programmierstandards erst im Projektverlauf identifiziert, kann das nachträgliche Nachziehen zu vermeidbaren Projektverzögerungen führen.

5. Welche Rolle spielt das Change Management bei agilen Projekten?

Für jedes agil geführte Projekt ist es zudem erforderlich, das konkrete Change-Management festzulegen. Agilität funktioniert am besten und wird deswegen gewählt, um Änderungen im Projekt (neue oder andere Anforderungen) oder im Projektumfeld (der Markt hat sich geändert) hinreichend zeitnah in der nächsten Iteration berücksichtigen zu können. Insbesondere die Automobilbranche ist derzeit vielen, sich schnell ändernden globalen Faktoren ausgesetzt. Projektverantwortlichen sollte daher von vorherein bewusst sein, welche Changes „on the fly“ berücksichtigt werden und bei welchen Changes ein eher förmliches Verfahren sinnvoll ist. Die frühzeitige Befassung hiermit dient auch dazu, mögliche Projektrisiken zu identifizieren und soweit möglich bereits von vornherein optionale Maßnahmen zur Reduzierung dieser Risiken zu bestimmen (wenn etwa ggf. zu viele Länderanforderungen umgesetzt werden müssen, kann es sinnvoll sein alternativ zumindest bestimmte Mindeststandards für alle Länder anzustreben).

6. Wieso steht und fällt ein agiles Softwareprojekt mit dem Grad der Transparenz?

Der wahrscheinlich wichtigste Regelungsgegenstand sind Mechanismen und Berichtspflichten über maßgebliche Aspekte der Projektumsetzung im Vergleich zur geplanten Projektumsetzung. So banal dies klingt, so wenig wird dies oftmals in der Praxis beachtet. In der Nachschau ist es beinahe immer frühzeitig erkennbar, wenn ein (agiles) Projekt in Schieflage gerät. Oftmals liegen beiden Parteien hierzu aber jeweils nur Teilinformationen vor, die allein in der Zusammenschau derartige Schlussfolgerungen ermöglichen.

Es ist daher elementar zu bestimmen, welche Personen in einem Projekt miteinander regelmäßig sprechen müssen und welche Informationslage diese benötigen. Die wichtigsten Informationen betreffen insofern regelmäßig

• erfolgte Änderungen/Überschreitungen des Scopes,
• fehlende Key Ressourcen, sowie
• tatsächliche Velocity vs. erforderlicher Velocity.

7. Wieso ist ein anfängliche Projektbegleitung durch Legal sinnvoll?

Der wohl zweitwichtigste Umstand für erfolgreiche agile Projekte ist, dass die vereinbarten vertraglichen Regelungen auch gelebt werden. Es ist nicht zielführend, wenn etwas auf dem Papier steht, die relevanten Informationen aber nicht bis auf die relevanten Ebenen durchgereicht werden.

Insbesondere Berichte zum Projektfortschritt werden keinen Erfolg haben (mögen sie noch so gut sein), wenn sie nicht beachtet und insbesondere auf ihrer Grundlage rechtlich unkluge Entscheidungen getroffen werden. Bei einem Projektverzug etwa weichen die Projektverantwortlichen oftmals von den vertraglich vorgesehen Mechanismen für einen Projektverzug ab und treffen dann in E-Mails/Meetings vollkommen andere Absprachen. Gerade der Auftraggeber kompromittiert damit oftmals seine gesetzlichen sowie vertraglich gesicherten Rechte und damit sein Druckmittel. Umgekehrt machen Auftragnehmer in kritischen Projekt-Situationen oftmals nicht erfüllbare Kapazitätszusagen oder weichen auf parallele Sprints aus, wodurch die Projektstruktur- und Qualität insgesamt gefährdet wird.

Fazit

Es dürfte unstreitig sein, dass agile Projektmethoden im Softwarebereich deutlich mehr Chancen als Risiken bieten. Gerade große Unternehmen in der Automobilbranche, die in einem volatilen Umfeld agieren, sind aber gut beraten, ihre Prozesse für agile Projekte nicht derart schematisch aufzubauen, dass die Vorteile einer agilen Projektumsetzung gefährdet werden.

Ein Großteil der hierüber aufgeführten Probleme und Lösungsansätze ist ebenso für rein interne agile Softwareprojekte relevant, dann zwar nicht in Form von Verträgen, aber zumindest Absprachen.