Freitag, 30. April 2021

Kommentierte Links (LXXIV)

Grafik: Pixabay / The Digital Artist - CC0 1.0

Shawn Carolan: A Path to the Minimum Viable Product

Steve Blank ist nicht irgendwer. Zusammen mit Eric Ries ist er einer der beiden Vordenker der Lean Startup-Bewegung, in der unter anderem das Konzept des Minimum Viable Product (MVP) entwickelt wurde. Wenn er es also einem anderen erlaubt auf seiner Website einen Artikel zu diesem Thema zu veröffentlichen kann man davon ausgehen, dass er lesenswert ist. Dieser Andere ist in diesem Fall Shawn Carolan, und sein Thema ist der so genannte "MVP-Tree", ein Entscheidungsbaum mit dessen Hilfe man bestimmen kann welches das richtige MVP ist das man bauen sollte. Wie alle "Standard-Rezepte" ist auch dieses mit Vorsicht zu geniessen, eine wertvolle Inspiration ist es aber auf jeden Fall.

Ron Ashkenas, Larry Hirschhorn, Thomas Giernalczyk: A Fair Way to Lead a Team of Contractors and Full-Time Employees

So schön die Theorie auch sein mag - manchmal kommt man nicht darum herum die Realität zur Kenntnis zu nehmen. Ein Aspekt bei dem das immer wieder vorkommt ist die in agilen Teams eigentlich vorgesehene Gleichbehandlung aller Teammitglieder, ungeachtet ihres Hintergrunds. Ron Ashkenas, Larry Hirschhorn und Thomas Giernalczyk merken völlig zu Recht an, dass das nur eingeschränkt funktionieren kann wenn ein Team sowohl aus internen als auch aus externen Mitarbeitern zusammengesetzt ist und arbeiten heraus welche unterschiedlichen Rahmenbedingungen und Motivationsfaktoren für diese Gruppen gelten.

Karin Bauer: Warum agile Coaches auf Widerstand stoßen

Man muss dich die Journalisten als gequälte Menschen vorstellen. Drei Jahrzehnte voller digitaler Disruption, sich wandelndem Medienkonsum, Redaktionszusammenlegungen und Entlassungswellen haben dazu geführt, dass die meisten von ihnen nach und nach zu Akkord-Textern degradiert worden sind. Dass das zu einem gesellschaftlichen Problem werden kann zeigt dieser Artikel, dem man ansieht, dass bei ihm weder für gründliche Recherche noch für Faktencheck und Redigieren Zeit und Geld vorhanden waren. Dass der relativ neue Beruf des Agile Coaches mitunter so dubios wahrgenommen (und ausgeübt) wird liegt auch an diesen Hintergründen: es gibt in den ausgezehrten Redaktionen kaum noch Kapazitäten um ihn angemessen zu erforschen und darzustellen.

GeePawHill: On Agile Methods

Die zentrale These dieses Artikels von GeePaw Hill lautet: "Keine der gängigen 'Agilen' Methoden kann hoch-performante Entwicklungsteams hervorbringen." Selbst wenn man dem nicht in dieser Absolutheit folgt, die Gründe die er dafür anführt verdienen es sorgfältig durchdacht zu werden.
  1. Teamübergreifende Standardisierungen sorgen dafür, dass individuelle Bedürfnisse einzelner Teams nicht mehr erfüllt werden können.
  2. Die Fixierung auf Prozesse sorgt dafür, dass das Arbeiten an den eigentlich wichtigeren Arbeitsbeziehungen in den Hintergrund tritt.
  3. Die unterschiedlichen Interessen von Kunden, Firmen und Mitarbeitern werden im Zweifel zugunsten des methodisch vorgegebenen Ziels vernachlässigt.
  4. Alle Methoden beschreiben einen Idealzustand der in der Realität nur schwer erreichbar ist.
  5. Für die Erfinder und Vertreter der Methoden ist es wichtiger mit ihnen Geld zu verdienen als anderen zu helfen.
Wie gesagt, man muss dem nicht in allem zustimmen, aber wer bereits Umsetzungen irgendwelcher agiler Frameworks erlebt hat wird einiges wiedererkennen. Und dass der Autor durchaus mit ein paar steilen Thesen provozieren will merkt man daran, dass unter den von ihm genannten Methoden auch eine ist als deren Fan er sich normalerweise bekennt: Extreme Programming.

J. Meadows: Epistemic Failure in Software Engineering

Wie häufiger bei den kommentierten Links steckt hinter dem letzten der längste Text, angeteasert von der kürzesten Beschreibung. Ein kurzer Spoiler: hier wird der Bezug zwischen Softwareentwicklung und Erkenntnisstheorie hergestellt. Und die Schlüssel zum Erfolg sind bayesscher Wahrscheinlichkeits-Begriff, Agilität und Demut.

Dienstag, 27. April 2021

Ein neues agiles Framework: FAST Guide veröffentlicht

Bild: Pixabay / Mahmur Marganti - CC0 1.0

Es ist schon eine Zeit lang her, dass zum letzten mal ein erwähnenswertes agiles Framework erfunden wurde. Es gab zwar Versuche, die waren aber entweder nur rudimentär entwickelt (z.B. POPCORN-Flow oder FLEAT) oder lediglich Variationen bereits bestehender Frameworks (z.B. Scrum 3.0 von Scrum oder TameFlow von Kanban). Dieses hier scheint in dieser Hinsicht besser zu sein: FAST (Fluid Agile Scaling Technology), erstmals veröffentlicht im März 2021 in Form des FAST Guide. Ob es erfolgreich sein wird muss sich noch zeigen, es ist aber ausdifferenziert genug um besprochen zu werden.


Wichtig ist zunächst, dass FAST sich selbst als Zusammenfassung und Weiterentwicklung bestehender Ansätze versteht, mit dem expliziten Anspruch Scrum abzulösen. Ron Quartel, der Schöpfer des Frameworks, nennt in dessen "Origin Story" die Hauptquellen Open Space Technology und Open Allocation/Dynamic Reteaming, im FAST-Guide kommen dazu noch Dunbar-Zahl/Tribe,  Ken Schwabers Überlegungen zu Post-Scrum und Verweise auf Conway, McGregor, Lewin, Pink und andere Vordenker. Aus all diesem Input entstehen die folgenden Elemente:


Tribes und (dynamische) Teams

Die  nach FAST arbeitenden Menschen bilden einen so genannten Tribe, der zunächst bis zu 14 Mitglieder haben kann (zu grösseren Einheiten siehe unten). Der Tribe ist in beliebig viele Teams unterteilt, die sich mit jeder Iteration (siehe nächster Absatz) selbstorganisiert in der für den Moment jeweils sinnvollsten Konstellation zusammenfinden. Das kann bedeuten, dass auf diese Art Feature-Teams zustande kommen, aber auch Komponenten-Teams oder Mischtypen sind möglich. Auch ein selbstorganisierter Neu-Zuschnitt der Teams während der Iteration geht, wenn es Bedarf dafür gibt.


Iterationen und FAST Meetings

Dass es Iterationen gibt ist auf den ersten Blick eine Gemeinsamkeit mit Scrum, ungewöhnlich ist aber die kurze Dauer und die sich oft ändernde Länge: empfohlen werden zu Beginn zwei Tage, anzustreben ist der kürzeste mögliche Zeitraum. Auch die Meeting-Struktur ist minimalistisch - es gibt lediglich ein Meeting, das zwischen zwei Iterationen stattfindet und ohne vorbereitete Agenda als Open Space durchgeführt wird. Alle Planungs-, Verbesserungs- und Teambuilding-Aktivitäten sollen selbstorganisiert in diesem Termin zur Diskussion gestellt, beschlossen und eingeleitet werden.


Vier Rollen

Angesichts des bisher zu erkennenden Minimalismus ist erstaunlich, dass es bei den Rollen sogar eine mehr gibt als in Scrum. Ein Product Director stellt im FAST-Meeting seine Vision für die nächste Iteration vor, aus der der Tribe selbstorganisiert seine Arbeit ableitet, ein pro Iteration gewählter Team- oder Feature Steward übernimmt in dieser Zeit die Koordination eines Themas, ein Tribe Coach hilft dabei zu verstehen wie die Methodik gemeint ist. Alle anderen Personen gelten einfach als Tribe Member, von denen jeder an mehreren Themengebieten arbeiten können sollte.


Vier Artefakte

Drei der vier Artefakte bilden mit möglichst geringem Detailgrad den Work Breakdown ab. Release Map (gross), Feature Tree (mittel), Iteration Board (klein, als einziges Artefakt optional). Das vierte bilden die so genannten Tribe Agreements, die aber nicht etwa bestimmte Beschlüsse und Regeln enthalten, sondern lediglich beschreiben wie diese möglichst unbürokratisch zu Stande kommen. Alle vier Artefakte können und sollen regelmässig selbstorganisiert geändert werden, ohne dass im Detail festgelegt ist wann das stattzufinden hat. Hauptsache Verbesserungen finden statt, egal wie.


Skalierung

Der Anspruch von FAST ist, dass es ohne zusätzliches Skalierungsframework funktioniert, bzw. sein eigenes Skalierungsframework ist. Tribes können dazu bis zur Dunbar-Zahl von 150 Mitgliedern anwachsen ohne dass zusätzliche Rollen und Meetings benötigt werden, lediglich das FAST-Meeting wird umfangreicher. Erst oberhalb der Dunbar-Zahl muss der Tribe in mehrere geteilt werden. Alternativ können FAST-Tribes in Skalierungsframeworks wie SAFe oder Flight Level-Kanban eingebettet werden, solange diese die internen Abläufe nicht verändern.


Aber: Ist das wirklich umsetzbar?

Ja, aber. Wie oben gesagt muss man sich FAST als ein Framework vorstellen das für Teams geeignet ist die Scrum gemeistert haben und jetzt einen Schritt auf die nächste Stufe machen wollen. Das bedeutet, dass sie Produkte haben die sich durch kleine, in wenigen Tagen umsetzbare Incremente erweitern lassen. Das bedeutet, dass sie die technische Exzellenz haben die für tägliche Produktionsdeployments nötig ist. Das bedeutet, das ihre Firma ihnen alle nötigen Freiheiten gibt. Und das bedeutet, dass ihre Mitglieder nah am Ideal des Fullstack-Developers sind, der nahezu jede nötige Arbeit erledigen kann.


Um ehrlich zu sein - nur wenige Teams dürften jemals den Entwicklungsgrad erreichen der für FAST nötig ist, nicht zuletzt weil nicht alle notwendigen Rahmenbedingungen selbst beeinflussbar sind. Aber vielleicht ist das auch gar nicht immer nötig - alleine der Versuch sich in diese Richtung zu entwickeln dürfte derartig viele positive Veränderungen bewirken, dass es den Aufwand bereits wert ist. FAST wäre damit weniger ein organisatorischer Rahmen und mehr ein guter Grund um ständig an Verbesserungen zu arbeiten. Aus "agiler Sicht" bereits mehr als ausreichend.

Donnerstag, 22. April 2021

Cost of Change, Coupling and Cohesion

Woran man erkennen kann, dass Kent Beck ein guter Konferenz-Speaker ist? Zum Beispiel daran, dass er die ersten vierzehn Minuten dieses Auftritts hier nur dafür verwendet einleitende Worte zu finden, Spannung aufzubauen und Scherze zu machen, ohne dass das langweilig wird. Man kann direkt zum Zeitpunkt 14:00 springen und in den eigentlichen Inhalt einsteigen, man kann sich aber auch den gesammten ersten Teil ansehen und sich gut unterhalten lassen.



Und bevor der falsche Eindruck aufkommt - nicht nur wegen der Art der Präsentation sondern auch wegen des Themas lohnt sich das Video. Es geht darum warum Betrieb und Erweiterung von Software häufig so teuer sind und was man tun kann um dem entgegenzuwirken.

Montag, 19. April 2021

Die Autonomie-Falle

Bild: Flickr / Royalty Free - CC BY 2.0

In der Theorie ist es ganz einfach: das Management erkennt, dass es für Flaschenhälse und Stille Post-Effekte sorgt wenn es alles zentral entscheiden will, also delegiert es Kompetenzen auf die niedrigeren Hierarchieebenen. Dort können die Mitarbeiter jetzt selbst Entscheidungen treffen ohne für alles nach Erlaubnis zu fragen und auf die Genehmigung warten zu müssen. Beschwingt wird in die neue Arbeitswelt gestartet - und zu oft ist eine Bruchlandung die Folge.


Dass es häufig zu diesen Bruchlandungen kommt hat Gründe. Wer in seiner Karriere noch keine wichtigeren Projekt- oder Produktmanagement-Entscheidungen treffen musste wird häufig nicht das Wissen über alle dazugehörigen Aspekte haben und darum wichtige vergessen und unwichtigen zu viel Aufmerksamkeit geben. Der amerikanische Wirtschaftswissenschaftler Claus W Langfred hat das schon 2008 unter dem Namen der "Autonomie-Falle" in einer Studie beschrieben, später ist dieser Begriff vom ebenfalls amerikanischen Informatik-Professor Cal Newport weitergedacht worden.


Langfred und Newport beschreiben vor allem zwei Aspekte. Zum einen durch welche System-Defizite es überhaupt dazu kommt, dass niemand die Delegation von Verantwortung mit einer Weiterqualifizierung der Mitarbeiter verbindet (überspitzt zusammengefasste Antwort: weil zuwenig mitgedacht wird), zum anderen was die Folgen davon sind (nochmal überspitzt: es entsteht ein hyperaktives Schwarm-Bewusstsein, das ständig irrelevante Arbeit erzeugt). Mindestens genauso interessant ist aber eine andere Frage - welches Wissen hätte eigentlich zusammen mit der Delegation vermittelt werden müssen?


Als erstes dürfte hier das Kontextwissen zu nennen sein. In welchem Umfeld sind die Entscheidungen zu treffen für die man auf einmal zuständig ist? Zu welchen anderen Organisationseinheiten bestehen Abhängigkeiten und wer ist dort jeweils der Ansprechpartner an den man sich zuerst wenden sollte? Bereits bei Personen auf der gleichen Hierarchie-Ebene ist in dieser Hinsicht schon viel zu beachten, noch komplizierter wird es wenn andere Hierarchiestufen beteiligt sind. Die Frage wo Selbstorganisation aufhört und wo man weiter eine Genehmigung braucht ist hier von elementarer Bedeutung.


Ein weiterer Punkt ist das technische Wissen. Ist das was zur Entscheidung ansteht überhaupt mit den vorhandenen Systemen umsetzbar oder müssten die umkonfiguriert oder sogar umgebaut werden? Und wenn das zweite der Fall ist - wer könnte (und darf) das machen? Wer benutzt diese Systeme sonst noch und sollte daher in die Entscheidung einbezogen werden, welche Architekturparadigmen sind zu beachten, gibt es bereits Pläne für eine Ablösung oder Weiterentwicklung und was sind erfahrungsgemäss die Teile die besonders kompliziert oder instabil sind?


Auch Wissen um die Prozesse gehört dazu. In welchem Kommunikations-Kanal, mit welchen Informationen und mit welchen Fristen müssen Informationen verschickt und Änderungen angekündigt werden, welche Gesetze und Vorschriften sind relevant und was muss wie dokumentiert werden? Auch die inoffiziellen Prozesse sind wichtig. Wer hat beim jeweiligen Thema Interesse und Einfluss, wer könnte ein Unterstützer sein und wer gilt eher als Quertreiber? Wer das nicht weiss wird sich mitunter an unerwarteten Stellen schwertun.


Genug der Problembeschreibung, wie kann die Befreiung aus der Autonomiefalle gelingen? Schulungen sind verbreitet aber meistens ineffektiv, Peer Groups sind hilfreich, stehen aber oft vor dem selben Problem. Coaching durch die bisherigen Entscheidungsträger könnte die beste Lösung sein, oft sind diese aber mit dem Konzept nicht vertraut (nochmal eine spezielle Ausprägung der Autonomiefalle: viele Manager haben wenig Erfahrung damit Anderen zu helfen ohne die Entscheidung an sich zu ziehen).


Eine mögliche Lösung kommt aus David Marquets Buch Turn the Ship Around. In einem (z.B. wöchentlichen) Regeltermin kann man dem bisherigen Entscheidungsträger erzählen was man vorhat (ich möchte Folgendes erreichen) und wie man es angehen will (dazu plane ich Folgendes zu tun). Der kann dann auf mögliche Probleme hinweisen und Erfahrungswerte weitergeben, ohne dass er die Entscheidung übernimmt oder genehmigt. Mit der Zeit kann dieser Termin dann immer seltener werden, so dass man dadurch nach und nach aus der Autonomiefalle herausgeführt wird.

Donnerstag, 15. April 2021

Selbstwirksamkeitserwartung und Kontrollüberzeugung

Bild: Pexels / Fauxels - CC0 1.0

"Die Gelegenheit beim Schopfe packen", Hilf Dir selbst, dann hilft Dir Gott", "Jeder ist seines eigenen Glückes Schmied" - die deutsche Sprache ist voll von derartigen Sprichwörtern, die alle einen ähnlichen Inhalt haben: wer bei einem Problem oder einer Aufgabe anpackt statt zu zaudern wird fast immer die besseren Ergebnisse erzielen. Dass darin viel Wahrheit steckt dürfte auch ohne wissenschaftlichen Beweis offensichtlich sein, wer etwas tut bewirkt im Zweifel mehr als jemand der nichts tut. Es bleibt dann aber die Frage - wie kommt es dann, dass oft nichts getan wird?


Eine Wissenschaft die sich mit dieser Frage schon lange beschäftigt ist die Psychologie. Vor allem in den 60er und 70er Jahren sind hier verschiedene Erklärungsansätze entstanden, die versuchen die Gründe für die Aktivität oder Inaktivität von Menschen nachzuvollzieren. Um zwei davon soll es heute gehen, es sind Selbstwirksamkeitserwartung und Kontrollüberzeugung. Sie überschneiden sich in weiten Teilen, so dass es Sinn macht sie gemeinsam zu betrachten.


Die Selbstwirksamkeitserwartung (im englischen Original Self-Efficacy) wurde in den 70er Jahren vom kanadischen Psychologen Albert Bandura entwickelt. Vereinfacht gesagt handelt es sich bei ihr um das Ausmass der Zuversicht mit dem man einer anstehenden Aufgabe oder einem auftretenden Problem entgegenblickt. Bei hoher Zuversicht ist man überzeugt, dass Aufgabe oder Problem erfolgreich bewältigt werden können, bei niedriger Zuversicht geht man eher davon aus, dass man scheitern wird.


Je nachdem wie hoch die Selbstwirksamkeitserwartung ist können die folgenden Aktionen sich stark unterscheiden. Ist die Erwartung hoch wird ohne grosses Zögern die Tat ergriffen, ist sie moderat erfolgt ein Abwarten und Abwägen, ist sie niedrig macht man entweder gar nichts (Resignation) oder sucht nach Wegen um Aufgabe, bzw. Problem zu umgehen, in die Zukunft zu verschieben oder delegieren zu können (Ausweichverhalten).


Die Kontrollüberzeugung (im englischen Original Locus of Control) geht auf den amerikanischen Psychologen Julian B. Rotter zurück, der den Begriff in den 60er Jahren einführte. Sie beschreibt in wiefern Probleme und Aufgaben überhaupt als selbst bewältigbar angesehen werden. Glaubt man daran selbst dazu in der Lage zu sein spricht man von einer internen Kontrollüberzeugung, glaubt man, dass nur jemand anders (oder mehrere andere) das können von einer externen Kontrollüberzeugung.


Von der Selbstwirksamkeit unterscheidet sich dieses Konzept folgendermassen: bei der Kontrollüberzeugung geht es darum ob man es überhaupt für möglich hält ohne externe Hilfe eine Veränderung herbeizuführen, bei der Selbstwirksamkeit steht im Mittelpunkt ob man es sich selbst zutraut eine theoretisch mögliche Veränderung auch tatsächlich umzusetzen. Beides sind subjektive Annahmen, die erste wird aber oft für objektiv gehalten.


Um diese Theorie mit der Praxis in Verbindung zu bringen: wenn eine Organisation es sich um Ziel gesetzt hat mit möglichst selbstorganisierten, sich selbst weiterentwickelnden und Intrapreneur-artig handelnden Teams Produkte zu entwickeln, dann kann das letztendlich nur dann gehen wenn Selbstwirksamkeitserwartung und interne Kontrollüberzeugung der Teammitglieder möglichst hoch sind. Sind sie das nicht werden sie zu oft auf externe Unterstützung warten statt selbst initiativ zu werden.


Aus dieser Erkenntnis können verschiedene Massnahmen abgeleitet werden um für die passende Zusammenstellung von Teams zu sorgen. Häufig aber meistens nicht zielführend sind Assessment Center, in denen die Teammitglieder auf die "richtige" Geisteshaltung überprüft werden. Durch kognitive Verzerrungen wie Observer-Expectancy Effects, Selection Biases oder Attribute Substitutions sind deren Ergebnisse kaum aussagekräftig und im Zweifel falsch.


Zielführender ist es sich die zugrundeliegenden psychologischen Mechanismen zu Nutze zu machen. Während niedrige Selbstwirksamkeitserwartung und externe Kontrollüberzeugung häufig durch Machtlosigkeits- oder Misserfolgs-Erfahrungen entstehen können häufige Erfolgserlebnisse das (positive) Gegenteil bewirken und zu hoher Selbstwirksamkeitserwartung und interner Kontrollüberzeugung führen.


An dieser Stelle kommen schliesslich Ansätze aus dem Lean-Agile-Bereich ins Spiel. Da diese durch Praktiken wie Pull Prinzip, regelmässige Refinements und kurze Planungszyklen vergleichsweise realistische und machbare Planungen hervorbringen können sie durch zahlreiche Erfolgserlebnisse eine Eigendynamik entwickeln die dafür sorgt, dass die für diese Art des Arbeitens notwendigen Selbst- und Systemwahrnehmungen von sich aus entstehen und verstärkt werden.

Montag, 12. April 2021

The agile Bookshelf: Mutual Aid - A Factor of Evolution

Bild: Wikimedia Commons / Nadar - Public Domain

Er dürfte eine der ungewöhnlichsten Biografien der letzten Jahrhunderte haben. Geboren wurde Pjotr Kropotkin in eine russische Adelsfamilie, er wurde Page des Zaren, Offizier an der chinesischen Grenze, Natur- und Geografieforscher in Sibirien, Anarchist, politischer Gefangener, Gefängnisausbrecher, Journalist in der Schweiz, Schriftsteller in England, Menschen- und Bürgerrechtsaktivist. Und aus diesem ungewöhnlichen Leben entstand ein ungewöhnliches Buch.


Gegenseitige Hilfe in der Tier- und Menschenwelt wurde von ihm 1902 in England veröffentlicht und später in verschiedene Sprachen übersetzt. Es stellt nicht weniger dar als den Versuch nachzuweisen, dass nicht etwa Konkurrenz und Wettbewerb sondern Kooperation und gegenseitige Unterstützung die Grundprinzipien sind an denen sich sowohl die Natur als auch die meisten menschlichen Gesellschaften ausrichten. Sowohl das Über- als auch das Zusammenleben von Menschen und Tieren basiert in dieser Sicht auf gegenseitiger Hilfe.


Man kann Kropotkins Buch vor allem als Gegenschrift zu den Werken zweier berühmter Engländer sehen, Charles Darwin und Thomas Hobbes. Anders als Darwin, der als erster die Evolution beschrieben hatte, ging Kropotkin davon aus, dass nicht in erster Linie die stärksten oder am besten angepassten Tierarten die erfolgreichsten sind (→ Survival of the Fittest) sondern vor allem die deren Angehörige sich am effektivsten bei Nahrungssuche, Selbstverteidigung und Aufzucht des Nachwuchses unterstützen.


Auf die menschlichen Gesellschaften bezogen vertrat Kropotkin eine Gegenposition zu Hobbes. Dieser war davon ausgegangen, dass die Menschen im Naturzustand ständig miteinander um Ressourcen und Macht kämpfen würden (→ der Krieg aller gegen alle), was Kropotkin mit zahlreichen Beispielen aus verschiedenen Gesellschaften widerlegte, darunter Eingeborenenstämmen in Asien und Afrika, antiken Reichen und Völkern, mittelalterlichen Städten und modernen Kommunen und Genossenschaften.


Für die Gegenwart anwendbar wird sein Werk dadurch, dass sich die ihm widersprechenden Gegenthesen bis heute gehalten haben. Auch ohne die Urheberschaft durch Darwin und Hobbes zu kennen oder zu nennen wird immer wieder mit ihren Standpunkten argumentiert wenn begründet werden soll warum ein selbstorganisiertes oder weitgehend hierarchiefreies Arbeiten in Konkurrenzkämpfe oder Chaos führen würde wenn man es zuliesse.


Das mit einem Verweis auf einen vor langer Zeit verstorbenen russischen Fürsten bestreiten zu wollen dürfte zwar nur wenig zielführend sein, was man aber machen kann ist seine zahlreichen Beispiele aufgreifen um zu zeigen, dass Selbstorganisation und Gruppenentscheidungen schon seit Menschengedenken gut funktionieren, gewissermassen also Good Practices sind.


---


Und übrigens: wer jetzt neugierig geworden ist kann sich das Buch hier im englischen Original herunterladen. Mehr als 100 Jahre nach Kropotkins Tod ist die Schutzfrist vorbei und sein Werk frei verfügbar. Einfach auf die nächste Zeile klicken.

Mutual Aid: A Factor of Evolution, by Knjaz Pjotr Alexejewitsch Kropotkin

Donnerstag, 8. April 2021

Alternative Metriken für eine agile Transition

Bild: Wikimedia Commons / James Petts - CC BY-SA 2.0

Eigentlich sollte es gar nicht so schwer sein herauszufinden mit welchen Metriken sich der Erfolg einer agilen Transition validieren lässt. Einige davon hatte ich schon einmal aufgeschrieben, unter anderem kämen da Time to Market, Feedback Implementation Time, (Mean)Time to Recovery und Time to Process Adaption in Frage. Eine häufige Sorge ist dabei aber, dass sie alle dazu führen können, dass alle Erwartungen und Verantwortungen nur auf die unteren Hierarchieebenen abgewälzt werden.


Aufbauend darauf stellt sich die Frage, was für weitere Metriken es geben kann, an denen sich auch das Management messen lassen könnte. Ausgehend davon, dass es in der agilen Zielwelt unter anderem für die richtigen Rahmenbedingungen um möglichst autonome Teams zuständig sein wird wäre dieser Bereich ein naheliegender Ansatz. Und auch für diese Zielzustands-Rahmenbedingungen gibts bereits Definitionen: flache Hierarchien, wenige organisatorische Silos, möglichst wenige Abhängigkeiten.


Bevor das operationalisiert wird aber noch eine letzte Vorbemerkung. Da jeder Einzelfall immer einzigartig ist und da eine agile Zielorganisationen hohe Grenzwerte zulassen kann und muss sollte es sich bei allen folgenden Metriken um die Durchschnittszahlen der gesamten Organisation handeln. Dadurch bleiben Ausnahmen noch immer möglich, es kann aber nicht dazu kommen, dass sie zur Regel werden. Und jetzt in medias res, hier sind Ideen für die alternativen Transitions-Metriken:


I. Anzahl der Menschen die einem Product Owner eine Entscheidung untersagen können

Dass diese Zahl bei Null liegen könnte werden zwar nur Scrum-Fundamentalisten glauben, wie hoch sie im Ist-Zustand fast jeder grösseren Firma ist, ist aber selbst für deren Angehörige immer wieder erschreckend. Vorstände gehören dazu, verschiedene Bereichs-, Abteilungs-, Initiativen-, Programm- und Projektleiter, dazu meistens Fachabteilungs-, Produkt- und sonstige Manager sowie Angehörige der Vertriebs-, Anforderungsmanagement-, Rechts-, Datenschutz- und Compliance-Abteilungen. In Summe kommt so schnell eine mittlere zweistellige Personenzahl zusammen, die entweder Sitz in Lenkungs-Gremien oder Vetorecht hat. Ein gutes Transitionsziel kann sein, diese Zahl einstellig werden zu lassen.


II. Anzahl der Menschen die einem Team die Art der Umsetzung vorschreiben können

Auf den ersten Blick ein ähnlicher Fall, nur mit anderen Beteiligten, auf den zweiten mehr. Zu den disziplinarischen Vorgesetzten kommen hier die Architekten, Lead Developer, Test-, Release-, Integrations- und sonstigen IT-Manager, dazu aber auch andere Angehörige der unteren Hierarchie-Ebenen. Wenn andere Teams die selben Services und Komponeneten benutzen ist es schliesslich nur natürlich, dass sie Entscheidungen widersprechen dürfen von denen sie betroffen sind. Ein Transitionsziel auch diese Zahl einstellig werden zu lassen muss daher nicht nur zur Entflechtung von Mitspracherechten führen sondern auch zur Entflechtung von IT-Systemen.


III. Anzahl der organisatorischen Einheiten die beteiligt sein müssen um ein crossfunktionales Team zu bilden

Auch hier gilt: selbst für die Angehörigen grosser Firmen ist immer wieder erschreckend wie gross diese Zahl sein kann wenn End to End-Verantwortung erreicht werden soll. Der PO hängt im Produkt-, der Scrum Master im Projektmanagement, Entwickler in der Entwicklung, Tester in der QA, UXler, Release-Manager und Business Analysten können eigene Abteilungen haben und der Produktions-Betrieb wird oft sogar von eigenen Gesellschaften verantwortet. Alleine um das Customer-Vendor Antipattern zu vermeiden macht es Sinn hier die Zahl zu reduzieren. Das ideale Transitionsziel wäre eine Eins, aber auch eine niedrige einstellige Zahl wäre fast überall eine Verbesserung.


IV. Anzahl der Teams denen ein durchschnittlicher Mitarbeiter der Ausführungsebene gleichzeitig angehört

Ein Phänomen das häufig gemeinsam mit einem funktionalen Abteilungsschnitt auftritt ist die gleichzeitige Zugehörigkeit einzelner Personen zu mehreren Teams, z.B. wenn sich zwei UX-Designer auf mehr als zwei Projekte aufteilen müssen. Die dadurch entstehenden negativen Effekte (Terminkonflikte, Kontext-Wechsel, etc.) sind zwar bekannt, trotzdem sind in grossen Organisationen fünf bis zehn gleichzeitige Mitgliedschaften nicht ungewöhnlich. Da manche Hochspezialisierungen kaum vermeidbar sind (z.B. Juristen oder Penetrationstester) ist ein Transitionsziel von Eins zwar wenig realistisch, ein Durchschnittswert zwischen Eins und Zwei kann aber angestrebt werden.


V. Anzahl der Genehmigungsschritte die ein Team durchlaufen muss um mit einem Endkunden reden zu können

Auch hier kann mehr dahinterstecken als man zunächst ahnt. Das erste und offensichtlichste Hindernis sind natürlich andere Einheiten die bisher das Monopol auf den Endkundenkontakt hatten (häufig Vertrieb, Marketing und/oder Kundendienst), dazu kommt aber auch, dass in der Budgetierung von Entwicklungsteams meistens kein Posten für Kunden-Gespräche vorgesehen ist, bzw. dass dieser aufwändig beantragt und genehmigt werden muss. Ein gutes Transitionsziel in diesem Bereich wäre die Zahl Null, was in der Umsetzung nicht nur zum Abbau von Kommunikationsbarrieren führen würde sondern auch zum Ende von Micromanagement-Versuchen über das Budget.


VI. Anzahl der Genehmigungsschritte die ein Team durchlaufen muss um alle (!) Zahlen zum eigenen Produkt zu erhalten

Apropos Budget. Vor allem Finanz-Zahlen, aber auch Absatzmengen und Nutzungsdaten sind in vielen Firmen für die Entwicklungsteams gar nicht oder nur erschwert zugänglich. Wie aber soll ein Team Intrapreneurship (wirtschaftliches Denken und Handeln) eintwickeln wenn ihm weder bewusst ist welche Kosten es verursacht noch welche Umsätze und Gewinne es erwirtschaftet? Auch hier ist das ideale Transitionsziel die Zahl Null, aber selbst eine Reduzierung auf den niedrigen einstelligen Bereich würde fast überall ein deutliches Mehr an Transparenz und deutlich weniger Herrschaftswissen bedeuten.


Wie oben gesagt, das Erheben und gezielte Senken derartiger Zahlen kann ein wirkungsvoller Weg sein um zu verhindern, dass die Änderungs-Aufwände (bewusst oder unbewusst) ausschliesslich auf die Teamebene gewälzt werden. Wer so vorgeht kommt am Verändern der Rahmenbedingungen nicht vorbei - und das ist auch gut so, denn ohne das haben nur die wenigsten Transitionen eine wirkliche Aussicht auf Erfolg.

Montag, 5. April 2021

Agile Rhapsody

 Ich muss mich im voraus entschuldigen, an der einen oder anderen Stelle klingt dieses Lied ein kleines bisschen schief. Aber da müssen wir jetzt durch, denn was diese Damen und Herren aufgenommen haben ist eine Coverversion von Queens Bohemian Rhapsody, mit auf Scrum und Kanban umgedichteten Texten. Und diese Kombination kann nicht unbeachtet bleiben.



Ganz nebenbei: gefühlt gibt es auf dieser Seite mittlerweile schon so viele "Agile Lieder", dass ich fast über eine eigene Kategorie nachdenken könnte.