On Lean and Agility

Dass viele "agile Methodiker" (Agile Coaches, Scrum Master, RTEs etc.) mit der Zeit eine eher negative Weltsicht entwickeln ist bedauerlich, aber erklärbar. Wer sich ständig mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue, Overcompliance und Konzern-Trolle beschäftigen muss, kann leicht zynisch und sarkastisch werden. Um nicht selbst irgendwann so zu enden, möchte ich dagegenhalten, indem ich ab und zu selbst erlebte "agile Erfolgsgeschichten" veröffentliche.

Eine an der ich vor längerer Zeit beteiligt war betraf die Qualitätssicherung in einem grossen IT-Projekt. Die hier tätigen Tester galten in der allgemeinen Wahrnehmung als doppelt problematische Schwachstelle: am Ende fast jedes Sprints wurden in den Entwicklungsteams die Tests der dort programmierten Features nicht mehr rechtzeitig fertig, und nach dem Sprintende waren die Regressionstests häufig zuerst grün, enthielten aber Wochen später plötzlich doch Fehlermeldungen.

Eine Analyse der Entwicklungsabläufe zeigte schnell zwei Hauptprobleme auf: zum Einen gab es in den Teams wasserfallartige Abläufe, in deren Rahmen die Entwickler lange unter sich arbeiteten, und die Tester erst kurz vor Sprintende erfuhren, was sie zu testen hatten (und das dann unter Zeitdruck tun mussten) zum Anderen hatte sich die übergreifende Regressionstest-Suite mit der Zeit selbst zu einem schwerfälligen Legacy-System entwickelt, dass nur noch aufwändig anzupassen war.

Dementsprechend wurden drei Verbesserungsmassnahmen durchgeführt. Zuerst wurden die Tester früher in die Abläufe ihrer Teams integriert. In den Backlog Refinements wurden sie daran beteiligt, die Akzeptanzkriterien testbar zu verfassen statt abstrakt, ihre Testaufwände wurden stärker in den Aufwandsschätzungen berücksichtigt und beim Planen der Sprints wurden Grösse, Auswahl und Anzahl der Entwicklungs-Aufgaben so vorgenommen, dass am Ende genug Zeit zum Testen blieb.

Als zweite Massnahme erfolgte eine stärkere Einbeziehung der Software-Entwickler in die QA-Abläufe. Wie oben geschrieben hatten die bis dahin das Testen als ein nachgelagertes Thema gesehen, das sie selber nicht mehr betraf. In dem verbesserten Vorgehen wurde dagegen eine Testpyramide angestrebt (siehe hier), in der bestimmte Mengen an (von den Entwicklern erstellten) Unit-, Integrations- und Lasttests zu einem Abnahmekriterium wurden, was das Testen am Sprintende deutlich beschleunigte.

Als Drittes wurde eine Überarbeitung der Regressionstest-Suite vorgenommen, die ja zu einem eigenen Problem geworden war. Bis dahin war sie einfach nach jedem Sprint um weitere Tests erweitert worden, während die bestehenden nur angepasst wurden, wenn (und nur dort wo) es Änderungen an den getesteten Funktionen gegeben hatte. Aufgrunddessen waren viele Tests redundant, kompliziert und unübersichtlich, was Anpassungen extrem aufwändig machte.

Um das zu verbessern wurde die Testsuite modularisiert und parametrisiert. Das Eine bedeutete, dass bestimmte Validierungen (z.B. des Login) nicht mehr in verschiedenen Tests enthalten waren, sondern nur noch in einem einzigen Modul, das dafür in beliebig viele Tests eingebunden werden konnte. Das Andere bedeutete, dass bestimmte variable Informationen (Browser, Ordnerpfade, etc.) nicht mehr hart im Test standen, sondern an einer zentralen Stelle systemweit geändert werden konnten.

In Summe führten diese verschiedenen Massnahmen dazu, dass die zu Beginn genannten Probleme fast völlig verschwanden. Die Tests (und mit ihnen die neuen Features) wurden in den Sprints fertig, in denen sie auch programmiert wurden, und die Aktualisierung der Regressionstests benötigte nur noch die Arbeit an einzelnen Modulen oder Parametern, statt an zig Stellen, wodurch versehentliche Seitenauswirkungen der neuen Features sofort gefunden werden konnten, statt Wochen später.

Am Ende ist es eine Binsenweisheit: eine Kette ist nur so stark wie ihr schwächstes Glied, und in vielen Softwareentwicklungs-Organisationen ist dieses schwächste Glied die Qualitätssicherung. Auch hier die agilen Praktiken einzuführen, und zwar sowohl technisch als auch prozessual, ist etwas, wovon alle Beteiligten massiv profitieren können.

Bild: Wikimedia Commons / David.Monniaux - CC BY-SA 3.0

Von den so genannten "Gesetzen der Softwareentwicklung" oder "Gesetzen des Projektmanagement" gibt es mittlerweile unübersehbar viele, allerdings stehen einzelne deutlich aus dieser Menge heraus. Eines davon ist Brooks's Law, benannt nach seinem Verfasser, dem amerikanischen Informatiker Frederick Brooks¹, der es 1975 im Essay The Mythical Man-Month in seinem gleich benannten Buch zum ersten mal veröffentlichte. Es lautet:

Adding manpower to a late software project makes it later / Das Hinzufügen von Arbeitskräften zu einem verspäteten Projekt sorgt für noch mehr Verspätung

Frederick Brooks, The Mythical Man-Month, S.25

Der Grund dafür, dass Brooks diese Gesetzmässigkeit verfasste war der, dass das übliche Management-Verhalten in Software-Projekten damals genau gegenläufig war.² Tatsächlich erscheint es auf den ersten Blick auch naheliegend - jede einzelne Person kann eine bestimmte Menge Arbeit pro Zeiteinheit erledigen, wenn man also weitere Personen hinzufügt könnte man davon ausgehen, dass in der selben Zeit mehr Arbeit erledigt werden kann. Aber so einfach ist es nicht.

Brooks nannte gleich mehrere Gründe, die dafür sorgen, dass statt einer Beschleunigung eine zusätzliche Verspätung auftritt. Der erste und offensichtlichste: neue Kollegen müssen zuerst eingearbeitet werden um arbeitsfähig zu sein, und das kann in der Regel niemand anderes tun als eine der Personen, die bereits länger mitarbeiten. Für die Dauer der Einarbeitungszeit kann er daher selbst nur eingeschränkt produktiv sein, die Arbeitskapazität nimmt also zunächst ab.

Selbst wenn die Einarbeitung abgeschlossen ist, gehen die verzögernden Effekte aber weiter. Wenn ein Vorhaben ursprünglich für eine geringere Umsetzungsmannschaft ausgelegt war, müssen als nächstes die Umsetzungsplanung und Aufgabenteilung überarbeitet werden, um sicherzustellen, dass synchrone und sequenzielle Abhängigkeiten berücksichtigt werden. Auch das benötigt wieder Arbeitskapazität, die dann bei der Umsetzung fehlt und diese dadurch verzögert.

Nun könnte man davon ausgehen, dass diese Verlangsamungs-Faktoren nur temporär sind. Irgendwann sind Einarbeitung und Umplanung abgeschlossen, und es kann mit erhöhter Geschwindigkeit weitergehen. Aber zum einen ist in den meisten verspäteten Projekten die dafür notwendige Zeit gar nicht gegeben, und zum anderen gibt es noch einen weiteren Faktor, der nicht temporär sondern dauerhaft sind, und der speziell mit den Abläufen der Softwareentwicklung zu tun hat.³

Wenn bei der Entwicklung einer Software neuer Code geschrieben wird, muss dieser danach in den bestehenden integriert werden. Um sicherzustellen, dass dieser danach noch immer funktioniert, sind Tests notwendig, und bei steigender Menge von Code schreibenden Entwicklern steigen auch Frequenz und Umfang der durchzuführenden Tests. Aufgrund dessen wird ein immer grösser werdender Teil der Arbeitskapazität dafür benötigt, die Tests aktuell zu halten, durchzuführen und auszuwerten.

Selbst wenn Softwareentwicklung heute etwas anders funktioniert als zu Brooks Zeit (sein Gesetz ist mittlerweile schon über 50 Jahre alt) haben sich die von ihm beschriebenen grundlegenden Zusammenhänge bis heute erhalten. Man kann daher noch immer davon ausgehen, dass das Hinzufügen von Arbeitskräften zu einem verspäteten Projekt nicht für eine Beschleunigung sorgt, sondern für noch mehr Verspätung, und das nicht nur kurzfristig, sondern dauerhaft.

Bild: Pexels / Picas Joe - Lizenz

Zu den am häufigsten missverstandenen (und aus diesem Grund immer wieder kontrovers diskutierten) Begriffen der Software-Entwicklung gehört die Zero Bug Policy, sinngemäss übersetzt die Regel keine Fehler in der Software mehr zu haben. Da die sich daraus ergebenden Debatten intensiv und zeitfressend sein können lohnt es sich, einen näheren Blick darauf zu werfen - um was geht es hier eigentlich und wo findet das Missverständnis statt?

Um mit dem Letzten zu beginnen: das Missverständnis besteht darin, dass oft angenommen wird, eine Zero Bug-Policy hätte zum Inhalt, dass keine Bugs mehr entstehen dürften. Dass das zwar wünschenswert aber nicht umsetzbar ist dürfte jedem klar sein, der sich schon einmal mit Softwareentwicklung beschäftigt hat. Die Komplexität und Vernetztheit von Anforderungen und Systemen ist zu gross um Fehler auszuschliessen, auch bei grösster Mühe.

Was tatsächlich hinter dem Begriff steckt ist die Regel, entdeckte Bugs schnellstmöglich zu beheben und das nicht auf einen späteren Zeitpunkt zu verschieben. Man kann sich Zero Bugs in diesem Kontext als die Kurzform von "Zero Bugs left behind" vorstellen, das macht den Begriff plastischer. Und schnellstmöglich bedeutet (vereinfacht gesagt), dass man zwar natürlich erst die laufenden Arbeitspakete abschliessen kann, aber keine neuen bearbeitet so lange noch Bugs gefixt werden können.

Mit dieser Erklärung erscheint die Reglung zwar nicht mehr undurchführbar, kontrovers bleibt sie aber. Ein häufiger Einwand ist z.B., dass es nicht vermittelbar ist, neue Features (mit denen Geld verdient und Kunden gewonnen werden können) aufzuschieben, nur um kleinere Bugs zu beheben, von denen nur wenige Anwender betroffen sind, die nur selten auftreten oder für die es einen Workaround gibt. Und isoliert betrachtet stimmt das sogar.

In der Realität treten derartige Bugs allerdings meistens nicht mit einer derartigen, von Beginn an klar erkennbaren nachrangigen Wichtigkeit auf. Zu Beginn ist fast immer eine Analyse nötig, die dann auch bereits den Grossteil des nötigen Aufwandes ausmacht. Die eigentliche Behebung kann im Anschluss daran eher schnell stattfinden, was ausserdem den Nebeneffekt mit sich bringt, dass die Analyse nicht mehr dokumentiert werden muss um zum Behebungszeitpunkt präsent zu sein.

Selbst im Fall einer von Beginn an klar erkennbar nachrangigen Wichtigkeit gibt es aber ein Argument gegen das Aufschieben. Bereits nach erstaunlich kurzer Zeit führt dieses Vorgehen nämlich zum Entstehen von Bug-Backlogs, die die Tendenz haben aus sich heraus ständig Bürokratie zu erzeugen: sind diese Tickes noch relevant? Sind sie noch aktuell? Sind sie richtig priorisiert? Sind sie bereits redundant? Alleine das zu überprüfen und zu dokumentieren kann einen irrsinnigen Verwaltungsaufwand bedeuten.

Die wirtschaftlichste Art damit umzugehen ist tatsächlich die No Bug Policy. Alle auftretenden Fehler müssen behoben werden, und zwar so bald wie möglich. Im Einzelfall könnte man zwar fast immer argumentieren, dass gerade dieses spezielle Ticket in Relation zu anderen unwichtig ist, im Durchschnitt spart die sofortige Behebung aber Zeit, Aufwand und Nerven. Und jedem der das nicht sofort einsehen will kann man gerne die Verantwortung für Analyse, Dokumentation, Aktualisierung, Priorisierung und Triage von Bugs übertragen.¹ Schnelle Lerneffekte sind dann garantiert.

Bild: Pixabay / Jill Wellington - Lizenz

Meine Tätigkeit als Test-Manager ist mittlerweile schon einige Jahre her, in vieler Hinsicht profitiere ich aber bis heute davon. Speziell die Frage wie in einem agilen Entwicklungsumfeld Qualitätssicherung betrieben wird ist spannend und herausfordernd, von der Zero Bug-Policy bis zum "agilen Testkonzept" gibt es vieles was anders ist als im klassischen Vorgehen. Ein weiterer derartiger Fall, der um den es hier gehen soll, ist die Priorisierung von Bug-Tickets.

Beginnen wir mit der Ausgangslage: klassisch werden Bugs in Kritikalitätsklassen eingeteilt, z.B. gering, mittel, schwerwiegend und systemkritisch.¹ Worauf diese Einteilung zurückgeht ist von Unternehmen zu Unternehmen unterschiedlich (und nicht immer klar definiert) sie beruht aber in der Regel darauf wie viele Funktionalitäten betroffen sind, wie wichtig diese für das Funktionieren des Gesamtsystems sind und ob es einen Workaround gibt. Diese Kritikalität beeinflusst dann auch das weitere Vorgehen.

In der Theorie ist es so, dass systemkritische Bugs sofort repariert werden, schwerwiegende zeitnah, mittelschwere mittelfristig (z.B. in Stabilisierungsphasen) und gering wichtige irgendwann - oder nie.² Die Idee dahinter ist meistens, dass es oberste Priorität ist neue Features zu bauen um die gesetzten (und mit Belohnung versehenen) Ziele zu erreichen. Die Qualitätssicherung erfolgt dann später im Projekt, ggf. sogar nach Go Live (mehr dazu hier) gering wichtige Bug-Tickets bleiben z.T. für immer ungefixt.

In der Realität funktioniert dieses Vorgehen auch im klassischen Kontext eher selten. Bei vielen Bugs fällt erst während der Behebung auf wie schwerwiegend sie sind, andere gelten wegen vorhandener Workarounds als weniger schwerwiegend, allerdings blockiert deren Nutzung die Weiterentwicklung der so genutzten Komponenten. Nochmal andere sind wirklich eher klein, sie beeinträchtigen die Benutzungserfahrung aber so sehr, dass die Nutzer unzufrieden werden. etc.

In einem agilen Entwicklungskontext wird ein solches Vorgehen dann völlig unmöglich, schliesslich soll die Anwendung (inclusive ihrer neuesten Features) durchgehend "potentially shippable" sein, also ständig im notwendigen Zustand um sofort released werden zu können. Das erfordert das zeitnahe Erledigen aller Bugtickets, wodurch der ursprüngliche Grund der klassischen Priorisierung (die Entscheidung welche Reparaturen auf später verschoben werden können) weitgehend obsolet wird.

Soviel zur Analyse, aber wenn die klassische Bug-Priorisierung im agilen Umfeld problematisch ist, wie geht es besser? Ein einfacher Ansatz mit dem ich gute Erfahrungen gemacht habe ist der: Bugs der Prioritätsklasse I werden sofort erledigt, ggf. sogar um den Preis des Sprint-Abbruchs. Bugs der Prioritätsklasse II kommen in den nächsten Sprint (und zwar alle, selbst wenn dann kein Platz mehr für Features bleibt), Bugs der Prioritätsklasse III werden nicht repariert und geschlossen.

Was steckt dahinter? Klasse I ist Produktionsausfall, Datenleck oder Vergleichbares, also etwas das alles andere schlägt. Klasse II ist Teil eins der Zero Bug-Policy, also die Reparatur aller reparaturwürdigen Fehler zum nächstmöglichen Zeitpunkt (der keinen Sprint sprengt), Klasse III ist Teil zwei der Zero Bug-Policy, in dessen Rahmen alle noch verbleibenden Bugs als so irrelevant eingruppiert werden, dass ihre Behebung den Aufwand nicht wert wäre.³

Vor allem zwei Vorteile enstehen durch diese neue Art der Priorisierung: zum einen wird die (oft widersprüchliche) Parallelität von Wichtig und Dringend aufgehoben, zum anderen wird das Backlog ausgemistet, das vorher durch Tickets verstopft wurde von denen jeder wusste, dass sie nie in die Umsetzung gehen würden. In Summe gehen Diskussions- und Pflegeaufwand zurück und es bleibt mehr Zeit für wirklich wichtige Themen.

An dieser Stelle gibt es übrigens auch einen weiteren Brückenschlag zur Agilität. Teams und Organisationen die weniger Zeit für ihre Bug-Verwaltung aufwenden müssen haben mehr Zeit für andere Themen und werden mit denen schneller fertig. Ein Zustand ein eigentlich jeder anstreben sollte, auch ohne einen Testmanagement-Hintergrund.

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.