Warum Unternehmen heute immer noch an der Softwareentwicklung scheitern

Die Situation ist meist wie folgt: In einem Unternehmen entsteht die Idee für ein eigenes Softwaresystem, meist eine Webanwendung oder eine App. Irgendwann fällt die Entscheidung, in die Umsetzung zu gehen. Hier treten die ersten Fragen auf:

• Sollen wir intern oder extern entwickeln?
• Welche Technologien sollen wir einsetzen?
• Woran erkennen wir (sehr) gute Entwickler?
• Gehen wir in die Cloud oder hosten wir selbst?
• …

Mit einem initialen Team sucht man Antworten auf diese Fragen und trifft die notwendigen Entscheidungen. Dann geht es voller Elan in die Umsetzung. Nach einiger Zeit treten die typischen Probleme der Softwareentwicklung auf:

• Alles dauert länger als geplant.
• Es gibt viele kleine Probleme, die die Aufmerksamkeit des Unternehmers und des Managements erfordern.
• Plötzlich ist ein aufwendiges Technologie-Update notwendig, das die Entwicklung um mehrere Wochen oder Monate zurückwirft.
• Die Kommunikation und Planung des Projekts sind aufwendiger als gedacht.
• Das Teammitglieder wechseln, neue Ansichten zur Technologie und zum Vorgehen sorgen für zusätzliche Aufwände.

Nach drei Jahren Entwicklungszeit und zwei Versuchen das System zu bauen, ist die Anwendung immer noch nicht in Betrieb.

Auch wenn es vielleicht auf den ersten Blick unrealistisch oder übertrieben klingt, ist das tatsächlich die Geschichte, die wir - in der ein oder anderen Form - immer wieder hören.

Wo liegt also das Problem? Ist es die Technologie? Ist es der Entwicklungsprozess? Oder ist es gar das Team?

Unserer Erfahrung nach ist es nichts davon. Es gibt in jedem Softwareprojekt den gleichen intrinsischen Zielkonflikt, der die meisten der oben genannten Probleme verursacht und verstärkt.

Worin liegt der Zielkonflikt?

Um mit ihrem Softwareprojekt erfolgreich zu sein, muss das Team zwei widersprüchlichen Anforderungen gerecht werden:

1. Das Richtige tun. Mit anderen Worten, etwas entwickeln, das dem Anwender oder Kunden einen größtmöglichen Nutzen bietet und damit am Markt erfolgreich ist. In der Softwareentwicklung bewegen wir uns hier auf einem Gebiet hoher Unsicherheit. Um das Richtige zu tun, muss man also schnell und mit geringem Aufwand lernen, was das Richtige ist, das heißt:

   • Prototypen bauen und damit schnell die wichtigsten offenen Fragen beantworten,
   • flexibel auf neue Anforderungen reagieren,
   • schnell neue Versionen herausbringen und immer wieder neues Feedback einarbeiten.

2. Dinge richtig tun. Mit anderen Worten das System mit Weitblick entwickeln. In der Softwareentwicklung geht es meist darum, Systeme über einen langen Zeitraum weiterzuentwickeln und zu betreiben, also:

   • Technologien auszuwählen, die zukunftsweisend sind,
   • guten und wartbaren Code schreiben,
   • die Skalierbarkeit des Systems sicherstellen,
   • eine Architektur wählen, die es erlaubt auch in Zukunft neue Anforderungen umzusetzen.

Während die Dinge auf der einen Seite möglichst einfach gehalten werden müssen, um schnell agieren zu können, möchte man auf der anderen Seite mit möglichst viel Weitblick handeln.

Dieser Konflikt ist für ein Unternehmen nicht leicht zu lösen, da es Kräfte gibt, die stark in beide Richtungen zerren.

Gerade bei uns im deutschsprachigen Raum ist - aus unserer Erfahrung - der Drang ‘Dinge richtig zu tun’ sehr stark und oft bestimmend. So hat ein deutscher Autobauer sieben(!) Jahre an einem neuen System entwickelt - zwischenzeitlich mit über 100 Leuten - bevor eine erste Version der Anwendung in den Testbetrieb ging.

Das andere Extrem gibt es auch: Etwas das nur als Prototyp gedacht war, geht in den Betrieb und muss plötzlich kontinuierlich weiterentwickelt werden. Das verursacht jede Menge Probleme. Die Entwicklung dauert immer länger, es treten immer wieder Bugs auf, der Code wird immer weniger wartbar.

Das sind natürlich nur Beispiele, dennoch ist der Wechsel zwischen den Extremen etwas, das man bei der Softwareentwicklung in der ein oder anderen Form immer wieder beobachten kann.

Wie kann man diesem Dilemma entkommen?

Der Schlüssel zur Lösung liegt darin, zu erkennen, dass es verschiedene Wege gibt, schnell voranzukommen und flexibel zu reagieren. Zum einen kann man alle Dinge einfach ‘schneller’ erledigen. Das geht meist zu Lasten der Qualität und endet in den oben genannten Problemen.

Der weit bessere Weg ist es unnötige Dinge einfach nicht zu tun und sich stattdessen auf das zu konzentrieren, was den größten Nutzen bietet - sowohl für den Anwender als auch für die weitere Entwicklung. Für diese Dinge hat man dann die notwendige Zeit, um sie richtig zu erledigen.

Das zehnte Prinzip des Agilen Manifests bringt es auf den Punkt: “Simplicity–the art of maximizing the amount of work not done–is essential.”

Die Frage, der sich ein Team also stellen muss, ist also: Was können wir weglassen und trotzdem unsere Softwareentwicklung zukunftssicher aufstellen?

In der Technologie ist das meist viel.

Aber auch bei den fachlichen Anforderungen muss sich das Team entsprechende Gedanken machen. Was ist das Kernproblem der Nutzer? Wo liegt der größte Nutzen der Anwendung? Ist ein 2-Faktor Authentifizierung mit eigener mobiler App wirklich von Anfang an notwendig? Hier kann ein Design Sprint helfen, die richtige Perspektive zu bekommen. Es ist aber auch eine Frage des entsprechenden Mindsets, das vor allem bei Senior-/Lead-Entwicklern bzw. dem Architekten vorhanden sein sollte.

In diesem Beitrag bleiben wir bei der Technologie und schauen uns ein einfaches Beispiel an, um den Punkt zu verdeutlichen.

Beispiel: Bestellsystem für die Gastronomie

In diesem Beispiel soll ein Bestellsystem für die Gastronomie entwickelt werden, bei dem Kunden direkt Essen zur Abholung oder Lieferung online bestellen können. Für den Start des Systems ist eine Pilotphase von 3 Monaten mit 10-20 Restaurants geplant. Jedes Restaurant rechnet mit ca. 100 Anfragen pro Woche. Kürzere Ausfälle des Systems von weniger als 15 Minuten sind in dieser Phase akzeptabel.

Jetzt geht es darum, vor dem Start der Entwicklung die Technologien auszuwählen und die grobe Architektur zu planen. Das Entwicklungsteam besteht aus vier Entwicklern, einer Designerin und einem Produkt Owner. Die erste Idee des Teams ist es mit einer modernen Microservice-Architektur in der Cloud zu starten und so auch die Hochverfügbarkeits- und Skalierungsmöglichkeiten zu nutzen. Aber ist das zum jetzigen Zeitpunkt die richtige Lösung?

Eine Microservice-Architektur ist besonders gut dazu geeignet mehrere Teams unabhängig voneinander arbeiten zu lassen und so die Softwareentwicklung zu skalieren. Das Problem gibt es in diesem Beispiel nicht und wird erst bei einem Wachstum des Teams um den Faktor 5 bis 10 relevant werden. Andere Vorteile, wie die Verwendung verschiedener Technologien, bieten in der jetzigen Phase aus Sicht des Teams keine nennenswerten Vorteile. Eine Microservice Architektur wird an dieser Stelle also nur die Komplexität erhöhen, aber keinen Nutzen bieten.

Zukünftig kann sich das natürlich ändern. Das liegt aber aller Voraussicht nach noch in weiter Ferne. Bis dahin wird sich noch viel an den Anforderungen und auch in der Umsetzung ändern. Um die Entwicklung jetzt einfach zu halten, fällt die Entscheidung auf eine monolithische Architektur. Es wird aber schon jetzt darauf geachtet die interne Struktur des Systems fachlich zu schneiden, so dass ein Wechsel auf eine Microservice Architektur später bei Bedarf gut durchgeführt werden kann.

Die zu erwartende Last des Systems ist relativ gering. Da kurze Ausfälle zu Anfang kein Problem darstellen, sind Mechanismen zur Skalierung und Hochverfügbarkeit vorerst nicht notwendig. Auch diese Komplexität kann also erstmal herausgenommen werden. Um später bei Bedarf schnell Kapazität und Ausfallsicherheit ergänzen zu können, entscheidet sich das Team für eine EC2 (Elastic Cloud Computing) Instanz bei AWS (Amazon Web Services). So hält sich das Team die Möglichkeit offen, zu einem späteren Zeitpunkt schnell Mechanismen zur Skalierung und Hochverfügbarkeit zu ergänzen.

Wie man an diesem einfachen Beispiel sieht, hat das Team bereits durch diese beiden Entscheidungen viel Komplexität aus der Entwicklung herausgenommen, hält sich jedoch die Möglichkeit für weitere Anpassungen durch die Entscheidungen weiter offen. Wenn die weiteren Entscheidungen des Teams dem gleichen Prinzip folgen, sollten sie in der Lage sein, mit einer ersten Version des Bestellsystems nach spätestens drei Monaten Entwicklungszeit in die Pilotphase zu gehen und sich von dort aus schnell weiterzuentwickeln.

Damit das möglich ist, reicht es natürlich nicht das Prinzip der Einfachheit - im Sinne der Maximierung der nicht getanen Arbeit - nur in der Technologie anzuwenden. Mindestens genauso wichtig ist der fachliche Fokus auf die wirklich relevanten Anforderungen. Wenn beides gegeben ist, hat das Team die Möglichkeit schnell voranzukommen und zu lernen und gleichzeitig langfristig tragbares System zu entwickeln.

Fazit

Jede Softwareentwicklung kämpft mit dem intrinsischen Konflikt auf der einen Seite die ‘Dinge richtig tun’ zu wollen und auf der anderen Seite ‘die richtigen Dinge zu tun’.

Um diesen Konflikt zu lösen, ist das zehnte Prinzip des agilen Manifests der Schlüssel: “Einfachheit – die Kunst die Menge der nicht getanen Arbeit zu maximieren – ist essentiell.”

Im Wesentlichen geht es dabei darum, so viel Komplexität wie möglich von vornherein auszuschließen. Das betrifft Technologie, Architektur, Umsetzung, Anforderungen, Prozesse und Kommunikation in gleichem Maße.

Folgt man diesem Prinzip, bleibt genügend Zeit die verbleibenden ‘Dinge richtig zu tun’ und trotzdem schnell zu lernen, ob man ‘die richtigen Dinge tut’.