In meiner beruflichen Laufbahn habe ich viele IT-Projekte erlebt, die mit guten Ideen, motivierten Teams und durchaus realistischen Zielen gestartet sind. Trotzdem wurden aus überschaubaren Aufgaben plötzlich umfangreiche Projekte, deren Umsetzung immer komplexer, langwieriger und riskanter wurde. Häufig lag das nicht einmal an den eigentlichen Anforderungen, sondern daran, wie mit ihnen umgegangen wurde.
Besonders interessant finde ich, dass selbst Projekte, deren technische Umsetzung vergleichsweise gut gelungen ist, am Ende noch erhebliche Schwierigkeiten bekommen können. Nämlich dann, wenn plötzlich die Frage aufkommt: Wie bekommen wir das jetzt eigentlich in den produktiven Betrieb?
Für mich gibt es deshalb zwei grundlegende Prinzipien, die wesentlich zum Erfolg von IT-Projekten beitragen: Große Aufgaben in kleine, sinnvoll lieferbare Schritte zerlegen und den Weg in die Produktion von Anfang an mitdenken. Beide Prinzipien hängen enger zusammen, als es auf den ersten Blick erscheinen mag.
Aus kleinen Aufgaben keine großen Probleme machen
Eigentlich klingt es selbstverständlich: Wenn wir vor einer großen Herausforderung stehen, versuchen wir, sie in kleinere, beherrschbare Aufgaben zu zerlegen. Genau das ist schließlich eine der grundlegenden Ideen agiler Softwareentwicklung.
In der Praxis beobachte ich allerdings immer wieder das Gegenteil. Aus einer zunächst überschaubaren Anforderung entsteht durch technische Überlegungen plötzlich ein umfangreiches Projekt. „Wenn wir dieses Feature umsetzen, sollten wir vorher noch diese Komponente modernisieren.“ Daraus ergibt sich die nächste Abhängigkeit, für die zunächst eine andere Architektur angepasst werden müsste. Und wenn wir ohnehin gerade dabei sind, könnten wir eigentlich auch noch das bestehende Datenmodell grundlegend überarbeiten.
Jede dieser Überlegungen kann für sich genommen durchaus sinnvoll sein. Schließlich möchten gute Entwickler keine kurzfristigen Lösungen schaffen, die später zusätzliche Probleme verursachen. Die Frage ist allerdings, ob die jeweiligen Abhängigkeiten tatsächlich zwingend notwendig sind oder ob wir sie durch unseren eigenen Anspruch an technische Perfektion erst erzeugen.
Aus einer kleinen Verbesserung wird auf diese Weise schnell ein umfangreiches Modernisierungsprojekt, dessen ursprünglicher Nutzen erst ganz am Ende sichtbar wird. Häufig wächst dabei nicht nur der Aufwand, sondern auch das Risiko. Mehr beteiligte Systeme, mehr technische Veränderungen und mehr gegenseitige Abhängigkeiten machen ein Projekt nicht automatisch besser.
Gute technische Architektur zeichnet sich für mich deshalb auch dadurch aus, dass sie Veränderungen in kleinen, möglichst unabhängigen Schritten ermöglicht, statt sie unnötig miteinander zu verknüpfen.
Agilität bedeutet, tatsächlich lieferbare Schritte zu schaffen
Hier liegt für mich einer der größten Vorteile einer richtig verstandenen Agilität. Es geht nicht darum, ein großes Projekt in viele kleine Tickets aufzuteilen und diese anschließend in zweiwöchigen Sprints abzuarbeiten. Wenn alle diese Tickets erst gemeinsam einen nutzbaren Stand ergeben, haben wir letztlich nur ein großes Projekt in kleinere Arbeitspakete zerlegt.
Entscheidend ist vielmehr, sinnvolle Iterationen zu finden, die jeweils einen eigenständigen Fortschritt ermöglichen. Das kann eine begrenzte Funktionalität sein, eine Verbesserung für eine bestimmte Nutzergruppe oder ein bewusst reduziertes MVP, das bereits einen tatsächlichen Nutzen liefert.
Ein MVP ist dabei keine Ausrede für schlechte Qualität. Es ist eine bewusste Entscheidung, zunächst nur den Umfang umzusetzen, der für einen sinnvollen ersten Schritt notwendig ist. Diese Unterscheidung erfordert Erfahrung und manchmal auch den Mut, auf technisch wünschenswerte Verbesserungen vorerst zu verzichten.
Natürlich lassen sich nicht sämtliche Abhängigkeiten vermeiden. Es gibt technische Grundlagen, die tatsächlich zuerst geschaffen werden müssen. Aber gerade hier lohnt es sich, kritisch zu hinterfragen, ob diese Voraussetzungen wirklich in ihrer vollständigen Ausprägung benötigt werden oder ob eine kleinere Lösung den nächsten sinnvollen Schritt bereits ermöglichen würde.
Das Ziel sollte sein, dass aus einem großen Projekt eine Folge überschaubarer Veränderungen entsteht, die einzeln umgesetzt, überprüft und möglichst auch produktiv genutzt werden können.
Das sind Grundprinzipien von agiler Softwareentwicklung. Das ist alles andere als neu, um so erstaunlicher, wie oft es einfach falsch gelebt wird. Was erfahrungsgemäß aber noch viel häufiger nicht gut mitgedacht wird:
Der Migrationsplan gehört an den Anfang, nicht ans Ende
Das zweite Prinzip wird aus meiner Sicht mindestens genauso häufig unterschätzt. Bei vielen Projekten wird sehr intensiv darüber nachgedacht, wie die neue Lösung technisch umgesetzt werden soll. Architektur, Anforderungen, Schnittstellen und Funktionalitäten werden diskutiert, geplant und entwickelt. Die Frage, wie der Übergang vom bestehenden System zur neuen Lösung erfolgen soll, wird dagegen gerne auf einen späteren Zeitpunkt verschoben.
Solange die Entwicklung läuft, erscheint das zunächst unproblematisch. Irgendwann ist die neue Lösung schließlich fertig (was auch immer „fertig“ ist), alle Tests sind erfolgreich und die wesentlichste Arbeit am Projekt scheint erledigt.
Doch dann kommen die unangenehmen Fragen. Wie stellen wir das bisherige System um? Was passiert mit bestehenden Daten? Wie lange dauert die Migration? Welche anderen Systeme sind betroffen? Was passiert, wenn etwas schiefgeht? Und vor allem: Können wir im Notfall wieder zurück?
Plötzlich wird aus einem erfolgreich umgesetzten Entwicklungsprojekt ein riskantes Migrationsvorhaben. Niemand möchte den berühmten „Big Red Button“ drücken, weil die Konsequenzen eines Fehlers möglicherweise erheblich wären.
Ich habe solche Situationen mehrfach erlebt. Eine technische Lösung war weitgehend fertig, aber der Schritt in die Produktion erforderte aufwendige Abstimmungen, zusätzliche Absicherungen und schwierige Entscheidungen. Gerade Geschäftsführungen und andere Entscheidungsträger lassen sich verständlicherweise nur schwer von einem riskanten Manöver überzeugen, wenn dessen Ausgang erhebliche Auswirkungen auf das operative Geschäft haben könnte.
Das eigentliche Problem ist dabei häufig nicht die fehlende Bereitschaft, Verantwortung zu übernehmen. Es ist vielmehr die Tatsache, dass wir das Risiko durch unsere Projektplanung selbst unnötig groß gemacht haben.
Jeder Schritt nach vorne braucht einen möglichen Schritt zurück
Genau hier greifen beide Prinzipien ineinander. Wenn wir Projekte von Anfang an in sinnvolle, produktiv nutzbare Iterationen aufteilen, können wir auch den Übergang in die Produktion schrittweise gestalten.
Statt ein bestehendes System an einem festgelegten Tag vollständig durch eine neue Lösung zu ersetzen, können wir beispielsweise zunächst einzelne Funktionen umstellen, ausgewählte Nutzergruppen migrieren oder neue und bestehende Komponenten übergangsweise parallel betreiben.
Dabei ist für mich ein weiterer Gedanke entscheidend: Bei jedem Schritt nach vorne sollten wir uns bereits überlegen, wie ein notwendiger Schritt zurück aussehen könnte.
Das alles lässt sich schwer in einfache Formeln gießen, das braucht Systemkenntnisse, Domänenwissen, Kundenkenntnis und oft auch einfach viel Erfahrung.
Was passiert, wenn die neue Funktion unter realen Bedingungen nicht wie erwartet arbeitet? Können wir sie gezielt deaktivieren? Können wir den bisherigen Prozess vorübergehend weiterverwenden? Sind Schnittstellen und Datenstrukturen so gestaltet, dass alte und neue Komponenten während des Übergangs miteinander funktionieren?
Natürlich ist ein vollständiger Rollback nicht immer möglich, insbesondere wenn Daten bereits verändert oder externe Prozesse angestoßen wurden. Umso wichtiger ist es, solche Situationen frühzeitig zu erkennen und geeignete Rückfall- oder Wiederherstellungsstrategien vorzusehen.
Es geht darum, irreversible Entscheidungen möglichst lange zu vermeiden und Veränderungen so zu gestalten, dass ihre Risiken beherrschbar bleiben.
Diese Überlegungen sollten nicht erst entstehen, wenn die neue Software fertig entwickelt wurde. Sie gehören bereits in die Architektur und in die Planung der einzelnen Iterationen.
Ein guter Release ist kein besonderes Ereignis
Wenn wir beide Prinzipien konsequent miteinander verbinden, verändert sich auch die Bedeutung eines Releases.
Anstatt über Monate auf einen einzigen großen Go-live hinzuarbeiten, werden produktive Veränderungen zum natürlichen Bestandteil des Projektverlaufs. Kleinere Releases lassen sich gezielter testen, ihre Auswirkungen leichter beurteilen und auftretende Probleme schneller eingrenzen.
Das reduziert nicht nur technische Risiken, sondern erleichtert auch die notwendigen Entscheidungen. Es macht einen erheblichen Unterschied, ob eine Geschäftsführung eine vollständige Systemumstellung mit schwer abschätzbaren Konsequenzen freigeben soll oder ob ein Team eine überschaubare, gut abgesicherte Veränderung produktiv nehmen möchte.
Ein guter Release sollte im Idealfall keine besondere Anspannung erzeugen. Er sollte ein weitgehend routinierter Schritt innerhalb eines kontinuierlichen Entwicklungsprozesses sein.
Das bedeutet selbstverständlich nicht, dass jeder Go-live vollkommen risikofrei sein kann. Aber wir können sehr wohl beeinflussen, wie groß die einzelnen Risiken werden und wie gut wir darauf vorbereitet sind.
Fazit: Der Weg in die Produktion ist Teil der Lösung
Für mich zeigt sich gute Projektplanung nicht nur daran, wie effizient eine technische Lösung entwickelt wird. Sie zeigt sich vor allem darin, wie schnell, sicher und kontinuierlich aus dieser Entwicklung ein tatsächlicher Nutzen für das Unternehmen entsteht.
Dafür müssen wir aufhören, aus kleinen Anforderungen unnötig große Projekte zu machen. Wir sollten technische Abhängigkeiten kritisch hinterfragen, bewusst pragmatische Entscheidungen treffen und unsere Arbeit in Iterationen organisieren, die möglichst eigenständig einen Mehrwert liefern.
Gleichzeitig müssen wir den produktiven Betrieb von Anfang an als Bestandteil der Aufgabe betrachten. Die Frage, wie eine Lösung live gehen kann und wie wir auf mögliche Probleme reagieren, gehört genauso zur technischen Konzeption wie ihre eigentliche Implementierung.
Dabei braucht es auch Führungskräfte und Projektverantwortliche, die bereit sind, technische Perfektion gegen tatsächlichen Nutzen abzuwägen, Prioritäten zu setzen und Teams den notwendigen Entscheidungsspielraum zu geben. Denn nicht jede technisch wünschenswerte Verbesserung muss Voraussetzung für den nächsten sinnvollen Schritt sein.
Ein erfolgreiches IT-Projekt ist für mich nicht eines, das irgendwann vollständig fertiggestellt und anschließend mit großem Aufwand produktiv genommen wird. Es ist eines, das von Anfang an so gedacht wurde, dass Umsetzung und produktive Einführung möglichst selbstverständlich ineinandergreifen.
Denn Software, die fertig entwickelt ist, aber niemand live nehmen möchte, hat ihren eigentlichen Zweck noch nicht erfüllt.
