Montag, 27. September 2021

The Missing Link: Extreme Programming

Als Fan des Extreme Programming (XP) freut es mich jedesmal wieder wenn dieses Framework öffentlichkeitswirksam in den Mittelpunkt gerückt wird, gerade auch deshalb weil das mittlerweile nur noch relativ selten passiert. Den Vortrag "Putting the XP in Scrum" von Roy Osherove kann ich daher nur empfehlen.



Interessant ist bei seinen Ausführungen die Einordnung. Für ihn besteht agile Softwareentwicklung aus zwei Elementen: dem aus Scrum abgeleiteten iterativ-incrementellen Prozess und der aus DevOps übernommenen Nutzung automatisierter Build-Pipelines. Da Extreme Programming sowohl einen mit Scrum kompatiblen Prozess-Anteil als auch mit DevOps verwandte Entwicklungspraktiken hat ist es für Osherove der "missing Link", der die beiden anderen Ansätze miteinander verbindet.

Donnerstag, 23. September 2021

Worst Scrum ever!

Bild: Pexels / Karolina Grabowska - CC0 1.0

Nach über 10 Jahren als Scrum Master, Agile Coach und in anderen "agilen Rollen" ist so einiges an Erfahrungen zusammengekommen die ich mit der Zeit gemacht habe, sowohl im Guten als auch im Schlechten. Basierend darauf gibt es eine Frage die mir immer wieder gestellt wird: ob es eine erkennbar schlimmste Umsetzung von Scrum unter denen gegeben hat die ich erlebt habe. Und tatsächlich gibt es sie, die eine die so übel war, dass sie wirklich aus allem heraussticht. Haltet Euch fest.


Der Kunde war ein Mittelständler aus Süddeutschland. Scrum war dort ein Jahr zuvor von einer grossen, mit A beginnenden Unternehmensberatung eingeführt und als revolutionäre Prozess-Optimierung angekündigt worden. In der Wahrnehmung des oberen Managements liessen die sichtbaren Verbesserungen aber auf sich warten, weshalb ein externer Experte (ich) überprüfen sollte ob das Vorgehen tatsächlich so umgesetzt wurde wie gedacht. Ich begann entlang der Wertschöpfungskette.


Die erste Überraschung erwartete mich gleich zu Beginn, denn am Anfang der Wertschöpfungskette befand sich eine Fachabteilung die ein Lastenheft verfasste, also eines jener Telefonbuch-dicken Dokumente die alles an Wünschen enthalten was der beauftragenden Einheit sinnvoll erscheint. Nichts davon war durch Marktforschung oder Kundenfeedback validiert, nichts davon war durch eine Machbarkeitsanalyse oder eine Aufwandsschätzung gegangen.


Dieses Lastenheft ging im nächsten Schritt an das Anforderungsmanagement, das den Auftrag hatte es in User Stories herunterzubrechen. Die Unternehmensberatung mit A hatte dafür eine Anleitung hinterlassen, der zufolge alle User Stories mit "als User möchte ich" beginnen mussten (der Zwecksatz fehlte dagegegen) und klein genug sein mussten um von einem einzigen Entwickler in einem Tag umgesetzt werden zu können.


Um dieses Anforderungsmanagement zu Höchstleitungen anzuspornen wurde seine Leistung an der Menge der geschriebenen User Stories gemessen. Um möglichst viele erzeugen zu können wurden diese folgerichtig noch kleiner als gefordert, zwei an die ich mich erinnern kann waren "Als User möchte ich, dass sich das Dropdown-Menue öffnet wenn man es anklickt" und "Als User möchte ich, dass das geöffnete Dropdown-Menue anklickbare Items enthält". Insgesamt waren es tausende.


Die so verfassten User Stories gingen als nächstes in das so genannte "Planning I", in dem der IT-Chef und die Architekten sie auf einen Zeitstrahl verteilten, der bis weit in das nächste Jahr hineinreichte. Aufgrund der schieren Masse (nochmal: tausende) wurden dabei nicht alle genau angeschaut, das Hauptkriterium war, dass ungefähr gleich viele in jedem Monat landeten. "Langfristig mittelt sich das", wurde als Begründung für dieses Vorgehen genannt.


Kurz vor Beginn eines Monats (der hier einem Sprint entsprach) folgte jeweils das "Planning II". Die Architekten und der in diesem Moment erstmals beteiligte Product Owner schätzten für jede der für diesen Monat eingeplanten User Stories den Aufwand und entschieden welchem Entwickler sie zugewiesen werden würden. Zusätzlich dazu verfassten sie neue User Stories für dringende Bugs ("Als PO möchte ich, dass Bugticket XY im nächsten Sprint gefixt wird") und wiesen auch die zu.


Am ersten Arbeitstag des Monats, bzw. Sprints folgte schliesslich das "Planning III". In dem wurde nacheinander jeder Entwickler in einen Raum gebeten in dem er von dem PO, den Architekten und seinem Abteilungsleiter (diese Rolle war in Personalunion auch Scrum Master) erwartet wurde. Dieses Kommittee erklärte dem einzeln vor ihm stehenden Entwickler welche Arbeit für ihn eingeplant war, erlaubte es ihm Verständnisfragen zu stellen und forderte ihn auf die Lieferung zuzusagen.


Dass diese Zusage auch eingehalten wurde, wurde im Sprint in den Daily Scrums sichergestellt. Die Scrum Teams (jeweils 15 bis 25 Entwickler) versammelten sich in einem Raum, der Abteilungsleiter/Scrum Master filterte das digitale Sprint Backlog nach Bearbeitern und forderte nacheinander jeden auf vorzutreten und einen Statusbericht abzugeben. Da dieser Termin länger als eine Stunde war konnte jeder direkt nach seinem Bericht zurück an die Arbeit, um so produktiver zu sein.


Erfahrungsgemäss zeigte sich in den meisten Sprints etwa in ihrer Mitte, dass sie zu optimistisch geplant waren. Um das auszugleichen forderten die Abteilungsleiter/Scrum Master die Entwickler zu Überstunden auf oder verschoben User Stories zu anderen die noch nicht im Rückstand waren. Neu entdeckte Bugs wurden in das "Bug Backlog" verschoben, aus dem alle die nicht dringend waren in einem der halbjährlich stattfinden "Bugfixing-Sprints" eingeplant wurden.


Im am Ende des Sprints stattfindenden Review Meeting überprüften die Architekten, die Product Owner und die Abteilungsleiter/Scrum Master ob alle User Stories wie geplant fertiggestellt worden waren, falls das nicht der Fall war konnten einzelne Entwickler in dem Raum geholt werden um ihren Rückstand zu erklären. Die Ergebnisse des Reviews wurden im Anschluss schriftlich dem Steuerungskommittee mitgeteilt, in dem u.a. der IT-Chef und die beauftragende Fachabteilung sassen.


Retrospektiven gab es keine. Sie hatten wohl früher stattgefunden, waren aber wegen Ineffektivität wieder abgeschafft worden.


Wie man sich denken kann konnte ich bereits nach wenigen Tagen mit einer umfangreichen Liste an identifizierten Missständen und konkreten Handlungsempfehlungen aufwarten. Ich hatte schon geahnt, dass sie keine Begeisterung auslösen würden, und genau so kam es. Ich sollte doch stattdessen bitte "pragmatische Lösungen" erarbeiten, die ohne grundlegendes Infragestellen der bestehenden Prozesse umsetzbar wären. Das wollte ich nicht, und als Folge dessen beendete die Firma unsere Zusammenarbeit.


Und das ist sie, die Geschichte der schlimmsten Umsetzung von Scrum die ich jemals erlebt habe. Ich habe später noch mitbekommen, dass in den folgenden Monaten über die Hälfte der Angestellten aus der IT gekündigt hat und dass weitere Unternehmensberatungen beauftragt wurden. Ob es eine Moral gibt die man daraus ziehen kann weiss ich nicht, vielleicht ist es diese hier: egal wie vermurkst Dir Deine agile Transformation erscheinen mag - irgendwo ist es schlimmer.

Montag, 20. September 2021

The agile Bookshelf: Escaping the Build Trap

Bild: Pixabay / Meridy - CC0 1.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 Fassung1 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,2 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.


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

Freitag, 17. September 2021

Unvermeidbare und versehentliche Komplexität

Grafik: Pixabay / Geralt - CC0 1.0

Im Umfeld der agilen Frameworks ist sie überall anzutreffen: die Komplexität. Wie es in nahezu jedem Einführungs-Training mit Hilfe von Stacey Matrix oder Cynefin Model vermittelt wird ist es vor allem die komplexe Domäne in der es nötig ist agil (und lean, dazu gleich mehr) zu sein, also in jenem Bereich in dem Kleinteiligkeit, Abhängigkeiten und Eigendynamiken ein ständiges Überprüfen von Arbeitsständen und Vorgehensweisen notwendig machen.


Vor dem Hintergrund dieser zentralen Positionierung ist es erstaunlich, dass nur sehr selten versucht wird das Phänomen der Komplexität differenziert zu betrachten. Sie ist einfach da oder eben nicht, eine Aufteilung in Untertypen kommt praktisch nie vor. Dass sie aber möglich wäre zeigt ein Blick in die Vergangenheit - bereits im Jahr 1986 veröffentlichte der spätere Turingpreis-Träger Fred Brooks das Paper No Silver Bullet, in dem er zwei Haupttypen identifizierte, Essential und Accidential Complexity.


Unter Essential Complexity (sinngemäss übersetzbar als unvermeidbare Komplexität) können alle Faktoren zusammengetragen werden deren Entstehung oder Entwicklung eine Organisation nicht beeinflussen kann. Dazu gehören z.B. Marktdynamiken, gesetzliche Regulierungen, technologische Neuerungen, und Ereignisse wie Naturkatastrophen oder Pandemien. Als Besonderheit im IT-Bereich kommt dazu noch die unberechenbare Natur der Softwareentwicklung.


Im Gegensatz dazu steht die Accidential Complexity (sinngemäss übersetzbar als versehentliche Komplexität), die von den betroffenen Organisationen unbeabsichtigt selbst erzeugt wird. Auf der einen Seite geschieht das in Form von unrealistischer Planung, Bürokratie und Überregulierung, auf der anderen Seite kommen IT-spezifische Phänomene dazu wie so genannte Alt- oder Legacy-Systeme, zu grosse Releases oder zu langlebige Branches.


Was sich bei näherer Betrachtung der beiden Grundtypen ergibt ist nicht nur eine jeweils unterschiedliche Natur sondern auch daraus abgeleitet eine jeweils andere Art des Umgangs. Bei der unvermeidbaren Komplexität kann es nur darum gehen im Fall des Eintretens möglichst schnell und effektiv reagieren zu können, während man der versehentlichen Komplexität dadurch entgegenwirken kann, dass man sie gar nicht erst entstehen lässt oder sie wieder eindämmt sobald sie erkannt wird.


Diesen beiden Umgangstypen wiederum kann man (vereinfacht gesagt) die beiden Ansätze Agil und Lean zuordnen. Für Agilität müssen die Organisationsstruktur und die eingesetzten Technologien darauf optimiert werden in kurzen Abständen reaktions- und lieferfähig zu sein, während schlanke (Lean-)Strukturen erreicht werden indem kontinuierlich defekte Systeme und gut gemeintes aber zur Bürokratie werdendes Overprocessing gesucht und beseitigt werden.


Basierend auf dieser Zuordnung lässt sich schliesslich erkennen, dass die manchmal geforderte Entscheidung eine Organisation entweder agil oder lean zu organisieren nicht zielführend ist. Um in einem von Komplexität geprägten Umfeld bestehen zu können ist beides nötig, die häufige Annahme, dass Lean nur im komplizierten Umfeld Sinn macht (mehr dazu bei den oben verlinkten Werkzeugen Stacey Matrix oder Cynefin Model) verkennt wichtige Zusammenhänge. Fred Brooks' Ausdifferenzierung in unvermeidbare und versehentliche Komplexität zeigt deutlich auf warum das der Fall ist.

Dienstag, 14. September 2021

Der agil-industrielle Komplex

Bild: Pxhere - CC0 1.0

Zu den Begriffen an denen man früher oder später vorbeikommt wenn man sich näher mit dem Thema der "organisierten Agilität" beschäftigt gehört der "agil-industrielle Komplex". Gemeint ist damit eine Gruppe von Firmen und Verbänden (u.a. Beratungen, SAFe, Scrum Alliance und Kanban University) denen die Überkommerzialisierung der Agilität unterstellt wird, bis hin zu einer so starken Anpassung an die Vertriebsinteressen, dass dadurch die ursprünglichen Ideale überlagert und verdrängt werden.


Um in derartigen Diskussionen mitreden zu können ist hier der Kontext. Geprägt wurde der Begriff 2016 von Daniel Mezick, einem amerikanischen Unternehmensberater. Der Name nimmt direkten Bezug auf den Begriff des militärisch--industriellen Komplexes, eines Schlagwortes aus den 60er Jahren, mit dem davor gewarnt wurde, dass Rüstungsunternehmen aus Profitgier versuchen könnten selbst einen Bedarf nach ihren Gütern zu erzeugen, statt nur die Lieferaufträge der Politik zu erfüllen.


In Analogie dazu lautet der Vorwurf an die oben genannten Organisationen, dass es ihnen mittlerweile nicht mehr darum gehen würde die Arbeitswelt bei ihren Kunden und zu verbessern, sondern dass eher die eigenen Profite im Vordergrund stehen. Ein zentraler Kritikpunkt ist dabei die Erfindung immer neuer Zertifizierungen, deren Nutzen für den Anwender mitunter fragwürdig ist (ein zweiter ist die häufig fragwürdige Art des "Ausrollens von Agilität" in Unternehmen, mehr dazu weiter unten).


Aber - sind SAFe, Scrum Alliance und Kanban University wirklich die gewissenlosen Schlangenöl-Verkäufer als die sie in der oft beissenden Kritik immer wieder dargestellt werden (siehe hier und hier)? Wie immer hilft auch hier eine differenzierte Betrachtung, die auch gerne Elemente von Systhemtheorie enthalten darf, und dankenswerterweise gibt es auch die bereits. Beispielhaft sind z.B. die Ausführungen von Ron Jeffries, einem der Erfinder von XP und einem der Verfasser des agilen Manifests.


Jeffries stellt in den Mittelpunkt seiner Überlegungen die Frage wer eigentlich die Kunden der grossen Zertifizierungsorganisationen sind und kommt zu der Antwort, dass es sich bei ihnen nicht um die Empfänger der Zertifizierungen handelt sondern um die zwischen den Zertifizierungsorganisationen und den Zertifizierten angesiedelten Anbieter der Zertifizierungsschulungen, deren Absolvierung eine Voraussetzung für die Verleihung eines Zertifikats ist.


Die von den Schulungsanbietern an die Zertifizierungs-Organisationen abgeführten Lizenzgebühren bilden deren Haupteinnahmequelle, was dazu führt, dass die Inhalte mehr und mehr darauf optimiert werden in kurzen Trainings (ein bis zwei Tage) vermittelt werden zu können. Und dass die Schulungs-Anbieter sich auf diese Trainings konzentrieren liegt wiederum an deren zahlende Kunden, bei denen es sich meistens nicht um die Zertifizierungs-Empfänger handelt sondern um deren Arbeitgeber.


Dass diese Arbeitgeber (bzw. deren HR- Change Management- oder Learning & Development-Abteilungen) derartig auf  diese möglichst kurzen Trainings fixiert sind hat wiederum meistens seine Ursache in einer Kombination aus Effizienz-Überoptimierung und Silo-Bildung. Das Erste führt dazu, dass versucht wird Lerninhalte und -zeiträume möglichst stark zu komprimieren, das Zweite hat zur Folge, dass die dadurch entstehenden Dysfunktionen von der beauftragenden Einheit nicht gespürt werden.


Denkt man Jeffries' Überlegungen auf diese Weise weiter werden diese Effekte durch die Arbeitsweisen (und Beauftragungen) vieler grosser Unternehmensberatungen verstärkt, welche die von ihnen begleiteten Veränderungsvorhaben in der Regel mit dem klaren Auftrag angehen die damit verbundene Umbruchphase so kurz wie möglich zu halten. Und was liesse sich in kürzerer Zeit erreichen und als Erfolg vermelden als die durchgeführte Schulung und Zertifizierung aller Mitarbeiter?


Zur "Vervollkommnung" getrieben werden diese Zustände schliesslich durch die internen Abläufe vieler grosser Firmen. Relativ kurze Management-Amtszeiten führen hier dazu, dass das Durchgeben unrealistisch optimistischer Zwischenstände, verbunden mit einem Verschieben von Problemlösungen in die Zukunft, für die eigene Karriere förderlich ist. Bedingt dadurch kommt es zu den genannten Beauftragungen jener Beratungen, die möglichst schnelle und einfache Lösungen versprechen.


Und damit sind sie aufgezählt, die wesentlichen Hauptakteure des agil-industriellen Komplexes und ihre Motive. Zertifizierungsorganisationen die von Schnelltrainings-Anbietern finanziert werden, welche von Unternehmensberatungen instrumentalisiert werden, die wiederum von Unternehmen beauftragt werden, deren interne Prozesse eher auf schnelle Scheinerfolge als auf nachhaltige Veränderungen ausgelegt sind. Ein Pandämonium.


Positiv gedacht ergibt sich aus diesen Zusammenhängen aber auch der grosse Hebel, mit dem diese Missstände sich wieder beheben lassen. In dem Moment indem die vor Veränderungen stehenden Unternehmen sich eher auf nachhaltige als auf schnelle Erfolge focussieren würden geriete die gesamte "Nahrungskette" des agil-industriellen Komplexes in Bewegung. Zertifizierungen und andere Scheinerfolge würden weniger nachgefragt, der dazugehörende Markt würde austrocknen.


Tatsächlich ist diese Veränderung sogar bereits im Gang, zahlreiche Firmen verzichten schon jetzt auf die Illusion des schnellen Erfolgs und arbeiten stattdessen langsam aber stetig an ihren Prozessen und Strukturen. Letztendlich ein wesentlich besserer Ansatz gegen die Überkommerzialisierung der Agilität als das Konstruieren sinistrer "Komplexe" an Stellen wo in Wirklichkeit nur der Markt eine real existierende Nachfrage bedient.

Donnerstag, 9. September 2021

Bugs priorisieren

 

Bild: Pixabay / Jill Wellington - CC0 1.0

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.1 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.2 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.3


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.


1Je nach Kontext können die Benennungen auch andere sein, der Aufbau ist aber meistens vergleichbar
2Ja, tatsächlich. In vielen grossen Organisationen ist es Standard, dass kleine Bugs nie gefixt werden
3Z.B. ein Rechtschreibfehler in einem Tooltip eines internen Workflows oder ein falsches Farbschema in einem Bereich den nur der Admin sieht

Montag, 6. September 2021

Extreme Programming (XP)

Bild: Wikimedia Commons / Lisamarie Babik - CC BY 2.0

Bei der heutigen "Monokultur" von Scrum, Kanban und SAFe mag man es kaum noch glauben, abes gab eine Zeit zu der keines dieser drei das dominierende agile Framework war. Um das Jahr 2000, also zu der Zeit als das agile Manifest geschrieben wurde, war ein anderes das bekannteste: Extreme Programming (XP). Damals noch so bekannt, dass es in den Dilbert-Comics veralbert wurde, sank es später zu einem nur noch schwach erinnerten Mythos herab. Höchste Zeit ihn hervorzuholen und zu entstauben.


Ein Sprung zurück in der Zeit: 1996 befindet sich beim amerikanischen Chrysler-Konzern ein IT-Projekt der Lohnbuchhaltung in der Krise, drei Jahre nach Beginn der Software-Entwicklung konnte noch kein einziges Gehalt mit dem neuen System ausgezahlt werden. Die Probleme sind dieselben die sich bis heute in IT-Grossprojekten finden - die Integration von Entwicklungs-Branches führt zu schwerwiegenden Merge-Konflikten, Tests, Bugfixes und Releases erzeugen massive Aufwände, die Kommunikation zwischen Fachabteilungen und Entwicklern ist voller Missverständnisse und Konflikte.


Neu zum Projekt gestossene Projektmanager und Entwickler untersuchen die Ursachen und finden ein Muster - da alle der gerade genannten Tätigkeiten für die Beteiligten anstrengend und unerfreulich sind werden sie so lange wie möglich aufgeschoben. Bedingt dadurch wachsen sie zu riesigen Arbeitspaketen heran, die zum Zeitpunkt ihrer Umsetzung zum Teil bereits veraltet sind und durch ihre Grösse, Unübersichtlichkeit und Vernetztheit selbst zu ernsthaften Fehlerquellen werden.


Die gemeinsam erarbeitete Lösung für dieses Problem ist das Durchführen dieser Tätigkeiten in immer kürzeren Abständen und immer kleineren Umfängen. Die Idee dahinter: kleine Arbeitspakete sind übersichtlicher, weniger in sich vernetzt und werden bei Fehlern tendenziell kleinere Bugs erzeugen, kurze Abstände sorgen für häufige Wiederholung und damit auch für mehr Übung, für engere Zusammenarbeit, intensivere Kommunikation und als Folge dessen für weniger Missverständnisse.


Wichtig für das Verständis dieser Entstehungsgeschichte ist, dass in all dem wenig Neues steckte. Code Reviews, Merges, Tests, Releases und Kommunikation mit Kunden und Auftraggebern gibt es seitdem Software entwickelt wird. Das Ungewöhnliche war die aus damaliger Sicht unglaubliche Beschleunigung. Aus einmal pro Quartal oder pro Jahr wurde mehrmals pro Woche oder sogar pro Tag. Diese extreme Häufigkeit gab dem Ganzen ihren Namen: Extreme Programming.


Die einzelnen Praktiken von XP sind vor diesem Hintergrund zu verstehen: Pair Progamming ist die extrem intensive Zusammenarbeit von zwei Entwicklern, Unit Tests sind extrem kleine Validierungen von Funktionalität. Iterationen (ein- bis dreiwöchige Zeiträume) sind extrem kurze Lieferzyklen, Refactorings sind extrem häufige Überarbeitungen der Codebasis, etc. Dass sie für XP nötig sind ist offensichtlich, und dass sie so zentral sind macht es zu einem der IT-spezifischsten unter den agilen Frameworks.


Vermutlich ist dieser sehr starke IT-Bezug auch einer der Gründe dafür, dass Extreme Programming der ganz grosse Durchbruch verwehrt geblieben ist. Bereits die "sichtbaren Praktiken" wie Pairing und Reviewing sind in Berater- und Management-Präsentationen nur schwer zu vermitteln, auf "unsichtbare Praktiken" wie Test First und Refactoring trifft das um so mehr zu. Und selbst wenn sie verstanden werden ist ihre Einführung ungleich schwerer als die neuer Rollen und Meetings.


Aus diesen Umständen ergibt sich auch ein fast schon tragisches Phänomen: das was von XP in andere Frameworks übernommen wurde ist in der Regel nicht der IT-spezifische Kernbereich sondern es sind die im Vergleich weniger wichtigen Prozess-Elemente. Das heisst nicht, dass diese (v.a. User Stories, Story Points, Planning Poker und Onsite Customer) nicht gut und richtig wären, aber dass vor allen sie in Scrum und SAFe integriert wurden vermittelt ein schiefes Gesamtbild ihres Ursprungs.


Noch einmal anders gesehen kann man aber auch Positives daran finden, dass Extreme Programming aus dem Scheinwerferlicht verschwunden ist. Da aus Softwareentwicklungssicht kaum ein anderes Framework so passend zur IT ist kann man seinen Bekanntheitsgrad als Indikator dafür benutzen ob und wie vertieft sich ein Entwicklungsteam mit dem Thema Agilität auseinandergesetzt hat. Wenn XP dort ein Begriff (oder sogar in Anwendung) ist kann man als Agile Coach direkt zu den fortgeschrittenen Themen springen und kann auf Grundlagenarbeit verzichten.


Freitag, 3. September 2021

Ist der Scrum Master eine Teilzeitstelle?

Bild: Akson / Unsplash - CC0 1.0

Zu den immer wiederkehrenden Diskussionen bei nahezu jeder Scrum-Einführung gehört die um die Frage ob der Scrum Master eine Vollzeitstelle ist ob diese Rolle auch in Teilzeit ausgefüllt werden kann. Während die meisten Agile Coaches und auch die meisten Scrum Master selbst das verneinen würden ist in den meisten Organisationen die sich an agilem Arbeiten versuchen die Versuchung gross es doch zu probieren, schliesslich liesse sich dadurch einiges an Budget sparen.


Das Problem bei derartigen Versuchen ist, dass damit mittlerweile ein gewisses Stigma verbunden ist. Wer auch immer seinen Scrum Mastern die Vollzeitstelle verweigert gerät in den Ruf es mit der Agilität nicht ernst zu meinen oder sie (bewusst oder unbewusst) kaputtzusparen. Um diesem Stigma zu entkommen werden mittlerweile alle Fälle in denen ein bekannter Agilist sich für den Teilzeit-Scrum Master ausspricht von interessierter Seite demonstrativ hervorgehoben. So auch dieser hier:1



Oh ha. Einer der beiden Väter von Scrum sieht den Scrum Master als halbe Stelle? Seit einiger Zeit wird dieses Zitat immer wieder in der agilen Filterblase und darüber hinaus weitergereicht und geteilt, scheint es doch der dominierenden Meinung mit der grösstmöglichen Methoden-Autorität zu wiedersprechen die dieses Framework zu bieten hat. Wie immer empfiehlt sich aber auch hier ein näherer Blick. Was steckt wirklich in diesem Zitat?


Zunächst lohnt es sich auf ein kleines Wort aufmerksam zu machen. Laut Sutherland sind die meisten guten Scrum Master ("great Scrum Masters") die er kennt in Teilzeit unterwegs. Darin steckt mehr als es zunächst scheint - ein Scrum Master ist nicht als Person gut oder schlecht, er ist es im Kontext seines Teams, dessen Teil er schliesslich ist (siehe hier). Und da gute Teams wenig betreuungsintensiv sind, sind ihre Scrum Master entsprechend weniger gefordert.


Umgekehrt erfordern unerfahrene Teams in der Regel einen eher hohen Betreuungsaufwand des Scrum Masters, bis zu dem Punkt, dass er bestimmte Handlungen nicht zulässt (z.B. das Ausfallen Lassen der Retrospektive um "mehr Zeit für das Arbeiten zu haben"). Damit greift er in die Selbstorganisation der Entwickler ein, und macht dadurch in puristischer Scrum-Interpretation keinen guten Job - was aber auch bedeutet, dass ihn diese (noch) nicht gute Rollenausübung meistens in Vollzeit beansprucht.


Ebenfalls zu beachten ist ein weiterer Aspekt: wie stark auf das Team fixiert ist die Rolle? Im klassischen Scrum findet ein Grossteil der Scrum Master-Tätigkeiten in der umgebenden Organisation statt (was meistens Vollzeit erfordert), nur wenn ihm diese Zuständigkeit genommen und auf andere Rollen übertragen wird bleibt ihm mehr Zeit. Und jetzt kommt's: zu diesen Rollen gehört nicht nur der SAFe-Release Train Engineer sondern auch der "Scrum of Scrums-Master" in Scrum@Scale, dem Skalierungsframework von - Jeff Sutherland. Was für ein Zufall.


Zusammengefasst bedeutet das, dass die Frage nach der Teilzeiteignung der Scrum Master-Rolle nicht klar zu beantworten ist, es gibt Gründe dafür und dagegen, und selbst bei prominenten Fürsprechern für eine der beiden Varianten lohnt sich ein Blick auf die damit verbundenen Motivationen. Vielleicht ist das aber auch das passende Fazit dieser Erwägungen - im Zweifel ist es immer eine gute Idee selbst nachzudenken und nach der individuell passenden Lösung zu suchen. Gerne mit Inspect & Adapt.


Und für alle denen das zu unkonkret ist gibt es eine einfache Faustregel: hätte der Scrum Master auch in Teilzeit ausreichend Ruhe und Zeit um regelmässig aus dem Hamsterrad herauszusteigen und sich Gedanken wie diese hier zu machen? Wenn ja kann er auch eine zweite Aufgabe im Team übernehmen, wenn nicht, dann nicht.


1Quelle: Linkedin, Link ist mittlerweile tot