Dienstag, 28. Februar 2023

Kommentierte Links (XCVIII)

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

Nils Markwardt: Die Erfindung des Alten

Mit Erfindungen wird von den meisten Menschen automatisch etwas Neues in Verbindung gebracht. Dass oft sogar das Gegenteil der Fall ist zeigt Nils Markwardt in diesem lesenswerten Text auf. Ein Großteil der bekannteren Erfindungen (von der Uhr über den Motor bis zum Computer) ist entstanden um Bestehendes effizienter und beherrschbarer zu machen und damit zu erhalten. Bei etwas Nachdenken ist das auch nachvollziehbar - die meisten Innovationen erfüllen den Zweck, real existierende Probleme zu lösen - und die entstehen nun mal aus dem Ist-Zustand heraus.

Rebecca Ackermann: Design thinking was supposed to fix the world. Where did it go wrong?

Ich muss gestehen, dass ich schon immer eine leichte Skepsis gegenüber Design Thinking hatte. Natürlich, vom Problem aus denken, crossfunktional zusammenarbeiten, Kreativtechniken nutzen und möglichst früh Feedback einholen sind sinnvolle Konzepte, und in den meisten Organisationen wird das viel zu wenig gemacht. Die grosse Schwäche besteht aber darin, dass am Ende lediglich ein rudimentärer Prototyp steht (oft nur in Form eines Bildes oder einer Lego-Konstruktion). Ob der wirklich ein Problem lösen kann oder in eine Fertigung überführt werden kann ist objektiv kaum validierbar. Rebecca Ackermann stellt diese Problematik dankenswerterweise ausführlich dar.

Assaph Mehr: Product development - or how to turn factories into gardens

Diese Idee von Assaph Mehr gefällt mir. Ein digitales Produkt sollte man sich nicht vorstellen wie eine grosse Maschine, deren Einzelteile in einem fliessbandartigen Fertigungsprozess entstanden sind, sondern eher wie einen Garten. Er wächst und blüht, braucht aber auch Pflege, Gestaltung und von Zeit zu Zeit eine gründliche Entferung der Unkräuter. Was für mich in diesem gedankliche Bild besonders entscheidend ist: Gärtner (Entwickler) und Besucher (Nutzer) sind im selben Garten unterwegs und interagieren in ihm. Anders in einer Fabrik findet keine Auslieferung statt sondern eine Einladung zu gemeinsamen Benutzung.

Erik de Bos: Full-time or Part-time Scrum Mastery

Seit Scrum erfunden wurde gibt es die Debatte, ob die Rolle des Scrum Masters nicht auch in Teilzeit ausgeübt werden könnte. Entweder mit dem Ziel, dass ein Scrum Master in mehreren Teams Mitglied sein kann, oder mit der Idee, dass eines der Teammitglieder den Job zusatzlich zu seiner sonstigen Arbeit machen kann. Erik de Bos ist diesen zweiten Weg gegangen und teilt seine Erfahrungen in diesem Praxis-Bericht. Wie so oft gibt es auch hier keine klare Antwort darauf ob solche Konstellationen gut sind oder nicht, es zeigt sich aber, dass sie zumindest nicht unproblematisch sind.

John Cutler: Subtractive and Additive Change

Was John Cutler hier beschreibt kann man in zahlreichen Veränderungsvorhaben beobachten. Veränderungen sollen häufig dadurch erziehlt werden, dass etwas hinzugefügt wird - Features, Rollen, Prozesse, Verbindungen, etc. Dass es genauso sinnvoll sein kann (oder sogar noch sinnvoller), bestehende Elemente zu entfernen wird dagegen vergleichsweise selten bedacht. Die Gründe dafür sind menschlich (Gewöhnung, Sicherheit, Sunk Cost Fallacy, etc), ein wirkliches Argument gegen das Weglassen sind sie aber nur selten.

Donnerstag, 23. Februar 2023

People Manager

Bild: Pexels / Fauxels - Lizenz

Dass sich bei der Umstellung auf agiles Arbeiten nicht nur die Umsetzungsteams ändern müssen, sondern auch die umgebende Organisation, ist mittlerweile weitgehend anerkannt. Auf welche Art und Weise das passieren muss ist wesentlich unklarer, einige Ideen setzen sich aber mehr und mehr durch. Um eine davon soll es heute gehen, und zwar um eine neue Rolle: den People Manager (je nach Firma auch People Coach, People Lead, o.Ä.).


Die zugrundeliegende Idee ist, dass mit dieser Rolle verhindert werden soll, dass der disziplinarische Vorgesetzte eines Teams auch dessen fachliche oder methodische Leitung innehat - dort wo das der Fall ist, ist es nämlich erfahrungsgemäss ein hohes Risiko für die Selbstorganisation eines Teams. Das eigentlich gewünschte kritische Hinterfragen von Anforderungen und Anweisungen fällt schliesslich gegenüber jemandem, mit dem man sein Gehalt verhandeln muss, eher schwer.


Abweichend davon soll der People Manager explizit keine fachliche oder methodische Führung ausüben. Stattdessen ist er in den meisten Umsetzungen für die erwähnten Gehaltsverhandlungen und für die Karriereförderung (incl. Versetzungen) zuständig, je nach Einzelfall können noch verwandte Tätigkeiten dazukommen, zum Beispiel sicherzustellen, dass regelmässige obligatorische Sicherheitstrainings oder Schulungen stattfinden, dass sich nicht zu viele Überstunden anhäufen, etc.


Ausgehend davon, dass mit der Einführung der People Manager meistens auch eine Öffnung der Karrierewege einhergeht, kommt es in vielen Fällen dazu, dass mit der Zeit er für Menschen aus unterschiedlichsten Fachrichtungen zuständig ist. Selbst wenn z.B. ursprünglich alle Softwareentwickler gewesen sind, können sie sich über die Zeit zu Architekten, Projektleitern, Produktmanagern oder anderen Rollen weiterentwickeln, die aber weiterhin zum selben People Manager gehören.


Spätestens bei dem letzten Punkt lässt sich erahnen, dass diese neue Rolle in der Realität regelmässig mit Problemen konfrontiert ist. Je diverser die Gruppe ist für die ein People Manager zuständig ist, desto schwerer wird es ihm fallen, allen von ihnen sinnvolle Hilfe bei der Karriereentwichlung zu geben. Und selbst dort, wo die Gruppe einheitlich ist, ist er so weit von der täglichen Arbeit entfernt, dass es ihm oft schwer fällt zu beurteilen, wer eine Gehaltserhöhung oder Beförderung verdient hat und wer nicht.


Im schlimmsten (aber leider durchaus häufigen) Fall wird der People Manager zu einer Station in einer Stille-Post-Kette. Welche Mitarbeiter Karriereförderung oder Gehaltserhöhung brauchen, wird weiterhin von den fachlichen oder methodischen Führungskräften entschieden, von denen der People Manager sich die entsprechenden Informationen holt und denen er mangels eigener Einsicht vertrauen muss. Ihm selbst bleibt noch eine Art personal coaching-Rolle, die mehr oder weniger gut angenommen wird.


Wie könnte es besser gehen? Ein naheliegender Weg wäre es, den fachlichen Schwerpunkt wieder herzustellen. Die persönlichen Entwicklungspfade der Mitarbeiter bleiben zwar offen, wer aber z.B. vom Softwareentwickler zum Projektleiter wird, wechselt vom People Manager IT zum People Manager Projektmanagement. Die Karriereförderung innerhalb dieser Fachgebiete wird dadurch wieder einfacher, da auch die People Manager selbst hier Expertise aufbauen können.


Auch der Bezug zur täglichen Arbeit lässt sich auf diesem Weg wieder herstellen, etwa dadurch, dass der People Manager die jeweilige Community of Practice oder Gilde organisiert oder indem er dabei unterstützt, wenn Teams sich in einem neuen (naheliegenderweise in seinem) Fachbereich Expertise aufbauen wollen. Ein klassischer derartiger Fall wäre z.B. die Arbeit in einem Nexus-Integration Team oder einer Einheit mit vergleichbarer Tätigkeit.


Wie so oft ist es übrigens eine gute Idee, sich diese Gedanken zu machen und derartige (oder andere) Lösungen zu erarbeiten, bevor man diese neue Rolle einführt. Man erspart sich dadurch Einiges an Irritationen und Frustrationen, die sonst sicher auf einen zukommen. Man muss sich nur unter People Managern umhören, die meisten werden davon berichten können.

Montag, 20. Februar 2023

Post-Transformation Bias

Bild: Wikimedia Commons / Erwin Soo - CC BY 2.0

"Grau ist alle Theorie, nur im Praxiseinsatz sieht man ob etwas funktioniert." Aufgrund von Überzeugungen wie dieser ist eine ganze Berater- und Erfahrungsbericht-Industrie um ehemalige Angestellte von vorbildhaft agil arbeitenden Firmen wie Google, Facebook, Netflix und Amazon entstanden, die Ratschläge zum agil werden geben. Das ist auch grundsätzlich nachvollziehbar, führt aber leider regelmässig in die Sackgasse. An einem Beispiel möchte ich erklären warum.1


In den letzten Wochen wurde in meinem Bekanntenkreis wiederholt ein Interview einer ehemaligen Amazon-Managerin herumgereicht,2 in dem diese betont, dass das Geheimnis der Agilität in dieser Firma darin liege, keine grossen, jahrelang dauernden Veränderungsprogramme zu starten sondern nur einzelne kleine, und auch die vor allem mit Focus auf Mindset und Achtsamkeit. Das klingt gut und bedient auch ein in der agilen Community beliebtes Narrativ, es ist aber leider inhaltlich falsch.


Wer sich mit der Geschichte von Amazon beschäftigt (z.B. hier und hier) wird das genaue Gegenteil entdecken. Um das Jahr 2000 herum war das Unternehmen durch schnelles Wachstum gross und eher träge geworden, weshalb es (Surprise!) ein grosses, mehrere Jahre dauerndes Veränderungsprogramm startete. Vieles von dem was heute seine Agilität ausmacht (kleine, empowerte Teams mit Verantwortung über klar abgegrenzte Services mit klar definierten Schnittstellen zu anderen Teams) entstand damals.


Die Frage die sich jetzt stellt: wie konnte es angesichts dieser Vergangenheit zu einer derartigen Falsch-Einschätzung der besagten Amazon-Managerin kommen? Die vermutliche Antwort: sie war Opfer einer Wahrnehmungs-Verzerrung die man "Post-Transformation Bias" nennen könnte. Als sie Amazon kennenlernte wird Change Management dort durch viele kleine Massnahmen üblich gewesen sein, dass das aber nur aufgrund eines früheren Grossprogramms möglich war wurde ihr aber nicht erzählt.


Dieses Muster kann man bei Unternehmen mit gut funktionierenden Prozessen immer wieder antreffen. In Unkenntnis der Existenz oder der Tragweite vergangener Umorganisationen wird der durch sie möglich gewordene leichtgewichtige und flexible Arbeitsmodus selbst für das Erfolgsgeheimnis gehalten, selbst wenn die vorgelagerten Weichenstellungen viel wichtiger und entscheidender gewesen sind. Schlimmstenfalls kann diese Fehlannahme sogar ins kollektive Gedächtnis der Firma übergehen.


Aufgrund dessen ist es ratsam dem verlockenden Gedanken nicht nachzugeben, Erfahrungsberichte aus vorbildhaft agil arbeitenden Firmen zum wesentlichen Input für die eigenen Veränderungsprogramme zu machen. Im Zweifel überträgt man auf diese Weise nur den dort vorhandenen Post-Transformation Bias auf sich selbst, mit ausbleibenden Erfolgen als Folge.



1Genauer gesagt, ich möchte einen Grund aufzeigen, es gibt natürlich noch weitere
2Hier nicht verlinkt, da ich sie nicht an den Pranger stellen möchte

Donnerstag, 16. Februar 2023

User Story Mapping einfach erklärt

Youtube ist und bleibt eine Fundgrube für die bemerkenswertesten Dinge. Das heutige Fundstück ist ein Video eines weitgehend unbekannten E-Learning-Anbieters namens Bean Stalk, der auf wunderbar nachvollziehbare Art und Weise das Konzept des User Story Mappings erklärt.



Was mir beim Ansehen auffällt - ich muss unbedingt wieder meine Visualisierungs-Fähigkeiten trainieren. Vor Corona hätte ich ein ähnliches wachsendes Gemälde wie das im Video auch hinbekommen, nach drei Jahren Miro-Nutzung ist dieses Talent aber etwas eingerostet.

Montag, 13. Februar 2023

Sagen, was schiefläuft

Bild: Pxhere - CC0 1.0

Die besten Lerneffekte erziehlt man erfahrungsgemäss dort wo man es nicht erwartet hätte. In diesem Sinn begeben wir uns jetzt auf die Reise an einen Ort an dem Veränderungs-Kommunikation auf ungewöhnliche und dennoch vorbildliche Art und Weise stattfindet. Wir steigen gedanklich ein in einen Zug der Deutschen Bahn und erinnern uns an etwas das jeder Zuggast schon zigfach erlebt hat: die Verspätungs-Durchsagen.


Warum die mittlerweile bemerkens- und erwähnenswert sind erschliesst sich vor allem dann wenn man bedenkt wie sie früher einmal waren. Bis vor wenigen Jahren eher nichtssagend und abstrakt, ohne einen wirklichen Informationswert. Ein Klassiker den noch jeder in Erinnerung haben dürfte sind die Verspätungen wegen "Störungen im Betriebsablauf", auch "Technische Probleme" kamen immer wieder vor. Was im Einzelen damit gemaint war blieb unklar.


Wer schon einmal beruflich mit der Kommunikation ungeplanter Veränderung zu tun hatte kann sich vorstellen was die Beweggründe für diese Art der Information gewesen sein werden. Die Betroffenen sollen nicht durch zu viele Details verwirrt oder durch die Nennung von Problemen verunsichert werden, eine Qualitätssicherung detaillierterer Informationen wäre aufgrund der Menge nicht machbar, eine dezentrale Kommunikation ohne Qualitätssicherung wäre ein Verlust der "Message Control", etc.


Das alles ist nachvollziehbar, führt aber zu einem Problem: die Betroffenen haben (zu Recht) das Gefühl, dass Informationen vor ihnen zurückgehalten werden, kennen aber die Gründe dafür nicht. Da sie die "professionellen Bedenken" gegen offene Kommunikation nicht kennen beginnen sie irgendwann unschöne Beweggründe zu unterstellen, etwa bösartig gewollte Intransparenz oder den Versuch grössere Probleme zu vertuschen. Misstrauen kommt auf und Konflikte entstehen.


Zurück zur Deutschen Bahn. Seit einiger Zeit sind deren Verspätungs-Durchsagen anders geworden. Sie nennen Probleme beim Namen, vom anderen Zug der Vorfahrt hat über den Polizeieinsatz auf den Gleisen bis hin zum Bordbistro, das geschlossen ist weil das Personal selbst in einem verspäteten Zug sitzt. Und wenn das Zugpersonal selber auch nicht weiss warum die Fahrt nicht weitergehen darf wird sogar das in aller Offenheit zugegeben.



Das erste Problem ist damit gelöst, die Fahrgäste sind nicht mehr im Ungewissen über das was gerade passiert, die Probleme erscheinen greifbarer und es lässt sich abschätzen zu wieviel Verzögerung der jeweilige Vorfall wohl führen wird. Das durch intransparente Kommunikation früher oft aufgekommene Misstrauen entsteht nicht mehr und kann auch nicht mehr zu Konflikten zwischen Personal und den Fahrgästen führen, die verlangen endlich informiert zu werden.


Aber bleibt nicht das zweite Problem, das der fehlenden Message Control? Ist es jetzt nicht so, dass die nicht in diplomatischer Kommunikation geschulten Schaffner und Zugführer die Informationen mitunter unsensibel, ruppig oder spürbar frustriert übermitteln? Kurz gesagt: ja es ist so, dass das immer wieder vorkommt, ein Problem ist es aber nicht. Tatsächlich kommt diese authentische Kommunikation so gut an, dass sich im Internet Best of-Sammlungen finden. Einige Beispiele:






Was professionelle Change-Kommunikation von der Deutschen Bahn lernen kann dürfte offensichtlich sein: wenn es nicht läuft wie geplant ist es keine gute Idee Informationen zurückzuhalten. Stattdessen offen, authentisch und in normaler Spache zu kommunizieren welche Probleme es gibt, was man selbst weiss und was nicht, ist dagegen sehr zu empfehlen. Das gilt auch und gerade dann wenn davon auszugehen ist, dass diese Informationen nicht auf Begeisterung stossen werden.


Wer sich dagegen entscheiden und weiter intransparent kommunizieren will sollte sich überlegen bei der Bahn nachzufragen wie das bei denen geklappt hat. Spoiler: nicht besonders gut. Das war schliesslich auch der Grund dafür, dass dort die Art der Kommunikation umgestellt wurde.

Donnerstag, 9. Februar 2023

Agile HR (II)

Bild: Unsplash / Jason Goodman - Lizenz

Agile Arbeitsweisen auf Bereiche ausserhalb der Produktentwicklung übertragen zu wollen trifft immer wieder auf die gleichen Widersprüche: das wäre doch etwas ganz Anderes, heisst es regelmässig, die Rahmenbedingungen und Arbeitsgegenstände wären völlig unterschiedlich, das könne man doch nicht gleich behandeln, etc. Dass die Gemeinsamkeiten grösser sind als von vielen gedacht kann man aber an Beispielen aufzeigen, z.B. im Bereich agile HR.


Auch Human Ressources hat ein Produkt (oder eine Dienstleistung), nämlich Bereitstellung von allem was zur Gewinnung, Bindung, Organisation, Entlohnung und Qualifizierung von Personal notwendig ist. Der Kunde, bzw. die Zielgruppe ist dabei das Personal selbst,1 das durch das sich Anstellen Lassen, den Verbleib oder die Kündigung dafür sorgt, dass auch hier ein Markt mit Angebot und Nachfrage entsteht, auf dem sich das durch HR vertretene Unternehmen behaupten muss.


Vor allem in grossen Unternehmen ist dieses HR-Produkt dabei oft von hinterfragbarer Qualität. Obwohl gut gemeint und mit nicht unerheblichem Aufwand erstellt wird es von den Angestellten häufig als nicht den Bedürfnissen entsprechend, sich nicht den Gegebenheiten anpassend und nur hinter bürokratischen Hürden erreichbar wahrgenommen. Die HR-Dienstleistungen schnell und unbürokratisch (🡒 agil) an Zielgruppenwünsche anzupassen sollte in Zeiten des Fachkräftemangels daher ein Ziel sein.


Die Änderungen die man zu diesem Zweck vornehmen kann sind denen in der Produktentwicklung sehr ähnlich. Ein in beiden Bereichen vorzufindender Klassiker ist zum Beispiel die Umstellung von Komponenten- oder Spezialistenteams auf crossfunktionale Teams, die möglichst viele Teile der HR-Dienstleistungen selbst erbringen können. Diese müssen dann nicht mehr ständig auf die Zulieferung anderer Spezialistenteams warten und werden alleine dadurch flexibler und schneller.


Aber ist eine klassische HR-Einheit denn wirklich Komponenten- oder Spezialisten-basiert aufgestellt? Bei näherer Betrachtung definitiv. Recruiting, Onboarding, Career Development, Compensation, Learning and Development, Diversity Management und Change Management bilden fast überall klar von einander abgegrenzte organisatorische Silos, die jedes für sich nur eine Teilleistung erbringen und mit den jeweils anderen nur mittelgut abgestimmt sind (mit Langsamkeit, Bürokratie und schlechter Qualität als Folge).


Eine Möglichkeit es besser zu machen wären gemischte Vollzeit-Teams, von denen jedes einzelne möglichst alle Aspekte der HR-Tätigkeiten abdecken kann. Und überall dort wo diese Tätigkeiten für viele Menschen erbracht werden müssen kann die Skalierung nicht nur durch Aufspaltung in Spezialistenteams erfolgen, sondern genau so gut dadurch, dass den Zielgruppen-Einheiten (Ressorts, Abteilungen, o.ä.) jeweils ein crossfunktionales HR-Team zugeordnet wird.


Ist eine solche Umstellung anspruchsvoll und anstrengend? In vielen Fällen ja. Ist die Sicherstellung übergreifend gleicher Qualitätsstandards eine Herausforderung? Definitiv. Wird die Umstellung von Hoch-Spezialisierung auf das in diesem Kontext nötige T-Shape-Profil allen HR-Fachkräften leicht fallen? Mit an Sicherheit grenzender Wahrscheinlichkeit nicht. Und ist all das nicht eine gute Begründung dafür, crossfunktionale, agile HR-Teams doch nicht anzustreben? Nein, ist sie nicht. Die Idee ist und bleibt gut.


In der Produktentwicklung sind all diese Herausforderungen schliesslich auch gegeben, und trotzdem wurde dort wieder und wieder der Beweis erbracht, dass kleine, crossfunktionale, agil arbeitende Vollzeit-Teams die ideale Organisationsform sind um den Bedürfnissen entsprechende, an sich ändernde Gegebenheiten anpassbare und unbürokratisch erbrachte Produkte und Dienstleistungen zu erstellen. Und damit kommen wir zurück zum Anfang.


Bei genauer Betrachtung sind die die Gemeinsamkeiten von Produktentwicklung und HR grösserals man im ersten Gedanken annehmen würde, und selbst wenn das agile Arbeiten ursprünglich explizit für die Produktentwicklung erfunden wurde ist eine Übertragung sowohl machbar als auch sinnvoll. Man muss nur bereit sein sich darauf einzulassen.


1Eine zweite, ganz andere Kunden- bzw. Zielgruppe ist das Unternehmen selbst.

Montag, 6. Februar 2023

Waiting und Blocked

Bild: Flickr /  Brian Beggerly - CC BY 2.0

Manche Begriffe im Umfeld von Agile und Lean sind sich in ihrer Bedeutung so ähnlich, dass sie immer wieder verwechselt werden, selbst wenn es bei genauerem Hinsehen doch deutliche Unterschiede gibt. Zwei bei denen das immer wieder der Fall ist sind Waiting und Blocked, zwei Zustände die gemeinsam haben, dass nicht an einem Arbeitsgegenstand gearbeitet werden kann wenn er von ihnen betroffen ist. Die Gründe dahinter sind allerdings verschiedene.


Von Waiting (Wartend) ist die Rede wenn alle Fertigkeiten, Genehmigungen und Berechtigungen vorhanden sind die benötigt werden um mit der Umsetzung eines Arbeitspaketes zu beginnen, es aber nicht dazu kommt weil andere gerade wichtiger sind oder schon länger darauf warten, dass mit ihnen begonnen wird. Worauf diese Priorisierungs- und Reihenfolgen-Entscheidungen beruhen ist dabei unwichtig, wichtig ist nur, dass der Status Waiting auf einer selbst getroffenen Entscheidung beruht.


Der Status Blocked (Blockiert) ist dagegen gegeben wenn nicht mit der Umsetzung eines Arbeitspaketes begonnen werden kann weil externe Zulieferungen fehlen oder extern zu vergebende Genehmigungen oder Berechtigungen nicht vorliegen. Unabhängig davon woher diese Zulieferungen, Genehmigungen oder Berechtigungen kommen müssten ist wichtig, dass es sich dabei um eine aussenstehende Einheit handelt, der man nicht selber angehört.


Warum das von Bedeutung ist? Weil die dadurch notwendigen Massnahmen jeweils andere sind. Um Wartezeiten zu reduzieren kann man z.B. versuchen effizienter zu werden (nicht wertschöpfende Tätigkeiten zu unterlassen) oder effektiver zu werden (nur noch an relevanten Zielen zu arbeiten), alternativ kann man das eigene Team (und damit die eigene Arbeitskapazität) aufstocken. All das führt zu schnellerer Erledigung und weniger Warten.


Blockaden werden dagegen reduziert indem entweder die Einheiten von denen man abhängig ist optimiert oder reguliert werden (letzteres z.B. durch vereinbarte zeitliche Obergrenzen für Zulieferungen) oder indem der eigenen Einheit zu den Befähigungen, Genehmigungen oder Berechtigungen verholfen wird deren Fehlen vorher zu den äusseren Abhängigkeiten geführt hat. Um das gängige Schlagwort zu benutzen: das eigene Team muss crossfunktional werden.


Diese unterschiedliche Art der notwendigen Massnahmen macht es schliesslich nötig, dass diese beiden unterschiedlichen Verzögerungstypen auch unterschiedlich kenntlich gemacht und separat gezählt werden, wird das nicht getan ist unklar welches Problem vorliegt und welcher Lösungsweg gegangen werden sollte. Um es mit einem häufigen Antipattern zu erklären: wer auf allem was sich auf dem Board nicht bewegt ein Stopschild-Icon anbringt vermengt die beiden Typen und tut sich selbst keinen Gefallen.


Zielführender sind separate Markierungen, z.B. ein oranger Punkt für jeden Tag an dem ein Arbeitspaket im Status Waiting ist und ein roter Punkt für jeden Tag an dem es sich im Status Blocked befindet. Dadurch sind beide klar unterscheidbar und unterschiedlich behandelbar. Und wer eine Zeit lang so vorgegangen ist wird den Unterschied zwischen Waiting und Blocked so gut kennen, dass es zu keinen weiteren Verwechselungen mehr kommen kann.

Freitag, 3. Februar 2023

Scaled Agile: Release Trains (II)

Bild: Pixabay / Annca Pictures - Lizenz

Die grosse Skepsis mit der die agile Community SAFe betrachtet hat dazu geführt, dass auch viele der mit diesem Skalierungs-Framework in Verbindung gebrachten Ideen abgelehnt werden. Das ist in den meisten Fällen bedauerlich, schliesslich wurde fast nichts von SAFe selbst erfunden sondern so gut wie alles aus anderen Kontexten übernommen, in denen die Umsetzung deutlich näher am agilen Idealbild war. Ein Beispiel an dem man das gut nachvollziehbar machen kann ist der Release Train.


In seinem Kern beruht dieses Konzept auf einer frühen Vor-Form von Continuous Delivery. Die ursprünglich üblichen Quartals- oder Jahres-Releases sollten vermieden werden, gleichzeitig waren automatisierte Build Pipelines und Continuous Integration zum Entstehungszeitpunkt der Release Train-Idee noch wenig verbreitet. Die Lösung für dieses Problem waren regelmässige (wöchentliche oder monatliche) Releases, die jeweils alles enthielten was zu diesem Zeitpunkt fertig entwickelt war.


In diesen regelmässigen Releases waren verschiedene relativ langwierige Vorgänge enthalten, die nicht unterbrochen oder übersprungen werden durften wenn die Qualität des Ergebnisses sichergestellt sein sollte, etwa das Konfigurieren von Staging-Umgebungen, das Einspielen von Testdaten, das Durchführen automatisierter und manueller Tests, etc. Für alle Features die zum Release-Zeitpunkt noch nicht fertig entwickelt waren war daher "der Zug abgefahren". Aus diesem Bild entstand dann die Benennung.


Aus heutiger Sicht erscheint das alles nur eingeschränkt agil (die aktuelle Benchmark sind beliebig viele Releases pro Tag), in der damaligen Zeit (frühe 2000er Jahre) war es dagegen revolutionär und verhalf Unternehmen wie Yahoo, Netscape, AOL, eBay und Google zu ihren damals marktbeherrschenden Positionierungen. Es gibt Vermutungen, dass Release Trains ursprünglich von eBay erfunden wurden, wozu passen würde, dass zu den frühesten Quellen der ehemalige eBay-Manager Marty Cagan gehört.


In bestimmten Konstellationen können Release Trains sogar heute noch Sinn machen, z.B. überall dort wo Regressionstests mehrere Stunden oder Tage dauern können (ein typischer derartiger Fall wäre die Embedded Software von autonomen Fahrzeugen oder Robotern, deren Testzyklus-Dauer durch die maximale Fahrtgeschwindigkeit und durch die Menge der möglichen Navigations-Manöver bestimmt wird und dadurch ggf. sehr lange sein kann).


Interessant und kontrovers ist schliesslich die Frage ob es in Release Trains spezifische Management-Rollen geben sollte. Im oben verlinkten Marty Cagan-Artikel aus dem Jahr 2007 ist allgemein von Projektmanagern und spezifisch von der Rolle des so genannten Conductor (Schaffner) die Rede, in SAFe gibt es den Release Train Engineer (Lokführer). Aus einer "agilen Perspektive" sollte man den beteiligten Teams dagegen zutrauen sich unkompliziert selbst zu koordinieren.


Leider drehen sich mittlerweile die meisten Release Train-Diskussionen nur noch um diesen Aspekt, bis zu dem Punkt, dass (SAFe-) Release-Trains heute primär über ihre Koordinations-Rollen und -strukturen definiert (und wegen ihnen abgelehnt) werden. In den Vordergrund zu stellen wie die Idee eigentlich gemeint ist könnte dabei helfen die Debatten wieder fokussierter und zielführender zu machen.