In the Code: Agile ist kein Entwickler-Dingsbums

Fachartikel für inside-it.ch vom 8. Mai 2017

In Informatikprojekten gibt es ein äusserst beliebtes A-Wort: die Agilität. Wer agil entwickelt, ist innovativ, Agile Leadership ist die neue Zusammenarbeit und überhaupt scheint Agilität das allgemein akzeptierte Erfolgsrezept für die schöne neue Welt zu sein.

In der Realität bleibt von der Agilität – abgesehen vom trendigen Vokabular – leider oft nicht viel übrig. Ein agiles Vorgehen hat die irritierende Eigenschaft, dass es Unstimmigkeiten und falsche Annahmen an die Oberfläche spült. Wenn es darum geht, diese zu adressieren, fallen wir nur zu gern in bekannte Muster zurück und vertrauen lieber dem ursprünglichen Plan, als dass wir das Risiko einer Kehrtwende auf uns nehmen. Aus der Distanz betrachtet, erinnert der resultierende Prozess am Ende mehr an den verpönten Wasserfall als an den versprochenen agilen Prozess. Was läuft da schief?

Korrektur statt Perfektion

Im Feuilleton der 'NZZ' erschien kürzlich eine lesenswerte Kolumne von Rolf Dobelli mit dem Titel «Wir Schönwetterpiloten». Sie gipfelt im Appell, unsere Energie nicht im perfekten Set-up, also den nötigen Vorbereitungshandlungen, zu verschwenden, sondern für kontinuierliche Korrekturen einzusetzen. Denn das ständige Justieren des eingeschlagenen Kurses sei kein Zeichen für schlechte Planung, sondern der einzige erfolgversprechende Ansatz, im komplexen Umfeld unseres Alltags zu navigieren.

Was hat das mit Softwareentwicklung zu tun? Eine ganze Menge! Auch in der Softwareentwicklung ist die Überbewertung des Set-ups zu Lasten von späteren Korrekturen allgegenwärtig. Insbesondere die Entwicklung von Individuallösungen ist ein Unterfangen, das sich in einem komplexen Umfeld mit vielen Unbekannten abspielt. Eine wesentliche Eigenschaft dieser Komplexität ist, dass sich Auswirkungen von Entscheidungen trotz intensiver Planung nicht exakt vorhersagen lassen. Agile Praktiken bewirken zwar, dass Abweichungen vom erwarteten Resultat sichtbar werden. Ohne Kurskorrekturen ist die Gefahr dennoch gross, eine letztlich unbefriedigende Lösung zu erhalten.

Die nachfolgenden Rezepte bieten konkrete Vorschläge, wie Sie als Auftraggeber Agilität leben, den Anteil des Set-ups in Softwareprojekten reduzieren und durch häufiges Korrigieren bessere Lösungen als durch perfekte Planung erhalten können.

Früh und oft Feedback suchen

Der Weg eines Features führt gewöhnlich über Stufen wie Analyse, Spezifikation, Implementierung, Verifikation und Inbetriebnahme. Im traditionellen Phasenmodell durchlaufen alle Features diese Stufen im Gleichschritt. Das bedeutet, zuerst werden alle analysiert, dann alle spezifiziert und so weiter. Das Vorgehen erlaubt einen klaren Abschluss jeder Phase, ist aber inhärent korrekturfeindlich. Darum ist es für komplexe Vorhaben unter Beschuss gekommen.

Die agile Entwicklung führt den Begriff des «Backlog» für den Katalog der noch umzusetzenden Features ein. Der wesentliche Punkt ist hier nicht der Name, sondern dass im Backlog Features auf unterschiedlichen Stufen ihres Lebenszyklus’ koexistieren. Der Backlog ist ein Trichter, der unscharfe Ideen verdichtet und als konkrete Umsetzungsvorgaben an die Entwickler ausspuckt.

Der Backlog gehört zum Hoheitsgebiet des Auftraggebers, nicht der Entwickler. Richtig nutzen können Sie ihn aber nur, wenn Ihr Projektprozess die Volatilität und die Unverbindlichkeit des Backlogs auch aushält. Lässt Ihre Organisation zu, dass Sie einen Projektauftrag budgetieren und genehmigen, dessen Ausgang nicht gesichert ist? Falls ja, haben Sie die Chance, Ihre Entwickler frühzeitig zu involvieren und wertvolle Zeit im Set-up zu sparen.

Verabschieden Sie sich dazu von der Vorstellung, dass sie den Entwicklern eine möglichst grosse Menge von detaillierten Spezifikationen bekannt geben, bevor die erste Zeile Code geschrieben ist. Wenn wir dem Pareto-Prinzip vertrauen, stecken vier Fünftel des möglichen Ertrags in einem Fünftel des gesamten Aufwands. Konzentrieren Sie sich also auf den Fünftel (oder den Fünftel des Fünftels) der Anforderungen, die maximale Priorität geniessen und zu denen Sie sehr klare Vorstellungen haben, und geben Sie den Entwicklern genau diese in Auftrag – für einen Bruchteil Ihres Budgets. Bis zur Lieferung der entsprechenden Software haben Sie Zeit, weitere Anforderungen zu konkretisieren und die nächste Teillieferung vorzubereiten.

Oft stellt sich heraus, dass die gelieferte Software sich zwar wie gefordert verhält und fehlerfrei ist, aber nicht den erhofften Geschäftsnutzen bringt. Es kann in dem Fall lohnenswerter sein, diese Schwäche mit hoher Priorität zu korrigieren, bevor Sie weitere Features einbauen lassen.

Es ist absehbar, dass das Endprodukt nicht exakt die Features haben wird, die Sie sich zu Beginn vorgestellt haben. Dafür stellt es die Lösung mit der höchsten Wertschöpfung dar, die sich im gegebenen Zeit- und Budgetrahmen erstellen lässt. Das ist ein Vertrauensvorschuss, zu dem längst nicht alle Auftraggeber bereit sind. Allerdings brauchen sie dann auch nicht zu erwarten, die möglichen Vorteile der Agilität ausschöpfen zu können.

Das Ziel statt den Weg beschreiben

Zur weiteren Reduktion des Set-up verzichten Sie darauf, die Umsetzung möglichst detailliert zu beschreiben. Konzentrieren Sie sich auf die Aspekte, die ein Feature für Sie wertvoll machen. Was ist das Ziel? Welche Akteure sind betroffen? Wie ändert sich das Verhalten dieser Akteure? Welche Informationen und Handlungsmöglichkeiten brauchen sie dazu? Eine nützliche Technik dafür ist beispielsweise Impact Mapping.

Es ist nachvollziehbar, dass Sie Ihre Erwartungen und Wünsche möglichst exakt festlegen wollen, bevor Sie bereit sind, sie in die Hände anderer zu legen. In die Gestaltung von Datenmodellen oder Benutzeroberflächen gehören aber die entsprechenden Experten Ihres Entwicklungspartners involviert. Ein zweistündiger Workshop mit Entwicklern, UX-Spezialisten und Testern ist in vielen Fällen wertvoller, als sich drei Tage im Alleingang mit dem Diagrammeditor herumzuschlagen. Skizzen auf Flipcharts und Whiteboards lassen sich bestens fotografieren und in einem gemeinsam benutzen Wiki ablegen.

Indem Sie sich auf das Was beschränken und Details des Wie offenlassen, geben Sie den Entwicklern mehr Freiheit, den gewünschten Effekt möglichst effizient umzusetzen. Stellen Sie sicher, dass die Entwickler bei Unklarheiten und Widersprüchen von Anfang an und im gesamten Projektverlauf Rückfragen stellen können und mit Ihnen in einem offenen Dialog stehen. Bieten Sie ihnen möglichst unkomplizierten Zugang zu Fachspezialisten auf Kundenseite, damit Fragen rasch und korrekt gelöst werden können.

Routine automatisieren

Von Helmuth von Moltke ist das Zitat überliefert, dass kein Plan die erste Feindberührung überlebt. Dies gilt übertragen auch für die Softwareentwicklung. Erst die Interaktion mit funktionierender Software macht offensichtlich, ob das, was gebaut wurde, die gesetzten Ziele auch erreicht. Will man möglichst schnell vom Set-up in den Korrekturmodus gelangen, ist es deshalb unverzichtbar, Schlüsselpersonen auf Kundenseite so rasch wie möglich Software zum Ausprobieren zur Verfügung zu stellen. Nur so wird ein allfälliger Korrekturbedarf überhaupt sichtbar.

Sorgen Sie von Beginn weg dafür, dass Sie jederzeit Zugang zu einem Testsystem haben, das den aktuellen Zustand der Software widerspiegelt, und dass alle Beteiligten über wichtige Updates informiert werden. Wenn neuer Code mit einem weitgehend automatisierten Prozess grob überprüft und in Testsysteme eingespielt wird, sind selbst tägliche Softwarelieferungen kosteneffizient und risikoarm. Im Idealfall genügt dann ein Knopfdruck, um einen Release, der die nötigen Qualitätsprüfungen durchlaufen hat, auch in der Produktion aufzuschalten.

Aktiv ins Chaos

Im Wasserfallmodell gibt es den Moment, in dem Sie als Auftraggeber den Ball an Ihre Entwicklungspartner abgeben und sich etwas zurücklehnen können. Im agilen Prozess haben Sie diesen Luxus nicht: Sie sind die ganze Zeit am Entwicklungsprozess beteiligt, selbst wenn Sie keinen Programmcode schreiben.

Rechnen Sie damit, dass Sie die Zeit, die Sie im Set-up sparen, während der Umsetzung leisten werden, weil Sie zwingend eine aktive Rolle einnehmen müssen. Iterative Softwareentwicklung ist möglicherweise intensiver und chaotischer, als Sie sich gewöhnt sind. Im Abstand von Tagen oder wenigen Wochen erhalten Sie neue Software geliefert, müssen diese ausprobieren, Ihre Planung anpassen und neue Anforderungen zur Umsetzung vorbereiten. Diese Anstrengung wird dadurch belohnt, dass Sie Reaktionsfähigkeit erhalten.

Missverständnisse und Fehlentwicklungen, wie sie in einem komplexen Umfeld praktisch unvermeidlich sind, können Sie laufend korrigieren. Strategiewechsel, Änderungen im Markt und neue Erkenntnisse fliessen innert kürzester Zeit in die Software ein.

Ist es das alles wert?

Ich will nicht verschweigen, dass iterative Softwareentwicklung, wie ich sie hier beschreibe, intensiv und anstrengend für alle beteiligten Parteien ist. Mängel in der Kommunikation und Verzögerungen im Prozess sorgen im Nu für Stress. Allerdings: Mit dem aktuellen Trend zur Digitalisierung nimmt die Bedeutung von Individuallösungen weiter zu. Digitalisierung beinhaltet schliesslich nichts anderes, als dass die Kernprozesse eines Unternehmens auf Softwarebasis gestellt werden. Je stärker diese Kernprozesse die Einmaligkeit eines Unternehmens ausmachen, desto schwieriger ist es, dafür ein Standardprodukt einzusetzen.

Nutzen Sie in dieser Situation die «soften» Eigenschaften von Software zu Ihrem Vorteil und betrachten Sie Korrekturen, als das, was sie sind: nicht Risiken, sondern Chancen.

Erich Oswald ist Chief Technology Officer beim Zürcher Softwarehersteller Ergon.