Development Agility

So sind Sie trotz Agilität nicht der Erste am Markt!

Der Artikel demonstriert anhand einiger Beispiele, was beim Einsatz moderner Entwicklungstechniken, die eigentlich eine agile Arbeitsweise unterstützen sollen, schief gehen kann. Diese Beispiele sollen zum Mitdenken anregen.

Stefan Starke

Author

Gerald Ernecker

Author

30.10.2020
Lesezeit: 16 Minuten
87 Views

„Jetzt haben wir im letzten Jahr alle Teams auf Scrum umgestellt und auch schon begonnen, mit Microservices zu arbeiten. Sogar ein paar DevOps-ler haben wir eingestellt. Das kostet alles Geld, viel Geld! Warum zum Teufel bekommen wir dann unsere neuen Features trotzdem erst in einem halben Jahr?”

Diese Aussage von Bereichsleiter Bernd ist frei erfunden. Sie trifft aber folgende Situation: Trotz agiler Vorgehensmodelle, DevOps-Ansätzen, Microservice-Architekturen und vielem mehr wird die Time-to-Market nicht kürzer. Lesen Sie mit einem Augenzwinkern, wie Sie diese vielversprechenden Ansätze ignorieren – oder besser –, zu Ihrem Vorteil nutzen können. Die vorgestellten Punkte werden dabei nur grob behandelt, sollen aber zum Mitdenken und Hinterfragen der eigenen Situation anregen.

Das agile Pflichtenheft

Das folgende Beispiel ist in vielen Projekten nach wie vor gelebte Praxis:

Zweihundert frisch gedruckte und spiralisierte Seiten. Das Gemeinschaftswerk des Fachbereichs und der erfahrenen Softwarearchitekten ist fertig. Eine Gesamtspezifikation der zu entwickelnden Software, die keine Wünsche offenlässt. Jede noch so kleine Funktionalität ist bis ins Detail ausformuliert. Die Anhänge sind zum Bersten gefüllt mit finalisierten Mockups, Architektur-Diagrammen und detaillierten Vorgaben zu den einzusetzenden Frameworks. Jetzt erfolgt die Übergabe des Schriftwerks an das agile Scrum-Team. Die Wochen zuvor hat das Team schon Zeitpläne für die täglichen Stand-up-Meetings, die wöchentlichen Retrospektiven, Reviews mit dem Kunden und Termine für das regelmäßige Backlog Grooming erarbeitet. Das Pflichtenheft bildet ab sofort die Basis für den Backlog. Alle sind zufrieden und glücklich. Nur Norbert, der neu im Unternehmen ist, kommt das Ganze eigenartig vor. Mit Agilität, wie er sie interpretiert, hat das nämlich gar nichts zu tun.

Wie erklärt sich das? Das bekannte Wasserfallmodell ist schwer zu durchbrechen. In internen Gesprächen und auch Audits wird immer beteuert, dass man ja eine agile Firma sei. Alle unsere Mitarbeiter haben Scrum-Schulungen absolviert. Jedes Team hat einen Scrum Master. Wir haben ein Sprint Board und einen Backlog im Tool XY. Wir machen täglich unsere Stand-up-Meetings. Alle zwei Wochen zeigen wir intern im Review-Meeting den aktuellen Fortschritt der Umsetzung. Der (interne) Kunde ist hier nicht dabei – schließlich ist er ja nur an der fertigen Software interessiert und nicht an den Zwischenständen. Man bestätigt sich gegenseitig darin, dass man das aktuelle Projekt richtig agil abwickelt – kann aber durch die falsche Interpretation von Agilität kaum Vorteile daraus ziehen.
Eine agile Vorgehensweise, die richtig gelebt und umgesetzt wird, bringt immense Vorteile sowohl für das Entwicklungsteam als auch für den Kunden. Im Gegensatz zu den Vorgehensmodellen nach Wasserfall muss der Kunde nicht Jahre auf neue Funktionalitäten warten. Anstatt monatelang an einem Pflichtenheft zu tüfteln, kann man diese Zeit weitaus besser investieren und die am dringendsten benötigten Features zu Beginn umsetzen. Ist der Kunde direkt in diesen Prozess eingebunden, kann er jederzeit Feedback zu der aktuellen Umsetzung geben. Im Anlassfall kann zeitnah korrigierend eingegriffen werden.

Diesen kurzen Feedbackschleifen wird oft nicht die Bedeutung zugemessen, die ihnen eigentlich gebührt. Führt man sich jedoch bildlich vor Augen (siehe Abbildung 1), dass sie den Unterschied ausmachen, ob man mögliche Konzeptionsfehler nach 10 Prozent der Umsetzungszeit oder nach 100 Prozent erkennen kann, ist der Vorteil plötzlich glasklar. Im Endeffekt spart man nicht nur Zeit und damit letztendlich auch Geld, sondern legt auch den Grundstein für die Entwicklung eines praxistauglichen Produkts.

Abb. 1: Traditionelles vs. Agiles Vorgehen

Der wichtigste Punkt ist, dass die neu entwickelte Software frühzeitig zum Einsatz kommt und es sehr früh erstes Feedback gibt. Im Falle einer Modernisierung eines Softwaresystems ist es möglich, bestimmte Funktionalitäten schon im neuen System abzuwickeln. Für die Entwicklung von neuen Softwareprodukten ist es denkbar, Funktionalitäten nach und nach produktiv zu setzen. Nichts ist schlimmer, als iterativ Sprint für Sprint Features umzusetzen und nach Jahren der Entwicklung das erste Feedback der Anwender zu bekommen.

Zusätzlich resultiert ein zu eng geschnürtes Korsett in der Praxis bei einem Projektteam oft in fehlender Motivation. Bei einem auf Punkt und Komma ausspezifizierten Pflichtenheft darf eine fehlende Identifikation des Projektteams mit dem Produkt nicht verwundern. Wenn alle Benutzeroberflächen pixelgenau definiert sind, die Architektur bereits bis zur kleinsten Methode vorgegeben ist und auch sonst kein Handlungsspielraum besteht, wird das Team an Eigenantrieb verlieren.

Natürlich bedarf es einiger, grundlegender Vorgaben für die Entwicklung, um zu vermeiden, dass eine nicht wartbare, zu heterogene Systemlandschaft geschaffen wird. Die Definition eines Styleguides inkl. der Interaktionsmuster kann die Basis für eine durchgängige User Experience (UX) bilden. Eine Entscheidung über einzusetzende Frameworks – User Interface, Backend, Datenbank – ist zum Beispiel notwendig, wenn die entwickelten Systeme nach der initialen Umsetzung von der IT-Abteilung des Auftraggebers übernommen werden sollen. Im Allgemeinen muss eine projektspezifische Umgebung geschaffen werden, die das richtige Maß an Vorgabe und Freiheit abbildet. Eine Umgebung, in der es den Teams möglich ist, Produktverbesserungen proaktiv aufzuzeigen, und in der gelebt wird, dass bereits getroffene Entscheidungen im Bedarfsfall angepasst oder erweitert werden.

Es wird sich die berechtigte Frage stellen: „Wozu eigentlich Scrum und Agil – Was ist nun wirklich anders?” Gelingt es, ein Projektteam aufzustellen, dem Rahmenbedingungen geschaffen werden, um sich mit dem Produkt zu identifizieren und, noch viel wichtiger, es auch formen zu können, werden sich viele positive Verbesserungen ergeben, die im Endeffekt zu einem optimal einsetzbaren Produkt und einem zufriedenen Kunden führen. Scheitert ein Projekt auf Basis eines Pflichtenheftes wie im eingehenden Beispiel skizziert, werden im Management schnell die Köpfe rauchen. Was ist nur falsch gelaufen? Man lebt doch so agil – alle Elemente von Scrum sind eingebaut. Der wahre Grund für das Scheitern, die Notwendigkeit eines Umdenkens und Anpassen des gesamten Prozesses, wird leider oft übersehen. Hoffentlich findet sich in der nächsten Retrospektive auf der „Improve”-Seite ein Post-it mit der Botschaft: Pflichtenheft – Notwendig?

Microservices: ja! Abgestimmte Zeitpläne: nein!

Ein großes Review kurz vor Quartalsende steht an. Mit Beginn des neuen Quartals sollen die neu entwickelten Features online gehen. Nach einer Zwischenfrage von Bereichsleiter Bernd, ob denn alle neuen Features jetzt auch integriert verwendet werden können, wird dies kurzerhand ausprobiert. Der Versuch wird durch eine NullPointerException gestoppt. Daraufhin großes Getöse von Bereichsleiter Bernd: „Das ist jetzt nicht euer Ernst? Warum hat das niemand getestet?” Die Antwort darauf fällt wie folgt aus: „Wir haben es schon getestet, aber eben nur für unseren Service und gegen die Spezifikation der Schnittstelle. Nachdem das Gegensystem die vereinbarten Änderungen anscheinend noch nicht umgesetzt hat, kommt es eben zu einer Exception.”

In vielen Bereichen der Softwareentwicklung wurde in den letzten Jahren viel Zeit und Geld in die Umstellung auf Microservices investiert. Sie sollen unabhängiger voneinander und auch verteilt entwickelt werden können; sie sollen überschaubarer und wartbarer sein; sie sollen leichter skalierbar und natürlich im Sinne eines Continuous Delivery unabhängig voneinander produktiv eingesetzt werden können [New15]. Im oben skizzierten Szenario bedingen zwei Microservices in bestimmten Versionen einander. Der Vorteil der Unabhängigkeit entpuppte sich hier als Nachteil. Die Versionen der Schnittstellen sind inkompatibel und somit kommt es zu einem Fehler. Welche Möglichkeiten gibt es, um solche Fehler zu einem so späten Zeitpunkt zu vermeiden? Wichtig ist, dass beim Aufbau

beziehungsweise dem Umstieg auf eine Microservice-Architektur die Größe und die Verantwortlichkeit der Microservices richtig definiert werden. Sprich: „Do one thing well!” Um eine gut gewählte Serviceaufteilung nachhaltig aufrecht erhalten zu können und nicht in eine Abhängigkeitshölle zu geraten, darf man bei der Weiterentwicklung keine Experimente wagen. An den Verantwortlichkeiten der Microservices darf nicht gerüttelt werden und Schnittstellen müssen sauber versioniert werden [SemVer]. Bei allen technischen Möglichkeiten, Abhängigkeiten zu vermeiden, wird es aber immer wieder zu Querschnittsanforderungen an die Software kommen, die eine Koordination zwischen den Microservices erfordert. Hier ist die frühzeitige Einbindung aller betroffenen Bereiche, zum Beispiel durch ein Architecture-Weekly, das Mittel der Wahl, um eingangs beschriebene Schreckensmomente zu vermeiden.

MVP? Für die Fahrt zum Bäcker brauche ich (k)einen SUV!

Zwei Unternehmen starten zeitgleich an einer neuen Idee, mit der sie den Markt erobern wollen: eine Dating-Plattform für Haustiere. Während die einen an einem Zeitplan für die Umsetzung in den kommenden Jahren arbeiten, startet das zweite Unternehmen anders. Binnen kurzer Zeit wird ein Webportal realisiert, welches das Kern-Feature – das Matching von Haustieren – enthält. Eine kleine Werbekampagne in einer geografisch eingeschränkten Region adressiert eine erste Zielgruppe. Bereits wenige Wochen nach der initialen Idee arbeiten die Teams an Verbesserungen und Erweiterungen der Funktionalitäten basierend auf den Rückmeldungen von realen Kunden.

Zu dieser Zeit ist das erste Unternehmen noch damit beschäftigt, jeden möglichen Sonderfall zu spezifizieren, User Interfaces zu designen und Cloud-basierte Konzepte für den weltweiten Betrieb zu erarbeiten. Von einer ersten Erprobung des neuen und unbekannten Markts ist man noch weit entfernt. Nach ungefähr zwei Jahren ist man dann soweit und bringt eine Version auf den Markt. Zur Verwunderung fällt das Feedback der Kunden negativ aus und das Produkt kann am Markt nicht richtig Fuß fassen. Was ist schief gegangen? Technologisch hat man doch alles richtig gemacht!

Dieses fiktive Beispiel lässt sich in der Praxis in vielen Bereichen finden. Das Konzept um ein Produkt oder einen neuen Teil einer Anwendung in Form eines Minimum Viable Products (MVP), dem kleinsten brauchbaren Produkt, schnell auf den Markt beziehungsweise zum Anwender zu bringen, klingt sehr einfach – ist es aber in der Praxis leider nicht immer. Die Gründe für das Scheitern sind vielfältig. Einmal ist es der Irrglaube, man kenne den Markt in- und auswendig, eine frühe Markterprobung sei daher nur Zeitverschwendung. Ein anderes Mal ist es die Angst, mit einem unfertigen, unausgereiften Produkt auf den Markt zu gehen. Aber was nützt es, Jahre der Entwicklung in ein System zu stecken, um nach Aufbrauchen sämtlicher finanzieller Ressourcen festzustellen, dass das Produkt in der umgesetzten Form vom Markt nicht akzeptiert wird?

Firmen wie Google, Amazon oder Facebook sind erfolgreich, weil sie unter anderem neue Features oftmals in Form von MVPs umsetzen. Mit dem frühen Feedback entscheiden sie, ob ein Feature weiterverfolgt oder verworfen werden soll. Ein Beispiel dafür ist die Evolution von Amazon von der kleinen Onlinebuchhandlung zum Universal-Onlineversandhändler [VersionMuseum].
Wie in Abbildung 2 ersichtlich, ist es wichtig, die Basisfunktionalität (Wie komme ich von A nach B?) so schnell wie möglich herzustellen und dann iterativ zu verbessern und zu erweitern (vom Skateboard zum Roller, vom Roller zum Fahrrad, …). Vielleicht wird das zu entwickelnde Feature gar nie in seiner vollen Ausprägung benötigt. Oder um wieder bildlich zu bleiben: Wenn ich nur für ein paar Brötchen zum Bäcker fahre, dann brauche ich keinen Geländewagen. Fahre ich nach dem Einkauf jedoch weiter zum Campen, dann bietet sich ein SUV an!

Abb. 2: Lange Wartezeit vs. frühe Produktnutzung und kontinuierliche Verbesserung

Der MVP-Ansatz beschränkt sich nicht nur auf neue, bisher unbekannte Ideen oder Produkte. Auch in der klassischen Anwendungsentwicklung findet dieser Ansatz seine Berechtigung. Oft ist man mit der Meinung konfrontiert, dass ein Fachprozess in seinem vollen, bisherigen Umfang berücksichtigt und umgesetzt werden muss. Erst danach kann er den Anwendern präsentiert werden. Weil das schon immer so war und auch das Vorgängersystem so arbeitet, sind klassische Antworten auf die Warum-Frage. Auf Basis des MVPs ist es aber möglich, deutlich schneller und auch kosteneffizienter zum Ziel zu kommen. Mit minimalem Aufwand wird der Kern eines Prozesses umgesetzt und sofort von den Anwendern in der Praxis validiert. Auf Basis des Feedbacks wird das Feature iterativ verbessert, bis die Anwender zufrieden sind.
Durch diese effiziente Herangehensweise ist es möglich, mehrere Features in einer ersten einsetzbaren Version parallel zu entwickeln. Ein komplexerer Fachprozess kann so frühzeitig abgebildet und validiert werden. Was nützt es einem Onlineshop, wenn er über einen ausgeklügelten Warenkorb verfügt, es aber nicht möglich ist, einen Bezahlvorgang abzuwickeln, da hierfür noch keine Zeit gefunden wurde. Der richtige Ansatz ist ein funktionierender Warenkorb, die Realisierung einer Zahlungsmöglichkeit und basierend auf diesem Fundament die iterative Umsetzung von Erweiterungen, sofern diese überhaupt notwendig sind. Überraschend oft stellt sich heraus, dass man mit weniger Funktionalität – zum Beispiel zwei statt fünf Zahlungsmöglichkeiten – auskommt. Die Anwender sind trotzdem – oder vielleicht gerade deswegen – zufrieden.

Letzte Zeile Code fertig. Restaufwand für das Team: 0 Stunden!?

Die letzte User-Story für das neue Feature der Paketnachverfolgung in der mobilen Applikation eines Pharmaunternehmens wurde gerade geschlossen. Seit sechs Sprints begleitete dieses, doch sehr umfangreiche Thema das Projektteam. Umso größer ist die Freude – vor allem bei der Abteilungsleiterin Nadine, die bereits das Budget für dieses Feature abschließt, gute Zahlen an das Management reportet und damit rechnet, dass das Team im nächsten Sprint gleich mit Vollgas an neuen Themen arbeiten wird. Zwei Wochen später. In der Sprint-Retrospektive sieht man nur lange Gesichter, da das aktuelle Sprint-Ziel bei Weitem nicht erreicht werden konnte. Nach kurzer Ursachenforschung stellt sich heraus, dass ein Großteil des Teams noch immer mit Themen des vermeintlich abgeschlossenen Features beschäftigt war. Konfigurationen richtig einstellen, Fragen aus dem produktiven Betrieb beantworten, kleine Bugs beheben und fachliche Unsauberkeiten gerade ziehen. Der Ärger bei der Abteilungsleiterin Nadine ist groß: Nun setzen wir doch alles in Sprints um und dann sind nach der Umsetzung noch immer Aufwände? In welcher Planung und in welchem Budget ist denn das bitte berücksichtigt?

Dieses und ähnliche Szenarien kommen in der Praxis sehr häufig vor. Neue Anforderungen werden sauber aufbereitet, Epics in User-Storys aufgeteilt, die dann wiederum vom Team geschätzt und in Sprints eingeplant werden. Am Ende jedes Sprints ist das Feature größer und komplexer geworden und wird in Form eines Shippable Increments ausgeliefert. Oftmals heißt eine Auslieferung, dass es auf einer internen QA-Instanz installiert wird. Bis zum realen Endkunden schaffen es noch nicht komplett umgesetzte Features sehr selten. Entweder weil der Endkunde nicht nach jedem Sprint eine neue Version bekommt oder weil das Feature so lange vor dem Anwender versteckt im Code schlummert, bis es finalisiert ist. Doch gerade das frühzeitige Feedback aus dem Betrieb ist extrem wichtig, um gegebenenfalls einlenken und die Umsetzung an die möglicherweise abweichenden realen Anforderungen anpassen zu können – nicht erst nach der letzten User-Story. Denn so entsteht die Situation, dass ein Feature – ja im schlimmsten Falle eine ganze Applikation – vom Team nach bestem Wissen und Gewissen umgesetzt wurde, Feedback dazu gibt es aber erst viel zu spät.

Abb. 3: Klassische Fragen nach Fertigstellung eines Features ohne vorheriger Feedback Zyklen

Und das führt zu der Situation, dass klassische Fragen (siehe Abbildung 3) erst nach der Fertigstellung des Codes gestellt werden. Ihre Beantwortung kostet Zeit, und somit auch Geld. Und das sorgt für Unverständnis im Management – denn wo ist hier genau der Vorteil der agilen Vorgehensweise? Diese Probleme gab es in der frühreren Wasserfall-Entwicklung auch – nur war man darauf vorbereitet, dass nach der Auslieferung des Jahres-Releases solche Themen auftauchen werden, und hat diese in der Kapazitäts- und Budgetplanung berücksichtigt.
Wenn man aber die Agilität richtig lebt und auch den letzten Schritt – in diesem Fall frühes Feedback durch Einbindung der Endkunden – geht, dann bewahrt man sich vor bösen Überraschungen und ein Epic ist nach dem Abschluss auch wirklich fertig.

Retrospektive

Die Welt der Agilen Entwicklung gibt uns Werkzeuge in die Hand. So wie man mit einem Hammer keine Schraube einschlagen sollte, muss man auch in der Softwareentwicklung beachten, dass das Werkzeug auf die Aufgabe abgestimmt sein muss, um erfolgreich zu sein. Das heißt, der angewandte Prozess muss zum Projekt und zur Projektphase passen. Wie kommt man zur Auswahl der geeigneten Projektmethodik, abgesehen von Erfahrung, Bauchgefühl und natürlich organisatorischen Vorgaben? Die Erstellung einer Stacey-Matrix [Zim], mit den beiden Eigenschaften Anforderungen und Technologie auf den Achsen aufgetragen, verdeutlicht ganz klar, in welcher Kategorie das Projekt einzuordnen ist (siehe Abbildung 4).

Abb. 4: Technologien und Anforderungen als Parameter für die Methoden-entscheidung

Der agile Ansatz funktioniert sehr gut für komplexe Projekte, wo Anforderungen und Technologie nur teilweise bekannt sind [ProMag]. Hier findet sich auch die Mehrheit der Softwareentwicklungsprojekte wieder.

Im chaotischen Bereich erreicht auch Agilität ihre Grenzen und ein wissenschaftlicher Ansatz, gekennzeichnet durch das gezielte Testen von Hypothesen, ist besser geeignet, das Chaos in ein beherrschbares Umfeld zu bringen. Im Falle von vorab genau spezifizierten Anforderungen (z. B. aufgrund von gesetzlichen Rahmenbedingungen) und gut bekannter Technologie (z. B. Erweiterung auf Basis schon bestehender Software) bewegen wir uns im simplen oder komplizierten Bereich der Stacey-Matrix. Ein agiles Vorgehen kann, muss hier aber nicht immer die erste Wahl sein. Agile Arbeitsweisen entwickeln sich ständig weiter. Schlagworte wie eigenverantwortliche Teams, DevOps usw. kannte man vor zwanzig Jahren noch nicht. Um die Vorteile richtig nutzen zu können, ist es wichtig, mithilfe des weitreichenden agilen Methodenkoffers einen durchgehenden agilen Prozess zu etablieren. So können die Vorteile der agilen Arbeitsweise voll und ganz ausgeschöpft werden. Wir hoffen, dass unsere Beispiele Sie ein wenig zum Nachdenken angeregt und für den einen oder anderen Aha-Moment gesorgt haben.