Nichts zeigt den Fortschritt in der Software-Entwicklung besser als die lauffähige IT-Anwendung selbst, die der Kunde ausprobieren und zu der er Feedback geben kann. Klingt trivial? Vielleicht. Doch die Praxis zeigt, wie wichtig dieses Erfolgsprinzip ist.
Das Agile Manifest hält in vier kurzen Aussagen die wesentlichen Werte und zwölf daraus abgeleitete Prinzipien der agilen Software-Entwicklung fest. Es wurde 2001 von 17 Software-Entwicklern, darunter die Scrum-Gründer Sutherland und Schwaber und der Erfinder von Extreme Programming, Ken Beck, formuliert. Die vier Werte sind:
- Individuen und Interaktion sind wichtiger als Prozesse und Tools
- Funktionierende Software ist wichtiger als umfassende Dokumentation
- Kundenzusammenarbeit ist wichtiger als Verträge zu verhandeln
- Reagieren auf Änderungen ist wichtiger als die Einhaltung des Plans
Tipp:
Diese vier agilen Werte sind sehr anschaulich und in zwei Minuten im YouTube-Video „The Agile Manifesto – 4 Agile Values Explained“ dargestellt. Ein Blick in dieses kurzweilige Erklärvideo lohnt sich.
Diese vier Werte sagen nicht, dass das, was rechts steht unwichtig ist – das ist keineswegs so. Nur sind die Dinge links von „wichtiger“ eben bedeutsamer. Daraus leiten sich zwölf Prinzipien ab, die diese Werte konkreter ausformulieren.
Ein Prinzip möchte ich besonders hervorheben, weil es meiner Erfahrung nach entscheidend für den Erfolg eines Software-Entwicklungsprozesses ist:
Funktionierende Software ist das wichtigste Fortschrittsmaß
Warum das so ist? Unsere Kunden erwarten in Software-Entwicklungsprojekten, dass wir auch kurzfristig konkret einsetzbare IT-Anwendungen entwickeln und ausliefern. Auch aus diesem Grund liefern wir nach jedem Sprint innerhalb von zwei Wochen tatsächlich funktionierende Software aus. Unsere Kunden können die Anwendung produktiv nutzen und Erkenntnisse in die weitere Entwicklung einfließen lassen.
Statt über Monate losgelöst vom Kunden und ohne Praxistest zu entwickeln und nur aus Projektsicht zu behaupten, man hätte schon 40% oder 80% geschafft, hat das regelmäßige Ausliefern lauffähiger Anwendungsteile viele Vorteile:
- Der Kunde kann den aktuellen Entwicklungsstand sofort produktiv einsetzen (ein enormer Wert für den Auftraggeber) und muss nicht Monate warten.
- Fortschritte in der Entwicklung sind direkt sichtbar – das senkt die Unsicherheit, ob am Ende das rauskommt, was man benötigt.
- Die funktionierende Software beweist auch die prinzipielle Machbarkeit. Grundsätzliche Schwierigkeiten am Projektende lassen sich so sicher vermeiden.
- Da wichtige Programmteile schon frühzeitig getestet werden, tauchen Fehler nicht erst in späteren Projektphasen auf (was teuer werden kann). Außerdem vermeidet dieses Vorgehen eine unberechenbare Flut von Bugs und Change Requests am Projektende.
- Missverständnisse über Entwicklungsziele werden durch funktionierende Software frühzeitig aufgedeckt, weil der Auftraggeber sofort Feedback geben kann. Eine „Überraschung“ am Ende bleibt den Projektpartner damit sicher erspart.
- Deployment-, Sicherheits- und Schnittstellenfragen müssen frühzeitig geklärt sein und führen damit nicht zu langen Verzögerungen am Projektende, wenn die Software angeblich „schon fertig“ ist.
- Wesentlich bessere Kostenkontrolle, weil die größten Unsicherheitsfaktoren vorgezogen oder vermieden werden. Noch offene Aufgaben und das noch vorhandene Budget machen einen realistischen Kostenabgleich viel einfacher.
Das regelmäßige Ausliefern funktionierender Software ist also die beste Methode, alle negativen Überraschungseffekte am Ende der Software-Entwicklung garantiert zu vermeiden. Für uns als Software-Entwicklungsunternehmen führt es auch zu einer starken Fokussierung auf das, was unser Kunde tatsächlich braucht. Und der Kunde ist wesentlich enger eingebunden.
Nichts zeigt den Fortschritt einer Entwicklung besser als lauffähige Software, die der Kunde ausprobieren und zu der er Feedback geben kann. Deshalb liefern wir in Projekten alle zwei Wochen funktionierende Software aus.
Es bleibt keine Zeit, sich in einer langwierigen Ideallösung zu verkünsteln, weil nach zwei Wochen der nächste Entwicklungsschritt ausgeliefert werden muss. Hier gilt das Prinzip Done is better than perfect (zu deutsch: erledigt ist besser als perfekt). Sie verhindert, dass man als Entwickler mehr Zeit in ein Feature steckt als nötig.
Kein Freifahrtschein für unsaubere Programmierung
Natürlich ist dieses Vorgehen kein Freifahrtschein für schlampige Software-Entwicklung („Hauptsache der Kunde sieht was“). Es geht also nicht darum, planlos drauf los zu programmieren, Style-Guide- und Compliance-Vorgaben „erst einmal“ links liegen und die Dokumentation schleifen zu lassen oder Abkürzungen zu programmieren, nur damit man nach zwei Wochen etwas sehen kann.
Fazit
Wer des Öfteren bei Software-Entwicklungsprojekten große Überraschungen am Ende erlebt hat, weiß, warum funktionierende Software als Fortschrittsindikator unverzichtbar ist: Sie beweist, wo man steht und verhindert eine Kostenexplosion oder extreme Zeitverzögerung am Schluss (wie beispielsweise im Frühjahr 2020 die Software-Auslieferung beim ID.3 von Volkswagen). Sie sorgt für eine permanente Kommunikation mit dem Auftraggeber, der jederzeit sehen kann, ob die Entwicklung das liefert, was er benötigt.
Das ist genau das, was unsere Kunden an expeso so schätzen: Sie wissen von Beginn an, dass sie das bekommen, was sie sich wünschen und können auch im laufenden Projekt Veränderungen vornehmen.
Stehen Sie am Anfang eines agilen Projekts? Wir unterstützen Sie gerne mit Workshops und Beratungsleistungen bei der Vorbereitung, der Anforderungsanalyse und Zieldefinition sowie der Entwicklung und Umsetzung. Nehmen Sie gerne Kontakt über unsere Webseite, per Telefon +49 621 66 988 988 oder E-Mail auf.
