Suche
Was wir aus dem Robaso-Debakel lernen können

Tote Projekte – oder tote Methoden? Warum (agile) Projekte scheitern

Ann-Cathrin Klose

© Shutterstock.com / blocberry

ROBASO ist gescheitert. Seit 2010 investierte die Bundesagentur für Arbeit 60 Millionen Euro in das Softwareprojekt; im Februar 2017 wurde die Arbeit daran abgebrochen. Sind agile Methoden der Ausweg aus dieser Situation – oder selbst längst zum Scheitern verurteilt?

ROBASO steht für Rollenbasierte Oberflächen und sollte die bisher 16 unterschiedlichen Softwarelösungen zusammenfassen, die bei der Bundesagentur für Arbeit zum Einsatz kommen. So sollte die Kundendaten künftig in einer einzelnen Oberfläche erfasst werden; die Notwendigkeit von Programmwechseln und Doppeleingaben der Daten hätte sich dadurch reduzieren sollen.

ROBASO zu spät von Anwendern getestet

Das 2010 gestartete Projekt wurde im Herbst 2015 erstmalig seinen vorgesehenen Anwendern im Rahmen einer Pilotphase vorgestellt. Dabei ließen sich laut Medienberichten zahlreiche Schwächen erkennen: Eine Änderung der Kontonummer eines Leistungsempfängers sei in ROBASO nur möglich, wenn alle Kundendaten neu eingegeben werden, wurde über das Projekt berichtet. Das Anwendungsziel wurde somit weit verfehlt.

Lesen Sie auch: Die Scrum-Revolution – Projektmanagement im Wandel

Wie die Bundesagentur für Arbeit in einer Pressemitteilung bekannt gab, sei eine nachträgliche Änderung der entsprechenden Funktionen nicht zeitnah und wirtschaftlich möglich gewesen. Dies habe ein externes Audit bestätigt, sodass der Projektabbruch im Februar 2017 beschlossen wurde. 60 Millionen Euro wurden zuvor in das Projekt investiert; der Bundesrechnungshof soll die Angelegenheit nun prüfen.

Das klingt nach der typischen Gruselgeschichte aus alten Wasserfalltagen, also der Zeit vor dem Aufkommen agiler Methoden. Anforderungen, einmal zu Projektbeginn definiert, wurden nie wieder kontrolliert; Projekte, bei denen erst nach Abschluss auffällt, dass sie das Ziel komplett verfehlen – ein typisches Problem, wenn während der Projektlaufzeit keine Kommunikation zwischen Auftraggeber und IT-Dienstleister erfolgt. In Zeiten der agilen Arbeitsweise sollte das aber nicht mehr vorkommen.

Künftige Agilität…

Das scheint auch der Bundesagentur für Arbeit bewusst zu sein. In ihrer Pressemitteilung zum Abbruch des Projekts ROBASO verweist die Bundesagentur auf das Vorhaben, künftig auf agile Methoden zu setzen, um weitere Fehlschläge dieser Größenordnung zu vermeiden:

„Die Entwicklung neuer Software erfolgt in überschaubaren Stufen mit begleitenden Anwendertests in der Praxis.“

Aber ist Agile denn wirklich noch Neuland für die Bundesagentur für Arbeit? Nein. Laut einer Präsentation zum „Projekt-, Programm- und Portfoliomanagement in der BA“ aus dem Mai 2016, gehalten von Ulrich Völkoi (Bereichsleiter ITP1 Strategie bei der Bundesagentur), begann man mit der Einführung agiler Methoden während der Arbeit an Allegro.

Allegro steht für „Arbeitslosengeld II Leistungsverfahren Grundsicherung Online“; die Arbeit an diesem System, das seit 2014 erfolgreich im Einsatz bei der Bundesagentur ist, begann im Jahr 2008. Wie inkrementelle Softwareentwicklung funktioniert, hätte beim Projektstart von ROBASO also bereits bekannt sein können. Der flächendeckende Einsatz agiler Methoden soll allerdings erst im Jahr 2014 begonnen haben, wie Marvin Strathmann für die Süddeutsche Zeitung berichtet.

…oder gegenwärtige Skalierungsprobleme?

ROBASO wird in der Präsentation aus dem Jahr 2016 jedoch als eines der zukunftsweisenden Projekte benannt, mit denen die Bundesagentur für Arbeit „noch konsequenter in Richtung Agilität“ gehen wolle:

© Bundesagentur für Arbeit: Robaso als agiles Projekt?

© Bundesagentur für Arbeit: Robaso als agiles Projekt?

500 Köche verderben den Brei

Wurde ROBASO nun also agil entwickelt oder nicht? Das Projektende und die dazu führenden Fehler im Projektverlauf deuten darauf hin, dass das nicht der Fall war; auch agil geführte Großprojekte können jedoch scheitern. Wie Sven Eisenkrämer für Springer Professional berichtet, seien nämlich zeitweise bis zu 500 Entwickler zeitgleich an ROBASO beteiligt gewesen. In diesem Kontext betrachtet, könnte ROBASO auch ein Beispiel für die Grenzen der Anwendbarkeit agiler Methoden sein.

Große Projekte scheitern häufiger als kleine Projekte, das ist erst einmal wenig überraschend. Das gilt sowohl für Projekte, die nach der Wasserfallmethodik entwickelt wurden, als auch für agile Projekte. Für den CHAOS Report 2015 der Standish Group wurden 50.000 IT-Projekte weltweit untersucht; über alle Projektgrößen hinweg gesehen, sind 29 Prozent der Wasserfallprojekte gescheitert. Für agile Methoden liegt die Zahl der Misserfolge über alle Projektgrößen hinweg bei nur neun Prozent. Für große Projekte fand die Standish Group jedoch ganze 23 Prozent gescheiterter agiler Projekte; bei Wasserfall-Projekten waren es 42 Prozent in derselben Größenordnung.

Skalierbarkeit als agile Achillesferse

Woran liegt das aber? Agile gilt vielen Autoren als schlecht skalierbare Entwicklungsmethode. So sei es leicht, wenige, einzelne Teams auf agile Methoden umzustellen, jedoch ungleich schwerer, ganze Unternehmen oder sehr große Projekte agil zu leiten. Im Kontext eines Projekts, an dem 500 Entwickler zeitgleich arbeiten und das nicht einmal hausintern entwickelt wird, sondern offenbar durch verschiedene externe IT-Dienstleister, ist leicht verständlich, woran das liegen könnte. Wo in kleinen Projekten problemlos der Kontakt zwischen Entwicklern und Auftraggebern gehalten werden kann, ist eine Projektstruktur wie die des Projekts ROBASO nur schwer zu überblicken und erschwert somit eine mögliche agile Arbeitsweise massiv.

Lesen Sie auch: Agilität – Wie dynamisch sind Sie?

Das ist jedoch nicht der einzige Kritikpunkt an Agile und nicht das einzige Beispiel dafür, dass auch agile Methoden nicht immer zum Erfolg führen. Auch die agile Teamstruktur an sich könnte zu Problemen führen, glaubt Pete Heard. Er erklärt Agile sogar gleich für tot. Agile sei nicht auf eine hohe Code-Qualität ausgelegt, sondern führe immer wieder zu schlechtem Code. Das meint Heard und belegt seine Sichtweise mit einer Studie aus dem Jahr 2010.

Die vom Unternehmen Cast Software durchgeführte Untersuchung besagt, dass das durchschnittliche Softwareprojekt technische Schulden und Probleme mit der Code-Qualität im Umfang von einer Millionen US-Dollar ansammelt. Das liegt für Heard daran, dass in Agile immer wieder die notwendige Qualitätskontrolle des Codes unterlassen wird, weil die Schulung in der agilen Arbeitsweise Menschen obliegt, die häufig keine Ahnung von Code haben. Wenn der Scrum Master kein IT-Profi ist, könne er die Code-Qualität als agilen Maßstab schlecht überwachen. Auch das könnte also zum Scheitern großer agiler Projekte beitragen.

Ist Agile also gescheitert?

Aber ist Agile gleich tot, wie Heard glaubt, nur weil auch agile Projekte scheitern können und die Methode häufig als schlecht skalierbar angesehen wird? Auch einige der Autoren des agilen Manifests, das vor inzwischen 16 Jahren die Grundlagen vieler agiler Arbeitsweisen und Frameworks festgehalten und die weitere Entwicklung der Methodenwelt mitgeprägt hat, glauben, dass Agile tot ist. Agile sei kein Allheilmittel für IT-Projekte; sei zur Marke geworden, die verkauft wird und mehr an Regelwerken als an den ursprünglichen Grundwerten der inkrementellen Auslieferung zugunsten zufriedener Kunden orientiert sei.

Glaubt man der Präsentation der Bundesagentur für Arbeit, die ROBASO als agiles Projekt listet, könnte man fast glauben, dass die Kritiker Recht haben. Doch schaut man sich ROBASO im Detail an, deutet der von den Medien berichtete Projektverlauf jedoch eher auf folgendes hin: ROBASO war kein echtes agiles Projekt und kann somit auch nicht zur Kritik an Agile herangezogen werden.

Lesen Sie auch: Interview – “Schätzen ist wie eine Droge – lassen wir dieses dumme Spiel!”

Vielmehr noch: Eine korrekte Umsetzung agiler Methoden hätte diesen Fehlschlag vermutlich vermeiden können. Immerhin wären die berichteten Probleme so früher aufgefallen; eine inkrementelle Entwicklung hätte dazu geführt, dass nicht erst fünf Jahre nach Projektbeginn der erste Praxistest erfolgt. Trotzdem bleibt aber festzuhalten, dass auch agile Methoden nicht jeden Fehlschlag verhindern. Sie können nicht jedes Problem aus der Welt schaffen kann und müssen vor allem richtig umgesetzt werden. Bleibt die Code-Qualität auf der Strecke oder mangelt es an Kommunikation, können Projekte auch agil scheitern.

Lesetipp:

Scrum richtig anpassen: Vor- und Nachteile von Agile Hybrid-Frameworks

 

Verwandte Themen:

Geschrieben von
Ann-Cathrin Klose
Ann-Cathrin Klose
Ann-Cathrin Klose hat allgemeine Sprachwissenschaft, Geschichte und Philosophie an der Johannes Gutenberg-Universität Mainz studiert. Bereits seit Februar 2015 arbeitete sie als redaktionelle Assistentin bei Software & Support Media und ist seit Oktober 2017 Redakteurin. Zuvor war sie als freie Autorin tätig, ihre ersten redaktionellen Erfahrungen hat sie bei einer Tageszeitung gesammelt.
Kommentare
  1. TestP2017-02-24 12:39:25

    Tja, agile Softwareentwicklung funktioniert halt nur wenn sie von Entwicklern gemacht wird. Kommen noch Schwätzer ala "Scrum master" oder irgendwelche Manager dazu dann kann man es gleich knicken und das Weite suchen. Weil dann entwickelt man nicht mehr sondern verplempert seine Zeit mit Bürokratie und plant irgendwelche Sprints etc.

    Ist echt gut, dass ich einen sehr liberalen AG habe.

    Grüße

  2. Desi2017-02-26 03:21:13

    Du hast so was von Recht. Das ist die große Wahrheit, das keiner der sog. Leiter, Master, Manager, usw. hören will. Sie würden eingestehen, wie überflüssig sie sind.
    Ich suche auch immer das weite wenn IT-Fremde Meeting-Profis anfangen sich in dem Projekt einzumischen, es wird ungemütlich, zeitaufwendig, uneffektiv und... oft scheitert es auch.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.