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

Dienstag, 31. August 2021

Kommentierte Links (LXXVIII)

Grafik: Pixabay / The Digital Artist - CC0 1.0
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.

Kevin Oakes: Let Your Top Performers Move Around the Company

Dass selbst in einem agil organisierten Umfeld das Wechseln zwischen Abteilungen nicht einfach ist hatte ich bereits im Rahmen von Dynamic Reteaming angesprochen, in einem klassischen Umfeld kommt noch ein weiterer Faktor dazu: die Manager, die ihre "Stars" nicht ziehen lassen wollen. Kevin Oakes sieht darin ein Zeichen systemischer Probleme, da die Motivation für derartige Verhaltensweisen meistens darauf zurückgeht, dass der mit einem Weggang der Leistungsträger verbundene Leistungsabfall negativ auf deren bisherigen Manager zurückfällt. Sein Lösungsansatz ist daher ebenfalls systemisch - um die positiven Effekte von Wechseln im Unternehmen zu haben (Wissensaustausch, Bildung von Netzwerken, etc) empfiehlt er Manager dafür zu belohnen, dass sie ihre besten Leute zum Wechseln auffordern und den Wechsel selbst zu einem unbürokratischen (horizontalen) Karrierepfad zu machen.

Maarten Dalmijn: 11 Laws of Software Estimation for Complex Work

Den szenischen Einstieg in den Artikel und die darauf folgende Anekdote aus dem Leben eines Product Owners kann man lesen, man kann aber auch direkt zu den "11 Gesetzen der Aufwandsschätzungen in der Softwareentwicklung" springen die Maarten Dalmijn zusammengetragen hat, auch für sich genommen sind sie lesenswert.
  1. The work still takes the same amount of time regardless of the accuracy of your estimate
  2. No matter what you do, estimates can never be fully trusted
  3. Imposing estimates on others is a recipe for disaster
  4. Estimates become more reliable closer to the completion of the project. This is also when they are the least useful
  5. The more you worry about your estimates, the more certain you can be that you have bigger things you should be worrying about instead
  6. When you suck at building software, your estimates will suck. When you’re great at building software, your estimates will be mediocre
  7. The biggest value in estimating isn’t the estimate but checking if there is a common understanding
  8. Keeping things simple is the best way to increase the accuracy of estimates
  9. Building something increases the accuracy of estimates more than talking about building it
  10. Breaking all the work down to the smallest details to arrive at a better estimate means you will deliver the project later than if you hadn’t done that
  11. Punishing wrong estimates is often like punishing a kid for something they don’t and can’t know yet
Wer Erfahrungen in klassischem Produktmanagement und klassischer Produktsteuerung hat wird erkennen, dass für jeden der so sozialisiert wurde diese 11 Gesetze hochgradig unintuitiv sind. Um so wichtiger sind die Erklärungen die hier zu jedem von ihnen geboten werden.

Stephanie Vozza: Here’s what happened when this company banned meetings

Einfach alle Meetings und alle Emails abzuschaffen ist ein Gedanke der so ziemlich jedem der in grossen Organisationen arbeitet irgendwann einmal gekommen sein wird, zu sehr hat man oft das Gefühl, dass sie nur sinnlose Zeitverschwendung sind. Vor diesem Hintergrund ist die von Stephanie Vozza beschriebene Fallstudie um so interessanter, denn das Unternehmen um das es hier geht (TheSoul Publishing) hat genau das gemacht und sich von beidem getrennt. Das dort stattdessen dominierende Kommunikations-Paradigma könnte man als "radikal transparente asynchrone Kommunikatin" beschreiben. Schriftlicher Austausch findet in für alle zugänglichen Foren und Chat-Kanälen statt, auch Anrufe und Video-Calls werden aufgenommen und dort veröffentlicht. Auf diese Weise hat jeder Mitarbeiter Zugang zu allen Informationen die im Unternehmen ausgetauscht werden. Wie Vozza selbst schreibt ist dieser Ansatz für alle neuen Mitarbeiter sehr gewöhnungsbedürftig, soll aber zu einem Produktivitäts-Boost führen. Vor allem zu dem letzten Punkt hätte ich zwar Fragen, aber als Beispiel für das was möglich ist, ist TheSoul bemerkenswert.

Virgilia Jansen-Preilowski: Wann eine Arbeitszeitverkürzung Produktivität und Wohlbefinden steigert – und wann nicht

Apropos bemerkenswerte Fallstudien. Seit einigen Jahren wird immer wieder von Unternehmen berichtet die bei gleichbleibendem Gehalt die Arbeitszeit ihrer Mitarbeiter drastisch verkürzt haben und dadurch wirtschaftlich erfolgreicher geworden sind. Da die einzelnen Fälle sehr unterschiedlich waren gibt es kaum eine Übersicht über die beeinflussenden Faktoren, was eine Besprechung und Bewertung schwierig macht. Virgilia Jansen-Preilowski bringt etwas Licht in das Dunkel indem sie einige nennt: Parkinson's Law, Effort-Recovery-Model, Stressempfinden und Soziale Einbindung, dazu verweist sie auf verschiedene weiterführende wissenschaftliche Quellen. Vor allem die an der Universität Bielefeld entstandene Meta-Studie "Arbeitszeitgestaltung in der digitalisierten Arbeitswelt: Ein systematisches Literatur Review zur Wirkung von Arbeitszeitverkürzung in Bezug auf die psychische Gesundheit" bietet dabei interessante weitere Einsichten.

Uno de Waal: Implementing Scrum in an Editorial Workflow

Auch ein Klassiker unter den Kategorien die hier gerne verlinkt werden: Berichte über den Einsatz agiler Frameworks in einem eher untypischen Umfeld. Uno de Waal hat die Einführung von Scrum in einer Redaktion miterlebt und mitgestaltet und die dabei gemachten Erfahrungen in einem Artikel zusammengefasst. Eine seiner Erkenntnisse findet sich auch in vielen vergleichbaren Fällen wieder - selbst grundlegende Praktiken wie die Visualisierung von Arbeit und die kollaborative Aufwandsschätzung können in Organisationen die bisher anders gearbeitet haben bereits zu weitreichenden Verbesserungen führen.

Donnerstag, 26. August 2021

The Daily Scrum Song

Heute mal wieder etwas Unfug zwischen all den ernsten Themen. Irgendjemand ist auf die grossartige Idee gekommen den Beitrag eines fiktiven Software-Entwicklers in seinem Daily Scrum zu einem Lied zu verarbeiten. Erkennbar einige typische Antipattern parodiend natürlich.



Bemerkenswert ist übrigens auch die erstaunlich gute Aufnahmequalität, die ja bei den von privaten Liebhabern eingesungenen Agile-Songs nicht immer gegeben ist. Dieses Lied ist gut genug um in eine Team-Playlist aufgenommen zu werden ohne zwischen den anderen durch schiefe Stimme oder rauschenden Ton aufzufallen.

Montag, 23. August 2021

Product Operations

Bild: Pexels / RF._.studio - CC0 1.0

Dass Organisationen die agil arbeiten wollen ihre Teams so neuzuschneiden müssen, dass sie Produkten entsprechen, dürfte mittlerweile Common Sense sein. Ebenfalls durchgesetzt hat sich die Erkenntnis, dass derartige Produktteams von empowerten Produktmanagern oder Product Ownern geführt werden sollten, also von zum Entscheiden berechtigten und befähigten Spezialisten für ihr jeweiliges Produkt. Diese klaren Verantwortlichkeiten einzuführen statt der vorher üblichen Entscheidungs-Kommittees beschleunigt Entscheidungen und reduziert Reibungsverluste.


Für die Inhaber dieser Rollen bedeutet das aber nicht nur Vorteile. Zwar geht die Abstimmungs- und Gremienzeit zurück, dafür liegen jetzt Aufgabenbereiche von erheblichem Umfang in der eigenen Verantwortung, sei es in der Marktforschung, bei der Erstellung von Road Maps und Produktvisionen, dem kurzfristigen Steuern der Umsetzungsteams oder der Erhebung und Visualisierung von Nutzungsdaten als Basis für das weitere Vorgehen. In vielen Fällen wird das zur Herausforderung.


Die besteht zum einen darin, überhaupt den Überblick zu behalten, was nicht nur wegen der z.T. sehr verschiedenen und bereits für sich umfangreichen Themen nicht einfach ist, sondern auch wegen der damit verbundenen verschiedenen Tools. Zum anderen sollen diese Tools, aber auch die Datenstrukturen, die Roadmap-Formate und andere Standards möglichst denen im restlichen Unternehmen entsprechen, um Vergleichbarkeit und Kompatibilität zu sichern. Sehr viel Arbeit.


Ein erster Weg um der dadurch drohenden Überlastung des Produktmanagers oder Product Owners entgegenzuwirken ist die Delegation von Teilen seiner Aufgaben in das Umsetzungsteam. In kleineren Organisationseinheiten ist das meistens auch völlig ausreichend, in grösseren stösst es aber an Grenzen. Nicht nur weil dem Team immer weniger Kapazität für seine eigentliche Arbeit bleibt, sondern auch weil das Problem der fehlenden übergreifenden Kompatibilitäten und Standards bestehen bleibt.


Eine andere Lösung die in den letzten Jahren in den USA entwickelt wurde trägt den Namen Product Operations. Hinter diesem Begriff stehen Unterstützungseinheiten, die unternehmensweit einheitliche Vorlagen für Roadmaps, Produktvisionen, etc. bereitstellen, darüber hinaus aber auch häufige Verwaltungsaufgaben übernehmen können, z.B. das Onboarding von Test-Usern, das toolgestützte Umwandeln von Daten in Grafiken oder das Beauftragen von Marktforschungsinstituten.


Product Operations-Teams übernehmen damit in Teilen vergleichbare Aufgaben wie andere Unterstützungseinheiten. Die Durchführung von Verwaltungstätigkeiten entspricht einem klassischen PMO, im Unterschied zu dem aber mit klarem Focus auf Produkt-Themen, die "Hilfe zur Selbsthilfe" bei Formaten und Standards ist vergleichbar mit den Angeboten der (im Vergleich eher generalistischen) Nexus Integration Teams. Nichts ganz Neues also, aber auf neue Bedürfnisse angepasst.


Wie sich dieser vergleichsweise neue Ansatz bewähren wird, wird spannend zu beobachten sein. Zum Einen ist die Abgrenzung zu verwandten Einheiten noch unklar, etwa zum gerade genannten PMO, aber auch zu Einkauf, Compliance und anderen. Zum Anderen bleibt die Frage ob hier nicht doch wieder notwendige Fähigkeiten und Berechtigungen so weit aus den Teams herausgenommen werden, dass Crossfunktionalität und Reaktionsfähigkeit beeinflusst werden. Man wird es sehen.


Zum weiteren Einarbeiten in das Thema bieten sich an:

Freitag, 20. August 2021

Software is still eating the world

Grafik: Pxfuel - CC0 1.0

Auf den Tag genau heute von 20 Jahren veröffentlichte der amerikanische Wagniskapital-Investor Marc Andreessen einen Artikel im Wall Street Jounal. Sein Titel: Why Software Is Eating the World. Vermutlich ohne es beabsichtigt zu haben gelang ihm damit das wovon jeder Journalist und Schriftsteller träumt - er prägte ein Sprichwort das bis heute in der englischen Sprache geläufig ist. Software is eating the world, sinngemäss übersetzt Software übernimmt die Welt.


Bereits zum damaligen Zeitpunkt konnte Andreesen aufzeigen, dass viele Branchen ohne Software nicht mehr funktionieren würden. Energieversorgung, Finanzwesen, Buch- und Einzelhandel, Filmindustrie, Verteidigungsindustrie, Telekommunikation und Anzeigenmarkt waren seine Beispiele, dazu kamen neue, von Anfang an digitale Geschäftsmodelle wie Suchmaschinen, Navigationssysteme und Video-Spiele. Schon um das Jahr 2000 war die Welt abhängig von Software.


Trotz der bereits damals weitgehenden Übernahme vieler Geschäftsprozesse durch Computerprogramme hat sich dieser Trend seitdem noch weiter verstärkt. Die vermutlich weitgehendste Weiterentwicklung dürfte dabei sein, dass Software heute nicht mehr bloss menschliche Entscheidungen ausführt sondern selbst welche trifft, sogar so weitreichende wie wer aus Gefängnissen entlassen wird, wer Arbeitslosenhilfe enthält oder wer von der Polizei gesucht wird.


Ein weiterer zunehmender Trend ist die ständige Vernetzung zwischen den Systemen, vor allem über das Internet. Schon vor 20 Jahren konnten so zwar bereits Updates eingespielt und Dateien versandt werden, mittlerweile gibt es aber immer mehr Anwendungen die ohne permanente Verbindung nicht mehr funktionieren. Das betrifft zum Beispiel Computerspiele, aber auch von Software betriebene Geräte wie Staubsauger und Türklingeln.


Alleine das ist bei genauerer Betrachtung bereits beunruhigend, geradezu verstörend wird es wenn man bedenkt, dass Software durch diese ständige Vernetzung fast immer von aussen angreifbar ist. Einer grösseren Öffentlichkeit dürfte die Anfälligkeit der amerikanischen Wahlen zu Ohren gekommen sein, aber auch die öffentliche Wasserversorgung lässt sich hacken, die IT-Systeme von Banken und (besonders albtraumhaft) das Betriebssystem von Insulinpumpen und Herzschrittmachern.


Diese Trends haben Folgen für die Art wie Software entwickelt wird. Wegen der möglicherweise schwerwiegenden Auswirkungen muss es möglich sein versehentlich falsch entwickelte IT-Programme schnell zu korrigieren, Updates schnell einzuspielen, Schäden an Software und IT-Infrastruktur schnell zu beheben und schnelle Gegenmassnahmen gegen Viren und Hacker umzusetzen. Ohne diese Reaktionsfähigkeit wird Software is eating the world zu einer existenziellen Bedrohung.


Das wiederum bedeutet, dass sich die Softwareentwicklungs-Organisationen in Unternehmen und Behörden ändern müssen (und es bereits tun). Egal ob man dafür Buzzwords wie Lean und Agile benutzt oder nicht - langsame und schwerfällige Prozesse (zu denen bereits Quartalsreleases gehören) werden in immer weniger Fällen akzeptabel. Für ein Sprichwort wird es zwar nicht reichen, ein zwingender Schluss ist es aber trotzdem: die Übernahme der Welt durch Software zwingt Organisationen in die Agilität.

Montag, 16. August 2021

Wie man Agile für tot erklärt (eine Anleitung)

Grafik: Pixabay / Revzack - CC0 1.0

Du kommst aus dem (IT-)Produkt- oder Projektmanagement? Du möchtest Deinen Bekanntheitsgrad erhöhen? Du möchtest als Sprecher auf Konferenzen eingeladen werden und Artikel in Fachpublikationen veröffentlichen? Dann ist das hier die Möglichkeit für Dich - Du musst nichts weiter tun als zu verkünden dass "Agile", der zur Zeit dominierende Denkansatz, tot ist. Das ist mittlerweile ein bewährtes Vorgehen, so bewährt sogar, dass es eine Blaupause dafür gibt. Hier ist sie:


I. Bau Deine Reputation auf

Zu Beginn Deines Vortrages oder Artikels solltest Du hervorheben wie relevant Deine Meinung ist. Praktischerweise kannst Du dafür alles als Beleg nennen - wenn Du schon lange mit agilen Frameworks arbeitest bist Du die weise Koryphäe, mit wenig Erfahrungen bist Du einer der jungen Wilden, wenn Du gar keine hast bist Du der unbefangene und sachliche Beobachter ausserhalb des Systems. Egal was es ist, Du kannst es als Grund dafür nennen, dass gerade Du zu originellen Gedanken in der Lage bist.


II. Verteile vergiftetes Lob

Auf gar keinen Fall solltest Du sagen, dass Agile schon immer Mist war, damit erzeugst Du zu frühen Wiederspruch. Streiche heraus, dass die Verfasser des Agilen Manifests bahnbrechende Pioniere waren, denen nur Hochachtung gebührt. Lass aber auch Relativierungen einfliessen, etwa, dass das Manifest "zur damaligen Zeit" genau das Richtige war, oder dass es die Arbeit "auf der Team-Ebene" revolutioniert hat. Selbst wenn Du es nicht aussprichst, jeder wird spüren, dass gleich ein "aber" folgen wird.


III. Prangere vermeintliche Unzulänglichkeiten an

Hier kannst Du kreativ sein. Egal ob "Agile funktioniert nicht in grösseren Organisationen", Agile funktioniert nicht mit Product Discovery" oder "Agile funktionier nicht in bestimmten Ländern" - je steiler die These desto besser. Empirische Belege dafür brauchst Du keine, es reicht anekdotische Evidenz, also eigene Erfahrungen (die keiner überprüfen kann). Ein schöner Seiteneffekt: Gegenbeispiele kannst Du als "verkopft" und theoretisch" abtun wenn Du sie nicht selbst erlebt hast.


IV. Hebe einzelne bekannte Negativ-Beispiele hervor

Zum Glück kannst Du hier aus dem vollen Schöpfen. Nimm irgendein Beispiel eines (angeblich) agil organisierten Vorhabens das schiefgelaufen ist und erhebe es zum Beweis, dass Deine persönlichen Erfahrungen universell richtig sind. Wenn Du weisst welcher methodische Ansatz dort verwendet wurde kannst Du zur Verstärkung Elemente aus dem Kontext reissen und Dich über sie lustig machen, etwa über das Wimmelbild auf der SAFe-Startseite oder über Begriffe wie Tribe und Gilde.


V. Immunisiere Dich

Irgendwann wirst Du es nicht mehr vermeiden können Dich mit Beispielen geglückter Umsetzung der agilen Frameworks auseinanderzusetzen. Dem kannst Du zuvorkommen indem Du selbst einige davon aufführst, aber mit einem überraschenden Dreh: behaupte, dass diese Organisationen nur deshalb erfolgreich sind weil sie das Vorgehen an ihre Bedürfnisse angepasst haben. Je nach der Agenda die Du verfolgst kannst Du sie dann als "nur noch eingeschränkt agil" oder sogar "post-agil" bezeichnen.


VI. Begeistere alle mit einer alternativen, besseren Lösung

Auf zum grossen Finale. Nachdem Du alle davon überzeugt hast, dass Agile wirklich tot ist bleibt nur noch Eines zu tun - die Alternative zu benennen. Je nach Deinen persönlichen Vorlieben (oder Deinen politischen Absichten) kann die darin bestehen alles wieder stärker zu steuern und zu kontrollieren, es kann aber auch Dein neuer, "post-agiler" Ansatz sein, mit dessen Vermarktung Du vorhast Geld als Berater oder Vortragsredner zu verdienen. Du machst das alles ja schliesslich nicht umsonst.


Und das war es auch schon. Nur sechs einfache Schritte und schon ist Agile tot und Du als neuer Thought Leader etabliert. Angesichts der Tatsache, dass das Ganze mit dieser Blaupause zu einer wirklich einfachen Übung wird ist es kein Wunder, dass das bereits seit Jahrzehnten von zig verschiedenen Leuten nach genau diesem Muster gemacht wird. Nur gut, dass die Agilität in all der Zeit noch nicht gestorben ist, so dass man sie immer wieder erneut für tot erklären kann.


[Ironie off] Inspiriert ist dieser Text von Jahn Meckes Artikel Agile is Dead (So is COBOL, XP, RAD, UML, SAFe, etc) und von zu vielen "Agile is Dead"-Meinungsbeiträgen in den letzten 10 Jahren. Meine persönliche Meinung: Agile wird zwar irgendwann in Vergessenheit geraten, aber nicht so wie in diesen Beiträgen beschrieben sondern aus banaleren Gründen. Mehr dazu hier.

Donnerstag, 12. August 2021

Chaos

Bild: Pixabay / Geralt - CC0 1.0

Vielleicht habe ich in letzter Zeit zu viele Grundlagenschulungen zum Thema agile Produktentwicklung gehalten, aber irgendwie ist mir danach etwas zum Thema Chaos zu schreiben. Nicht etwa weil sie chaotisch verlaufen wären, sondern weil ich dort entweder die Stacey Matrix oder das Cynefin Framework einsetze um zu erklären wo es Sinn macht agil zu arbeiten und wo nicht. In beiden Modellen kommt ein chaotischer Bereich vor und in beiden wird er oft anders beschrieben als ich es für sinnvoll halte.


Um mit der offensichtlichsten Frage zu beginnen - was ist das eigentlich, dieses Chaos? Vereinfacht gesagt handelt es sich bei ihm um einen Zustand der Unordnung der sich durch (Eigen)Dynamiken und Vernetzung so schnell verändert, dass es nicht möglich ist sich einen Gesamt-Überblick zu verschaffen und Ursache-Wirkungs-Zusammenhänge zu erkennen. Die Veränderungsgeschwindigkeit und Unübersichtlichkeit sind so gross, dass Informationen obsolet werden bevor sie vollständig sind.


Aus dieser Erklärung ergibt sich auch, dass Chaos kein gottgegebenes Schicksal ist. In beiden Modellen entsteht es durch die Zunahme der fördernden Faktoren, kann aber durch deren Eindämmung auch reduziert werden. Das ist ein wesentlicher Unterschied zu den Erklärungen die ich von vielen Beratern, Scrum Mastern und Agile Coaches gehört habe: in ihnen ist Chaos etwas was in bestimmten Situationen oder Umgebungen kategorisch da ist oder eben nicht.


Ein weiteres Missverständnis besteht darin, dass es angeblich methodische Vorgehensweisen gibt mit denen man im chaotischen Bereich strukturiert arbeiten kann. Vor allem bei einer Bildersuche nach der Stacey Matrix findet man zahlreiche Visualisierungen die unterstellen, dass man in ihm Agile- oder Lean- Ansätze wie Lean Startup, Design Thinking, Scrum oder Kanban einsetzen könnte. Beim Cynefin Framework ist dieses Missverständnis seltener, aber auch hier kommt es vor.


Dass es ein Missverständnis ist, ist dabei eigentlich leicht zu verstehen: egal ob es um das Testen eines MVP in Lean Startup oder eines Prototypen im Design Thinking geht, um Inspect & Adapt in Scrum oder um das Verbessern eines Arbeitsdurchflusses in Kanban - in jedem dieser Frameworks folgt ein zweiter Schritt auf einen ersten. Wenn die Ergebnisse des ersten sich im Chaos aber ständig verändern, dann hat der zweite Nichts worauf er aufbauen kann und das ganze Vorgehen bleibt ergebnislos.


Häufig wird dem in meinen Trainings mit dem Argument begegnet, dass das nur für manche, aber nicht für alle Menschen gelten würde. Wer schnelle Auffassungsgabe, grosse Erfahrung oder "agiles Mindset" habe bekäme auch Chaos in den Griff. Auch da fürchte ich - ein Missverständnis. In chaotischen Situationen wie Börsencrashs, Erdbeben oder Massenpaniken kann auch das grösste Genie keinen Überblick mehr herstellen (und BTW: viele IT-Grossprojekte haben Eigenschaften von Massenpaniken).


Was man in chaotischen Situationen machen kann ist für Genies und Nicht-Genies gleich: Firefighting (verhindert kurzfristig Schäden, verbessert aber die Gesamtsituation nicht), Triage (im Vergleich weniger wichtige Elemente werden dem Untergang überlassen um die wichtigeren zu retten) und eine ggf. rabiate Reduktion von Chaos-Faktoren, indem diese (egal ob Einzelpersonen, Gruppen oder Systeme) ausgesperrt, isoliert oder in ihrer Wirkungskraft eingeschränkt werden.


An dieser Stelle wird auch klar warum der im Chaos tatsächlich gegebene Handlungsspielraum nur selten thematisiert wird - es würde klar werden, dass das was ins Chaos hineingeraten ist nur in Teilen zu retten ist, bzw. nur um den Preis der Beschädigung anderer Teilsystme. Das ist eine Wahrheit die sich viele Berater ("es gibt für alles eine Lösung") und Manager ("kommen Sie mit Lösungen zu mir, nicht mit Problemen") nicht eingestehen wollen oder können.


Auch das ist übrigens menschlich und verständlich, dass man nur sehr ungern etwas verloren gibt in dessen Aufbau man Zeit und Aufwand investiert hat dürfte jeder nachvollziehen können. Die tragische Ironie dieser Geschichte ist aber, dass durch das verzweifelte Festhalten an umfassenden Rettungsvorhaben und unrealistischen Steuerungsphantasien das Chaos nur noch schlimmer wird, da es den realistischen Optionen Ressourcen entzieht.


Der beste Umgang mit Chaos ist daher, es gar nicht erst entstehen zu lassen. Und hier entfalten die zu Beginn genannten Modelle Stacey Matrix und Cynefin Framework ihre wahre Stärke: wenn man es einmal akzeptiert hat, dass Vorhaben in ihnen nicht einem der vier Bereiche (Einfach, Kompliziert, Komplex, Chaotisch) fest zugeordnet sind sondern sich zwischen ihnen bewegen, kann man gegensteuern sobald es klar ist, dass es in Richtung Chaos geht.


Geschehen kann das wie weiter oben beschrieben, durch die Eindämmung und Zurückdrängung von Chaos fördernden Faktoren. Das kann anstrengend werden, da dieses Zurückdrängen häufig aus System-Refactorings besteht, deren Sinn sicht Nicht-Technikern nicht erschliesst oder aus der bewussten Entscheidung Wünsche von Kunden oder Managern nicht zu erfüllen wenn dadurch Instabilität entsteht. Es ist aber immer noch deutlich weniger anstrengend als das Chaos selbst.



PS: da wir gerade bei Missverständnissen sind - zu den grössten gehört die Gleichsetzung von Chaos und Anarchie. Anarchie ist Ordnung ohne Herrschaft, Chaos ist Unordnung. Ein wesentlicher Unterschied.

Montag, 9. August 2021

The agile Bookshelf: Dynamic Reteaming

Bild: Pixabay / Metsik Garden - CC0 1.0

Es gibt Bücher die nicht in erster Linie wegen der Innovativität oder Eloquenz ihres Inhalts grosse Bekanntheit erreichen, sondern weil in ihnen zum ersten mal vor einer grossen Öffentlichkeit eine tabuisierte Wahrheit ausgesprochen oder ein scheinbarer Widerspruch aufgelöst wird. Dynamic Reteaming von Heidi Helfland gehört in diese Kategorie, weshalb es Sinn macht seine Besprechung nicht mit dem Buch selbst zu beginnen sondern mit seinem Entstehungskontext.


Vereinfacht gesagt besteht dieser Kontext aus dem Spannungsfeld zwischen möglichst weitgehender Ressourcenoptimierung und möglichst ungestörtem Arbeiten. Die erste führt dazu, dass versucht wird eine möglichst hundertprozentige Auslastung der Mitarbeiter zu verwirklichen indem sie (ganz oder in Teilen ihrer Zeit) immer dorthin versetzt werden wo gerade Bedarf ist, das zweite geht in die andere Richtung und nimmt ggf. sogar Leerlauf in Kauf um Ineffektivität durch Multitasking und Versetzungs-Bürokratie zu vermeiden.


Während in hierarchisch-arbeitsteiligen Organisationen die Ressourcenoptimierung das dominierende Paradigma ist, wird in agilen Arbeitsumgebungen meistens Wert auf das ungestörte Arbeiten gelegt. Grundsätzlich ist das auch sinnvoll (siehe hier und hier), an vielen Stellen hat es aber zu dem sehr dogmatischen Ansatz geführt, dass ein Wechsel zwischen verschiedenen Teams grundsätzlich abgelehnt wird - schliesslich würde er Unruhe in das Arbeitsumfeld bringen, was ja vermieden werden soll.


An dieser Stelle setzt Helflands Buch an. Nicht etwa durch ein Einsteigen in die gerade beschriebene Diskussion, sondern ganz pragmatisch durch die Feststellung, dass es gute Gründe für neue Teamschnitte oder den Wechsel von Personen zwischen Teams geben kann, und durch Vorschläge wie das möglichst selbstorganisiert und unbürokratisch vor sich gehen kann. Aus diesen Ansätzen ergeben sich auch die drei Abschnitte in die das Buch eingeteilt ist.1


Im ersten Teil "What is Dynamic Reteaming?" werden die Grundlagen gesetzt. Es geht darum was überhaupt ein Team ist, wie man dorthin versetzt werden kann (Spoiler: es gibt mehr als eine Art) und was Gründe dafür sein können einen neuen Teamschnitt anzustreben. Dazu gehören sowohl solche aus der Angestelltenperspektive, etwa der Wunsch nach dem nächsten Karriereschritt, als auch solche aus Systemsicht, wie das Verhindern von Silobildung und eingefahrenen Denkmustern.


Im zweiten Teil geht es konkret um den Vorgang des "Reteamings", bei dem Helfland fünf Haupttypen beschreibt: Einzelversetzung, Teamteilung, Bildung neuer Produkt- oder Spezialistenteams, Teamzusammenlegung und Neuordnung zum Zweck von Wissens- und Erfahrungsaustausch. Für jeden dieser Fälle gibt sie Beispiele und Handlungsempfehlungen, warnt aber auch vor möglichen Fehlern, die die angestrebten positiven Effekte zunichtemachen können.


Im dritten Teil wird schliesslich beschrieben welche Rahmenbedingungen und Praktiken in der umgebenden Organisation dazu beitragen können, dass das Reteaming dynamisch, also schnell und flexibel, wird. Zum Teil ist das sehr spezifisch auf IT-Teams bezogen, es gibt aber auch grundsätzliche Elemente, z.B. vergleichbare Rollen in den verschiedenen Einheiten. Hervorgehoben wird auch, dass die Reteamings nicht nur vor- sondern auch nachbereitet werden sollten.


Wie oben gesagt - das ist alles nicht wirklich innovativ, viele Organisationen (egal ob klassisch oder agil organisiert) nutzen viele Elemente des Dynamic Reteaming schon lange unter anderem Namen. Trotzdem bietet das Buch einen Mehrwert: zum einen in dem es das Dogma der unbedingt zu erhaltenden stabilen Teams aufbricht, zum anderen indem es den bisherigen Wissensstand konsolidiert, zusammenführt und agil-kompatibel aufbereitet. Daher eine klare Leseempfehlung.


1Dieser Text hier bezieht sich auf die zweite Auflage, die erste ist wohl in Teilen anders aufgebaut.

Freitag, 6. August 2021

Stacey Matrix

Wenn es irgendwo ein Erklär-Workshop für Agilität gibt kann man Geld darauf wetten, dass sie früher oder später auf einem Flipchart oder einer Präsentationsfolie auftaucht: die Rede ist von der Stacey Matrix, benannt nach dem englischen Wirtschaftswissenschaftler Ralp Douglas Stacey, der sie in den 90er Jahren entwickelte um aufzuzeigen welcher Vorgehens-Ansatz in welchem Umfeld am ehesten Sinn macht. Das ist bis heute ihr Zweck, oft verengt auf die Frage in welchem Umfeld Agilität sinnvoll ist.


Die Variante die dabei am häufigsten gezeigt wird (und die auch weiter oben auf dieser Seite zu sehen ist) trägt ihren Namen allerdings nicht völlig zu Recht. Es handelt sich bei ihr lediglich um eine modifizierte und stark vereinfachte Variation des ursprünglichen Modells, die um das Jahr 2000 von der kanadischen Organisationsforscherin Brenda Zimmermann entwickelt worden ist (und daher eigentlich Zimmermann-Matrix genannt werden müsste).


Dass die Zimmermann-Variante sich durchgesetzt hat und nicht das Original dürfte vermutlich an zwei Gründen liegen. Zum einen ist sie aufgrund ihres reduzierten Inhalts einfacher zu erklären, zum anderen wurde sie durch den Scrum-Miterfinder Ken Schwaber popularisiert, der sie 2004 in seinem Buch Agile Project Management with Scrum abbildete. Da heute fast nur noch diese Ableitung genutzt wird soll es im Folgenden um sie gehen. Wer mehr über das Original wissen will erfährt hier und hier mehr.


Die zwei Achsen der Stacey/Zimmermann-Matrix sind das Was (fachliche Anforderungen) und das Wie (eingesetzte Technologie). Beide sind im unteren linken Bereich der Matrix klar, werden aber nach oben, bzw. nach rechts unklarer. Durch die Kombination der beiden sich verändernden Werte entstehen vier Bereiche: Einfach (links unten, Kompliziert (links-untere Mitte), Komplex (rechts-obere Mitte) und Chaotisch (rechts oben). Ihnen werden empfohlene Vorgehensweisen zugeordnet.


Der einfache Bereich ist der in dem am Ehesten klassisches Management mit Hierarchien, Arbeitsteilung und langfristigen Plänen machbar ist. Die Anzahl der beeinflussenden Faktoren hält sich in Grenzen, Änderungen treten selten auf und sind dann in der Regel vorhersehbar (oder selbst herbeigeführt), die Umsetzung erfordert nur geringe Expertise und kann häufig automatisiert werden. Beispiele wären eine Kartoffelernte oder das Bauen einer Ziegelmauer.


Im komplizierten Bereich ist es schon schwieriger den Überblick zu behalten. Es gibt viele kleinteilige Faktoren die sich auch gegenseitig beeinflussen, durch Standardisierung und optimierte Informationsflüsse kann aber auch hier noch nach Plan gearbeitet werden. Beispielhaft dafür sind der Betrieb einer Fabrikstrasse oder einer Systemgastronomie, empfohlene Vorgehensweisen kommen aus dem Lean Management-Umfeld, etwa Kanban oder SixSigma.


Im komplexen Bereich sind Fachlichkeit und Technik so unklar, dass Detail- und Langfristplanung nicht mehr funktionieren. Die Menge der Faktoren und Inputs und die Anzahl ihrer Abhängigkeiten sorgen dafür, dass das System sich ständig unvorhersehbar verhält, etwa in der Produktentwicklung oder in der Kathastrophenhilfe nach Überflutungen, Grossbränden, etc. Am besten können Inspect & Adapt-getriebene Ansätze damit umgehen, etwa die verschiedenen agilen Frameworks.


Der Chaotische Bereich lässt schliesslich überhaupt kein strukturiertes Arbeiten mehr zu, da eine extreme Kleinteiligkeit und Vernetztheit dafür sorgt, dass es nicht mehr möglich ist alles im Blick zu haben und darauf zu reagieren. Beispiele wären unkontrollierte Kettenreaktionen in Kernkraftwerken oder die Weiterentwicklung sehr grosser, alter und schlecht gewarteter Softwäre-Monolithen. Einzig mögliche Vorgehensweisen sind situatives Firefighting, Triage und (wenn möglich) das Abschalten ganzer Systeme.


Wie alle vereinfachten Informationsvermittlungs-Ansätze hat auch die Zimmermann-Variante der Stacey-Matrix Vor- und Nachteile. Zu den Vorteilen gehört die bereits erwähnte einfache einfache Erklärbarkeit und Verständlichkeit, zu den Nachteilen eine so hohe Abstraktion, dass sie auf Kosten der Anwendbarkeit geht. So ist es etwa auch bei grösstem Bemühen nicht möglich zu sagen ab wann Fachlichkeit und Technik so unklar werden, dass der Gesamtzustand von kompliziert zu komplex wechselt.


Wenn man sich dieser Begrenzungen bewusst ist kann diese Matrix aber ein sehr nützliches Werkzeug sein um im Rahmen von Schulungen und Methodeneinführungen aufzuzeigen, dass kaum eine Vorgehensweise überall anwendbar ist, jede aber in bestimmten Kontexten ihre Stärken haben kann. Alleine diese Erkenntnisse können vielen Organisationen bereits weiterhelfen und das Erreichen weiterer, darauf aufbauender Erkenntnisschritte deutlich erleichtern.

Dienstag, 3. August 2021

Brauchbare Illegalität als Organisationskultur

Das Konzept der brauchbaren Illegalität hat mich schon als Student fasziniert, und bis heute hat sich das nicht geändert. Stefan Kühl weist in diesem Vortrag auf einen Aspekt hin der oft heimlich verschwiegen wird: in vielen Organisationen ist diese Art des Regelbruchs Teil der Organisationskultur, ist also ein üblicher Weg des täglichen Arbeitens.



Für das tiefere Eintauchen in das Thema der Gesetzes- und Regelbrüche empfiehlt sich ein längerer Text den Kühl vor einiger Zeit geschrieben hat: Zur Entstehung, Durchsetzung und Regulierung von Regelabweichungen. Nicht nur wegen seines Inhaltes zu empfehlen sondern auch wegen seines umfangreichen Literaturverzeichnis.

Samstag, 31. Juli 2021

Kommentierte Links (LXXVII)

Grafik: Pixabay / The Digital Artist - CC0 1.0
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.

Shishir Mehrotra: Rituals for hypergrowth - An inside look at how Youtube scaled

Dass viele grosse Firmen mit der Zeit ihre eigenen agilen Frameworks entwickeln (und mit der Zeit weiterentwickeln oder verwerfen) ist eine verhältnismässig unbekannte Tatsache, lediglich das (oft missverstandene) Spotify Model hat eine gewisse Berühmtheit erlangt, die anderen sind wenig bekannt. Um so interessanter ist das was Shishir Mehrotra hier vorstellt: es ist das Vorgehensmodell das bei Youtube nach der Übernahme durch Google entwickelt wurde. Erkennbar sind hier andere Frameworks integriert worden, wie z.B. OKRs und Teile von Scrum, vieles ist aber offensichtlich selbst entworfen worden und dürfte in dieser Form sicher einzigartig sein. Wie in anderen derartigen Fällen kann man auch hier nur davon abraten dieses Modell kopieren zu wollen, einige Elemente (wie z.B. das Verbot kurzfristig einberufener Meetings) sind so kontextspezifisch, dass sie an anderen Stellen eher Schaden als Nutzen anrichten würden. Eine faszinierende Fallstudie ist es aber auf jeden Fall.

Tom Rusell: Planning & estimating large-scale software projects

Den wichtigsten Satz über die Aufwandsschätzungen nicht nur in grossen sondern in allen komplexen Projekten hat Tom Rusell fast versteckt in den Untertitel einer Absatz-Überschrift geschrieben: "You must always involve those who will actually do the work". Alleine damit würde er einem Grossteil der derartigen Vorhaben schon weiterhelfen, er geht aber noch darüber hinaus und liefert eine ganze Reihe sinnvoller Anleitungen und Ideen. Das meiste davon erscheint wenn man es liest eher naheliegend als revolutionär, man muss sich allerdings bewusst machen, dass dieser Schein trügt - in vielen grossen Organisationen werden diese Praktiken eher simuliert als angewandt.
Übrigens - um zu zeigen, dass dieser Ansatz zwar funktionieren kann, er aber auch er keineswegs der einzige oder beste ist, ist hier eine völlig andersartige Fallstudie: No Estimates at Scale in the US Federal Government.

Jason Yip: Concepts I use every day - BAPO

Hinter der Abkürzung BAPO stehen die Begriffe Business, Architecture, Process und Organisation, sinngemäss übersetzbar mit Geschäftszielen, IT-Architektur, Arbeitsabläufen und Organisationsstruktur. Dass Jason Yip geht davon aus, dass diese Teilsysteme in dieser Reihenfolge geändert werden müssen wenn die Umstrukturierung einer Organisation wirklichen Erfolg haben soll. Den häufiger anzutreffenden Ansatz direkt von den Geschäftszielen zur Änderung der Organisationsstruktur überzugehen hält er für weniger sinnvoll, da dieses Vorgehen dazu führt, dass die neue Ablauforganisation nicht mehr mit den IT-Systemen kompatibel ist, da diese ja auf die alte Struktur optimiert wurden (Conway's Law). Als jemand der sowohl gelungene als auch misslungene Transformationsversuche miterlebt hat kann ich dem nur aus voller Überzeugung zustimmen.

Jeff Patton: The Mindset That Kills Product Thinking

Wieder mal ein bisschen Meta-Content. Jeff Patton reagiert mit diesem Artikel auf zwei weitere Artikel (hier und hier) die etwas früher von Marty Cagan geschrieben worden. Die Synthese in die er die beiden Inhalte mit seinem seit einiger Zeit vorgetragenen Zweifel an der agilen Produktentwicklung (des Jahres 2001) zusammenführt ergibt eine umfassende Kritik daran, dass die Software-Industrie im speziellen, aber auch der Markt und die Menschheit im Allgemeinen zu stark auf Output focussiert sind und zu wenig auf Outcome. Das ist zwar weder neu noch unstrittig, es ist aber anschaulich beschrieben und pointiert präsentiert, so dass es einen guten Anstoss für Diskussionen bietet. Denn selbst wenn man nicht in jedem Aspekt mit ihm übereinstimmt - er weist hier definitiv auf ein Thema hin über das man nachdenken sollte.

Daniel Lebrero: Lucky Lotto, chaos engineering but for teams

Für alle Fans resilienter Organisationen und für Anhänger des Chaos Engineering hat Danieö Lebrero eine Idee die man sofort bei sich selbst ausprobieren kann: Jeden Montag wird ein Mitarbeiter ausgelost das seinem Team in der nächsten Woche nur in absoluten Ausnahmefällen zur Verfügung steht und sonst ausschliesslich an einem kleinen Sonderprojekt arbeitet. Der angestebte Effekt ist eine höhere Ausfallsicherheit und Crossfunktionalität, entweder dadurch dass die Teams sich auf mögliche Ausfälle vorbereiten oder dadurch, dass der Ausfall eintritt und die verbleibenden Kollegen jetzt auch die Tätigkeiten übernehmen müssen die bisher immer der jetzt abwesende Spezialist übernommen hat. Die Spannung bei der Verlosung gibt es gratis dazu.