Kommentierte Links (XCVII)

Bild: Unsplash / Fabio Bracht - Lizenz

Das Internet ist voll von Menschen die interessante, tiefgründige oder aus anderen Gründen lesenswerte Artikel schreiben. Viele dieser Texte landen bei mir, wo sie als „Food for Thought“ dazu beitragen, dass auch mir die Themen nicht ausgehen. Wie am Ende jedes Monats gibt es auch diesesmal wieder eine kommentierte Übersicht über die erwähnenswertesten.

Dmitriy Blinov: Why you need your user stories to fit into one sprint

Für die meisten Teams mit denen ich gearbeitet habe war es normal, dass sie einen Teil der User Stories (oder anderen Aufgaben) die sie in ihre Sprints eingeplant hatten in den jeweils nächsten schieben mussten. Tatsächlich kann man so auch gute Ergebnisse erzielen, es gibt aber gute Gründe dafür es nicht zu tun und stattdessen möglichst alle Aufgaben im laufenden Sprint zu beenden. Dmitriy Blinov fasst die wichtigsten davon zusammen: Planung und Risikomanagement werden einfacher, Qualität und Reaktionsfähigkeit steigen, unnötige Aufwände gehen zurück, Kunden und Stakeholder werden zufriedener. Wenn das keine Motivationen sind, was dann?

Julian Borger: Ukrainian coders aim to gain battlefield edge

Dass die Ukraine in ihrem Verteidigungskrieg gegen den russischen Angriff von agilen Methoden profitiert gehört zu den bemerkenswerten Phänomenen dieser Auseinandersetzung (siehe auch hier und hier). Julian Borger führt das an verschiedenen Beispielen noch weiter aus, von der bereits aus anderen Berichten bekannten Drohnen-Einheit Aerorozvidka über die ebenfalls aus den Medien bekannte Echtzeit-Aufklärungssoftware Delta bis hin zur ukrainischen Armee selbst, die durch Abbau von Hierarchien und durch direkte Kommunikation zwischen zusammenkämpfenden Einheiten immer flexibler und reaktionsfähiger wird (während die russischen Streitkräfte noch immer wie in der Sowjetunion organisiert sind). Clausewitz wäre begeistert.

Itamar Gilad: Feature Factories vs. Value Generators

Irgendwann ist in der Putput vs Outcome-Debatte der Begriff der "Feature Factory" entstanden, einer Organisationsform der Software-Entwicklung die in ähnlich hoher Taktung neue Funktionen produzieren soll wie eine Fabrik physische Konsumgüter. Itamar Gilad fasst zusammen wie die Idee der Feature Factory entstanden ist, von den Wurzeln in der klassischen Fabrikation bis zu modernen agilen (?) Ansätzen wie SAFe. Darüber hinaus zeigt er auch die Risiken auf die mit dieser Idee verbunden sind: die Vernachlässigung des Kontakts zwischen Kunden/Nutzer und Entwicklern und als Folge dessen das unnötige Aufblähen von Funktions- und Code-Umfang durch schnell produzierte aber nicht ausreichend validierte Features (siehe auch The Build Trap).

Steven Lemon: How Blocking and Wait Times Impeded Our Sprints

Waiting Time und Blocked Work kennt man vor allem aus dem Lean Management, dass es aber auch für agil arbeitende Teams Sinn macht sich damit zu beschäftigen kann man bei Steven Lemon gut nachvollziehbar nachlesen (ein Bonus sind die guten Illustrationen). Was er zurecht als zentralen Punkt herausstreicht: nicht die Wartezeiten selbst sind das Hauptproblem, sondern das dadurch entstehende Multitasking. Schliesslich wird in der Regel eine Pause überbrückt indem man mit der nächsten Aufgabe beginnt, und wenn auch die wegen einer Abhängigkeit warten muss mit der übernächsten. Sehr gut ist bei ihm auch die Verbindung zu Scrum, zu dessen Zielen schliesslich das Abbauen von Abhängigkeiten und Wartezeiten gehört.

Christiaan Verwijs: The Church Of Scrum

Zum ersten mal von der Kirche/dem Kult von Scrum gehört habe ich vor ca. 10 Jahren, seitdem kommt das Thema immer wieder hoch. Tatsächlich ist der Dogmatismus mit dem mache Scrum Master auf der Einhaltung von (dann häufig auch noch falsch verstandenem) "Scrum by the Book" beharren amüsant bis verstörend, so dass man Christiaan Verwijs dankbar dafür sein kann, diesen Klassiker mal wieder hervorgeholt zu haben (Apropos Klassiker: das hier ist eine gute Gelegenheit um auch auf diesen hier von Emily Kager hinzuweisen).

Das Integrationsparadox

Bild: Pexels / Fauxels - Lizenz

Eine immer wieder zu hörende Beschwerde ist die, dass die Einführung agiler Arbeitsweisen zu ständigen Konflikten zwischen alter und neuer Arbeitswelt führen würde, oft verbunden mit der Aussage, dass das nicht im Sinn der Sache sein könnte. Sollte es nicht vielmehr so sein, dass in der Agilität alles einfacher wird? Um diese Frage zu beantworten lohnt sich einmal mehr der Blick über den Tellerrand, in diesem Fall in die Soziologie, zu einem Professor namens Aladin El-Mafaalani.

El-Mafalaani ist einer breiteren Öffentlichkeit durch sein im Jahr 2018 erschienenes Buch Das Integrationsparadox bekanntgeworden, in dem er darüber aufklärt warum eine gelungene Integration von Einwanderern in die sie aufnehmenden Gesellschaften nicht zu weniger sondern zu mehr Auseinandersetzungen führt. Die Grundprämisse ist übertragbar: das Zusammenwachsen von zwei sozialen Gruppen führt fast zwangsläufig zu mehr Konflikten - und das ist auch gut so.

Der erste Faktor der zu einer Zunahme der Konflikte führt ist ein fast schon banaler: die Anzahl der Untergruppen in einer Grossgruppe (oder Grossorganisation) erhöht sich wenn neue integriert werden. Denn: Integration bedeutet nicht, dass es zu einer völligen Anpassung der neuen an die alten Gruppen kommt (das wäre Assimilation),¹ sondern nur, dass die neuen den Zugang zu den Aufgaben, Wissensquellen und Kommunikationskanälen bekommen, den sie für ihre Arbeit brauchen.

Trotz dieser Integration bleiben viele "Neuankömmlinge"² weiterhin als solche erkennbar, alleine deshalb weil sie sich in Auftreten und Erscheinung von den "Alteingesessenen" abheben. Das ist zwar in einem Firmenkontext weniger offensichtlich als bei einer Migrationsbewegung, allerdings gibt es auch hier Unterscheidungsmerkmale: Durchschnittsalter, Kleidungsstil und Fachjargon machen erkennbar wer zu welcher Gruppe gehört. Und die eigene Gruppe will man auch repräsentiert sehen.

Sobald die neuen Gruppen (im Unternehmenskontext: die agil arbeitenden Mitarbeiter) sich in die bestehenden Strukturen integriert haben, kommt es daher fast automatisch zu einer Konkurrenz um Ressourcen, Budgets, Sitze in Entscheidungsgremien, Verantwortungsbereiche, Vetorechte, und vieles mehr. Das Übertragen auf die neu arbeitenden Gruppen kann dabei von den alten als Verdrängung empfunden werden, die Verteidigung des Ist-Standes kann wie eine Aussperrung der neuen wirken.

Derartige Konflikte sind nicht ohne eine gewisse Tragik, da in der Regel keine der beiden Gruppen ihn wirklich will. Beide werden von durchaus verständlichen Motiven angetrieben: die neuen Gruppen von dem Wunsch nach Teilhabe und Repräsentation, die alten von dem Wunsch nach der Verteidigung von ihren Errungenschaften, die in der Vergangenheit hart und langwierig erarbeitet werden mussten (siehe dazu auch den Artikel über die Thukydides-Falle).

Bitte kurz Luft holen. Um an dieser Stelle kurz auf eine weiter oben stehende Aussage Bezug zu nehmen - warum soll all das etwas Positives sein? Was ist am fast zwangsläufigen Abrutschen in Konflikte gut? Die Antwort: dort wo Konflikte wie die hier beschriebenen konstruktiv ausgetragen werden führen sie zum Einen zu einer Sichtbarkeit der Diversität und zum Anderen zu einem Wettbewerb der Ideen. Beides sind anzustrebende Entwicklungen.

Hinter der Sichtbarkeit der Diversität verbergen sich gleich zwei mögliche Ausprägungen. Zum Einen werden die neuen Gruppen und ihre Anliegen wahrnehmbarer, und zwar nicht nur in ihrer blossen Existenz sondern auch in ihrem Anspruch das Gesamtsystem mitgestalten zu wollen. Zum Anderen bleiben auch die schon länger vorhandenen Gruppen sichtbar, mitsamt ihrer Wünsche, Bewährtes nicht voreilig und ohne Durchdenken der Konsequenzen zu verwerfen.

Der Wettbewerb der Ideen ist dagegen eine natürliche Folge der Knappheit der zu vergebenden Ressourcen und Positionen. Wer auch immer die haben möchte muss begründen warum die mit ihm verbundene Verwendung die im Vergleich bessere ist. Im besten Fall kommt es dadurch zu einem ständigen Inspect & Adapt und zu einer Tendenz zu MVPs, früh zeigbaren Erfolgen und nachhaltigem Wirtschaften, da all das valide Argumente bei einer Vergabe sind.

Um diesen besten Fall möglichst oft eintreten zu lassen kann eine Firma schliesslich dafür sorgen, dass vergleichbare Ausgangspositionen bestehen. Im Wesentlichen bedeutet das, dass eine willkürliche oder systematische Benachteiligung aufgrund einer Gruppenzugehörigkeit unterbunden wird, so dass alle die gleichen Chancen haben. Zu diesem Zweck kann eine Firma auch auf die gleichen Antidiskriminierungs-Mechanismen zurückgreifen wie eine Gesellschaft.

Am Ende kann das Integrationsparadox in der gerade beschriebenen Weise sogar zu einer Neuwahrnehmung des Konfliktbegriffs führen. Statt Konkurrenz und Verdrängung wird mit ihm dann das gemeinsame, konstruktive Ringen um die beste Lösung verbunden. Und das ist etwas was sich eigentlich jede Organisation und Gesellschaft wünschen sollte.

¹Die im Firmenkontext nicht gewollt ist, schliesslich werden die neuen Gruppen ja bewusst wegen ihrer Andersartigkeit geholt.
²Zu denen man sowohl in der Gesellschaft als auch in Organisationen noch nach Jahren gezählt werden kann.

Lean-Metriken (I)

Was sind eigentlich die im Lean Management verwendeten Metriken? Die darauf häufig gegebene Antwort ist Durchflussmessung, was auch grundsätzlich richtig ist (wenn auch nur ein Teil der Antwort). Allerdings gibt es mehr als eine Art davon, so dass sich eine Aufschlüsselung lohnt. Wichtig zum Verständnis ist dabei, dass es nirgendwo eine zentrale Stelle gibt, die die Begriffe und ihre Bedeutungen festlegt. Je nachdem wo man ist kann es also Unterschiede geben, die grundlegenden Typen werden aber die gleichen sein.

Customer Lead Time

Die Gesamtzeit zwischen der Beauftragung durch einen Kunden und dem Beginn der Nutzung des bestellten Produkts oder Service durch ihn. Eine der eher selten erhobenen Zahlen, aus Kundensicht aber eine der wichtigsten. Sie zu messen kann verhindern, dass zwar die internen Produktions- und Lieferprozesse optimiert sind, gleichzeitig aber unbemerkte Verzögerungs- und Frustrationsfaktoren bei beim Kunden vorliegen, z.B. ein kompliziertes Einloggen in Bestellportal oder ein langwieriger Schulungsprozess der Anwender.

Feedback Loop Time

Diese Zahl ist der ersten ähnlich, geht aber noch einen Schritt weiter. Gemessen wird nicht nur die Gesamtzeit zwischen der Beauftragung durch einen Kunden und dem Beginn der Nutzung des bestellten Produkts oder Service, sondern zusätzlich auch die Zeit die für eine erste Nutzung, das Sammeln von Feedback und dessen Übermittlung an den Produzenten nötig sind. Vereinfacht gesagt: erst nach dem ersten Feedback Loop weiss man, ob man dem Kunden h,elfen konnte.

(Production) Lead Time

Das ist die erste rein interne Metrik, und vermutlich auch die bekannteste. Erhoben wird die Gesamtdauer aller Vorgänge vom Auftragseingang bis zur Auslieferung. Grundsätzlich ist das zwar relativ einfach zu erheben, kompliziert wird es aber dann, wenn Zulieferer Hardware- oder Software-Komponenten vorfertigen, die dann nur noch eingebaut werden müssen. Die Bestellung, Erstellung und Lieferung dieser Komponenten muss ggf. in die Lead Time mit einbezogen werden.

Pre-Processing Lead Time / Processing Lead Time / Post Processing Lead Time

Bei diesen drei Typen wird die Lead Time in drei unterschiedliche Abschnitte unterteilt, die sich so fast überall wiederfinden und separat betrachtet werden können. Die Pre-Processing Lead Time umfasst alle Verhandlungs, Bestell- oder Beauftragungsprozesse, die Processing Lead Time ist die eigentliche Anfertigung inclusive Qualitätssicherung, die Post-Processing Lead Time umfasst die nachgelagerten Auslieferungs- und Rechnungsstellungs-Prozesse.

Cycle Time

Nach der Lead Time die vermutlich zweitbekannteste Metrik. Für ihre Erhebung werden die übergreifenden Abschnitte nochmal unterteilt, z.B. die Processing Lead Time in Vormontage, Endmontage und Qualitätssicherung. Diese Unterteilung kann u.a. deshalb Sinn machen, weil verschiedene Cycle Times parallel laufenden Prozessen entsprechen können (z.B. zwei verschiedenen Vormontagen), die aufeinander abgestimmt werden sollen.

Process Step Time

Die kleinste Einheit, die nur noch wenigen manuellen oder automatisierten Vorgangsschritten entspricht. In der Hardware-fertigenden Industrie wäre das z.B. eine Station am Fliessband, bei Software-Releases kann eine Build Pipeline-Station so gemessen werden. Wichtig bei der Process Step Time ist, dass sie v.A. bei repetitiven Tätigkeiten und Prozessen Sinn macht, nicht in der Wissensarbeit (z.B. in Journalismus und Softwareentwicklung), wo sie aufgrund fehlender Vergleichbarkeit kaum Aussagekraft hat.

Wie bei allen Metriken gilt auch bei den verschiedenen Durchflussmessungen, dass sie kein Selbstzweck sind. In der Regel dient ihre Erhebung dem Ziel, die Prozess-Effektivität oder Prozess-Effizienz zu optimieren. Dafür sind nochmals weitere Unterteilungen und Differenzierungen nötig, für die weitere Teile dieser Übersicht über die Lean-Metriken geben wird.

Customizing-Software

Bild: Direct Media / StockSnap.io - CC0 1.0

Wenn man versucht Kategorien für verschiedene Arten von Software-Anwendungen zu bilden landet man häufig bei einem bekannten Gegensatzpaar: Individualsoftware, bei der es sich gewissermassen um eine "massgeschneiderte Lösung" handelt und Standardsoftware, die eher "von der Stange gekauft wird". Diese Unterteilung ist auch nicht falsch, zumindest in grösseren Unternehmen lässt sie aber eine wichtige Zwischenkategorie aus und ist dadurch zu ungenau.

Für das bessere Verständnis zunächst ein Blick auf die beiden Grundkategorien, zuerst auf die Individualsoftware. Wie der Name erahnen lässt ist sie jeweils für einen einzigen, meist sehr speziellen Zweck erstellt worden und lässt sich meistens auch nur für den verwenden. Das sorgt auf der einen Seite zwar dafür, genau die nötige Lösung zu haben (wenn es denn richtig gemacht wird), ist aber auf der anderen Seite durch die jeweilige Einzelanfertigung recht teuer.

Standardsoftware dagegen ist für einen häufig und in verschiedenen Unternehmen anzutreffenden Zweck konzipiert, lässt sich also nach einer einmaligen Erstellung immer wieder benutzen und verkaufen (das bekannteste Beispiel dürfte das Computer-Betriebssystem Windows sein). Aus Käufer-Sicht ist neben dem durch Skaleneffekte geringeren Preis der Vorteil, dass der Hersteller für Qualitätsstandards garantiert, Updates entwickelt und einspielt und Schulungsmaterial bereitstellt.

Gerade vor dem Hintergrund, dass praktisch jede Firma heute nur noch auf Basis von Software funktioniert,¹ ist der Markt für Standardsoftware mittlerweile riesig. Von Bürosoftware über Buchhaltungsanwendungen bis hin zu Warenwirtschaftssystemen und den Kernsystemen von Banken und Versicherungen wird überall angestrebt fertige Lösungen zu finden, die man nur noch installieren und benutzen muss, ohne sich mit eigener Entwicklung beschäftigen zu müssen.

Die Realität sieht allerdings anders aus. Implementierungsprojekte von Standardsoftware können heute Jahre dauern, dreistellige Millionenbeträge kosten und ganze Unternehmen an den Rand der Handlungsunfähigkeit bringen (ein Klassiker ist dabei die Einführung von SAP, hier eine Übersicht über die spektakulärsten Fälle). Wie kann das sein, oder anders gefragt: wenn bei dieser Art von Software alles Standard ist, wo kommen die ganzen Aufwände her?

Die Antwort hat mit der zu Beginn genannten Zwischenkategorie zu tun, die keinen allgemein anerkannten Namen hat, die ich aber "Customizing-Software" nennen würde. Es handelt sich dabei um scheinbare (und auch als solche verkaufte) Standardsoftware, die aber ohne umfangreiche Anpassungen an den Anwendungs-Einzelfall (so genanntes Customizing) nicht funktionsfähig ist, was die genannten grossen Einführungsprojekte zur Folge hat.

Die Gründe für diesen Anpassungsbedarf können vielfältig sein, häufig anzutreffen sind aber spezifische, aber vom Standard nicht unterstützte Formatierungen von Produkt-, Finanz-, Prozess- oder Personaldaten im die Software kaufenden Unternehmen, Schnittstellen zu Kunden- oder Lieferantensystemen, die auf bestimmte Art bedient werden müssen, oder bestehende Zentralsysteme (ein schlichtes Beispiel wäre ein Single Sign-On), die bestimmte Rahmenbedingungen vorgeben.

Die sich daraus ergebenden (und in den meisten Fällen nicht vermeidbaren) Anpassungen machen den eigentlichen Vorteil von Standardsoftware, die sofortige Nutzbarkeit des fertig eingekauften Produkts, zu nichte. Nicht nur muss initial ein umfangreiches Customizing stattfinden, auch jedes weitere Update des Herstellers muss durch diesen Prozess, da die ursprüngliche Anwendung durch ihre Modifikation nicht mehr mit den auf dem Standard basierenden Weiterentwicklungen kompatibel ist.

Die mit Customizing-Software verbundenen Einführungs- und Anpassungs-Aufwände sind in sehr vielen Fällen ähnlich teuer wie die Entwicklung einer spezifischen Individualsoftware und in einigen Fällen sogar höher, weshalb man sehr sicher sein sollte, die als Standardsoftware angebotene Anwendung auch weitgehend ohne Customizing nutzen zu können (so wie es z.B. im weiter oben genannten Beispiel Windows der Fall ist). Auf die Angaben der Hersteller sollte man sich dabei nicht zu sehr verlassen.

Die Alternative des in Auftrag Gebens einer eigenen Individualsoftware kollidiert zwar häufig mit den vorhandenen Glaubenssätzen und Vorgaben ("Wir bauen keine Entwicklungsabteilung auf, wir sind doch kein IT-Unternehmen", "Wir müssen immer mehrere Lösungen vergleichen können bevor wir uns für die günstigste entscheiden", etc.), an denen zu arbeiten ist aber auf Dauer deutlich billiger als durch Schmerzen und Kosten herauszufinden, dass es sich bei scheinbarer Standardsoftware meistens doch um Customizing-Software handelt.

¹Es gibt heute keinen Mittelständler oder Konzern mehr der ohne Software arbeitsfähig wäre.

Chaos Engineering (II)

Grafik: Wikimedia Commons / Henrique José Teixeira Matos - CC BY-SA 3.0

Dass Chaos Engineering zu den eher unbekannten und unterschätzten agilen Frameworks gehört, dürfte auch daran liegen, dass nicht sofort ersichtlich ist, was es eigentlich mit Agilität zu tun hat. Sowohl von der formalen Perspektive (Prozesse, Rollen, Meetings, etc.) als auch von den Ergebnissen (Releases, Incremente, Features, o.Ä.) bietet es wenig von dem, was wir von SAFe, Scrum & Co kennen. Man muss es anders betrachten.

Der erste "agile Aspekt", über den ich bereits geschrieben habe, ist die Resilienz. Wenn wir Agilität als die Fähigkeit definieren, in kurzen Zyklen reaktions- und lieferfähig zu sein, dann muss man verhindern, dass Störungen und Ausfälle die eigenen Systeme für längere Zeiträume betriebsunfähig machen.¹ Der Weg den Chaos Engineering wählt um das zu verhindern sind permanente Stresstests, durch die Schwachstellen möglichst früh erkannt und behoben werden können.

Darüber hinaus ergibt sich aber noch ein zweiter "agiler Aspekt", denn es wird nicht versucht, diese System-Resilienz auf einmal, also in einen Big Bang herbeizuführen. Stattdessen soll sie nach und nach wachsen und ausgebaut werden, was ziemlich genau dem iterativ-incrementellen Ansatz praktisch aller agilen Frameworks entspricht. In gewisser Weise ist dabei die System-Resilienz selbst das Produkt, das basierend auf echten Anwendungserfahrungen ständig weiterentwickelt wird.

In der Umsetzung kann diese "incrementelle Resilienz" so aussehen, dass das System zuerst kleineren, noch beherrschbaren Störungen ausgesetzt wird. Sobald es für diese einen funktionierenden Kompensations-Mechanismus gibt können etwas grössere folgen, sobald auch diese kompensierbar sind nochmal grössere, etc., etc. Beispiele für solche kleineren Störungen wären zu Beginn noch moderate Nutzungs-Anstiege oder eine zunächst nur geringe Reduzierung des verfügbaren Speicherplatzes.

An diesen Beispielen lässt sich gut absehen wie die immer anspruchsvolleren Experimente (so nennt man in Chaos Engineering die Stresstests) aussehen könnten. Das Ausmass der Störfaktoren (in diesen Fällen steigende Nutzungs-Intensität und schrumpfender Speicherplatz) kann mit jedem Experiment hochgeschraubt werden, bis zu dem Punkt an dem selbst Grosstörungen wie der komplette Ausfall einer ganzen AWS-Region simuliert werden können.

Darüber hinaus ist es in späteren "Resilienz-Incrementen" auch sinnvoll verschiedene Experimente gleichzeitig auf dem selben System laufen zu lassen, um auch mögliche Interdependenzen erkennen zu können. Um bei den Beispielen zu bleiben: gleichzeitig steigende Nutzungs-Intensität und schrumpfender Speicherplatz, in einem nächsten Experiment dann zusätzlich dazu noch die Simulation von Übertragungs-Störungen oder ausfallender Leitungen.

Rein theoretisch liesse sich Chaos Engineering sogar nach Scrum umsetzen, mit jeweils einem Experiment als Sprintziel und den damit verbundenen Umsetzungs-, Monitoring- und Stabilisierungs-Massnahmen als Backlog-Items. Gegenstand der Sprint Reviews wären die erfolgreich verhinderten (oder doch stattgefundenen) Systemausfälle, die eingeladenen Stakeholder wären die Verantwortlichen der dort betriebenen Anwendungen, die dann sagen können wie viel mehr Ausfallsicherheit sie benötigen.

Zusammenfassend gesagt: bei genauerer Betrachtung ist der Bezug von Chaos Engineering zu Agilität relativ offensichtlich. Man muss sich nur davon trennen, "Agile" lediglich als eine Sammlung von Rollen, Meetings und Prozessen zu sehen. Das sollte man aber natürlich ohnehin tun, wenn man verhindern will, in einem weitgehend wirkungslosen Cargo Cult zu enden.

¹Und in einem agilen Kontext sind bereits mehrere Stunden lang.

Zero Bug-Policy (II)

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.

¹Und zwar so, dass er es nicht delegieren kann.

Story Points vs. Story Points

Grafik: Public Domain Pictures / Karen Arnold - CC0 1.0

Man könnte eigentlich denken, dass irgendwann alles zum Thema Story Points gesagt sein müsste. Vielleicht kommt dieser Tag auch bald, aber noch nicht heute. Heute soll es hier um einen Fakt gehen, der seit Jahren immer wieder für nachhaltige Verwirrung sorgt: es gibt nicht nur eine verbreitete Definition dessen was Story Points sein sollen sondern gleich zwei. Und diese beiden sind nicht deckungsgleich sondern widersprechen sich scheinbar sogar an einer entscheidenden Stelle.

Über die erste Definition habe ich bereits vor einiger Zeit etwas geschrieben, es ist die von Ron Jeffries. Er ist Mit-Begründer von Extreme Programming, dem agilen Framework in Story Points zum ersten mal benutzt wurden, und selbst wenn es nach der langen Zeit (irgendwann Ende der 90er) nicht mehr ganz genau nachvollziehbar ist geht er davon aus, dass er es war der sie erfunden hat (mittlerweile bedauert er das übrigens, aber das ist eine andere Geschichte).

Für ihn sind Story Points ganz klar eine Messung von Aufwand. Ursprünglich hervorgegangen aus den missverständlich benannten "ideal Developer Days" war die initiale Beschreibung "how long it would take a pair to do it if the bastards would just leave you alone", also die Zeit die man brauchen würde wenn man nicht gestört würde. Später wurde daraus die abstrakte Schätzgrösse, die für verschiedene Teams oder Personen je nach Kontext in unterschiedliche Aufwände übersetzt werden kann.

Die zweite Definition kommt von Mike Cohn, einem der ersten Scrum Master, und stammt aus seinem damals (2005) bahnbrechenden Buch Agile Estimating and Planning, in dem er die seinerzeit (und heute) gängigsten Praktiken zum agilen Schätzen und Planen zusammenfasste. Für viele agile Praktiker ist es die Quelle aus der sie Story Points kennen (oder mittlerweile haben viele die Definition von Menschen gelernt die sie ursprünglich aus diesem Buch haben).

In ihm beschreibt Cohn Story Points als eine Mischung aus Aufwand, Risiko und Komplexität. Zwar hat er später in seinem Blog darauf hingewiesen, dass auch in seiner Sicht der Dinge der Aufwand die entscheidende Dimension ist, da die anderen beiden lediglich die Ursachen für eine weitere Vergrösserung des notwendigen Aufwands sind, mit seiner ursprünglichen Definition hat er aber zu einer Unklarheit beigetragen, die seitdem zahllose Teams geplagt hat.

In einem Versuch der (scheinbaren) Anleitung des (scheinbaren) scheinbaren Erfinders zu folgen definieren derartige Teams bis heute Story Points als eine Messgrösse der drei im Buch genannten Dimensionen, in vielen Fällen sogar mit der erst recht irreführenden Verkürzung, dass es sich nur noch um die Messgrösse für Komplexität handelt - einen Begriff der ohne die Verknüpfung zum Aufwand nur noch schwer zu erklären und gar nicht mehr quantifizierbar ist.

Oft bringt das die Mitglieder agiler Teams in eine Erklärungsnot, die ohne Notwendigkeit ihr Standing nach aussen untergräbt, ebenfalls kann es vorkommen, dass sie dieser zu entkommen versuchen indem sie die Komplexität aus der Ermittlung der Story Points herausnehmen und durch irgendetwas anderes ersetzen, was aber nur zu einer neuen Variante einer schlecht zu erklärenden Schätzgrösse führt (hier ein Beispiel: Kompliziertheit und Bauchgefühl sind ebenso schlecht quantifizierbar wie Komplexität).

Der beste Weg mit derartigen Situationen umzugehen ist der, den betroffenen Teams die oben verlinkten Blog-Artikel von Jeffries und Cohn zuzuschicken (ggf. mit einer Erklärung wer die beiden sind). Die sich daraus ergebende Erkenntnis, dass Story Points eben doch Aufwand sind wird es zwar nötig machen von einem bisher vertretenen Standpunkt abzurücken, aufgrund des hohen Werts den Inspect & Adapt und Fehlerkultur im agilen Vorgehen haben dürfte das den allermeisten aber gelingen.

Extreme Contracts

Wer mich kennt weiss, dass Jacopo Romei mich in dem Moment dieses Vortrags schon halb überzeugt hatte, in dem er ankündigte, seine folgenden Ausführungen auf seiner Abneigung gegen Muda (無駄), also die im Toyota Production System beschriebenen nicht gewinnbringenden (und aus diesem Grund zu vermeidenden) Tätigkeiten basieren zu lassen. Seine Extreme Contracts sollen dementsprechend bewirken, dass die durch viele herkömmliche Verträge versehentlich erzwungene Durchführung nicht wertstiftender Tätigkeiten unterbleibt.

Auf den Kern reduziert besteht die Idee extremer Verträge daraus, dass diese nur für jeweils einen Sprint von einer Woche zu einem immer gleichen Fixpreis geschlossen werden. Nach jedem kann die beauftragende Seite überprüfen ob das Ergebnis für sie wertvoll ist - und wenn nicht, entscheiden nicht zu bezahlen (wenn das passiert muss sie allerdings damit rechnen, dass der beauftragte Dienstleister nicht für weitere einwöchige Fixpreisverträge zur Verfügung steht). Die entfallende Muda besteht dabei aus den nicht mehr notwendigen Aufwänden für Aufwandsschätzung und Preisverhandlung. Eine interessante Idee mit vielen Implikationen, über die ich nochmal genauer nachdenken muss.

Kickoff Meetings

Bild: Unsplash / Florian Schmetz - Lizenz

Häufig am Anfang des Jahres aber auch zu anderen Zeitpunkten finden sie statt: die Kickoff-Events. Dabei handelt es sich in der Regel um grosse Veranstaltungen für alle Beteiligten eines neu startenden Projekts oder einer neu startenden Programmlinie, mit dem Ziel Zusammenhalt und ein gemeinsames Verständnis der anstehenden Aufgabe zu schaffen. Vieles davon ist gut, einige eigentlich wichtige Elemente fehlen aber leider fast immer. Zeit für einen näheren Blick.

Was fast immer gegeben ist, ist die Präsentation des grossen Zielbilds. Aus diesem Grund starten wir dieses Vorhaben, aus jenem Grund ist es besonders wichtig für das Unternehmen und aus folgendem Grund passt es gut zu dem bereits vorhandenen Leitbild oder der bereits verkündeten Strategie. In der Regel ist das der beeindruckendste Teil, mit beeindruckender Bühne, Vorstands-Rede, Erfolgsmeldungen der Vor-Projekte und ggf. mit Multimedia-Show.

Anschliessend daran erfolgt meistens die Darstellung des mehr oder weniger detaillierten Projektplans, mit Liefergegenständen, Meilensteinen und Lieferdaten. Meistens mit einer zeitlichen Darstellung verbunden kann man aus ihm z.B. ablesen welche Tätigkeiten in welcher Phase stattfinden sollen, häufig aber auch welches Budget für welchen Zeitraum eingeplant ist, welche Einheit wann beteiligt wird und wo dadurch Abhängigkeiten entstehen. 

Falls das neue Vorhaben auch mit einer relativ neuen Vorgehensweise durchgeführt werden soll (Stichwort "Agiles Pilotprojekt") kann ein weiterer Teil folgen in dem auch das näher beleuchtet wird. Ein beliebtes Element ist der Vortrag eines "Thought Leaders" oder eines Menschen der in einem anderen Unternehmen schon erfolgreich so gearbeitet hat, ebenfalls gerne gezeigt werden Videos vom geschäftigen Gewusel eines PI-Plannings oder eines Design Thinking-Workshops.

Emotional und bewegend ist schliesslich der Socializing-Teil. Je nach Kontext kann der unterschiedliche Formen annehmen: Speeddating von Entwicklung und Fachabteilung, Gruppen-Challenges, gemeinsame Führungen durch die zukünftigen Arbeitsräume, Exkursion zu den Nutzern des zu erstellenden Produkts oder Services (in Shopfloor, Frontoffice, etc) und nicht zuletzt eine abendliche Feier in einer ausgefallenen Location oder einem eigens dafür umgestalteten Bereich des Firmengeländes.

Soviel zum üblichen Ablauf, und um es klar zu sagen: in vielen Fällen ist der gut. Allerdings - vor allem dort wo gut planbare Tätigkeiten in einem berechenbaren Umfeld stattfinden. In einem komplexen Umfeld, also dort wo man von ungeplanten Entwicklungen, ungeahnten Problemen und sich ändernden Rahmenbedingungen ausgehen muss, sollten noch weitere Teile dazukommen, die dabei helfen können schon im Kickoff Meeting zu erkennen wo die Reise hingeht.

Für alle bei die jetzt laut "Feedback-Schleifen" rufen wollen: nicht falsch, aber noch zu früh. Um Feedback geben zu können sollte klar sein, woran man erkennen kann, dass etwas fertig genug ist um Gegenstand von Feedback zu werden - und diese Kriterien sollten nicht quantitativ sein (alle Arbeitspakete vom Typ B sind abgeschlossen) sondern qualitativ (z.B. ein Prototyp kann auf der Hausmesse Funktion X vorführen). Diese Kriterien können im Kickoff vorgestellt werden.

Aufbauend darauf sind die Feedback-Schleifen aber der nächste Schritt. Vor allem dort wo sie bisher wenig verbreitet waren macht eine Vorstellung in der Auftaktveranstaltung Sinn, da eine konkrete Erläuterung einzelner Formate (denkbar sind z.B. KVP-Boxen, skalierte Retrospektiven, Focusgruppen-Befragungen, MVP-Vorführungen, Marktforschung und vieles mehr) den eher abstrakten Feedback-Begriff verständlicher und greifbarer machen kann.¹

Vor allem könnte man in Kickoff Meetings aber etwas machen, dass für fast alle Firmen so brisant ist, dass es nicht einmal ernsthaft diskutiert wird: erklären was passieren wird, wenn die Realität deutlich von den ursprünglichen Plänen abweichen sollte. Wann (und wie) würden Kurskorrekturen stattfinden, unter welchen Bedingungen würde die Reissleine gezogen und (besonders brisant) bei welchem Grad der Fortschritts- oder Zielverfehlung würde ein Abbruch des Vorhabens erwogen werden?

Wer die in grossen Unternehmen häufige Effizienz-Focussierung und Fehlervermeidungskultur kennt, wird ahnen können, warum die zuletzt genannten Punkte in den Kickoffs nur selten vorkommen. Wer die Unwägbarkeiten der komplexen Produktentwicklung kennt wird aber auch ahnen, welche positiven Auswirkungen auf agiles Arbeiten sie haben könnten. Wie so oft gilt: mann kann sie ja vorschlagen und sich überraschen lassen was dann passiert.

¹Natürlich könnte man erwarten, dass bereits bei der Vorstellung der neuen Arbeitsweisen von Feedback-Schleifen die Rede ist, (zu) häufig geht es da aber vor allem um Rollen, Meetings und Lieferzyklen