On Lean and Agility

An sich klingt es erst einmal wie etwas Positives: mit Hilfe der immer besseren und intuitiveren KI-Tools ist es heute so einfach wie nie, Software zu erstellen. Sei es als Programmier-Unterstützung, wie im Fall des Github Copilot, oder als ein Programm, dass einem den Grossteil der Arbeit abnimmt, wie Lovable - es gibt eine ganze Reihe von Möglichkeiten, die eigene Produktivität in bisher ungeahnte Höhen zu schrauben. Und doch steckt auch ein Risiko dahinter.

Vereinfacht gesagt: wenn es auf einmal so einfach ist, neue Programme und Features zu erstellen, wird das auch mit grösserer Bereitwilligkeit getan werden als bisher. Statt aufgrund der begrenzten Kapazität der IT-Abteilungen nur die wirklich wichtigsten Anforderungen umzusetzen, kann jetzt jeder Kundenwunsch, jede einzelne Stakeholder-Anforderung und jede Entwickler-Idee in Produktion gebracht werden. Und das ist bei weitem nicht so positiv, wie es klingen mag.

Die offensichtlichste Folge eines derartigen bereitwilligen Umsetzens aller Wünsche ist die Entstehung von Bloatware, also von Anwendungen, die derartig mit Funktionen überladen sind (von denen viele nur eine sehr kleine oder ggf. sogar lediglich eine hypothetische Anwendergruppe haben) dass sie unübersichtlich werden, schlecht zu bedienen sind, hohe Ladezeiten haben und viel Speicherplatz einnehmen. Mit anderen Worten - es wird ein aus Kundensicht schlechtes Produkt.

Und auch unterhalb der Benutzeroberfläche führt das massenhafte Erzeugen von Funktionalitäten (und damit von Code) zu Problemen. Auch hier ist die Unübersichtlichkeit ein zentrales Problem. Je grösser die Codebase wird, desto schwieriger wird es zu sagen, an welcher Stelle was passiert. Die Überprüfung der KI-Ergebnisse durch einen Menschen (deren Verzicht einem Kontrollverlust gleichkäme) wird immer schwieriger und irgendwann sogar unmöglich.

Diese Phänomene erinnern nicht ohne Grund an die Build Trap (sinngemäss die Produktivitäts-Falle), die 2019 von Melissa Perri in ihrem gleich benannten Buch beschrieben wurde. Auch ihr selbst ist diese Parallele aufgefallen, und sie hat sie in mehreren Social Media-Posts thematisiert. Von ihr stammt auch die Erweiterung des ursprünglichen Begriffs zu dem der AI Build Trap, der damit als zusätzliche und spezifische Ausprägung dieses Antipatterns beschrieben ist.

Um auch hier zu einem konstruktiven Ausblick zu kommen: in die AI-Produktivitäts-Falle zu geraten, ist zum Glück kein Naturgesetz, man kann (und sollte) es auf verschiedene Weisen verhindern. Zum einen, indem man durch kleine, schnell veröffentlichte Incremente überprüft, ob es für die neuen Funktionen überhaupt Bedarf oder Akzeptanz gibt, zum anderen indem intern regelmässig sichergestellt wird, dass der Code von Menschen verstanden wird und ggf. verändert werden kann.

Das kann sich natürlich wie eine Entschleunigung der gerade erst gewonnenen Programmier-Höchsgeschwindigkeit anfühlen - und es ist auch eine. Trotzdem ist es sinnvoll, sich darauf einzulassen, wenn man nicht riskieren will, sich in der Build Trap wiederzufinden, und Produkte gebaut zu haben, die vom  Kunden nicht gewollt und von den eigenen Entwicklern nicht verstanden werden.

Bild: Flickr / Oregon State University - CC BY-SA 2.0

Unter den gedanklichen Konstrukten, die ich aus der Politikwissenschaft in meinen Beruf übernommen habe, ist die Verflechtungsfalle einer meiner Favoriten. Sie beschreibt die Situation in der sich überschneidende Verantwortlichkeiten zu einer Koordinations-, Kooperations- und Kontrollbürokratie führen, die alles lähmt, die aber auch einen derartigen Komplexitätsgrad hat, dass sie nur mit erheblichen Aufwänden wieder auflösbar ist. Fast alle grossen Organisationen sitzen in dieser Falle.

In welcher Form sie auftritt kann von Fall zu Fall unterschiedlich sein, es gibt aber einen grossen, immer wieder anzutreffenden Klassiker: eine Matrix-Organisation, die einer auf dem Anforderungsmanagement basierenden Budgetplanung unterliegt. Eine derartige Struktur ist ein fast sicherer Garantiefaktor für das Zuschnappen der Verflechtungsfalle - und bemerkenswerterweise ist sie trotzdem die Grundlage für das Organisationsdesign vieler Grossunternehmen.

Wie sieht das in der Realität aus? Zunächst so, dass die Verantwortung für einzelnen Programme, Projekt- oder Produktteams aufgeteilt wird. Häufig ist eine Trennung in Personal- und Produktverantwortung, auch die lassen sich aber nochmal unterteilen. Die Produktverantwortung lässt sich z.B. trennen in Entwicklung und Betrieb, der Personalverantwortung in Disziplinarisch und Fachlich. Es wirken also zwei, drei, vier (oder noch mehr) Manager gleichzeitig auf die Menschen der Umsetzungs-Ebene ein.

Das verkompliziert sich nochmal dadurch, dass die Gruppen, auf die die jeweiligen Manager einwirken, sich nur zum Teil überschneiden. So sind z.B. die Projektleiter für ihre jeweiligen Projekte zuständig, die Abteilungsleiter für jeweils eine über alle Projekte verteilte Gruppe von Spezialisten (etwa die Frontend-Entwickler) und die Architekten dafür, dass diese Menschen sich in bestimmten Themenfeldern (etwa bei der Weiterentwicklung des Intranets) an bestimmte system- und projektübergreifende Standards halten.

Alleine das wäre schon ausreichend, um für regelmässige Abstimmungsprobleme zu sorgen, aber jetzt kommt die Budgetierung dazu. In solchen Konstellationen verfügen in der Regel die Programm- oder Projektleiter über die Budgets. Diese nutzen sie um auf einem unternehmens-internen Markt von den Abteilungen jeweils die Spezialisten einzukaufen, mit denen die gerade anliegenden Anforderungen umgesetzt werden können. Und nur damit werden diese dann beauftragt.

Die anderen Manager bringt das in ein Problem. Die Ziele der Personalentwicklung (z.B. alle lernen regelmässig neue Programmiersprachen) oder der Architektur (z.B. alle Anwendungen bestehen aus Self Contained Systems) können den Zielen der Produktentwicklung widersprechen, da sie die Umsetzung von Anforderungen temporär oder dauerhaft verlangsamen würden. Da aber an der Produktentwicklung das Budget hängt, droht allen anderen Zielen permanent das Schicksal "wegpriorisiert" zu werden.

Um diesem Schicksal zu entgehen, wird oft versucht, auf einem anderem Weg als über das Budget Einfluss auf die Produktentwicklung zu nehmen. Es gibt beispielsweise Organisationen, in denen Architekten unternehmensweit geltende Entwicklungsvorschriften machen können, deren Einhaltung in einer Qualitätssicherungsphase überprüft wird. Und die Abteilungsleiter können ihre Ziele in die Jahresziele ihrer Untergebenen schreiben, wodurch die versuchen werden, sie irgendwie unterzubringen.

Die häufige Folge eines solchen Organisationsdesigns ist eine auf allen Ebenen ausgetragener ständiger Zielkonflikt, bestehend aus Verhandlungen, Eskalationen, verweigerten Freigaben, zurückgehaltenen Informationen, Kompromissen und Versuchen vollendete Tatsachen zu schaffen, wodurch sich alle Beteiligten gegenseitig behindern. Und wenn dann auch noch jeder Manager Teile seines Gehalts mit der Erreichung seiner Ziele verknüpft hat, wird er für ein solches Verhalten sogar noch belohnt.

Wenn es das Ziel einer Organisation ist, agile Produltentwicklung zu betreiben, ist das alles natürlich nicht zielführend. Wie man davon wegkommt hängt sehr von der Ausgangssituation ab, gute Ideen sind aber, Produkt- und Personalverantwortung zusammenzulegen, die Verfolgung gegenläufiger Ziele nicht zu belohnen (alleine das wäre ein Thema für sich) und die Budgetierung nicht mehr auf Anforderungen beruhen zu lassen sondern auf stabilen, produktorientierten Teams.

In fast allen Fällen sind das tiefgreifende Eingriffe in die bisherigen Strukturen und Abläufe, wodurch das unschöne Kriterium erfüllt wird, das aus einer Verflechtung die Verflechtungsfalle macht - man kommt nur schwer wieder heraus. Aber man kommt heraus, wenn man es darauf anlegt. Ganz nebenbei ist das auch ein guter Test um herauszufinden, wie ernst es mit der Agilität gemeint ist. Dort, wo es keine derartigen Anpassungen gibt, im Zweifel nicht so sehr.

Bild: Wikimedia Commons / Museo del Templo de Santo Domingo de Guzmán - Public Domain

Ein Blick über den Telerrand kann interessante Inspirationen bringen. Auf The Atlantic schreibt Brian Klaas über die Dictator Trap, hinter der sich verbirgt, dass die Inhaber bedeutender Machtpositionen gefährdet sind die Realität nur noch gefiltert wahrnehmen zu können, mit schlechten Entscheidungen als Folge. Was beim Lesen ins Auge fällt: vieles von dem was Klaas hier beschreibt trifft auch auf Manager in grossen Firmen zu.

Um mit einem Disclaimer anzufangen: natürlich ist nicht jeder Manager ein Autokrat, es gibt auch solche die einen jener Führungsstile pflegen die als "lateral", "partizipativ" oder "auf Augenhöhe" bezeichnet werden. Sehr viele setzen aber in ihrer Berufsausübung stark auf einsame Entscheidungen, Einweg-Kommunikation, direktive Führung und Absonderung von der "Ausführungs-Ebene".¹ Um diese zweite Gruppe soll es hier gehen.

Wie so häufig steht auch hier am Anfang eine rationale Entscheidung: wer neu in eine zentrale Position aufgerückt ist will sich meistens mit Mitstreitern umgeben die die eigenen Ziele und Überzeugungen teilen, umgekehrt macht es Sinn sich von Menschen mit gegenläufigen Zielen und Ansichten zu trennen.² Das sorgt zu Beginn für grössere Handlungsfähigkeit, steigert aber das Risiko, dass Group Think entsteht und auch relevante abweichende Einwände unter den Tisch fallen.

Selbst dort wo sogar die ähnlich denkenden Unterstützer der Meinung sind, dass eine getroffene Entscheidung falsch ist, wird Widerspruch mit der Zeit immer weniger stattfinden. Wenn die eigene Karriere auf das Wohlwollen des Chefs angewiesen ist, ist es naheliegend von jetzt an dessen Ansichten zu den eigenen zu machen. Und für den der das irgendwann mit seinen Überzeugungen nicht mehr vereinbaren kann ist es naheliegend zu gehen und bei einem anderen Förderer Karriere zu machen.

Auch das lässt sich aber noch steigern. Wenn falsche Entscheidungen an der Spitze zu Misserfolgen geführt haben kann es sein, dass diese aus Angst um die eigene Karriere oder als Loyalitätsbeweis verschwiegen oder umgedeutet werden - die fehlgeschlagene System- oder Methodenumstellung wird dann nach oben als Erfolg reportet, im Zweifel durch kreative Auslegung und selektive Nutzung von Daten oder Ergebnissen.³ Ein Phänomen das häufiger ist als man denken sollte.

Die Diktatoren-Falle ist damit zugeschnappt. Der Manager an der Spitze hat aus seiner Sicht alles richtig gemacht - sich mit Unterstützern umgeben und diejenigen unter ihnen gefördert die Erfolgsmeldungen statt ständiger Bedenken vorgetragen haben. Das Ergebnis ist aber eine Abkoppelung von der Realität. Probleme und Fehlschläge werden verschwiegen, Erfolge aufgebauscht oder künstlich konstruiert. Und wenn dieses Konstrukt irgendwann zusammenbricht ist es für ihn überraschend.

Um dieser Situation zu entgehen gibt es verschiedene Wege. Einer besteht darin, sich bewusst mit einigen kritischen Geistern zu umgeben, die auch dezidiert abweichende Meinungen vertreten. Das kann zwar die Tendenz zum Groupthink aufbrechen, führt aber häufig dazu, dass nur wenige "Hofnarren" das Recht haben unsanktioniert zu widersprechen, während die Dysfunktionen in der umgebenden Organisation erhalten bleiben.

Bild: CCNull / Tim Reckmann - CC BY 2.0

Es gibt Bücher, deren Autor ein seltenes Kunststück fertigbringen: schon nach wenigen Seiten hat man das Gefühl, dass die Kernbotschaft übermittelt wurde und eigentlich kaum noch ein relevanter Mehrwert kommen kann, aber wenn man doch weiterliest wird man postitiv überrascht, erhält zusätzlichen Wissensgewinn und wertvolle Impulse. Melissa Perri's Erstwerk Escaping the Build Trap gehört in diese bemerkenswerte Kategorie.

Dass früh der Eindruck aufkommt, dass schon alles Pulver verschossen sein könnte, liegt daran, dass bereits im Vorwort abschliessend erklärt wird was die "Build Trap" ist - das im Akkord stattfindende Einbauen immer neuer Features in ein Produkt, ohne zu überprüfen ob diese von den Anwendern gewünscht oder benutzt werden. Auch der verdeutlichende Erfahrungsbericht (der natürlich einen die Botschaft unterstreichenden Aha-Effekt enthält) findet sich bereits hier.

Einen Hinweis darauf, warum dieser merkwürdig frühe Kulminationspunkt gewählt wurde, liefert Perri in der Einleitung selbst: insgesamt dreimal hat sie ihr Werk vor der Veröffentlichung überarbeitet und dabei jedesmal den Focus geweitet - von der in der "Produktionsfalle" feststeckenden urprünglichen Zielgruppe (den einzelnen Produktmanagern) über immer grössere Einheiten bis zuletzt zu einem Gesamtblick auf ganze Firmen. Der Titel und die frühe Auflösung dürften noch Teil der ersten Version sein.

In der veröffentlichten Fassung¹ wird auch über die Build Trap hinaus das ganz grosse Bild des Produktmanagements gezeichnet, angefangen von der Frage, was überhaupt ein Produkt ist, über die Produktvision, die Produktstrategie, die produkterzeugende Organisation (und deren idealen Aufbau), die Budgetierung, die Rolle und die Karrierepfade des Produktmanagers und die Erfolgsmessungen, bis hin zu den Lern- und Erkenntnisprozessen und zahlreichen anderen Themen.

Dass das Buch den Anspruch verfolgt, für alle Karriere- und Erfahrungsstufen geeignet zu sein, merkt man ihm manchmal an,² zumindest wenn man selbst bereits einige Erfahrungen mitbringt und daher einen Teil der beschriebenen Inhalte bereits kennt, es entsteht aber dadurch ein stimmiges Gesamtbild, das Einsteigern eine gute Orientierung über alle relevanten Themengebiete ermöglicht und erfahrenen Produktmanagern vieles wieder in Erinnerung rufen dürfte.

Eine weitere Besonderheit besteht darin, dass Perri sich (z.T. explizit, z.T. unterschwellig) an den dominierenden agilen Frameworks Scrum und SAFe, bzw. an deren Rollen des Scrum-Product Owners, des SAFe-Product Owners und SAFe-Product Managers abarbeitet. Unter anderem kritisiert sie die häufige Besetzung der Product Owner mit relativ unerfahrenen Personen und die Entkoppelung von Team-orientierten und Kunden-orientierten Rollen in SAFe. Man kann ihr da nur zustimmen.

Ungeachtet dessen lässt sie aber keinen Zweifel daran, dass sie eine Befürworterin der agilen Produktentwicklung ist und betont auch ihren eigenen Lean Startup-Hintergrund. Die Aussagen von Escaping the Build Trap sind daher gut mit den gängigen agilen Frameworks (ausser SAFe) vereinbar, so dass man allen derartig arbeitenden Menschen das Lesen bedenkenlos empfehlen kann, gerade als Ergänzung zu der häufig dominierenden Prozess- oder Technologie-Sicht.

Etwas kurios (aber nicht weiter störend) ist die in unregelmässigen Abständen auftauchende fiktive Firma Marquetly, der Melissa Perri in verschiedenen fiktiven Erlebnisberichten hilft, ihr Produktmanagement zu optimieren. Vermutlich war eine der früheren Fassungen des Buches in Romanform verfasst, vergleichbar mit Gene Kim's Phoenix Project, was dann durch die weiter oben erwähnten Überarbeitungen in den Hintergrund getreten ist.

Zuletzt bietet das Buch in seinem letzten Kapitel auch eine praktische Hilfe für die Selbsteinschätzung. Mit einem kurzen Fragenkatalog und einer Erläuterung der passenden Antworten kann jeder selbst überprüfen wie produktorientiert seine Firma ist, bzw. ob sie in der Build Trap feststeckt. Ist das letzte der Fall, kann es ein guter nächster Schritt sein, allen Entscheidungsträgern dieses Buch zu empfehlen.

¹Genauer gesagt in der zweiten Auflage, auf der diese Besprechung beruht
²Perri schreibt selbst, dass sie das beabsichtigt

Bild: Flickr / Royalty Free - CC BY 2.0

In der Theorie ist es ganz einfach: das Management erkennt, dass es für Flaschenhälse und Stille Post-Effekte sorgt wenn es alles zentral entscheiden will, also delegiert es Kompetenzen auf die niedrigeren Hierarchieebenen. Dort können die Mitarbeiter jetzt selbst Entscheidungen treffen ohne für alles nach Erlaubnis zu fragen und auf die Genehmigung warten zu müssen. Beschwingt wird in die neue Arbeitswelt gestartet - und zu oft ist eine Bruchlandung die Folge.

Dass es häufig zu diesen Bruchlandungen kommt hat Gründe. Wer in seiner Karriere noch keine wichtigeren Projekt- oder Produktmanagement-Entscheidungen treffen musste wird häufig nicht das Wissen über alle dazugehörigen Aspekte haben und darum wichtige vergessen und unwichtigen zu viel Aufmerksamkeit geben. Der amerikanische Wirtschaftswissenschaftler Claus W Langfred hat das schon 2008 unter dem Namen der "Autonomie-Falle" in einer Studie beschrieben, später ist dieser Begriff vom ebenfalls amerikanischen Informatik-Professor Cal Newport weitergedacht worden.

Langfred und Newport beschreiben vor allem zwei Aspekte. Zum einen durch welche System-Defizite es überhaupt dazu kommt, dass niemand die Delegation von Verantwortung mit einer Weiterqualifizierung der Mitarbeiter verbindet (überspitzt zusammengefasste Antwort: weil zuwenig mitgedacht wird), zum anderen was die Folgen davon sind (nochmal überspitzt: es entsteht ein hyperaktives Schwarm-Bewusstsein, das ständig irrelevante Arbeit erzeugt). Mindestens genauso interessant ist aber eine andere Frage - welches Wissen hätte eigentlich zusammen mit der Delegation vermittelt werden müssen?

Als erstes dürfte hier das Kontextwissen zu nennen sein. In welchem Umfeld sind die Entscheidungen zu treffen für die man auf einmal zuständig ist? Zu welchen anderen Organisationseinheiten bestehen Abhängigkeiten und wer ist dort jeweils der Ansprechpartner an den man sich zuerst wenden sollte? Bereits bei Personen auf der gleichen Hierarchie-Ebene ist in dieser Hinsicht schon viel zu beachten, noch komplizierter wird es wenn andere Hierarchiestufen beteiligt sind. Die Frage wo Selbstorganisation aufhört und wo man weiter eine Genehmigung braucht ist hier von elementarer Bedeutung.

Ein weiterer Punkt ist das technische Wissen. Ist das was zur Entscheidung ansteht überhaupt mit den vorhandenen Systemen umsetzbar oder müssten die umkonfiguriert oder sogar umgebaut werden? Und wenn das zweite der Fall ist - wer könnte (und darf) das machen? Wer benutzt diese Systeme sonst noch und sollte daher in die Entscheidung einbezogen werden, welche Architekturparadigmen sind zu beachten, gibt es bereits Pläne für eine Ablösung oder Weiterentwicklung und was sind erfahrungsgemäss die Teile die besonders kompliziert oder instabil sind?

Auch Wissen um die Prozesse gehört dazu. In welchem Kommunikations-Kanal, mit welchen Informationen und mit welchen Fristen müssen Informationen verschickt und Änderungen angekündigt werden, welche Gesetze und Vorschriften sind relevant und was muss wie dokumentiert werden? Auch die inoffiziellen Prozesse sind wichtig. Wer hat beim jeweiligen Thema Interesse und Einfluss, wer könnte ein Unterstützer sein und wer gilt eher als Quertreiber? Wer das nicht weiss wird sich mitunter an unerwarteten Stellen schwertun.

Genug der Problembeschreibung, wie kann die Befreiung aus der Autonomiefalle gelingen? Schulungen sind verbreitet aber meistens ineffektiv, Peer Groups sind hilfreich, stehen aber oft vor dem selben Problem. Coaching durch die bisherigen Entscheidungsträger könnte die beste Lösung sein, oft sind diese aber mit dem Konzept nicht vertraut (nochmal eine spezielle Ausprägung der Autonomiefalle: viele Manager haben wenig Erfahrung damit Anderen zu helfen ohne die Entscheidung an sich zu ziehen).

Eine mögliche Lösung kommt aus David Marquets Buch Turn the Ship Around. In einem (z.B. wöchentlichen) Regeltermin kann man dem bisherigen Entscheidungsträger erzählen was man vorhat (ich möchte Folgendes erreichen) und wie man es angehen will (dazu plane ich Folgendes zu tun). Der kann dann auf mögliche Probleme hinweisen und Erfahrungswerte weitergeben, ohne dass er die Entscheidung übernimmt oder genehmigt. Mit der Zeit kann dieser Termin dann immer seltener werden, so dass man dadurch nach und nach aus der Autonomiefalle herausgeführt wird.

Bild: Flickr / Karen Rustad Tölva - CC BY 2.0

In den Diskussionen um Psychologische Sicherheit, Kultur, "Agile Mindset" und Change Management geht es manchmal unter, aber zumindest im IT-Kontext hat Agilität auch immer eine sehr technische Seite, ohne die schnelle Reaktions- und Lieferfähigkeit weder denkbar noch umsetzbar ist. Einer der wichtigsten Aspekte ist dabei die Automatisierung der Software-Tests, also der Qualitätssicherung der neu erstellten Funktionalitäten. Und wie so oft gilt auch hier - es reicht nicht es zu machen, man muss es auch richtig machen.

Zur Erinnerung: während die Abnahme-Tests im Sprint noch irgendwie mit manueller Arbeit zu stemmen sein können ist das bei den Regressionstests nicht mehr der Fall. Unter denen versteht man das regelmässige Überprüfen aller (!) älteren Funktionen, womit sichergestellt wird, dass diese nicht versehentlich durch neuere Entwicklungen beschädigt wurden. Bei grösseren IT-Systemen kann das eine fünfstellige Anzahl an Tests erfordern, was bei manuellem Durchklicken Wochen und Monate dauern kann.

Die einzige Lösung wenn man schnell sein will ist das Automatisieren möglichst aller Regressionstests. Erst wenn diese von einem Computerprogramm ausführbar sind können die erforderlichen Mengen und Geschwindigkeiten erreicht werden die nötig sind um Fehler schnell entdecken und beheben zu können. Ohne Testautomatisierung kommen bei grösseren Systemen die Jahres- und Quartals-Releases zurück. Aber (Ironie der Geschichte): auch eine falsch durchgeführte Testautomatisierung kann den selben Effekt haben.

Um aussagekräftig zu sein müssen die automatisierten Testsuiten immer dem aktuellen Stand der jeweiligen Anwendungsentwicklung entsprechen, sonst geben sie Fehlermeldungen aus sobald ein Feature verändert wurde, die Aktualisierung der Tests aber noch nicht stattgefunden hat. Das Risiko ist schnell erkennbar: wenn bei grösseren Änderungen hunderte von Tests aktualisiert werden müssen kann das einen Pflegeaufwand bedeuten, der wieder Wochen und Monate dauert - damit ist man wieder bei den Zeiträumen die man vorher hatte.

Um diesem Phänomen (der so genannten "Testautomatisierungs-Falle") zu entgehen müssen Erstellung und Struktur der automatisierten Tests an die agilen Entwicklungsprozesse angepasst werden. Wie das im Einzelfall aussieht kann von Fall zu Fall anders aussehen, folgende Grundsätze sind aber sehr häufig: Zusammenlegung von Test- und Entwicklungsteam, Modularisierung und Parametrisierung.

Die Zusammenlegung von Test- und Entwicklungsteam ist die einfachste, weil eher organisatorische Massnahme. Statt zwischen Entwicklung und Test einen kleinen Wasserfall aufzubauen werden die Tests jetzt gleich vom Entwicklungsteam erstellt, wodurch sie schneller fertig und aktueller sind. Ein unterschätzer Nebeneffekt kommt dazu: die "Tester" können in diesem Vorgehen selbst programmieren, was die Voraussetzung für Automatisierung ist.

Die Modularisierung sorgt dafür, dass der Instandhaltungsaufwand sinkt. Wenn z.B. nicht mehr in jedem von 100 Tests die Login-Schritte separat ausgeführt werden, sondern diese Schritte nur noch aus einem einzigen zentral gepflegten Modul abgerufen werden, muss ein geänderter Login-Vorgang nur noch einmal geändert werden statt 100 mal. Der Instandhaltungsaufwand sinkt damit auf 1% seines Umfangs (!).

Ähnliche Auswirkungen hat eine Parametrisierung. Bei ihr werden veränderbare Variablen (Testumgebungen, Browser, Testdaten, etc.) nicht mehr hart in den Test gecodet sondern ebenfalls zentral gepflegt. Bei der Test-Suite einer Web-Anwendung reicht es dann eine einzige zentrale Einstellung zu ändern und hunderte Tests laufen auf Firefox statt auf Chrome. Auch hier sinkt der Instandhaltungsaufwand immens.

Es ist offensichtlich, dass (und warum) die Testautomatisierungs-Falle und die dazugehörenden Gegenmassnahmen von zentraler Bedeutung für agile Software-Entwicklung sind. Und ganz nebenbei ergibt sich aus ihnen übrigens auch ein brauchbarer Lackmustest für Agile Coaches und Scrum Master. Die müssen nicht selbst Tests automatisieren können, sie sollten die Testautomatisierungs-Falle aber beschreiben können. Wenn das nicht geht sind sie (noch) zu technikfern.

Bild: Wikimedia Commons / Museo Antonino Salinas - CC BY 2.5

The real cause [of the war] I consider to be the one which was formally most kept out of sight. The growth of the power of Athens, and the alarm which this inspired in Lacedaemon, made war inevitable.

Thukydides, The History of the Peloponnesian War

Bild: Wikimedia Commons / Fallaner - CC BY-SA 4.0

Verflechtung

Die Verflechtungsfalle

Der gordische Knoten