Start-up aufbauen: Was Gründer:innen beachten müssen
NeoCargo feiert erfolgreichen Go-Live
Agile Softwareentwicklung – wo liegen die Vorteile?
Hagen Buchwald spricht im Interview über agile Softwareentwicklung und die Vorteile dieses Systems.
Galt der plangetriebene, geschlossene Ansatz jahrzehntelang als Maß aller Dinge in der Softwareentwicklung, wurde dieser inzwischen abgelöst. Der Trend, dem auch wir bei der NeoCargo AG folgen, geht zu einem nutzengetriebenen, offenen Ansatz: der agilen Softwareentwicklung mit Scrum. Unser Aufsichtsratsmitglied Hagen Buchwald spricht über den Einsatz und die Vorteile.
Herr Buchwald, Sie sind bei der NeoCargo AG im Aufsichtsrat und waren über ein Jahrzehnt Vorstand der andrena objects, ein auf Agiles Software Engineering spezialisiertes Beratungsunternehmen mit heute mehr als 400 Mitarbeitenden. Sie haben in dieser Funktion Ihren Kunden die agile Softwareentwicklung nähergebracht. Was genau ist darunter zu verstehen?
Buchwald: Software-Systeme sind zu Beginn der Entwicklung unsichtbar. Der Kunde sieht nicht, was da entsteht und welcher Nutzen aus dem System erwachsen wird. Das Ziel der agilen Softwareentwicklung ist es, so schnell wie möglich zu einer ausführbaren Software zu gelangen, um das Softwaresystem für den Kunden sichtbar und erfahrbar zu machen. Ausführbare Software ermöglicht es, den Kunden aktiv in den Entwicklungsprozess mit einzubinden. Bei NeoCargo ist uns dies bereits nach dem ersten Sprint, also nach 14 Tagen Entwicklungszeit gelungen. Fünf Monate später haben wir die erste Version der NeoCargo-Plattform in Produktion gesetzt. Diese Geschwindigkeit ist entscheidend für den Erfolg des Gesamtvorhabens.
Warum?
Buchwald: Damit wir so früh wie möglich genau diese Frage unseren Kunden stellen können: Warum? Warum brauchen wir genau diese Funktionalität? Welchen Nutzen erhofft sich der Kunde davon? Und zeigen uns unsere Erfahrungen im Betrieb, dass die neue Funktionalität auch tatsächlich den erhofften Nutzen stiftet?
Sind solche Fragen nicht eher Aufgabe der fachlichen Berater in der Analyse-Phase?
Buchwald: Im plangetriebenen Ansatz: Ja. Im nutzengetriebenen agilen Ansatz: Nein. Da verlassen wir uns auf Erkenntnisse aus unseren Experimenten mit echten Nutzenden, nicht auf Annahmen, die vorab in einer Analyse-Phase aufgestellt wurden.
Gibt es im agilen Ansatz also keine Analyse-Phase mehr?
Buchwald: Im agilen nutzengetriebenen Ansatz findet die Analyse – im Gegensatz zum plangetriebenen Ansatz – nicht vorab als eigene Phase, sondern kontinuierlich in Form regelmäßiger Events jeden Sprint statt. Ebenso wie Design, Implementierung, Test, Produktivsetzung und Betrieb. Alles innerhalb eines Sprints mit einer Dauer von 14 Tagen. Und alles innerhalb eines Teams, das aus diesem Grund cross-funktional aufgestellt ist.
Was spricht gegen eine fundierte Analyse-Phase zu Beginn des Projekts?
Buchwald: Digitale Produktinnovationen sind komplexe Vorhaben. Komplexität heißt unter anderem: Alles ist mit allem vernetzt. Und viele der Annahmen, die wir im plangetriebenen Ansatz vorab in einer Analyse-Phase über das komplexe Problem oder seine potenzielle Lösung treffen, stellen sich in der Umsetzung als falsch heraus. Und erzwingen Änderungen am Plan. Die Grundannahme des plangetriebenen Ansatzes, dass Änderungen die Ausnahme sind, hält einem komplexen Vorhaben nicht stand. Änderungen am Plan sind nicht die Ausnahme, sondern die Regel. Das macht sich der agile Ansatz zu eigen.
Änderungen
sind willkommen. Sie zeigen, dass Annahmen fehlerhaft waren und korrigiert
werden müssen. Fehlerhafte Annahmen zu korrigieren, heißt dazu zu lernen. Das
agile Vorgehen ist ein Lernansatz. Lernen in kleinen Schritten, Tag für Tag. Daher
ist es klug, den Elefanten – das komplexe Problem – in Scheiben zu schneiden.
Sprint für Sprint wird die am höchsten priorisierte Scheibe gemeinsam mit dem
Kunden analysiert, eine Lösung designt, umgesetzt, getestet und in Produktion genommen.
Aus der Art und Intensität der Nutzung durch die Endanwender lernen wir, ob
unsere Annahmen zu Beginn des Sprints zutrafen und korrigieren sie, bevor wir
nach dem gleichen Schema die nächste Scheibe angehen.
Was ist der Vorteil dieser Salami-Taktik?
Buchwald: Wir sprechen von Just-in-time-Refinement, das typisch für das Agile Requirement Engineering ist. Was genau im nächsten Sprint umgesetzt werden soll und wie wir es umsetzen sollten, klären wie so spät wie möglich. Das erhöht die Wahrscheinlichkeit, dass wir fehlerhafte Annahmen bereits aufdecken und korrigieren konnten, bevor wir uns an die eigentliche Umsetzung machen. Je näher die Analyse und das Design der nächsten Scheibe an ihrer eigentlichen Umsetzung liegen, desto mehr Zeit haben wir zu lernen, was wirklich aus Nutzersicht umzusetzen ist und wie wir es am besten anstellen.
Die Salami-Taktik als eine Art kontinuierliche Analyse, um mehr über den eigentlichen Nutzen zu lernen?
Buchwald: Ja, so kann man es auf den Punkt bringen. Es gilt, einen echten Nutzen für den Endanwender zu realisieren. Was keinen Nutzen verspricht, wird gar nicht erst entwickelt. Anhand der ausführbaren Software – wir sprechen von einem Produkt-Inkrement – können wir mit den Kunden über den Nutzen einer neuen Funktion viel besser diskutieren als auf Basis von dokumentenbasierten Spezifikationen, die auf bereits überholten Annahmen beruhen. Der Auftraggeber und das Softwareentwicklungs-Team begeben sich gemeinsam auf eine Lernkurve: Was braucht der Endanwender wirklich? Ist diese neue Funktionalität technisch umsetzbar? Und lohnt er sich der damit verbundene Aufwand wirtschaftlich?
Wie bringt man solch einen Prozess in Gang?
Buchwald. Mit der richtigen Ausgangsfrage: Was ist der Kernnutzen, den die digitale Produktinnovation stiften soll? Diese Frage steht im Zentrum des Vorhabens. Und der Antwort dieser Frage nähern wir uns iterativ-inkrementell. Iterativ, weil jeder Sprint nach dem gleichen Muster abläuft. Inkrementell, weil jeder Sprint ein neues Produktinkrement, also eine erweiterte Funktionalität des Software-Systems liefert. Dieses neue Produktinkrement erlaubt uns neue Experimente mit dem Endkunden. Und die Experimente helfen uns, unsere Annahmen zu korrigieren und die richtigen Prioritäten für den nächsten Sprint zu setzen.
Experimente mit dem Endkunden? Ein empirischer Ansatz?
Buchwald: Der agile Ansatz nennt es empirische Prozesskontrolle. Scrum fördert das gemeinsame, kontinuierliche Lernen durch regelmäßige Events, die die Kommunikation im Scrum-Team und mit dem Kunden gezielt fordern und fördern. Wir sprechen von Inspect & Adapt – also immer wieder überprüfen und anpassen, ein hochwirksamer Lernansatz. Scrum-Teams erkennen durch regelmäßiges Inspect & Adapt Risiken frühzeitig, korrigieren fehlerhafte Annahmen und halten den Fokus auf den Nutzen für den Endanwender aufrecht. Wie nutzen diese die in Produktion genommenen Features? Welche unserer bisherigen Annahmen müssen wir korrigieren? Worauf sollten wir in den kommenden Sprints den Fokus legen? Wenn man sich diese Fragen immer wieder stellt, kommt man schneller und mit einer deutlichen höheren Erfolgswahrscheinlichkeit zum Ziel einer digitalen Produktinnovation, die echten Nutzen stiftet.
Der Nutzen für den Kunden als Leitstern des Projekt-Teams?
Buchwald: So könnte man in der Tat sagen. Der agile Softwareentwicklung definiert das Projekt anhand des Nutzens. Zeit und Budget sind die Antwort auf die Frage: Was ist uns dieser Nutzen wert? Und bis wann wollen oder müssen wir diesen Nutzen in Produktion bringen, um den Wert erzielen zu können? Durch regelmäßige Feedbackschleifen und Sprints lassen sich Kurskorrekturen schneller vornehmen. Und dank der Rückkopplung lernen beide Seiten voneinander und behalten den Nutzen im Blick.
Wird ausschließlich auf den Nutzen geschaut? Wie steht es um die Wirtschaftlichkeit und technologische Machbarkeit?
Buchwald: Tatsächlich handelt es sich beim agilen Ansatz um einen permanenten Abwägungsprozess zwischen drei scheinbar konkurrierenden Zielen: Der Anwender als Nutzer des Systems möchte möglichst bald ein attraktives, leicht nutzbares Software-System haben, das ihm die Arbeit spürbar erleichtert. Der Auftraggeber als Business Owner möchte eine hohe Wirtschaftlichkeit des Produkts und damit möglichst niedrige Entwicklungskosten. Und das Entwicklungsteam als Owner der technologischen Machbarkeit möchte die innere Qualität des Software-Systems aufrechterhalten, um die Software jung und formbar zu halten und damit auch weiterhin Änderungswünsche schnell und einfach umsetzen zu können.
Wieso sind es scheinbar konkurrierende Ziele?
Buchwald: Weil eine hohe Geschwindigkeit hilft, die Kosten niedrig zu halten. Und weil eine hohe innere Qualität der Software einfache Lösungen forciert, die wiederum helfen, die Kosten niedrig zu halten und die Umsetzungsgeschwindigkeit hoch. Eine der Schwierigkeiten bei der Einführung von agiler Software-Entwicklung ist es, diesen Aha-Effekt herbeizuführen, dass die Ziele Geschwindigkeit, Wirtschaftlichkeit und Qualität keine Antagonisten sind, sondern sich – wenn man es richtig anpackt – gegenseitig verstärken. Daher rührt auch die Erfahrung vieler Kunden, dass Scrum zwar leicht zu verstehen, aber schwierig umzusetzen sei.
Wie leicht oder schwer war die Einführung von Scrum bei NeoCargo?
Buchwald: NeoCargo hat eine ideale Ausgangsposition. Als junges Start-Up schleppt NeoCargo keinerlei organisatorischen oder technologischen Ballast mit sich herum, kann also frei agieren. Es herrscht eine familiäre Arbeitsatmosphäre, mit direkter, offener Kommunikation und klarem Fokus auf ein spannendes Ziel. NeoCargo tickt also schon von sich aus agil. Da passt Scrum perfekt als Arbeitsmethode.
Also ist eine Umsetzung von agiler Software-Entwicklung nach Scrum ganz ohne externe Hilfe möglich?
Buchwald: Wichtig für NeoCargo war es, von Anfang an alle drei Säulen von Agilität konsequent zu leben: methodisch mit Scrum. Fachlich mit agilem Requirement Engineering. Und technologisch mit agilem Software Engineering. Dieser agile Dreiklang fällt nicht vom Himmel. Da braucht es Anleitung und Vorbilder, die vorleben, wie Scrum funktioniert, wie sich ein produktives Scrum-Team anfühlt und wie man vom ersten Tag an konsequent die innere Qualität der Software hochhält. Dazu haben wir uns Unterstützung von andrena objects geholt. Gerade im technologischen Bereich ist das schnelle Erlernen von Agile Software Engineering wichtig.
Warum?
Buchwald: Eines der Kernprobleme von jungen Start-ups ist das Fehlen von Know-how im Bereich Agile Software Engineering. Die Folge ist eine unbewusste Anhäufung technischer Schulden. Technische Schulden bremsen die Entwicklung aus. Aus dem einstigen Schnellboot wird ein lahmer Kahn. Agiles Software Engineering hilft, diese Schulden auf ein vertretbares Maß zu begrenzen. Das hält die entstehende Software jung und formbar. Genau das, was wir brauchen, um alle 14 Tage ein neues Produkt-Inkrement ausliefern zu können.
Dass so eine Softwareentwicklung gut zu einem Start-up passt, das selbst flexibel und agil ist, ist einleuchtend. Funktioniert das auch in großen Konzernen?
Buchwald: Dafür braucht es den Willen, sich konsequent an dem Modell der agilen Softwareentwicklung auszurichten und seine Software-Entwickler zu Agile Software Engineers auszubilden. Eines der Unternehmen, das sich in Deutschland dahingehend verändert hat, war SAP ab dem Jahr 2009. Durch die Verkleinerung der Teams und dem engen Austausch mit den Kunden reduzierte das Softwareunternehmen in den Folgejahren die Entwicklungszeit in der Produktentwicklung von 15 auf weniger als acht Monate. Oder wie Jim Hagemann Snabe, der damalige SAP-CEO, sagte: „Fast so schnell wie ein Start-up“. Seit diesem Wendepunkt ist die agile Softwareentwicklung im Mainstream angekommen.