Es könnte so schön sein: Als neues Teammitglied wendet man sich einem Softwareprojekt zu, alle wissen, was sie zu tun haben, die Anforderungen sind klar und verständlich und das Team beherrscht die Technik (und nicht umgekehrt). Gibt es doch mal Probleme, dann kümmern sich eigens dafür vorgesehene Rollen darum, und räumen die Schwierigkeiten beiseite. Die Organisation sorgt dafür, dass alle in Ruhe arbeiten können. Am Ende hat man dann eine Sache ganz gewiss erreicht: Anwender beziehungsweise Kunden erhalten ein Produkt mit echtem Mehrwert. Das klingt doch zu schön, um wahr zu sein!

Aber ist es nicht häufig so, dass man als neues Teammitglied in ein Softwareprojekt hineingerät, und eben nicht alle wissen, was sie zu tun haben, und die Anforderungen ebenso wie die Technik unbeherrschbar sind? Mit den Problemen steht man häufig alleine da, Kunden und Anwenderinnen erhalten schließlich kein Produkt mit Mehrwert, und Projektziele erreicht das Team nur unzureichend.

Dazu gibt es tatsächlich Statistiken wie der Standish Group Chaos Report aus dem Jahre 2020. Die Teilnehmenden der zugrunde liegenden Umfragen waren überwiegend IT-Führungskräfte von Dienstleistern aus verschiedenen Branchen wie Banken, Versicherungen, Fertigung, Einzelhandel, Gesundheitswesen sowie aus öffentlichen Einrichtungen auf lokaler, staatlicher und föderaler Ebene. Dabei bezieht sich der Report auf den globalen Markt.

Die Zahlen besagen, dass 31 Prozent aller Softwareprojekte erfolgreich verlaufen, das heißt, die Projekte bleiben innerhalb der Zeitplanung, innerhalb des Budgets und liefern am Ende den besagten Mehrwert für die Anwender beziehungsweise Kunden. Aber was ist mit den restlichen 69 Prozent? Die Hälfte der Projekte haben zumindest enorme Probleme verschiedenster Art (u. a. wird das Budget überschritten), und 19 Prozent scheitern vollständig, das heißt sie kommen nicht zu einem befriedigenden Ende, und verursachen ausschließlich Kosten.

Im Fokus dieses Artikels stehen eben diese Projekte, die zu den 50 Prozent gehören, die Projekte, die (noch) nicht vollständig gescheitert sind, aber auch noch nicht auf gutem Kurs – also Sanierungsfälle, die man wieder in die richtige Richtung drehen kann. Und richtige Richtung bedeutet: Am Ende wird den Kunden tatsächlich ein Produkt mit Mehrwert geliefert.

Welche Faktoren führen zu Problemen?

Es gibt sehr viele Faktoren, die (nicht nur) in Softwareprojekten zu Problemen führen können. In Sanierungsfällen stößt man häufig unter anderem auf folgende Herausforderungen:

• Unklare Anforderungen: Der Kunde ist nicht in der Lage, das, was er haben will, klar zu artikulieren, wodurch Anforderungen widersprüchlich oder unbrauchbar sind. Immer neue Sonderfälle führen zum gefürchteten Scope Creep: Die schleichende Ausweitung des Projektumfangs, wobei häufig weder Zeit noch Budget oder Ressourcen entsprechend angepasst werden.
• Unrealistische Deadlines: Den Kunden werden Lieferzeitpunkte von Features versprochen, ohne vorher mit dem Entwicklungsteam gesprochen zu haben. Das Team kann jedoch nicht rechtzeitig liefern, weil es zu viel zu tun gibt. Dadurch entsteht Unzufriedenheit, und auf Dauer leidet die Qualität der Software, da das Team nebenbei immer neue Brandherde löschen muss.
• Strukturlose Agilität: Es wird viel von agilen Methoden oder agilen Transformationen gesprochen, aber die Umsetzung erfolgt oft nur halbherzig. Prioritäten ändern sich täglich, weil man „agil arbeitet“, und aus dem gleichen Grund existiert auch keine langfristige Planung. Stakeholder beginnen, sich in Meetings und kurzfristigen Planungen einzumischen, da sie das Gefühl haben, die Kontrolle zu verlieren.
• Unkontrolliert eskalierende technische Schulden: Aus Zeitgründen wird schnell etwas implementiert, und „wir verbessern das später“ ist das Mantra innerhalb des Projekts. Die Zahl von Workarounds und Quickfixes steigt, und irgendwann verbringen Entwicklerinnen und Entwickler mehr Zeit damit, über den Code und das Projekt zu fluchen, als neue Features zu implementieren. Davor haben sie ohnehin Angst, denn jede Codeänderung kann unvorhersehbare Konsequenzen mit sich bringen.
• Politik und Machtkämpfe: Es gibt viele Projektbeteiligte, die etwas zu sagen haben, was dazu führt, dass es häufig lange dauert, bis Entscheidungen getroffen werden, da niemand für vermeintlich falsche Entscheidungen verantwortlich sein möchte. Es gibt aus dem Management unterschiedliche, teilweise sich widersprechende Anforderungen, und Features werden aus politischen Gründen entwickelt oder blockiert.

Diese Liste lässt sich beliebig fortsetzen und soll nur einen kleinen Eindruck vermitteln, welche Problematiken häufig anzutreffen sind. Oftmals ist es jedoch so, dass sich diese Probleme zunächst verstecken und neuen Mitarbeitenden erst nach einiger Zeit im Projekt auffallen.

Echte Probleme aus echten Projekten

Wie sieht die Praxis aus? Zur Veranschaulichung dienen zwei beispielhafte Sanierungsfälle. Sie zeigen, wie dort eingesetzte Kollegen aus dem Unternehmen des Autors mit den dort vorherrschenden Problemen umgegangen sind.

Ein Disclaimer vorab: Ähnlichkeiten mit „lebenden oder toten Projekten“ sind rein zufällig – niemand sollte sich in einem der Projekte wiedererkennen können, Inhalte und Branchen sind verschleiert, einige Stellen sind überzeichnet, andere vereinfacht. Die zugrundeliegenden Probleme entsprechen jedoch der Realität.

Kaufen, kaufen, kaufen – E-Commerce

Das erste Beispiel führt in den E-Commerce-Sektor. Inhaltlich geht es um das Thema Identitätsmanagement. Grundsätzlich soll die SSO-(Single Sign-on)-Funktionalität von Keycloak, einer Open-Source-Software für Identitäts- und Zugriffsmanagement (Identity and Access Management, IAM) um weitere Services angereichert werden. Als besonderer Bonus: Das Projekt soll annähernd auf der sogenannten grünen Wiese starten – für den Kollegen, der als Lead-Developer fungiert und dem ein neues Team versprochen wird, scheinbar ein Glücksgriff. Bei diesem Sanierungsfall lagen die Probleme allerdings kurz nach Start in das Projekt bereits klar auf der Hand:

Beim versprochenen Entwicklerteam handelte es sich um drei Mitarbeitende, die zwar aus IT-affinen Umfeldern kamen, jedoch nicht über eine klassische Entwicklerausbildung verfügten. Tatsächlich handelte es sich mehr oder weniger um Hobbyprogrammierer, die nie zuvor mit Java Software entwickelt haben, und Java war als Sprache gesetzt.

Diese drei hatten bereits angefangen, etwas zu implementieren, es war jedoch unbrauchbar – sowohl vom Design als auch von der konkreten Codequalität her. Darüber hinaus erwiesen sich die Anforderungen als vollkommen unklar. Unterschiedliche fachliche Ansprechpartner lieferten verschiedene Aussagen, die sich häufig sogar widersprachen. Detailwissen über Prozesse und Use Cases existierte nicht.

Im Projekt gab es niemanden, der die wenigen vorliegenden Anforderungen entgegennahm, um sie für die Entwicklung aufzubereiten und zu priorisieren – in agilen Projekten wäre das etwa ein Product Owner.

So konnte das Entwicklungsteam zunächst nur auf Basis der wenigen bekannten Anforderungen arbeiten, und wenn man den fachlichen Ansprechpartnern den aktuellen Stand zeigte, führte das häufig dazu, dass das Entwicklungsteam wieder zurück in den Code musste, weil (vorher unbekannte) Sonderfälle nicht berücksichtigt wurden.

Zu guter Letzt gab es kein Vorgehensmodell sowie kein wirkliches Projektmanagement. Es gab lediglich das Entwicklungsteam mit einem Lead-Developer und einige am Projekt beteiligte Mitarbeitende, die gelegentlich Aussagen über die Anforderungen machten. Unabhängig davon gab es natürlich ein Management, das Ergebnisse sehen wollte, aber nicht verstehen konnte, warum das Entwicklungsteam nicht vernünftig arbeitet.