Softwareprojekte auf der grünen Wiese neu starten?

Softwareprojekte langfristig erfolgreich und zukunftsweisend durchzuführen, ist eine Herausforderung. Am Anfang steht oft eine relativ einfache Idee mit einer Handvoll Funktionen und Anwendungsgebieten. Diese werden relativ schnell und sauber umgesetzt und der Kunde erhält eine schlanke, einfache Lösung, die alle Wünsche erfüllt. Mit der Zeit wachsen jedoch die Anwendungsbereiche, es werden immer mehr Funktionen implementiert und auch die Anzahl der Kunden und damit die Bedeutung der Software für das Unternehmen wächst stetig.

Alte Strukturen, welche die Grundpfeiler der ursprünglichen Softwarearchitektur bildeten, stehen diesen Neuerungen nun im Weg. Es müssen alternative Wege gefunden werden, um diese Blockaden zu umgehen. Die Entwicklung geht munter weiter und wenn nötig wird mit Klebeband und Bostitch gearbeitet um neue Features um die alte Architektur herum zu bauen.

Irgendwann lassen sich aber bestimmte Änderungen und Features nicht mehr mit vertretbarem Aufwand umsetzen. Die alte Architektur lässt sich nur bis zu einem gewissen Grad verbiegen und nach x-Lagen Klebeband und Bostitch führt auch diese Methode nicht mehr zum Ziel.

Was tun, wenn man an diesem Punkt angelangt ist?

Im Prinzip gibt es nur zwei Möglichkeiten:

• Augen zu und durch - Inkrementelle Strukturveränderungen
• Zurück auf Los - Neuanfang auf der grünen Wiese

Beide Modelle haben unterschiedliche Vor- und Nachteile. Die Entscheidung für das eine oder andere Lösungsmodell wird jedoch häufig aufgrund falscher Argumente getroffen.

Die menschliche Seite der Geschichte

Bisher wurde nur die eine Seite der Geschichte erzählt. Die andere Seite der Geschichte basiert auf der Beziehung zwischen den Personen, die die Software entwickeln (die Entwickler oder die F&E-Abteilung) und den Personen, die die Anforderungen definieren (der Kunde, der Projektleiter oder der Produktmanager).

Die Geschichte beginnt damit, dass alle zufrieden sind. Es gibt klare Anforderungen und technische Lösungen, um diese zu erfüllen.

Wie in der Einleitung erwähnt, kommen immer mehr Funktionen hinzu. Das bedeutet, dass die Entwicklung Abwägungen treffen muss. Trade-offs haben Einfluss auf verschiedene Parameter des Produktes und dessen Zukunft. Was wiederum den Kunden, den Projektleiter und den Produktmanager beschäftigt. Kurz: Trade-offs führen zu Verhandlungen.

Beide Parteien, Entwickler und Produktmanager, kennen das Produkt und das Problem sehr gut. Allerdings aus zwei völlig unterschiedlichen Blickwinkeln bzw. Dimensionen. Da gibt es viel Potential für Missverständnisse und so manche Verhandlung kann in einem jahrelangen Stellungskrieg enden.

Was liegt da näher, als noch einmal auf der grünen Wiese zu beginnen? Ohne die alten technischen Zwänge und festgefahrenen Mentalitäten?

Das erste Mal kommt kein zweites Mal

Man startet also ein Projekt auf der vermeintlich grünen Wiese und am Anfang sind alle wieder glücklich. Die Entwickler können in neuen Technologien schwelgen und alle nun neuen Module passen perfekt zusammen. Für den Kunden und Produktmanager ist es ein Wunschkonzert und endlich können alle modernen Konzepte der Zeit in die Produkte des Unternehmens einfließen.

Alle sind zufrieden, und die Entwicklung wird eifrig vorangetrieben.

Leider ist diese Freude nur von kurzer Dauer, denn wo der Kunde bei der ursprünglichen Entwicklung des ersten Produktes schnell begeistert und zufrieden war, ist er nun von der bestehenden Lösung, die über Jahre oder Jahrzehnte entwickelt wurde, verwöhnt.

Das erste Mal kommt kein zweites Mal. Selbst wenn man verspricht, auf der grünen Wiese zu beginnen, ist das nie wirklich der Fall. Nur weil man sich bemüht, die Vergangenheit auszulöschen, existiert sie noch in den Köpfen der Entwickler und Produktmanager, aber noch viel mehr beim Kunden. Kein Kunde will ein Nachfolgeprodukt, das nur noch die Hälfte des alten Funktionsumfangs hat und auch noch mit Kinderkrankheiten zu kämpfen hat.

Das neue Produkt muss also wohl oder übel sowohl die alten als auch die neuen Features abdecken. Ein Spektrum an Features, das früher Jahre oder Jahrzehnte für die Implementierung gebraucht hat, muss nun in 1-2 Jahren abgedeckt werden.

Mit Vollgas ins fallende Messer

Noch sind alle voller Tatendrang, denn auf der heutigen Seite des Technologiegartens ist die Wiese sicherlich grüner als auf der gestrigen. Die Implementierung beginnt, die Architektur wächst, aber auch hier müssen bald Abwägungen getroffen werden. Langsam wird klar, dass alle nur mit Wasser kochen, die alte wie die neue Entwicklergeneration. Was anfangs wie eine verknöcherte Architektur und eine grandiose Serie von Fehlentscheidungen in der bestehenden Lösung aussah, entpuppt sich als das Erbe einer Generation von Entwicklern, die ihr Bestes gegeben haben, um den Anforderungen der Zeit gerecht zu werden.

Was sich jetzt abspielt, ist Ernüchterung auf allen Seiten - reihenweise verpasste Deadlines, aus dem Ruder laufende Kosten, ein verwässertes Produktportfolio und eine erneut verknöcherte Architektur. Zu allem Überfluss ist die Welt während der nun schon sehr langen Entwicklungszeit nicht stehen geblieben. Was einmal zukunftsträchtig war, ist heute Schnee von gestern - man wurde von der Konkurrenz überholt.

Alternativen

Wenn ein Produkt in der Stagnation stecken geblieben ist, gibt es grundsätzlich nur drei Möglichkeiten:

1. Neuanfang auf der grünen Wiese. Dieser Ansatz hat seine Berechtigung, wird aber in den meisten Fällen aus den falschen Gründen gewählt. So ist dieser Ansatz (wie eben beschrieben) kaum planbar und führt in vielen Fällen zu extrem hohen Kosten, obwohl die ursprüngliche Vision letztendlich nicht erreicht wird.
2. Reduktion des Funktionsumfangs Dadurch wird das Projekt planbarer und deterministischer.
3. Inkrementelle / schrittweise Einführung von Neuerungen.

Auf die Punkte 2 und 3 wird in den folgenden Kapiteln näher eingegangen. Jede Variante hat ihre eigenen Vor- und Nachteile.

Konzept: Reduzierung des Funktionsumfangs

Eines der Probleme des ersten Ansatzes (Neustart auf der grünen Wiese) war, dass man sich zwar auf die neuen Features konzentrieren wollte, die alten aber noch in den Köpfen der Entwickler, Produktmanager und vor allem der Kunden vorhanden waren. Dadurch war die Entwicklung gezwungen, sowohl die alten als auch die neuen Features zu implementieren. Das bedeutet eine enorme Bandbreite an Features.

In diesem Konzept wird dieses Spektrum gezielt reduziert. Dies kann wiederum auf verschiedene Arten geschehen:

• Nur die alten Features implementieren - keine neuen. Dies macht z.B. bei Legacy-Produkten Sinn, bei denen eine Basistechnologie so veraltet ist, dass nichts anderes übrig bleibt, als alles auf einer neuen Technologie aufzubauen. Im Idealfall sollte diese Situation jedoch nie eintreten, wenn das Produkt regelmäßig gewartet wird.
• Ein 50:50-Mix aus alten und neuen Features Dieser Weg ist selten zu empfehlen, da die Versuchung groß ist, zu viele Features implementieren zu wollen. Außerdem ist das Produkt weder klar in der Gegenwart noch in der Zukunft positioniert.
• Den Schwerpunkt auf neue Funktionen legen Dieser Ansatz ist im Prinzip derselbe, den ein Startup wählen würde. Auch Unternehmen mit bestehenden Produkten können diesen Weg gehen, allerdings muss dabei ein großer Teil der alten Ansprüche bewusst verworfen werden. Am besten wäre es, eine "abgespeckte" (z.B Light) Produktfamilie auf den Markt zu bringen, die beispielsweise auf eine bestimmte, neu entstehende Kundengruppe abzielt. Damit wird dem Kunden auch kommuniziert, dass diese Produktfamilie nicht die ursprünglichen Anforderungen abdeckt.

Der große Vorteil dieses Ansatzes ist, dass das Projekt planbarer und deterministischer wird. Der Nachteil ist, dass man sich sowohl auf der Seite des Produktmanagers als auch auf der Seite der Entwicklung extrem zurückhalten muss, um sich nicht zu überfordern. Außerdem muss die Erwartungshaltung des Kunden genau überprüft werden.

Konzept: Inkrementelle Innovation

Im Idealfall besteht jedes Produkt aus einem kontinuierlichen Strom inkrementeller Änderungen. Diese sollten sowohl neue Funktionen als auch Arbeiten und Änderungen an der bestehenden Architektur und Technologie umfassen. Nur so kann sichergestellt werden, dass man nicht einen Berg technischer Schulden anhäuft und in ein paar Jahren nicht mehr weiterkommt.

Theoretisch kann man jedes Ziel erreichen, wenn man genügend Geduld und Zeit aufbringt. Dasselbe gilt für inkrementelle Innovation. Durch die inkrementelle Arbeitsweise ist die Software jederzeit releasefähig. Dadurch ist das Projekt sehr gut planbar, deterministisch und das Risiko gering. Die Feedbackschleife von Erfolgen und Misserfolgen ist extrem kurz, was optimal ist, um Erfahrungen mit neuen Technologien und Features zu sammeln.

Natürlich hat diese Vorgehensweise auch Nachteile. Durch Änderungen an teilweise grundlegenden Architekturelementen können leicht Bugs und Instabilitäten erzeugt werden. Außerdem führen viele dieser Arbeiten oft nicht zu einem direkten unmittelbaren Nutzen für den Kunden. Beides ist für Produktverantwortliche und Kunden schwer nachvollziehbar. Ein weiterer großer Nachteil ist, dass mit diesem Ansatz nie ein großer Release vermarktet werden kann. Der Vorteil bei einem Greenfield-Projekt ist, dass das Marketing mit einem großen Big Bang Release beim Kunden viel Aufmerksamkeit erregen kann. Bei inkrementellen Änderungen passiert zwar zeitlich gesehen das Gleiche, aber psychologisch ist es ein großer Unterschied. Ein weiterer Nachteil kann sein, dass das Produkt nach außen unvollständig erscheint. Wenn z.B. etwas Grundlegendes an der Bedienung des Produktes geändert wird, z.B. eine neue Benutzeroberfläche (GUI), bedeutet das für den Kunden eine Umstellung. Wenn aber die neue GUI nicht alle Funktionen der alten GUI abdeckt, muss der Kunde sowohl die alte als auch die neue GUI bedienen. Dies kann den Kunden verwirren und einen schlampigen Eindruck hinterlassen. Letztendlich erfordert die inkrementelle Innovation vor allem eine gute Zusammenarbeit und Vertrauen zwischen den Entwicklern und den Produktverantwortlichen. Genau das ist wohl die Achillesferse des inkrementellen Ansatzes. Denn genau dieses Vertrauen ist in vielen festgefahrenen Projekten verloren gegangen und es wird nach einem Ausweg gesucht. Noch mehr Geld in den bereits ausgetretenen Pfad zu stecken, erscheint dann kontraproduktiv. Mit der Folge, dass dann oft die Illusion der grünen Wiese folgt.

Doppelgleisigkeit

Ein Argument gegen inkrementelle Veränderung ist oft auch, dass bestimmte Dinge doppelt gemacht werden müssen. Dies wäre beim idealisierten ersten Ansatz (grüne Wiese) nicht der Fall, da alles aus einem Guss kommt. In der Praxis ist dies jedoch fast nie der Fall und es wird viel zu viel Zeit in die Vorplanung investiert, als dass später tatsächlich Zeit eingespart wird. Doppelarbeit ist nicht zu empfehlen, aber man macht zumindest Fortschritte und sammelt Erfahrungen, was bei einer Trockenübung auf Papier nicht möglich ist.

Maßnahmen zur Abmilderung der Nachteile

Maßnahmen, um den Nachteilen der inkrementellen Entwicklung entgegenzuwirken:

• Features mit "Preview" kennzeichnen, um Klarheit für den Kunden zu schaffen
• Feature Flags um einen bestimmten Satz von Features vor dem Kunden geheim zu halten und in einem "Big Bang" zu veröffentlichen.

Fazit

Der inkrementelle Ansatz erfordert Mut und Verständnis auf allen Seiten. Bei den Produktverantwortlichen muss das Vertrauen in die Stimme der Entwickler gepflegt werden, wenn diese Änderungen an der Architektur vornehmen wollen, die keinen direkten Kundennutzen bringen. Gleichzeitig müssen die Entwickler verstehen, dass auch frühere Generationen von Entwicklern nur das Beste im Sinn hatten und Experten auf ihrem Gebiet waren. Letztendlich ist die heutige Generation und Technologie nicht universell klüger oder besser, sondern nur inkrementell etwas anders und weiter fortgeschritten.

Die Entscheidung, ein Projekt auf der grünen Wiese neu zu beginnen, sollte meiner Meinung nach nur mit großer Vorsicht getroffen werden. In den meisten Fällen würde ein pragmatischer Ansatz wie die Rückkehr zur inkrementellen Innovation mehr Sicherheit und letztlich auch mehr Kundennutzen bringen. Paradoxerweise braucht ein festgefahrenes Projekt also kein Heilmittel, sondern sollte sich auf seine Ursprünge besinnen. Mit anderen Worten: Eine Architektur ist nie endgültig, sondern immer nur eine von (hoffentlich) vielen Iterationen.