Prostep | Newsletter

Agile Methoden in Großkundenprojekten

Von Norbert Lotter

Agile Methoden sind heute State-of-the-Art im IT-Projektmanagement. Auch Konzerne wenden sie in großen IT-Projekten an, die sie gemeinsam mit Dienstleistungsunternehmen umsetzen. Das am weitesten verbreitete agile Vorgehensmodell ist dabei Scrum, das inzwischen das traditionelle Wasserfallmodell und seine Varianten weitgehend abgelöst hat. Es erfordert allerdings eine Neudefinition der Kunden/Lieferantenbeziehungen.

Große IT-Projekte mit externen Dienstleistern wurden in der Vergangenheit üblicherweise im Rahmen von Werkverträgen abgewickelt und zum Festpreis abgerechnet. Dieses Modell ist mit agilen Methoden insofern unverträglich, als es hier zu Projektbeginn keinen fest umrissenen Lieferumfang mehr gibt, der Gegenstand einer formellen Abnahme und Abrechnung sein könnte. Stattdessen gibt es eine grobe Zielvorgabe (Produktvision), ein Zeitfenster und ein Team. Das Management des Kunden muss also eine Investitionsentscheidung ohne detaillierte Kostenschätzung treffen, eher im Sinne einer Absichtserklärung: Wir werden in einem definierten Zeitraum die Summe von x EUR investieren, um ein bestimmtes Ziel zu erreichen, ohne die Ergebnisse im Detail im Voraus zu kennen und eine vertragliche Grundlage zu haben, um das Ergebnis notfalls einzufordern.

Das erfordert nicht nur ein Umdenken beim Projektcontrolling, es hat auch direkte Auswirkungen auf die Vergütungsregelung, denn es müssen messbare Kriterien zur Bewertung der Lieferantenleistung identifiziert werden. Im Wesentlichen gibt es dabei zwei Varianten: Abrechnung nach geleisteter Arbeitszeit (Time & Material) oder nach Arbeitsergebnissen (Agiler Festpreis). Das Time & Material Modell ist organisatorisch einfacher umzusetzen, verschiebt das Projektrisiko jedoch komplett zum Auftraggeber. Das ergebnisbasierte Modell ist im Prinzip ein Festpreismodell mit sehr kleinen Abrechnungseinheiten (User Stories), dessen Randbedingungen durch einen Rahmenvertrag geregelt sind. Es erfordert deutlich mehr organisatorischen Aufwand für Abnahme und Abrechnung, führt aber in der Konsequenz zu höherer Transparenz und einer gleichmäßigeren Risikoverteilung.

Problematisch können Konflikte bei der Aufwandsbewertung von User Stories werden, denn es herrscht mehr oder weniger eine Pattsituation. Schätzt der Lieferant eine User Story deutlich höher ab, als das der Auftraggeber akzeptieren will, kann keine Seite die andere zwingen, ihre Sicht der Dinge zu akzeptieren. Das bedeutet in der Konsequenz, dass Bewertungskonflikte konstruktiv im Rahmen der Zusammenarbeit gelöst werden müssen. Hier wird eine generelle Eigenschaft agiler Zusammenarbeitsmodelle besonders deutlich sichtbar: Sie setzen sehr viel beiderseitiges Vertrauen und eine hohe Bereitschaft zur konstruktiven Lösung von Konflikten voraus. Befürworter agiler Prinzipien werden dem entgegnen, dass das für die erfolgreiche Umsetzung von IT-Projekten generell gilt und agile Vorgehensmodelle wie Scrum nur einen methodischen Weg aufzeigen, damit professionell und ergebnisorientiert umzugehen.

Scrum ist an sich nur für Teams mit einer Größe von bis zu neun Personen konzipiert. Industriell relevante Software wie PLM-Systeme erfordern jedoch weit größere Entwicklungsmannschaften, so dass sich die Frage stellt, wie sich die Zusammenarbeit einer mehr oder weniger großen Zahl von Scrum-Teams effizient organisieren lässt.

Die in der Literatur vorgeschlagenen Ansätze wie LeSS oder SaFe basieren typischerweise auf einem Modell mit mehreren Ebenen, wobei auf der unteren Ebene die operative Arbeit und auf den oberen die Koordination stattfindet. LeSS verfolgt z.B. das Ziel der Minimierung von Overhead, hier entsenden die operativen Teams Vertreter in die Teams der oberen Ebene, der Scrum-Prozess wird nur geringfügig abgewandelt. SaFe, das derzeit am häufigsten verwendet wird, führt insgesamt drei Ebenen und zahlreiche neue Rollen und Events ein.

Wie gut Scrum in der Praxis tatsächlich skaliert, wird unterschiedlich bewertet. Für die wesentlichen Probleme bei der Koordination kreativer Arbeit in großen Organisationen gibt es keine einfache Lösung. Es ist jedoch zu beobachten, dass mit wachsender Größe der Projektteams verbindliche, für alle Akteure gültige inhaltliche und technische Festlegungen und ein tiefgehendes, gemeinsames Verständnis des Gesamtziels kritische Erfolgsfaktoren sind. Sie zu vermitteln ist wichtiger als die vermeintlich perfekte Skalierungsmethode zu finden.


Die Anwendung des agilen Vorgehensmodells birgt gewisse Risiken, wenn umfassendere Digitalisierungsmaßnahmen in einer in einer gewachsenen Unternehmens-IT umgesetzt werden sollen. Es kann nämlich dazu verführen, auch größere Projekte ohne ausreichende Klärung von Zielen und Randbedingungen zu beginnen und zu hoffen, dass man im Projektverlauf in der Lage ist, diese Klärung herbeizuführen. Das endet häufig in teuren Sackgassen. Leider gibt die Methodik keine klaren Empfehlungen dazu, was man vorab wie detailliert klären und festlegen sollte. Die Projektbeteiligten müssen also aus eigener Erfahrung diese Entscheidung treffen und einen Mittelweg zwischen kreativem Chaos und Überspezifikation à la Wasserfallmodell finden.

Die Erfahrung zeigt, dass vor allem fehlendes Prozesswissen und unzureichende Analyse des Datenmodells zu teuren Fehlentwicklungen führen können, die sich mit etwas mehr konzeptioneller Vorarbeit vermeiden oder zumindest reduzieren ließen. Daraus lässt sich als Konsequenz ableiten – und das gilt in besonderem Maße für Projekte im Umfeld des Digital Twin – dass auch bei der agilen Vorgehensweise der Prozess- und Datenmodellbeschreibung so viel Aufmerksamkeit gewidmet werden muss, dass frühzeitig eine solide konzeptionelle Grundlage für die Realisierung der gewünschten Funktionalität vorhanden ist. Diese Information sollte dann auch allen Projektbeteiligten vermittelt werden, damit die gestalterischen Freiräume, die agiles Arbeiten schafft, auch im Sinne des Gesamtziels genutzt werden können.

© PROSTEP AG | ALL RIGHTS RESERVED | IMPRESSUM | DATENSCHUTZERKLÄRUNG HIER KÖNNEN SIE DEN NEWSLETTER ABBESTELLEN.