Donnerstag, 27. Januar 2022

Stacey Matrix (III)

Ich möchte noch einmal über die Stacey Matrix sprechen. Diesesmal nicht darüber was sie ist und wofür sie meistens benutzt wird und auch nicht darüber, dass sie ursprünglich ganz anders aussah als auf den mittlerweile üblichen Darstellungen. Beides habe ich an anderer Stelle bereits gemacht (siehe hier und hier). Heute möchte ich eine weitere Einsatzmöglichkeit aufzeigen, und zwar eine die zwar wichtig ist aber leider noch zu selten genutzt wird.


Um mit der Problemstellung zu beginnen: sehr häufig wird die Stacey-Matrix eingesetzt um Vorhaben oder Herausforderungen in eine der vier Kategorien (Einfach, kompliziert, komplex, chaotisch) einzusortieren und sie dann lagfristig dort stehenzulassen (meistens verbunden mit der Auswahl eines jeweils passenden methodischen Ansatzes). Das entspricht allerdings im Normalfall nicht der Realität, in der sich früher oder später alles von der Position wegbewegt in die es einsortiert wurde.1


Darüber hinaus (und jetzt kommt der eigentliche Punkt) erfolgt diese Bewegung im Normalfall nicht in irgendeine Richtung sondern fast immer in die selbe: nach rechts oben. Praktisch jedes Vorhaben in mittleren oder grossen Organisationen wird über die Zeit immer komplizierter, komplexer und chaotischer, bis zu dem Punkt an dem es ohne Gegensteuerung ins Unbeherrschbare abkippt. Und sobald man sich Beispiele dafür ansieht wird auch nachvollziehbar warum das so ist.


Bei einfachen Vorhaben oder Herausforderungen ist eine häufige Ursache die Automatisierung. Die ist im einfachen Bereich richtig und wichtig, was oft übersehen wird ist aber, dass die dafür nötige Hard- und Software mindestens kompliziert, im Zweifel sogar komplex ist. Da sie aber untrennbar mit ihrem Durchführungs-Gegenstand verbunden ist kann auch dieser nicht mehr einfach sein. Eine andere Ursache ist das Outsourcing, das alleine durch Verträge und Zahlungsströme kompliziert werden muss.


Auch im komplizierten Bereich sind es eine eigentlich richtige Massnahmen die zum Abrutschen in die Komplexität führen: die Normierung und Standardisierung vergleichbarer Tätigkeiten sowie ihre Optimierung und Beschleunigung. Ab einem bestimmten Punkt ist der Regulierungsumfang so hoch und die Durchführungsgeschwindigkeit so schnell, dass sich nicht mehr rechtzeitig nachverfolgen lässt welcher Prozess gerade in Kraft tritt oder in Kraft treten müsste. Kleine Kontrollverluste häufen sich.


Dort wo es komplex ist greifen schliesslich zwei Effekte ineinander: das hier sehr effektive Inspect & Adapt führt versehentlich immer wieder zu einem Vorrang kurzfristiger und lokaler Lösungen vor langfristigen und grösseren. Der Reflex das durch übergreifende Kontroll- oder Verwaltungsstrukturen kompensieren zu wollen führt dann ins Chaos -  die Organisation wird schwerfällig und kann nicht mehr rechtzeitig auf die ständigen Störungen und Disruptionen reagieren. Es kommt zum grossen Kontrollverlust.


All das kann man wunderbar anhand der Stacey Matrix erklären, sei es indem man Post-Its oder digitale Kacheln von links unten nach rechts oben wandern lässt oder indem man die Dynamik durch Pfeile darstellt. Und wer eine mittlere oder grosse Organisation auch nur ein bisschen kennengelernt hat wird zahlreiche Beispiele nennen können mit denen sich der Einwand "so etwas würden wir doch niemals bei uns zulassen" widerlegen lässt.


Das Fatale an der so beschriebenen Situation ist, dass sie in einer Zwickmühle endet. Auf der einen Seite führen die an sich richtigen Optimierungsbemühungen früher über später über den Kipp-Punkt hinaus an dem aus Verbesserungen Verschlimmbesserungen werden, auf der anderen Seite führt seine unklare Position dazu, dass ab einem bestimmten Optimierungsgrad Ineffizienz und Ineffektivität nicht mehr weiter beseitigt werden können, wenn man sicher sein will nicht versehentlich zu weit zu gehen.2


Die einzige Möglichkeit mit der sich ein Abkippen in eine dieser beiden Dysfunktionen vermeiden lässt ist die Anwendung von agilen Entwicklungspraktiken auch auf die Organisationsentwicklung selbst. In einem kontinuierlichen, niemals endenden Prozess muss regelmässig überprüft werden ob sich alles noch in der "goldenen Mitte" zwischen Verbesserung und Verschlimmbesserung befindet. Nur so entsteht in der Stacey Matrix-Visualisierung wieder die ausgleichende Bewegung nach links unten.


An dieser Stelle fällt auch einer der am weitesten verbreiteten "agilen Mythen" in sich zusammen: der Mythos, dass der Scrum Master, bzw. Agile Coach sich irgendwann selbst überflüssig macht. Zwar gibt es Teams die in der Lage sind selbst gegen den Sog nach rechts oben zu arbeiten, zu viele verlieren sich aber früher oder später in Routinen, Termindruck und Bestätigungsfehlern - sie brauchen jemanden der ausserhalb des Hamsterrades steht, und hilft dauerhaft gegen diese Strömung zu arbeiten.


Wie zu Beginn gesagt, die Stacey Matrix wird nur selten für die hier genannten Erklärungen eingesetzt. Ich kann nur empfehlen es trotzdem zu tun, denn meiner Meinung nach entfaltet sie nur so ihre volle Wirkung und zeigt den Bedarf nach agilem Vorgehen und agilen Prozessbegleitern auf, die für eine erfolgreiche Organisationsentwicklung in einer sich ständig ändernden Welt nötig sind.



1Wie man so schön sagt: πάντα ῥεῖ
2Dass diese Position nicht festzustellen ist liegt daran, dass auch sie von verschiedenen Faktoren beeinflusst wird und sich ständig verlagert

Montag, 24. Januar 2022

Agile Governance (III)

Das Thema der Governance in einem agil arbeitenden Umfeld ist noch immer eine der grossen Herausforderungen für nahezu alle Teams und Unternehmen. In diesem Vortrag bringt Sanjiv Augustine auf den Punkt warum es so schwer ist: komplexe Regeln führen zu Passivität und nachlassender Eigeninitiative, sie nicht komplex zu gestalten ist aber anspruchsvoll. Sein Lösungsansatz enthält mit Portfolio-Kanban, Skalierungsframeworks und OKRs bekannte Ansätze, mit dem "Value Management Office" (VMO) aber auch eine neue Idee von der man sich inspirieren lassen kann.



Apropos neu: mit dem "License Raj" führt Augustine einen Begriff ein der sich gut in den immer häufiger werdenden Projekten mit indischen Beteiligten einsetzen lässt. Sinngemäss übersetzt ist es die Bürokratenherrschaft, würtlich übersetzt das fast schon poetische "Königreich der Genehmigungen".

Freitag, 21. Januar 2022

Pasta-shaped Teams

Bild: Wikimedia Commons / Popo le Chien - CC0 1.0

Bei der Vermittlung komplexer oder komplizierter Inhalte geht nichts über eine bildhafte Sprache. Dinge die man sonst nur schwer im Gedächtnis behalten könnte werden auf diese Weise gleich doppelt in den Erinnerungen verankert, sowohl in Wort- als auch in Bildform. Wenn es dann noch gelingt Metaphern zu finden die ungewöhnlich oder kreativ sind werden diese im Zweifel sogar bereitwillig weitererzählt und gelangen so dauerhaft in ein kollektives Gedächtnis.


Eines der bekanntesten Beispiele dafür ist The evolution of software architecture - Italian food perspective (siehe hier). In ihm werden verschiedene Paradigmen der Software-Architektur dadurch nachvollziehbar gemacht, dass sie mit italienischen Nudelgerichten verglichen werden. Schon lange trage ich den Gedanken mit mir herum, dass sich diese Bildsprache auch auf die Typologie von Entwicklungsteams anwenden lässt. Gedacht, gemacht! Hier kommen sie, die Pasta-shaped Teams.


Bild: Pixabay / Salahgraphic - CC0 1.0

Der erste Team-Typ sind die Spaghetti-Teams. Charakterisiert sind sie dadurch, dass ihre einzelnen Mitglieder sehr lange an sehr schmal geschnittenen Aufgaben sitzen, wodurch es ihnen schwerfällt ihren gemeinsamen Inhalt (symbolisiert durch das Ragù Bolognese) zusammenzuhalten. Spricht man mit den Mitgliedern findet man immer wieder lange Enden die irgendwohin führen, im Zweifel in Legacy-Tätigkeiten wo noch "Restaufwände" zu erledigen sind. Alles wirkt irgendwie unordentlich.


Bild: Wikimedia Commons / PoiseWinsTitles - CC BY 2.0

Lasagne-Teams bringen schon etwas mehr Ordnung zusammen, indem sie sich in Schichten organisieren (z.B. Frontend, Middleware, Backend). Das beseitigt zwar das gröbste Durcheinander, allerdings besteht das Risiko, dass die Schichten aufeinander verrutschen und nicht mehr genau aufeinanderpassen wenn man versucht handhabbare Teile abzutrennen. Und in alle seitlichen Richtungen laufen die Inhalte in die Breite um sich mit allem zu vermischen was daneben liegt.


Bild: Wikimedia Commons / Alpha - CC BY-SA 2.0

Cannelloni-Teams gehen noch einen Schritt weiter. Der Inhalt ist bereits von überschaubarer Grösse und wird ausserdem durch eine feste Hülle zusammengehalten, die es einfacher macht einzelne Einheiten unabhängig von den anderen zu bewegen. Es besteht auch nicht mehr die Gefahr, dass die Inhalte an den Seiten mit anderen ineinanderfliessen - zumindest nicht an allen. Vorne und hinten gibt es noch offene Stellen, z.B. bei Konzeption oder Betrieb. Hier können sich noch wertvolle Teile der Kontrolle entziehen.


Bild: Wikimedia Commons / Cyclone Bill - CC BY-SA 2.0

Diesen Kontrollverlust haben Ravioli-Teams nicht mehr. Die Inhalte werden auf allen Seiten zusammengehalten, jedes einzelne Objekt ist damit für sich genommen vollständig und servierbereit. Die entsprechende Organisationsform wäre das crossfunktionale Team, das keine Abhängigkeiten nach Aussen mehr hat. Allerdings: das Ganze ist dadurch so gross und unhandlich, dass es am Ende zerteilt werden muss und dann doch wieder offene Seiten hat, die kaum zusammenzuhalten sind.


Bild: CCNull / Marco Verch - CC BY 2.0

Gelöst wird auch diese letzte Herausforderung schliesslich durch die Tortellini-Teams. Alles was auf die Ravioli-Teams zutrifft, trifft auch auf sie zu - mit einer weiteren Verbesserung: es ist gelungen sie auf eine so kleine Grösse zu bringen, dass sie bis zum Schluss nicht aufgeteilt werden müssen. Das Äquivalent wäre z.B. ein mit Microservices arbeitendes Feature-Team. Die Kontrolle über die Inhalte ist hier am grössten, die potentielle Unordnung am geringsten.


Und das sind sie, die Pasta-shaped Teams in ihrer ganzen Vielfalt. Dass aus einer "agilen Perspektive" die Ravioli- und Tortellini-Teams den anderen zu bevorzugen sind dürfte klar sein, in der Realität dürften die meisten agil arbeitenden Teams allerdings eher Cannelloni-artig sein. Letztendlich gilt aber, dass jede Variante besser ist als die jeweils vor ihr genannten. Auch ein Lasagne-Team kann im Vergleich zu einem Spaghetti-Team ein Fortschritt sein.


Um die Idee weiterzuspinnen: sogar ein Maturity-Model für Teams liese sich aus den Pasta-Formen ableiten, anhand dessen man erkennen kann an welchen Stellen die Organisation noch weiterentwickelt werden muss. Denn bei den Teamschnitten die eine Organisation ausprobiert ist es wie bei den Nudelgerichten die ein Mensch in seiner Kindheit nach und nach kennenlernt: am Anfang stehen immer die Spaghetti, das ist quasi ein Naturgesetz.

Dienstag, 18. Januar 2022

Das agile Manifest und die 'agilen Werte'

Quelle: agilemanifesto.org

Es ist mal wieder Zeit für eine steile These, und diesesmal für eine die ans Eingemachte geht: ich glaube, dass es bei der Übertragung des Manifest für agile Softwareentwicklung aus dem Englischen in Deutsche eine missverständliche Übersetzung gegeben hat. Und nicht nur das - ich glaube, dass sich hier (im deutschsprachigen Raum) durch diese Übersetzung ein tendenziell anderes Verständnis von Agilität entwickelt hat als in englischsprachigen Ländern, in denen das Original verstanden werden kann.


Bevor ich näher ausführe wie ich zu dieser These komme möchte ich eines vorwegschicken: es ist nicht meine Absicht die Übersetzer auf einer persönlichen Ebene anzugreifen, dass sie diese Arbeit auf sich genommen haben verdient Dank und Respekt. Und ich bin sicher, dass die Übersetzung mit den besten Absichten erfolgt ist und z.T. einfach das Ergebnis von Sachzwängen sein dürfte, alleine um prägnant zu sein und um die Formatierung des englischen Originals beibehalten zu können.


Um zu zeigen warum ich trotzdem glaube, dass die deutsche Version in ihrem Inhalt von der englischen abweicht, möchte ich zuerst die beiden nebeneinander halten, angefangen mit dem englischen Original von 2001.


We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.


Und hier ist die offizielle deutsche Übersetzung von 2010, die laut Fussnote (ganz unten auf der Seite) von einer ganzen Übersetzer-Gruppe vorgenommen und auf mehreren Konferenzen und Meetups verfeinert worden ist.


Wir erschließen bessere Wege, Software zu entwickeln,
indem wir es selbst tun und anderen dabei helfen.
Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

Individuen und Interaktionen mehr als Prozesse und Werkzeuge
Funktionierende Software mehr als umfassende Dokumentation
Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
Reagieren auf Veränderung mehr als das Befolgen eines Plans

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden,
schätzen wir die Werte auf der linken Seite höher ein.


Auf den ersten Blick eine sehr genaue Übersetzung, auf den zweiten Blick kann aber auffallen, dass es einen Begriff gibt der im Englischen anders verwandt wird als im Deutschen: es sind die Values, bzw. Werte, samt der aus ihnen abgeleiteten (oder eben nicht abgeleiteten) Verben. Auch der Aufbau der Sätze in die diese Worte eingebettet sind ist in beiden Sprachen ein anderer. Und diese Unterschiede sind wichtiger als man denken könnte.


Gehen wir ins Detail: "we have come to value" heisst es in der dritten Zeile des Originals und "wir [haben] diese Werte zu schätzen gelernt" in der Übersetzung - das ist aber nicht das Selbe. Eine sinngemässe Übersetzung der englischen Zeile wäre etwa "wir finden Folgendes wichtig" oder "wir wertschätzen Folgendes" (die wörtliche Übersetzung der ganze Zeile wäre noch sperriger), von der Existenz von Werten ist im englischen Original nicht die Rede.


Auch weiter unten im Text gibt es einen inhaltlichen Unterschied zwischen den beiden Versionen: "while there is value in the items on the right" heisst es in Zeile acht im Englischen und "obwohl wir die Werte auf der rechten Seite wichtig finden" im Deutschen. Eine sinngemässe Übersetzung des Originals wäre etwa "obwohl wir in den Handlungsmustern auf der Rechten einen Wert erkennen" (auch hier wäre eine wörtliche Übersetzung sperrig). "Ein Wert sein"  und "einen Wert haben" sind aber zwei sich stark voneinander unterscheidende Konzepte, selbst wenn sie ähnlich klingen.


In Zeile neun entsprechen die Begriffe wieder weitgehend denen in der dritten Zeile. Das englische "we value the items on the left more" bedeutet sinngemäss "wir schätzen die Handlungsmuster auf der linken Seite mehr", die offizielle Übersetzung lautet dagegen "wir [schätzen] die Werte auf der linken Seite höher ein". Auch an dieser Stelle enthält die englische Originalfassung den Begriff des Werts nicht (lediglich das in seiner Bedeutung andere Verb [to] value), die Übersetzung schon.


Um die Unterschiede weiter herauszuarbeiten: im englischen Ursprungstext steckt in dem zuerst und zuletzt genannten "[to] value" eine Güterabwägung und in "there is value in ..." eine rational-wirtschaftliche Betrachtung. Beides ist eher sachlich und nüchtern. Der im deutschen Text an beiden Stellen zu findende "Wert" wirkt dagegen in seinem grammatischen Kontext wie eine Wertvorstellung, und eine Wertvorstellung ist etwas das anzustreben ist weil es aus moralischer Sicht richtig ist.


An dieser Stelle wird auch das Problem erkennbar: während bei der im Englischen gegebenen rationalen Formulierung Abwägungen und Entgegenkommen naheliegend und sogar fast zwingend sind ist die normativ-moralisch wirkende deutsche Übersetzung deutlich polarisierender. Wertvorstellungen lassen Richtig und Falsch zu, keinen Mittelweg. Besonders im letzten Absatz ist das spürbar - im Englischen liest er sich wie ein Kompromiss während er im Deutschen eine eher dualistische Gegenüberstellung ist.


Aufgrund dieser voneinander abweichenden Inhalte ist deutschen Sprachraum eine dogmatisch-kategorische Auslegung dessen was Agilität ist einfacher machbar als im englischen, in dem der Originaltext eher eine pragmatische Sichtweise fördert. Und dass diese strikte Auslegung sich auch (scheinbar) mit dem agilen Manifest begründen lässt kann zu Schwarz-Weiss-Denken und Konfrontationen verleiten, die dann Veränderungen unnötig schwer machen können.


Um nochmal auf den Disclaimer vom Anfang zurückzukommen: ich gehe fest davon aus, dass die deutschen Übersetzer des agilen Manifests diese Missverständlichkeit nicht beabsichtigt und vermutlich auch nicht wahrgenommen haben, in der Praxis findet man ihre Folgen aber immer wieder. Dort wo es möglich ist verwende ich daher immer das englische Original, und dort wo dieses nicht verstanden wird füge ich der Übersetzung einen "Beipackzettel" hinzu um Missverständnisse zu vermeiden.

Donnerstag, 13. Januar 2022

Ein neues agiles Framework: das Unfix Model

Bild: Unsplash / Marvin Meyer - CC0 1.0

Eigentlich könnte man denken, dass der Markt für agile Frameworks gesättigt ist. Auf Teamebene hat sich Scrum durchgesetzt, vor Kanban und mit weitem Abstand dahinter Extreme Programming, auf Ebene der Skalierungsframeworks liegen SAFe und das so genannte Spotify Model vorne, dahinter ebenfalls mit grossem Abstand die Scrum-Skalierungen LeSS, Nexus und Scrum@Scale sowie Flight Level-Kanban und Disciplined Agile. Zum ersten mal seit langem gab es in letzter Zeit aber neue Ansätze, 2021 das Fast Framework und Anfang 2022 ein noch neueres: das Unfix Model (zu finden hier).


Hinter diesem neuen Namen steckt Jurgen Appelo, der breiteren Öffentlichkeit als Erfinder von Management 3.0 bekannt, das er auch als eine der Inspirationen für sein neues Framework nennt. Die anderen sind das Spotify Model und die Bücher Dynamic Reteaming, Team Topologies und Turn the Ship around, aus denen er jeweils verschiedene Elemente übernommen hat. Erstmals vorgestellt wurde die Idee zu Unfix im Herbst 2021, der offizielle Start mit eigener Website und zusätzlichem Material war im folgenden Januar.


Zum Inhalt: die Grund-Einheit in Unfix ist die so genannte Base, eine Gruppe von bis zu 150 Menschen, die an einem gemeinsamen Produkt arbeiten und einen oder mehrere Chiefs als Vorgesetzte haben (je nach Gesamtgrösse, bei kleineren reicht einer). Eine Base muss alle für das Produkt nötigen Arbeiten selbst ausführen können, d.h. dafür qualifizierte Mitglieder haben. Feste Untergruppen existieren nicht, bei sehr arbeitsintensiven Produkten können aber mehrere Bases für jeweils ein Teilprodukt verantwortlich sein und zusammen eine so genannte Super-Base bilden.1


Innerhalb der Bases können bei Bedarf kleinere Untereinheiten von ca. fünf Personen temporär oder für längere Zeit gebildet werden, die so genannten Crews. Idealerweise sind es crossfunktionale und End to End-verantwortliche Value Stream Crews, ebenfalls möglich sind aber auch Facilitation Crews (aus Coaches und Trainern), Capability Crews (Komponenten-Teams), Governance Crews (aus mehreren Chiefs), Platform Crews (z.B. Infrastruktur), Experience Crews (Kunden- und Nutzerservice) und Acquisition Crews (Einkauf). Teilzeit-Mitgliedschaften in ihnen sind nicht wünschenswert aber möglich.


In den Crews tritt auch eine weitere Unfix-Rolle auf, der Captain, von denen es nur einen pro Crew geben darf. Je nach Ausgestaltung kann seine Rolle vergleichbar mit der eines Product Owners oder eines Themenverantwortlichen sein, wichtig ist nur, dass er in seinem Verantwortungsgebiet nicht weisungsgebunden ist und auch selbst kein Vorgesetzter anderer Base-Mitglieder ist. Er soll ihnen inhaltliche, aber keine disziplinarische Führung geben. Bei Bedarf können auch weitere fachliche oder technische Lead-Rollen eingeführt werden, die aber immer einem Captain zuarbeiten müssen.


Für die Koordination zwischen den einzelnen Crews existieren Querschnittseinheiten, die Forum genannt werden. Welche das sind kann je nach Bedarf entschieden werden, von technischen Standards bis hin zu organisatorischen Themen lässt sich für alles Denkbare ein Forum einrichten. Foren werden von einem Chair moderiert, sind in der Form ihrer Zusammenarbeit selbstorganisiert, nicht aber in der Themenauswahl. Sie werden durch die Chiefs gegründet und erhalten Arbeitsaufträge von den Captains. Wenn zwei Bases eine Super-Base bilden können gleichartige Foren ein Super-Forum bilden.



Das ist es, das Unfix Model. Wie Appelo selber schreibt ist eigentlich nichts davon neu, jedes Element findet sich unter irgendeinem Namen bereits in zahlreichen Unternehmen wieder. Sein Anspruch ist aber, alles zum ersten mal gebündelt und mit wiedererkennbaren Benennungen versehen zu haben. Und für alle die an einer Abgrenzung zu anderen Frameworks interessiert sind findet sich auf der Website ein Vergleich mit SAFe, LeSS und dem Spotify Model. Dem letzten dürfte Unfix auch am ähnlichsten sein, selbst wenn Appelo die bei ihm fehlende Matrix-Struktur als grundlegenden Unterschied sieht.2


Ob Unfix eine grössere Verbreitung finden wird bleibt abzuwarten, das Dynamic Reteaming in den Crews dürfte aber viele Unternehmen abschrecken. Andererseits hat es mit seinem Schöpfer ein international bekanntes und populäres Zugpferd, was zu einer schnellen Verbreitung beitragen könnte. Und was man nicht vergessen darf: am Anfang gab es auch grosse Skepsis gegenüber dem Spotify Model (zu alberne Namen) und gegenüber SAFe (viel zu kompliziert). Wir werden sehen wie es sich entwickelt.



1Wie bei den meisten agilen Frameworks gilt auch bei Unfix, dass es mit einer Terminologie verbunden ist die gewöhnungsbedürftig sein kann.
2Er leitet das daraus ab, dass bei ihm weder die Captains noch die Chairs disziplinarische Führung ausüben.

Montag, 10. Januar 2022

10 Jahre #NoEstimates (II)

Bild: Wikimedia Commons / U.S. Department of Agriculture - Public Domain

Weiter geht es mit Teil 2 von "10 Jahre #NoEstimates" (hier ist Teil 1). Wie schon im ersten Teil gesagt ist diese Bewegung mehr als ein Jahrzehnt nach ihrer Gründung noch immer weit davon entfernt im Mainstream angekommen zu sein, alleine wegen des für viele Manager provozierenden Namens. Über den Umweg anderer Frameworks und Praktiken hat sie es aber geschafft zumindest eines ihrer Elemente in den Mainstream zu bringen. Um das soll es heute gehen.


Dazu noch einmal eine kurze Zusammenfassung des zentralen #NoEstimates-Arguments aus Tei 1: beim Grossteil der Vorhaben in der Softwareentwicklung lassen sich die nötigen Aufwände nicht seriös schätzen, da die Voraussetzungen auf deren Basis geschätzt wird sich ständig ändern. Aufgrunddessen sind derartige Schätzungen bestenfalls Indikatoren, eine Ausgangsbasis für eine Planung mit fixiertem Umfang, Zeitrahmen und Budget können sie aber nicht sein.


Auch die Annahme, dass sich eine Schätzung aufgrund von Erfahrungswerten aus vergleichbaren Vorhaben durchführen liesse, trifft leider nicht zu. Anders als in der industriellen Serienfertigung werden in der IT Produkte nur ein einziges mal erstellt, die "Auslieferung" erfolgt dann durch Herunterladen oder Aufspielen der einmal erstellen Software auf beliebig viele Geräte. Es werden also ausschliesslich Einzelanfertigungen programmiert, zur Herausbildung von Erfahrungswerten kommt es nicht.


Die gleiche Problematik tritt auch auf der operativen Ebene auf. Selbst bei relativ kleinen Arbeitspaketen lässt sich nicht zuverlässig schätzen wieviel Zeit sie in der Umsetzung benötigen werden, auch dann nicht wenn sie soweit heruntergebrochen werden, dass sie (vermutlich) in Sprints, Wochen oder Monate passen. Ob es am Ende fünf Tage dauern wird, vier oder sieben lässt sich nicht seriös sagen, auch hier ist die Unklarheit zu gross.


Was sich bei derartig kleinen Aufgaben aber (für nicht alle, aber die meisten Fälle) sagen lässt, ist lediglich ob sie überhaupt in einen Sprint oder Monat passen. In der Regel sind die Arbeitspakete auf dieser Ebene nur einige Tage in der Umsetzung, bei einem Lieferzyklus von 14 bis 20 Arbeitstagen kann man also ziemlich sicher sein, dass die Fertigstellung rechtzeitig erfolgt und sogar noch Zeit für weitere Arbeiten übriglässt. Diese Erkenntnis wurde im Januar 2012 von Vasco Duarte in #Noestimates eingebracht.


Der Schlüssel liegt in einer leichten Einschränkung der Grundidee: statt gar keine Schätzungen mehr zu machen gibt es lediglich keine Schätzungen unterhalb einer bestimmten Granulatität mehr. Wie im letzten Absatz beschrieben kann das bedeuten, dass das Umsetzungsteam nur gefragt wird ob eine Aufgabe überhaupt in einen Sprint passt. Für die sich daraus ergebenden drei Möglichkeiten Ja, Nein und Keine Ahnung gibt es sogar eigene Planning Poker-Karten.



Die Planbarkeit ergibt sich jetzt aus den an dieser Stelle doch möglichen Erfahrungswerten. Mit dem gleichbleibenden Umsetzungsteam und der gleichbleibenden Technologie liegen zwei stabilisierende Faktoren vor, die bei verschiedenen Projekten oder Produkten in der Regel fehlen, so dass die durchschnittliche Menge der in den letzten Sprints geschafften Arbeitspakete (der Durchsatz, bzw. Throughput) in der Regel auch dem entspricht was im nächsten realistisch machbar ist.


Als Nebeneffekt ist diese Variante der (Nicht-)Schätzung und Planung auch weniger manipulierbar als andere. Während Teams häufig unter Druck gesetzt werden ihre Stunden- oder Story-Point-Schätzungen "optimistischer" zu gestalten ist das bei dieser groberen Schätzung weniger möglich. Und der Durchschnittswert der in der Vergangenheit fertiggestellten Arbeit ist überhaupt nicht manipulierbar, wenn man nicht offensichtliche "Geschichtsfälschung" begehen will.


Der Ansatz ausserhalb einer groben Machbarkeit in Sprints, bzw. Monaten überhaupt keine Aufwandsschätzungen vorzunehmen und Planungen auf dem Durchsatz der jüngeren Vergangenheit basieren zu lassen findet sich mittlerweile auch ausserhalb von #NoEstimates wieder, unter anderem bei SAFe und bei der Kanban University. In gewisser Weise das Vermächtnis einer Nischen-Bewegung an den Mainstream, und ohne die provozierende Benennung auch durchaus erfolgreich.

Donnerstag, 6. Januar 2022

Innovations-Durchdringung und Agilität

Grafik: Flickr / Jurgen Appelo - CC BY 2.0

Wenn es darum geht Organisationen auf einen neuen Arbeitsmodus wie z.B. Agilität umzustellen stehen die Vordenker und Pioniere vor dem gleichen Problem das auch aus anderen Change-Vorhaben bekannt ist. Die Gruppe derer die nicht nur zu überzeugen sondern überhaupt mit der neuen Idee bekanntzumachen sind ist riesig, so gross dass sich kaum sagen lässt bei wem angefangen werden sollte. Ein Ansatz diese Zielgruppe zu strukturieren ist das Modell der Innovations-Durchdringung (Diffusion of Innovations). Da es relativ bekannt ist und immer wieder versucht wird es einzusetzen ist es hilfreich es zu kennen, samt seiner Vor- und Nachteile.


Das Modell geht auf die beiden amerikanischen Organisationsforscher Everett Rogers und Geoffrey A. Moore zurück, genauer gesagt auf ihre Bücher Diffusion of Innovations (1962) und Crossing the Chasm (1991). In ihnen wird die Zielgruppe unterteilt in die fünf Untergruppen der Innovatoren (Innovators), der frühen Anwender (early Adopters), der ersten Hälfte der Mehrheit (early Majority), der zweiten Häfte der Mehrheit (late Majority) und der Nachzügler (Laggards). Es wird weiterhin davon ausgegangen, dass die Teil-Zielgruppen unterschiedlich gross sind, bei einer Anordnung von links nach rechts eine Glockenkurve bilden (siehe Abbildung oben) und nacheinander zu überzeugen sind.1


Die Akzeptanz und Anwendung von Innovationen "durchdringt" dabei von links nach rechts die einzelnen Teil-Zielgruppen. Dabei wird angenommen, dass auch diese Durchdringung in Phasen abläuft. Auf der Ebene einzelner Personen sind das Kenntnis des Neuen (Knowledge), Überzeugt werden (Persuasion), Zustimmung (Decision), Umsetzung (Implementation) und Erfolgswahrnehmung (Confirmation), auf der Ebene der Teil-Zielgruppen entsprechen dem Themensetzung (Agenda-Setting), Planung (Matching), Einführung (Restructuring), Gewöhnung (Clarifying) und Verinnerlichung (Routinizing). Auf beiden Ebenen sind Rückfälle und Ablehnungen möglich, werden aber in späten Phasen unwahrscheinlicher.1


Der Vorteil des Innovations-Durchdringungs-Modells ist zunächst, dass die zuvor grosse und schwer fassbare Gesamtmenge der zu überzeugenden Menschen sich in besser greifbare kleinere Einheiten unterteilen lässt. Darüber hinaus bieten die Reihenfolge der Gruppen und die beiden Phasenmodelle ein zwar grobes aber universell anwendbares Muster, anhand dessen bestimmt und geplant werden kann welche Werbe- oder Change Management-Massnahme auf welche Gruppe anzuwenden ist (was in der Detail-Umsetzung je nach Gruppe und Phase sehr unterschiedlich gestaltet werden kann und muss). Vereinfacht gesagt: Mustererkennung und Massnahmenplanung werden einfacher.


Der Nachteil des Modells liegt darin, dass es für die Einführung von Produkt-Neuheiten entwickelt wurde und nicht für die Einführung von Arbeitsmethoden und Vorgehensweisen. Infolgedessen geht es von eher binären Entscheidungen aus: man bleibt bei der Handwäsche oder steigt auf die Waschmaschine um, man bleibt beim Tastentelefon oder kauft sich ein Smartphone, etc. etc. Die Übernahme neuer Arbeitsweisen ist dagegen eher vielschichtig: man kann sie z.B. abstrakt verstanden haben aber noch nicht wissen wie sie umzusetzen sind oder sie mechanisch durchführen ohne den Sinn dahinter zu erkennen. Die eindeutige Zuordnung zu den Gruppen oder Phasen funktioniert so nicht mehr.


Noch unklarer wird es im Fall agiler Transitionen, da hier verschiedene Teilbereiche zusammenkommen die zwar erst zusammengenommen einen Sinn ergeben, die aber separat angeeignet werden können. Naheliegende Beispiele dafür sind Selbstorganisation im Team, (technische) Releasefähigkeit in kurzen Abständen, Produkt- und Domänenverständnis und Kundenorientierung. Tatsächlich ist es in Umbruchphasen häufig so, dass diese Teile über einen längeren Zeitraum unterschiedlich stark ausgebildet sind und erst nach und nach alle ein hohes Level erreichen.2 Auch das erschwert die im Modell vorgesehene eindeutige Zuweisung.


Und selbst wenn irgendwann alle Teilgruppen alle Veränderungsphasen durchlaufen haben kann nicht davon ausgegangen werden, dass dieser Status Bestand hat. Der Versuch erfolgreich agil arbeitende Einheiten durch Skalierung zu vergrössern oder auf ein gemeinsames Ziel auszurichten kann zu Bürokratie und Erstarrung führen, technische Schulden können die Releasefähigkeit untergraben und über längere Zeit stabile Teams können verengte Weltsicht und Konformitätsdruck entwickeln. Eine Folge davon kann z.B. sein, dass Innovatoren in frühe Entwicklungsphasen zurückrutschen und dann sogar schlechter dastehen als die Nachzügler. Die Innovations-Durchdringung ist damit ausgehebelt.


Heisst das, dass dieses Modell für agile Transformationsvorhaben völlig unbrauchbar ist? Natürlich nicht, im Gegenteil: das Herunterbrechen (zu) großer Vorhaben in kleine, handhabbare und separat abschliessbare Arbeitspakete passt hervorragend zu agilem Arbeiten. Was aber nicht funktionieren wird ist der Versuch Personen oder Gruppen fix oder auch nur längere Zeit in Gruppen oder Phasen einzuordnen oder sogar Fortschrittsstände daraus abzuleiten (z.B. "Wir haben jetzt die Innovatoren und die frühen Anwender überzeugt, als nächstes gehen wir die erste Hälfte der Mehrheit an."). Das wird fast zwangsläufig in Missverständnissen und Scheinerfolgen enden, mit bösen Überraschungen als Folge.


Zusammengefasst: in der Produktentwicklung und -vermarktung hat das Innovations-Durchdringungs-Modell seine Berechtigung, auf die Einführung von Arbeitsmethoden und Vorgehensweisen lässt es sich aber nur sehr eingeschränkt übertragen. Inspirieren lassen kann man sich davon, man sollte sich aber seiner Limitierungen bewusst sein.



1Natürlich ist das eine verkürzte Darstellung, wie die Gruppen, ihre Grösse und die Change-Phasen zustandekommen lässt sich in den beiden Büchern nachlesen
2Vorausgesetzt die agile Transition verläuft erfolgreich

Montag, 3. Januar 2022

Warum es so viele unerfahrene Scrum Master und Agile Coaches gibt

Bild: Pexels / Robert Nagy - CC0 1.0

Ich möchte eine These in den Raum stellen. Aufgrund der Erfahrung die ich in über 10 Jahren mit einer dreistelligen Anzahl von agilen Teams in Unternehmen verschiedenster Branchen und Grössen gemacht habe, aufgrund der Begegnungen auf einer ebenfalls dreistelligen Anzahl an Meetups und Konferenzen und durch den Austausch mit vielen weiteren Kollegen glaube ich: mindestens 50 Prozent aller Scrum Master, Agile Coaches und ähnlicher Rollen haben weniger als fünf Jahre relevante Berufserfahrung.1


Um es gleich zu Beginn klar zu sagen - ich glaube, dass das (wenn es denn zutreffen sollte) sowohl negative als auch positive Auswirkungen hat, von dem fehlenden Wissen wie man bestimmte Herausforderungen bewältigt auf der einen Seite bis zur Verhinderung festgefahrener Denk- und Verhaltensstrukturen auf der anderen. Darum soll es heute aber noch gar nicht gehen, sondern um die grundlegendere Frage: wie kann dieses erstaunliche Ungleichgewicht entstanden sein?


Eine erste naheliegende Erklärung wäre der Analogschluss zu den Software-Entwicklern, schliesslich arbeiten fast alle Scrum Master und Agile Coaches in der IT. Es gibt Statistiken (siehe hier, hier und hier) die darauf hindeuten, dass die Anzahl der Entwickler sich etwa alle fünf Jahre verdoppelt. Bei den anderen Rollen liegt ein vergleichbares Wachstum nahe. Die im Gesamt-Durchschnitt geringe Erfahrung der "agilen Methodenmenschen" wäre demnach eine Folge dieses starken Wachstums.


Ein zusätzlicher Faktor der die (Gesamt-)Zunahme von Erfahrung erschwert ist die in vielen Firmen vorherrschende Projekt-orientierte Organisation. Wenn nicht jedes Projekt agil aufgesetzt ist (was auch nicht immer Sinn macht) führt das in diesem Kontext übliche Springen zwischen Projekten dazu, dass die Phasen in denen relevante Erfahrungen gesammelt werden immer wieder unterbrochen werden von Phasen in denen "klassisch" gearbeitet wird und in denen sogar Wissen wieder verloren gehen kann.


Ebenfalls verstärkend kommt dazu, dass viele Produkte während ihres Lebenszyklus auch verschiedene methodische Phasen durchlaufen (mehr dazu hier). Selbst wenn Personen langfristig einem Produkt zugeordnet werden kann das bedeuten, dass nur in einem Teil dieser Zeit ein Agile- oder Scrum-Spezialist gebraucht wird. In den anderen Phasen kann sich die Rolle dann in eine andere ändern, die entweder gar keinen oder einen eher klassischen Methodenbezug hat.


Als vierter Faktor kommt dazu, dass oft in den "agilen Rollen" keine Karriere-Aufstiege möglich sind. Junior/Middle-Weight/Senior-Abstufungen gibt es eher selten und selbst wenn es sie gibt (der Aufstieg vom Scrum Master zum Agile Coach ist z.B. in manchen Firmen möglich) dann nur im Rahmen sehr flacher Hierarchien. Wer auf eine mehrstufige Karriere Wert legt wird so zwangsläufig irgendwann wieder in nicht-agilen Rollen landen.


Nicht zu vernachlässigen ist zuletzt, dass eine nicht unwesentliche Gruppe irgendwann frustriert oder ausgebrannt den Job hinschmeisst wenn spürbar wird, dass es ihrer Firma mit der agilen Transition doch nicht so ernst ist wie zu Beginn behauptet. Ein häufiger Rückzug ist in solchen Fällen der in die vorherige Rolle oder in eine die weniger im Mittelpunkt von Veränderungsprozessen steht. Ein ähnlicher Fall liegt vor wenn der Kampf gegen Cargo Cult-Scrum resignierend aufgegeben wird.


Soviel zur Ursachenforschung (man könnte sicher noch weitere Faktoren finden, dass es sie gibt dürfte aber klar geworden sein). Alle genannten Phänomene konnte ich bereits mehrfach beobachten, und selbst wenn sie schwer zu quantifizieren sind dürften sie alle zu dem Phänomen beitragen, dass Scrum Master, Agile Coaches und ähnliche Rollen über eine im Durchschnitt eher geringe relevante Berufserfahrung verfügen.


Wie zu Beginn gesagt hat das auch nicht ausschliesslich negative Folgen, selbst wenn einige unbestreitbar vorhanden sein werden (siehe z.B. hier). Zumindest sollte man sich dieses Phänomens aber bewusst sein wenn man Agile Transitionen, agil arbeitende Organisationen und die agile Community als Ganzes betrachtet. Vieles wird mit diesem Wissen im Hinterkopf anders erscheinen und gegebenenfalls anders behandelt werden müssen als zunächst gedacht.



1Ja, ich weiss, Anekdotische Evidenz. Aber mit einigen starken Indikatoren.