Du hast deinen AdBlocker an?

Es wäre ein Traum, wenn du ihn für t3n.de deaktivierst. Wir zeigen dir gerne, wie das geht. Und natürlich erklären wir dir auch, warum uns das so wichtig ist. Digitales High-five, deine t3n-Redaktion

Interview

Mega-Panne bei der Bundesagentur für Arbeit: Mit agiler Entwicklung wäre das nicht passiert

(Grafik: Shutterstock)

Dass große Software-Projekte in einem späten Stadium scheitern können, hat das Projekt der Bundesagentur für Arbeit gezeigt. Wie Unternehmen das vermeiden, sagt uns ein Experte im Interview.

Ein 60-Millionen-Euro-Grab hat die Bundesagentur für Arbeit mit dem Robaso-Projekt geschaffen. Es sollte 14 verschiedene Plattformen vereinen und die Vorgänge in den Arbeitsagenturen vereinfachen. Nach mehrjähriger Entwicklung hatte sich das Projekt im Praxiseinsatz nicht beweisen können. So sei beispielsweise das Ändern einer Kontonummer schlicht nicht möglich gewesen. Da die Behebung der Fehler zu aufwendig und teuer geworden wäre, wurde das Projekt eingestellt.

Gerade bei großen Software-Projekten mit klassischen Methoden ist die Gefahr groß, irgendwann an einem Punkt zu sein, an dem schwerwiegende Fehler schwierig zu beseitigen und vor allem teuer sind. Wir haben mit Stefan Roock, Management-Coach für agile Transitionen (Scrum und Kanban) bei IT-Agile, gesprochen. Darüber, wie Verantwortliche Probleme früher bemerken – und wann ein Großprojekt überhaupt noch zu retten ist.

t3n.de: Mit dem Robaso-Projekt der Bundesagentur für Arbeit ist ein Software-Millionen-Projekt gescheitert. Wie kann es passieren, dass Probleme erst so spät bemerkt werden?

Stefan Roock: In klassisch-sequenziellen Vorgehensweisen ändert sich die Art der Arbeit von Phase zu Phase. Analyse ist etwas ganz anderes als Design und Design etwas ganz anderes als Programmierung. Daher kann man aus der Geschwindigkeit in einer Phase nicht auf die Geschwindigkeit in Folgephasen rückschließen.

Ein anderes Problem ist, dass die Phasen-Ergebnisse nicht sinnvoll qualitätsgesichert werden können. Wie soll man sinnvoll feststellen, ob man in der Analysephase alle relevanten Anforderungen erfasst hat. Oft versucht man dieses Problem mit Masse zu erschlagen. Man sucht ganz intensiv nach allen möglichen Anforderungen. Und dann entsteht auf einmal ein anderes Problem: Man kann nicht feststellen, welche Anforderungen man nicht braucht. Und dann erstickt man in Komplexität. Jeder arbeitet an Einzelteilen und niemand versteht mehr das große Ganze.

Die Bundesagentur für Arbeit hat letzte Woche ein 60 Millionen Euro teures Software-Projekt namens Robaso eingestellt. (Foto: dpa)

Wenn du an deine Erfahrung als Coach denkst: Woran scheitern große Projekte oft?

Häufig leiden große Projekte einfach daran, dass sie unnötig groß sind. Man glaubt, alles von Anfang an berücksichtigen zu müssen. Da schwingt häufig auch der Irrglaube mit, dass alle 1.000 Funktionen Must-Have-Funktionen sind und man daher erst nach Jahren ein erstes Release produktiv nutzen kann.

Und dann verliert man leicht den Überblick. Wenn das dann noch mit einer Projektkultur kombiniert wird, in der keine Fehler gemacht werden dürfen, werden Probleme zu spät thematisiert und Gegenmaßnahmen werden gar nicht oder zu spät eingeleitet.

Ich habe in 20 Jahren Software-Entwicklung keinen einzigen Fall gesehen, wo tatsächlich alle „Must-Have“-Features tatsächlich notwendig gewesen wären. Es ließ sich immer eine Möglichkeit finden, die Software deutlich früher produktiv zu nutzen. Dazu muss man mitunter mal „um die Ecke“ denken und häufig auch in Kauf nehmen, etwas Zusatzaufwand für Adapter zu investieren. Dieser Zusatzaufwand ist aber meist gut investiert, weil eine frühe produktive Software-Nutzung einen ganz erheblichen Beitrag zur Risikoreduktion hat.

Wie sollten Unternehmen große Projekte angehen, um das Scheitern zu vermeiden?

Das Wichtigste ist, die Software sehr früh produktiv zu nutzen. Ich strebe stets drei Monate oder kürzer an. In Ausnahmefällen können es auch auch sechs Monate werden. Danach wird die ganze Geschichte aber extrem heikel.

Stefan Roock ist Management-Coach und hat seit 1999 Erfahrung mit agilen Projekten. (Foto: Stefan Roock)

Wenn man innerhalb dieser Releases alle Phasen parallel durchführt, bleibt die Art der Arbeit während der ganzen Projektlaufzeit identisch. Im ersten Monat wird analysiert, entworfen, programmiert und getestet, genauso im zweiten etc. Dadurch kann man zumindest grob auf Basis der Vergangenheit abschätzen, wie produktiv man in der Zukunft sein wird.

Außerdem werden Zwischenergebnisse wie Anforderungsbeschreibungen binnen weniger Tage in lauffähige Software überführt. Damit kann kontinuierlich an der Software überprüft werden, welche Features wirklich benötigt werden. Natürlich müssen die Entwicklungsteams durch den Einsatz passender Architekturen und agiler Entwicklungspraktiken Code entwickeln, der sich leicht ändern lässt.

Sprich: Agile Softwareentwicklung ist ein guter Mechanismus, um Probleme sehr frühzeitig aufzudecken. Dann hat man noch gute Möglichkeiten, sinnvoll auf die Probleme zu reagieren. Wenn man die Probleme allerdings nicht sehen will, die sich offenbaren, wird man auch „agil“ eine Bauchlandung hinlegen.

Wann ist es zu spät, Großprojekte noch zu retten? Ist es unabdinglich, direkt von Anfang an auf agile Methoden zu setzen?

Ich habe eine ganze Reihe gescheiterter Projekte gesehen, die klassisch begonnen wurden. Allerdings ließen sich diese mit agilen Verfahren immer noch retten. Eine Rettung erscheint mir vor allem dann nicht möglich, wenn die Entwickler ihr Handwerkszeug nicht beherrschen und unwartbaren Code geschrieben haben.

Daher muss man nicht unbedingt von Anfang an auf agile Methoden setzen. Es erleichtert die Sache aber ungemein.

Oft ist es schwierig, alteingesessene Methoden über den Haufen zu werfen. Wie gelingt es, großen Unternehmen die agile Softwareentwicklung näher zu bringen?

Wenn die Katastrophe bereits eingetreten ist, sind Unternehmen natürlich bereit, auch ungewohnte Lösungswege zu versuchen. Es kann ja nicht mehr schlechter werden. Der Charme an so einer Situation ist, dass auch sehr weitreichende agile Ansätze ausprobiert werden können.

Wichtig ist auf jeden Fall, dass die Unternehmen überhaupt einen Änderungsdruck verspüren. Wenn das nicht der Fall ist, wird es meist schwierig. Die Transition zu agilen Denk- und Arbeitsweisen ist schmerzhaft und das wird man sich nicht antun, wenn alles gut läuft.

Was sind deine Tipps für die Anfänge in der agilen Softwareentwicklung?

Ich finde Jeff Pattons Buch über User Story Mapping großartig. Im Zweifel empfehle ich natürlich das Buch „Scrum – verstehen und erfolgreich einsetzen“, das ich zusammen mit Henning Wolf geschrieben habe.

Vielen Dank für das Gespräch!

Finde einen Job, den du liebst

Bitte beachte unsere Community-Richtlinien

5 Reaktionen
Jan Setzer

Unabhängig von den Vor- und Nachteilen der verschiedenen Entwicklungsmethoden: Es sei noch angemerkt, dass das derzeitige Vergaberecht im öffentlichen Sektor eher ungeeignet ist für agile Ansätze in der Softwareentwicklung. Es ist Irrglaube, dass durch ein Vergabeverfahren bereits vor Auftragserteilung Endpreis und Fertigstellungszeitpunkt komplexer IT-Projekte festgesetzt werden könnten. Per Definition zeichnet sich ein Projekt durch eine gewisse Erstmaligkeit und Komplexität aus. Sonst wäre es kein Projekt sondern Fertigung. Es lebt und verändert sich. Agil oder klassisch: Ein Projekt kann in beiden Welten zum Erfolg geführt werden. Das Problem ist nicht die Methodik. Das Problem ist die Festlegung auf Umfang, Kosten und Budget zu einem Zeitpunkt weit vor Beginn der Arbeiten.

Antworten
Robert Willemelis

Agilität heißt ja auch mehr als Meetings mit bunten Zetteln. Es bedeutet ein mehr an Kommunikation, ein ständiges Feedback sowohl in der Codereview oder Pair-Programming als auch an dem gemeinsamen Verständnis und dem Umgang mit neuen Anforderungen als auch das Testen des MVP am Kunden. Klassisch wird nur das umgesetzt, was in Lasten -und Pflichtenheft vertraglich vereinbart wurde.

Und Agilität heißt nicht zwangsläufig schlechte Code-Qualität, sondern diese kommt von mangelnder Kommunikation, zu schnellem Umsetzen und fehlenden Code Conventions und Deployment-Prozessen.

Hier gibt es ein paar Tipps wie man damit umgeht:
https://www.amazon.de/dp/B00QXAGIDO/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1

Antworten
egghat (@egghat)

Ich empfehle einen weiteren Artikel zum Thema:

https://entwickler.de/online/agile/robaso-agile-projekte-scheitern-579778658.html

Darin sieht man schön, dass man allein mit dem Buzzwrd "agil" nicht weiter kommt. Klar, wenn man das sagt, kommt sofort der Einwand dass es nicht "richtig" agil gewesen sei. Aber der Artikel bei Entwickler.de zeigt IMHO sehr schön, dass allein "Agil" nicht die Lösung für scheiternde IT-Großprojekte ist. Und dass sich sowohl bei der Integration von vorhandenen IT-Projekten als auch bei der Skalierung ganz andere Herausforderungen stellen als wenn man eine Software von Grund auf neu baut (bei letzterem braucht man über die Überlegenheit der agilen Software-Entwicklung IMHO nicht mehr diskutieren).

Antworten
Lars

Ich finde die Aussage im Titel und teilweise auch im Artikel zu pauschal. Agile Entwicklung oder (oldschool) iterative Entwicklung können beide gleichermassen in die Hose gehen. Es hängt am Ende immer an den beteiligten Personen. Ein schlechter Scrum Master kann auch ein agiles Projekt zerlegen. Selbst erlebt habe ich, dass man sich in Workflow Deadlocks programmiert oder so in Stories und Tasks ertrinkt, dass man das eigentliche Projektziel vergisst.
Umfangreiche und komplexen Projekte mit einer grossen Anzahl von Abhängigkeiten gerade in der Industrie oder im öffentlichen Sektor bergen immer ein grösseres Risiko des Scheiterns. Die Programmierung selbst ist bei Grossprojekten doch der kleinste Teil. Nach meiner Erfahrung scheitert es häufig schon an der Definition der Stakeholder und der Definition der Workflows in der Applikation. Da spielt es keine Rolle ob ich klassisch mit Volere Template in iterativen "Häppchen" arbeite oder agil mit Sprints.
Die Methode löst in den meisten Fällen nicht die zu Grunde liegenden Probleme wie mangelnde Organisation, Desinteresse der Beteiligten oder fehlendes Verständnis für Prozesse.

Antworten
Ilja Preuß

Tatsächlich lösen agile Vorgehen *gar keine* Probleme. Was sie erlauben ist, Probleme sehr schnell aufspürbar zu machen, so dass ich sie managen kann, bevor das Kind vollständig in den Brunnen gefallen ist. Und wie Stefan selber gesagt hat: wenn ich dann vor den Problemen die Augen verschließe, nützt mir auch die agilste Methode nichts.

Antworten

Melde dich mit deinem t3n Account an oder fülle die unteren Felder aus.