Dienstag, 30. November 2021

Kommentierte Links (LXXXI)

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

Jeff Gothelf: Why does planning require a “season"?

Aus einem neuen Blickwinkel betrachtet kann sich die Absurdität scheinbar normaler Vorgänge offenbaren. Der den Jeff Gothelf hier einnimmt ist so einer, verbunden mit einem schönen neuen Begriff: der "Planungs-Saison". Die dahinter liegende Idee ist es, aufzuzeigen, dass es für Planungen (ähnlich wie für Erdbeeren, Ski-Urlaub oder Monsun-Stürme) eine bestimmte Jahreszeit gibt in der sie besonders häufig auftreten. Es sind die Wochen vor Weihnachten, in denen intensiv an Budgets, Feature-Wunschlisten, Zieldaten und ähnlichen Planungselementen gearbeitet wird. Während aber die anderen Saisons nachvollziehbare und kaum änderbare Ursachen in der Biologie, den Schulferien und der Metereologie haben ist die Entscheidung eine Planungs-Saison durchzuführen keineswegs zwangsläufig. Wäre nicht eine kontinuierliche Aktualisierung der Planungen viel sinnvoller für eine Welt in stetiger Bewegung?

Brian Milner: The Product Owner’s Second Team

Apropos neuer Blickwinkel: das was Brian Milner hier gelingt ist einer der seltenen neuen Blicke auf Scrum. Was er dabei entdeckt ist etwas was sich zwar aus dem offiziellen Regelwerk nicht ablesen lässt, was aber in der Realität häufig vorkommt und bei konsequenter Anwendung agiler Prinzipien extrem naheliegend ist - ein zweites Team in dem der Product Owner Mitglied ist, das Stakeholder-Team. Die Idee dahinter ist, dass die Stakeholder eines Scrum Teams ein gemeinsames Interesse haben (die Weiterentwicklung des gemeinsamen Produkts), einen gemeinsamen Ansprechpartner für dieses Interesse (den Product Owner) und einen gemeinsamen Arbeitszyklus, an dessen Ende ein gemeinsames Meeting steht (den Sprint, bzw. das Sprint Review). Das sind deutlich mehr Gemeinsamkeiten als viele andere Organisationseinheiten haben die sich Team nennen.

Stefan Kühl: Selbstorganisation – Von den hierarchischen Grenzen eines verklärten Konzeptes

Das hier ist der etwas verquere Fall eines Artikels der irgendwie sein Thema verfehlt aber trotzdem interessant und erkenntnisreich ist. Was Stefan Kühl hier beschreibt ist Delegation von oben nach unten unter Vorbehalt. Mit anderen Worten: ein Vorgesetzter erlaubt es seinen Untergebenen über bestimmte Sachverhalte selbstorganisiert zu entscheiden, aber nur so lange bis er einen guten Grund hat diese Kompetenz wieder an sich zu ziehen. Der durchschlagendste dieser Gründe liegt dann vor, wenn er fürchten muss für die ausbleibenden oder nicht erwartungsgemässen Ergebnisse zur Verantwortung gezogen zu werden - sein Micro-Management erfolgt dann aus versuchtem Selbstschutz. Das alles ist hier anschaulich und eloquent beschrieben, allerdings mit einem etwas schrägen Twist. Der Vorgesetzte wird zu einem Teil der sich selbstorganisierenden Organisationseinheit erklärt, die damit auch im Fall des hierarchischen Durchgriffs als selbstorganisiert gilt. Nun ja. Wie Kühl selbst scheibt: jede und jeder kann Worte so bestimmen, wie sie oder er es möchte.

Bill Wake: Backroom/Frontroom to Smooth Releases

Eine nützliche Analogie die ich noch nicht kannte. Bill Wake vergleicht die Prozesse der Produktentwicklung mit denen in einem Restaurant. In ihm gibt es den vorderen Bereich, in dem Speisen und Getränke bestellt, aufgetischt, konsumiert und bezahlt werden und den hinteren Bereich in dem die Lagerung der Zutaten und ihre Zubereitung erfolgt. Das Besondere an diesem Vergleich ist, dass das Auftragen und Konsumieren im Vorderbereich in einer signifikant anderen Reihenfolge stattfinden kann als die Zubereitung im Hinterbereich. Je nach Bestellung muss die Zubereitungsreihenfolge sogar von der Konsumreihenfolge abweichen damit alles zum richtigen Zeitpunkt fertig ist. Wer seine Produkte ohne ein ständig wachsendes und Kapital bindendes Zwischenlager noch nicht benutzbarer Teilergebnisse erstellen möchte, der sollte sich an den Küchen ein Beispiel nehmen und seine Planung an der Integration der Einzelteile ausrichten statt am Auftragseingang.

Clive Thompson: 13 Ways Of Looking at a Post-It Note

Selbst die immer populärer werdende Heimarbeit hat nichts daran ändern können, dass der Post-It-Zettel die ikonische Manifestation agiler und leaner Arbeitsweisen ist. Sogar viele der gängigen Tools wie Miro oder Jira versuchen mit unterschiedlichem Erfolg sich an seine Funktionsweise anzulehnen. Clive Thompsons zählt einige Gründe dafür auf wie es zu diesem Status gekommen ist.

Donnerstag, 25. November 2021

Resource Utilization Trap

Dieses Video zeige ich seit Jahren immer wieder in Workshops oder verschicke es an Kunden von denen ich glaube, dass sie etwas zu sehr der Idee anhängen, dass sie ihre Mitarbeiter möglichst voll auslasten müssten. Für alle die keine Lust auf längere Texte haben ist es eine gute Möglichkeit um herauszufinden welche negativen Folgen eine Auslastungsfixierung haben kann.



Auf einer zweiten Ebene zeigt sich hier sehr schön, dass man für wirkungsvolle Lehrvideos weder ein grosses Budget noch professionelle Schauspieler oder eine grosse Bearbeitungs-Talent braucht. Wenn die Botschaft sehr klar und einleuchtend ist (so wie in diesem Fall) kommt man schon mit geringen Mitteln sehr weit.

Montag, 22. November 2021

Der Vorteil von SAFe (II)

Dass das Scaled Agile Framework (SAFe) in der agilen Community eher kritisch gesehen wird dürfte sich mittlerweile herumgesprochen haben. Es zu bashen gehört mittlerweile fast schon zum guten Ton, was dazu führt, dass es leider nur noch sehr einseitig betrachtet wird. Man kann ihm nämlich auch positive Aspekte abgewinnen, darunter einen der auf den ersten Blick überraschend wirkt - SAFe ist einfach zu erklären und zu verstehen.


Überraschend ist das deshalb weil in der öffentlichen Wahrnehmung vor allem das grosse Wimmelbild auf der Startseite von scaledagileframework.com bekannt geworden ist. Das als Grundlage einer einfachen Erklärung zu nutzen wäre tatsächlich eine Herausforderung. Was dabei allerdings oft übersehen wird ist, dass diese Übersicht stark mit Elementen überladen ist die optional sind oder bei denen es sich um Implementierungsdetails handelt. Um SAFe zu verstehen braucht man nur wenige.


Fangen wir oben an, bei einem Teil der zentral ist und in keiner Umsetzungen vernachlässigt werden sollte: dem Portfolio Kanban. Sein Design kann sich zwar je nach Fall unterscheiden, wichtig ist aber, dass hier die grossen Arbeitspakete (Epics) der zur Zeit umgesetzten Initiativen von links nach rechts wandern. Idealerweise wird diese Übersicht genutzt um zu verhindern, dass zu viele gleichzeitig begonnen werden, so dass mehr Focus und weniger Multitasking entstehen.


Bei der Organisation der Umsetzung tritt eine zentrale Annahme von SAFe in den Vordergrund: die, dass es einzelnen Team in kurzen Zeiträumen nicht möglich ist Arbeitspakete von relevantem Wert abzuschliessen. Aus diesem Grund wird eine doppelte Gruppierung vorgenommen - jeweils mehrere Teams arbeiten über mehrere aufeinanderfolgende Kurz-Zeiträume an einem solchen Arbeitspaket. Der Name einer solchen Gruppierung ist Release Train, die Zeitspanne nennt sich Program Increment (PI).


Damit die Teams eines Release Trains nicht nur gemeinsame Umsetzungszeiträume haben sondern auch an zusammengehörigen Themen arbeiten (und dabei die untereinander bestehenden Abhängigkeiten berücksichtigen) findet zu Beginn jedes Program Increments eine gemeinsame Planung statt, das PI Planning, bzw. Big Room Planning. Ggf. können begleitend dazu auch Retrospektiven stattfinden, entweder davor (für das letzte PI) oder danach (für das PI Planning selbst).


In der Theorie arbeiten die einzelnen Teams zwischen zwei PI Plannings nach Scrum (in mehreren Sprints), de facto ist dieser Arbeitsmodus aber stark beschnitten, da die Integration in einen Release Train dafür sorgt, dass die eigentlich vorgesehene Team-Autonomie nur noch eingeschränkt möglich ist. Vor allem die Kompetenzen des Product Owners und Scrum Masters werden zum Teil auf entsprechende Koordinationsrollen im Release Train übertragen, den Product Manager und den Release Train Engineer.


Und das ist sie auch schon, die einfache Erklärung von SAFe in nur vier Absätzen. Wendet man diesen Erklärungsansatz an hat das zwei Vorteile: zum Ersten den, dass erkennbar wird, dass sich hinter dem unübersichtlichen offiziellen Übersichtsbild eigentlich nur ein relativ einfacher Skalierungsansatz verbirgt. Hat man den erfasst wird es auch einfacher zu beurteilen welche der zahlreichen anderen Elemente man nutzen will und welche nicht.


Zum anderen kann man die zentrale Annahme von SAFe herausstreichen: die, dass es einzelnen Team in kurzen Zeiträumen nicht möglich ist Arbeitspakete von relevantem Wert abzuschliessen, weshalb sie in Release Trains und Program Incrementen zusammengekoppelt werden. Und an dieser Stelle wird diese einfache Erklärung auch für die SAFe-Skeptiker interessant - wenn sie belegen können, dass die Teams dazu doch in der Lage sind, entfällt die Notwendigkeit SAFe einzuführen.


Umgekehrt betrachtet: dort wo einzelne Teams nicht in der Lage sind in einzelnen Sprints Mehrwert abzuliefern ist SAFe zumindest eine Option. Ob es die richtige ist muss sich im Vergleich mit anderen Skalierungsframeworks klären, deren Befürworter dann in der Lage sein sollten sie ähnlich einfach zu erklären wie das bei SAFe möglich ist.

Donnerstag, 18. November 2021

Welches Kanban darfs denn sein?

Bild: Flickr / Paul Downey - CC BY 2.0

"Wir machen Kanban" ist eine Aussage die man mittlerweile von sehr vielen Teams hören kann. Schaut man sich einzelne davon näher an lassen sich allerdings grosse Unterschiede erkennen, zum Teil sogar so grosse, dass praktisch keine Vergleichbarkeit mehr gegeben ist. Das hat mit dem Fehlen eines offiziellen Regelwerks zu tun (sorry, Kanban University), mit Missverständnissen und mit Cargo Cult, selbst wenn man das in Betracht zieht bleibt aber noch eine erstaunliche Vielfalt übrig. Der Grund dafür - es gibt mehrere Varianten von Kanban, die sich z.T. deutlich unterscheiden:


Irgendetwas Sichtbares

Da Japanisch und Deutsch sich stark unterscheiden ist eine wörtliche Übersetzung schwierig, je nach Auslegung lautet sie aber "visuelles Signal", "sichtbare Information" oder etwas Vergleichbares. Damit können zum Beispiel die farbigen Signallampen an Fabrikstrassen oder an Warteschlangen als Kanban bezeichnet werden (was aber fast ausschliesslich japanische Muttersprachler tun). Zur Abgrenzung: nicht in diese Kategorie fallen Zahlen, Buchstaben und Diagramme, für die es eigene Bezeichnungen gibt.


Irgendetwas mit Karten oder Post-Its

Ein spezifischerer Übersetzungs-Versuch ist Signal-Karte oder Informations-Karte (Kan = Sichtbare Information, Ban = Karte oder Post-It). Das ist enger gefasst als die wörtliche Übersetzung, umfasst aber noch immer recht viel, neben den verbreiteten Boards oder Wänden auf denen Post-Its hin und her geschoben werden z.B. auch Kamishibai-Visualisierungen, Planning Poker-Karten und ggf. sogar aus Papierzetteln erstellte Kunstwerke.


Durchfluss-Visualisierungen

Die vermutlich am weitesten verbreitete Definition. In ihr wird unter einem Kanban-System oder Kanban-Board eine Darstellung aufeinanderfolgender Arbeitsschritte verstanden, die von den einzelnen Arbeitspaketen durchlaufen werden (hier ein Beispiel). Dargestellt werden diese Pakete durch Post-Its (physisch) oder Kacheln (digital). Auch hier gibt es eine Abgrenzung: werden keine Arbeitsschritte abgebildet sondern To do, Doing und Done ist es ein Task Board, kein Kanban-Board.


Erweiterte Durchfluss-Visualisierungen

Hier beginnt es für die Tool- und Methoden-Nerds interessant zu werden. Häufige visuelle Elemente in erweiterten Kanban-Systemen sind Work in Progress-Limits (sowohl für die Unter- als auch für die Obergrenzen), Zähl-Punkte für die Messung von Lead Time und Cycle Time und "Parkplätze" für blockierte oder wartende Arbeit, es gibt aber noch zahllose weitere. Für viele "Überzeugungstäter" darf sich nur Kanban nennen was solche Erweiterungen enthält.


Eine Change Management-Methodik

Die vermutlich engste Definition von allen. In ihr hat sich Kanban weitgehend von seinen Ursprüngen in der Visualisierung, bzw. Informations-Übermittlung gelöst und ist zu einer Methode des Change Managements geworden. Die Darstellung eines Arbeitsflusses durch aufeinanderfolgende Arbeitsschritte ist nur noch ein Mittel zum Zweck, und der ist die kontinuierliche und behutsame Optimierung und Effizienzzsteigerung des Gesamtsystems.


Grober Unfug

Wie oben erwähnt, Cargo Cult gibt es überall, also auch hier. Eine seiner häufigsten Manifestationen ist der Glaube Kanban wäre "Scrum mit weniger Meetings" (mitunter auch "Scrum ohne Sprints" oder "Scrum ohne Rollen"). Dahinter steckt meistens guter Wille, falsch ist es aber trotzdem (und auch die Wortschöpfung "Scrumban" macht es nicht besser). Das heisst nicht, dass man das nicht machen könnte, es hat dann aber mit Kanban ähnlich wenig zu tun wie mit Scrum.


Und noch mehr ...

Bei weiterem Suchen würde man mit Sicherheit noch weitere Varianten von Kanban finden, gute, schlechte und viele die irgendwo in der Mitte sind. Wichtig ist es dabei sich über die jeweiligen Unterschiede im Klaren zu sein, denn eines ist angesichts dieser Vielfalt sicher: "Wir machen Kanban" ist zu wenig Information um zu erkennen was genau da gemacht wird.

Montag, 15. November 2021

Story Points sind Schweine

Bild: Wikimedia Commons / Nela König /Hot Action Records - CC BY-SA 3.0

Eine Anekdote aus der Musik: einer der grössten Hits der legendären Band Die Ärzte trägt den schönen Namen Männer sind Schweine. Das Besondere an ihm ist, dass die Ärzte bereits kurz nach seiner Veröffentlichung 1998 aufhörten ihn aufzuführen - seine Beliebtheit auf Volksfesten, Schlager- und Ballermann-Partys führte dazu, dass sie als Punk-Gruppe mit diesem Umfeld nicht in Verbindung gebracht werden wollten. Sie verstiessen daher dieses "kontaminierte" Lied aus ihrem Repertoire.


Die Tragweite dieser Entscheidung wird klar wenn man sich vor Augen hält, dass "Männer sind Schweine" bis heute das komerziell erfolgreichte und (über alle Bevölkerungsgruppen hinweg) vermutlich auch bekannteste Werk der Ärzte ist. Das nicht mehr aufführen zu wollen ist ein bemerkenswertes Statement und lässt Rückschlüsse darauf zu, wie stark ihre Abscheu vor der Schlager- und Ballermann-Szene sein muss und was sie bereit waren zu opfern um zu ihr auf Abstand zu bleiben.


Um die Anekdote zu beenden und wieder zum Hauptthema dieser Seite zurückzukommen: vergleichbare Abstossungs-Vorgänge wie den gerade beschriebenen gibt es auch im Umfeld der agilen Frameworks. Auch hier gibt es extrem populäre Konzepte die wegen ihrer Beliebtheit bei einer als unpassend empfundenen Zielgruppe von vielen kaum noch genutzt werden. Und wer die Geschichte der "agilen Bewegung" kennt wird die "unpassende Zielgruppe" ahnen - es ist das Management.


Das vielleicht bekannteste (weil verbreitetste) Beispiel dafür sind die aus dem Extreme Programming stammenden Story Points. Selbst ihr (Mit-)Erfinder Ron Jeffries bedauert mittlerweile sie erfunden zu haben, auch von anderen bekannten Agilisten wie z.B.  Allen Holub, Troy Magennis und Joshua Kerievski werden sie kritisch gesehen. Der Grund dafür ist die Gewohnheit vieler Manager (v.a. im SAFe-Kontext) sie zu normieren, vorzuschreiben und als Grundlage für langfristige Detailplanung zu benutzen.


Ein weiteres ist das so genannte Spotify Model, ein bei der gleichnamigen schwedischen Firma entwickelter Skalierungsansatz. Auch hier hat mit Joakim Sundén einer der Erfinder mittlerweile eine eher kritische Einstellung, genau wie andere bekannte agile Practitioner, z.B. Ben Linders und Willem-Jan Ageling. Und auch hier ist die Ursache für die Ablehnung eine Begeisterung bei "den falschen Menschen", in diesem Fall Managern die den Ansatz unreflektiert als Blaupause benutzen wollen.


Neben diesen weit verbreiteten gibt es zusätzlich zahllose weitere eher lokale Beispiele dafür, dass agile Teams und Enthusiasten von bestimmten Frameworks und Praktiken abwenden weil sie "den falschen Menschen" in die Hände gefallen sind. Abstossungen die ich in verschiedenen Firmen gesehen habe betrafen unter anderem Burndown Charts, Scrum, Kanban, OKRs, Communities of Practice, Definition of Done, Definition of Ready und sogar die Begriffe Agile und Lean.


Auf einen ersten Blick kann ein solches Aufgeben "kontaminierter" Begriffe und Konzepte Sinn ergeben. Man erspart sich Konflikte und Prozessdiskussionen und kann das was man eigentlich erreichen will stattdessen unter einem anderen anderen Namen unverändert vorantreiben (z.B. DevOps statt Agile oder T-Shirt Size statt Story Points). Das Ausweichen in derartige Fluchtvarianten ist damit ein scheinbar bequemer Ausweg.


Auf den zweiten Blick werden allerdings Probleme sichtbar. Da die aufgegebenen Begriffe und Konzepte nicht verschwinden sondern von den "falschen Menschen" weiterhin verwandt werden kann es zu Auseinandersetzungen zwischen den Befürwortern verschiedener Ansätze kommen. Und das möglicherweise sogar wiederholte Ausweichen auf andere Benennungen kann zur so genannten "Euphemismus-Tretmühle" führen (mehr dazu hier).


Wesentlich zielführender ist es, den Konflikt anzunehmen und auf zivilisierte Weise auszutragen. Ein erster Schritt kann dabei sein zu erkennen, dass es gar keine "falschen Menschen" gibt sondern auch diese im Regelfall guten Intentionen und rationalen Erwägungen folgen. Auf dieser Basis herauszuarbeiten, dass die "Originalversionen" der agilen Frameworks eher zum Ziel führen als Blaupausen und Abkürzungen kann anstrengend sein, im Zweifel ist es aber der nachhaltigere Weg.


Selbst wenn das Ausweichverhalten stattgefunden hat ist ein Umsteuern noch möglich. Da die Deutungshoheit über die agilen Begriffe und Buzzwords mittlerweile ausserhalb der Unternehmen und Unternehmensberatungen liegt lässt sich eine missverstandene oder verdrehte Bedeutung auf Dauer kaum aufrechterhalten und kann korrigiert werden. Und auch dafür, dass es dafür nie zu spät ist sind die Ärzte ein gutes Beispiel: nach mehr als 10 Jahren Pause wird Männer sind Schweine mittlerweile wieder von ihnen gespielt.

Donnerstag, 11. November 2021

10 Jahre #NoEstimates (I)

Bild: Pixabay / Geralt - Lizenz

Die vermutlich kontroverseste unter den agilen Bewegungen hat Geburtstag: #NoEstimates (übersetzbar mit #KeineAufwandsschätzungen) wird 10 Jahre alt. Ein Jahrzehnt nach ihrer Gründung ist sie noch immer weit davon entfernt im Mainstream angekommen zu sein und wird das vermutlich auch in absehbarer Zeit nicht. Trotzdem hat sie leidenschaftliche Anhänger, so dass davon auszugehen ist, dass sie in ihrer Nische noch lange weiterbestehen wird.


Um diese Bewegung besser zu verstehen muss man sich eines bewusst machen: trotz ihres Namens wendet sie sich nicht explizit gegen Aufwandsschätzungen, lediglich gegen solche in Vorhaben die so sich so unvorhersehbar entwickeln, dass es sich nicht mehr um Schätzungen sondern um wildes Herumraten handelt. Woody Zuill, der Schöpfer von #Noestimates bezeichnete das im November 2011 in seinem ersten Artikel zu diesem Thema als "Wild Ass Guessing" (WAG), was inhaltlich deckungsgleich ist.


Um das plastischer zu machen: es gibt tatsächlich Vorhaben in denen derartige Rahmenbedingungen vorliegen, dass realistische Schätzungen nahezu unmöglich sind. Ein Beispiel wäre die Entwicklung eines neuartigen Online-Produkts bei dem nur die intensiv genutzten neuen Features weiterentwickelt, die weniger genutzten aber ausgebaut werden. Ein anderes, später von Zuill selbst erwähntes wäre die Reparatur eines uralten Systems mit hunderten von Bugs.


Jeder Versuch diese oder ähnliche Projekte mit Aufwandsschätzungen zu versehen würde lediglich in einem Haufen Datenmüll enden, da die Wissensgrundlage auf der die Aufwandsschätzungen stattfinden ständig wegbricht und sich in veränderter Form neubildet. Verhindern lässt sich das nicht, schliesslich lassen sich weder die Nutzungsintensität eines noch nicht gebauten Features noch der Reparaturaufwand eines noch nicht genau analysierten Bugs voraussagen. Und derartige Beispiele gibt es viele.


Es ist aber nicht nur so, dass Aufwandsschätzungen in solchen Fällen keinen Mehrwert bringen, sie können sogar schädliche Auswirkungen haben. Am offensichtlichsten dadurch, dass die für sie aufgewendete Zeit nicht mehr in die Umsetzung fliessen kann, aber auch durch zunehmenden Verwaltungsaufwand - verfehlte Schätzungen führen in vielen Organisationen zu Korrekturversuchen in Form von noch mehr Reporting und Planung, was nochmal mehr Arbeitszeit bindet.


Zielführender ist es in einem solchen Szenario einfach so lange weiterzuarbeiten bis das Ziel erreicht ist, etwa dann wenn die Interaktions- oder Zahlungsbereitschaft der Kunden ausgeschöpft ist (im Fall einer volatilen Produktentwicklung) oder dann wenn alle Bugs und Performanceprobleme der kritischen Systeme behoben sind (im Fall der Reparaturarbeiten am Altsystem). Natürlich nur im Rahmen eines verfügbaren Budgets, das aber bis zur Zielerreichung immer wieder verlängert werden kann.


Die Moral der Geschichte ist also, dass es bestimmte Vorhaben gibt in denen Aufwandsschätzung keinen Mehrwert bringen und stattdessen das Potential haben Schaden anzurichten, weshalb man sie besser ganz lassen sollte. Allerdings ist das nur der eine Teil von #NoEstimates, der andere ist (Überraschung!) eine Methode zur Schätzung von Aufwänden. Das ist nochmal eine eigene Geschichte und geht auch nicht mehr auf Zuill zurück, mehr dazu im bald folgenden Teil II (hier ist er).



PS: Natürlich gibt es noch eine andere, destruktive Art von "No Estimates", bei der es sich um die Verweigerung aller Aufwandsschätzungen handelt, also auch dann wenn sie möglich oder sinnvoll wären. Zur Abgrenzung davon erfolgt die Schreibweise seit 2012 in einem Wort und mit Hashtag.



Siehe auch:

Montag, 8. November 2021

Scaled Agile: Big Room Planning

Bild: Flickr / Marco Verch - CC BY 2.0

Es gilt als eines der Erkennungsmerkmale von SAFe, ist aber als verbreitete Praktik auch in anderen agilen Skalierungsframeworks zu finden, und sogar in manchen klassisch aufgestellten Organisationen als Teil ihrer Jahres- oder Quartalsplanung. Die Rede ist vom Big Room Planning oder BRP (mittlerweile in SAFe in PI Planning umbenannt), einer Veranstaltung die genutzt wird um die Backlogs oder Roadmaps der beteiligten Teams aufeinander abzustimmen.


Wichtig zu seinem Verständnis ist, dass es aus puristisch agiler Sicht eigentlich Ausdruck einer Dysfunktion ist, bzw. diese kompensiert. Agil arbeitende Teams sollen möglichst crossfunktional sein, d.h. alle zum Abschluss ihrer Vorhaben nötigen Fähigkeiten und Berechtigungen selbst besitzen. Dort wo das gegeben ist gibt es für übergreifende Planungsstrukturen keine Notwendigkeit. Da das in der Realität oft aber nicht gewollt oder möglich ist wurde das Big Room Planning erfunden.


Als eine agile Praktik wird es deshalb angesehen, weil es zwei Sachen anders macht als traditionelle Planungspraktiken. Zum einen werden von einander abhängige Arbeitspakete nicht sequentiell abgearbeitet (wie häufig in Gantt-Charts zu sehen) sondern weitgehend parallelisiert. Die zusammengehörigen Aufgaben werden dabei von den Teams in den selben Sprints oder Wochen eingeplant um bereits in ihnen zusammengeführt und integriert zu werden.


Das zweite agile Merkmal der Big Room Plannings ist, dass die Koordination der Teams nicht von einem dafür zuständigen Management übernommen wird sondern von den jeweiligen Teammitgliedern selbst. Um das möglich zu machen führen die beteiligten Teams ihre Planungsaktivitäten gemeinsam in einem grossen Raum durch (daher der Name)1 um sich bei Bedarf schnell besuchen und unbürokratisch miteinander abstimmen zu können.


Ein typischer Ablauf sieht so aus, dass bereits im Vorfeld grob geklärt wurde welche Arbeitspakete externe Zulieferungen benötigen (ggf. in teamübergreifenden Refinements). Basierend darauf können diese in einer initialen teamübergreifenden Vorstellungsrunde hervorgehoben werden, wodurch der Bedarf klargemacht wird. Zusätzlich können alle anderen überprüfen ob auch sie ebenfalls davon betroffen sein könnten.


In einer ersten Planungsrunde erarbeitet und priorisiert danach zuerst jedes Team für sich die eigenen Anforderungen und Zulieferungen, in einer zweiten Phase werden diese Ergebnisse den anderen Teams mitgeteilt und diesen wird die Möglichkeit zu Feedback und Änderungsvorschlägen gegeben, in einer dritten passt jedes Team basierend darauf seine Pläne an. Dieser Wechsel von Einzelplanung und Abstimmung kann so lange wiederholt werden bis ein gemeinsamer Plan herauskommt.


Als zusätzlicher Effekt können durch ein Big Room Planning nicht nur die Umsetzungs- sondern auch die Planungszeiträume deutlich verkürzt werden. Die teamübergreifend gemeinsame Terminierung, die direkte Kommunikation und die kurzen Wege können in Stunden oder Tagen ermöglichen, was vorher mitunter Wochen und Monate gedauert hat.2 Natürlich unter der Voraussetzung, dass alle Mitglieder aller beteiligten Teams für die gesamte Dauer der Veranstaltung zur Verfügung stehen.


Bereits für eine effizientere Durchführung der Planungen für bestehende Teams kann ein Big Room Planning auf diese Weise einen erheblichen Mehrwert liefern, zu einer nachhaltigen Agilisierung des Unternehmens trägt es aber paradoxerweise dadurch bei, dass es sich selbst nach und nach abschafft. Die in ihm offensichtlich werdenden Abhängigkeiten lassen sich nämlich festhalten und auf langfristige Muster untersuchen, die dann grundlage für Prozessverbesserungen sein können.


Wenn beispielsweise alle Teams jedesmal von einem einzelnen abhängen kann überlegt werden dessen Skills und Berechtigungen auf die anderen zu übertragen (wenn es ein Spezialistenteam ist) oder seine Systeme für die Bearbeitung durch andere zu öffnen (wenn es ein Komponententeam ist). Andere denkbare Verbesserung wären die Vergrösserung von Flaschenhals-Teams oder das Aufteilen eines Teams (und seiner Systeme) analog zu fachlichen Domänen.


Als Folge derartiger Optimierungen werden Big Room Plannings häufig mit der Zeit kleiner oder teilen sich in voneinander unabhängige "Small Room Plannings" auf. Umgekehrt kann ein mit der Zeit immer grösser werdendes Big Room Planning ein Zeichen dafür sein, dass die Zahl der Abhängigkeiten zwischen den Teams wächst und die Gesamtorganisation dadurch schwerfälliger wird. Sicherlich eine weitere interessante Transitionsmetrik.



1Eine Durchführung in Video Calls ist auch möglich, ist erfahrungsgemäss aber weniger effizient.
2Ich habe einen Fall erlebt bei dem in zwei Tagen geklärt wurde was zuvor immer ca. ein dreivierteljahr gedauert hatte.

Donnerstag, 4. November 2021

The agile Bookshelf: Cultish

Bild: Pxfuel - Lizenz

Ein Wort der Warnung vorweg: das hier ist ein düsteres Buch. In dem schlicht Cultish genannten Werk von Amanda Montell (hier geht es zu ihrer Website) geht es um Selbstmord-Sekten, Pyramidenspiele, Fitness-Besessenheit und um Fans im wahrsten Wortsinn (Fanatiker die ihrem Idol bedingungslos folgen, selbst wenn das nur ein Social Media-Sterchen ist). Dass all das irgendeine Gemeinsamkeit mit agilem Produkt- und Projektmanagement haben soll klingt zuerst abwegig - und doch gibt es eine.


Das was für Montell ein entscheidendes Erkennungsmerkmal eines Kults ist (egal ob es ein religiöser Kult ist oder die Anhängerschaft eines Kult-Produkts oder einer Kult-Figur) ist die Sprache. An zahlreichen Beispielen zeigt sie auf nach welchen Mustern sich diese entwickelt und immer stärker ausdifferenziert, bis zu dem Punkt an dem normale Menschen sie nicht mehr verstehen. "Kultisch" ist für sie kein Adjektiv sondern eine Sprachen-Bezeichnung, wie Spanisch oder Schwedisch.


Diese Sprache wird (oft bewusst aber häufig auch unbewusst) entwickelt um bestimmte Zwecke zu erfüllen. Einer davon ist es zum Beispiel, die eigene Bewegung cool oder mysteriös erscheinen zu lassen und damit attraktiv für Neumitglieder. Häufig dafür eingesetzte Stilmittel sind Abkürzungen und Wörter aus exotischen Sprachen, wobei beide möglichst selbstverständlich und ohne Erklärung in die tägliche Alltagssprache integriert werden.


Neben dieser Aussenwirkung entfaltet sich gleichzeitig auch eine zweite, die nach innen gerichtet ist. Die Abkürzungen und Fremdwörter als einzige zu kennen kann ein Gefühl der Zusammengehörigkeit und der Abgrenzung nach aussen erzeugen. In der Soziologie spricht man in diesem Zusammenhang von "In Groups" und "Out Groups" wobei sich innerhalb einer In Group nochmal weitere, kleinere In Groups befinden können, mit noch exklusiverem Wortschatz.


Diese Verschachtelung hilft wiederum dabei Neumitglieder und bestehende Mitglieder möglichst lange an die eigene Gruppe zu binden. Das Entdecken und Erlernen immer neuer Fach- und Fremdbegriffe sorgt nicht nur für eine möglichst lange und intensive Beschäftigung der Angehörigen mit ihrem Kult sondern kann darüber hinaus eine spannende und informative Lernreise sein. An dieser Stelle gibt es also durchaus positive Effekte, die Grenzen zwischen Kult und Didaktik verschwimmen.


Neben diesen positiven oder neutralen Begriffen (gering ausdifferenzierte In Groups sind etwas Alltägliches, z.B. Familien und Schulklassen) stehen aber auch kritischer zu sehende, wie z.B. "Loaded Language". Dabei erhalten alltägliche Begriffe eine abwertende oder verdrehte Bedeutung die nur Eingeweihte kennen. Sowohl als (wertende) Zusatzinformation als auch als Ersatz für den bisherigen Begriffsinhalt laden sie eine scheinbar nomale Unterhaltung mit Subtext auf.


Vollends ins Negative kippt die kultische Sprache schliesslich bei den "Thought-terminating Clichés", womit Aussagen mit sehr einfacher und eindeutiger Botschaft gemeint sind die nicht bezweifelt werden können ohne dass die Gefahr besteht von den anderen Kultmitgliedern als Abtrünniger angesehen zu werden. Ein Beispiel wäre "alle wahrhaft Gläubigen erkennen, dass diese Aussage wahr ist". Das kann nicht mehr hinterfragt werden ohne den eigenen Status angreifbar zu machen.


Wer sich häufig in der agilen Community aufhält wird an dieser Stelle bereits vieles wiedererkannt haben. Selbst wenn Amanda Montell selber nicht auf die Buzzwords der agilen Frameworks und Denkschulen eingeht - die von ihr beschriebenen Phänomene (nicht nur die gerade erwähnten sondern noch viele weitere) lassen sich problemlos von den anderen Kulten hierher übertragen. Falls daran noch Zweifel bestehen - bitte, gehen wir ins Detail.


Abkürzungen und Fremdwörter? Gibt es, zu den bekannteren gehören OKRs und Kanban. In Group und Out Group? Natürlich, dass sind die agil und "klassisch" arbeitenden Menschen. In Groups in der In Group? Finden sich z.B. bei Team die nicht nur Scrum machen sondern "sogar Extreme Programming". Loaded Language? Ausserhalb der "agilen Filterblase" ist Wasserfall eine neutrale Beschreibung. Thought-terminating Clichés? Finden sich u.a. in der Zu- und Absprechung des "Agilen Mindset".


Das heisst natürlich nicht, dass alle Agilisten verblendete Fanatiker mit einer sektenartigen Sprache sind, das wäre dann doch übertrieben. Aber etwas das man aus Cultish in die "agile Alltagswelt" mitnehmen kann ist die Erkenntnis, dass fast alle dort beschriebenen Bewegungen harmlos angefangen haben, sich dann aber durch eine Wechselwirkung aus immer kultischer werdender Sprache und immer extremeren Ansichten radikalisiert haben.


Bis zu einem bestimmten Grad kann kultische Sprache noch Kommunikation effektiver machen, Zusammengehörigkeitsgefühl erzeugen, hip sein und sogar selbstironisch benutzt werden, bis dahin ist das auch noch völlig unproblematisch. Was bleibt ist aber die Warnung davor es nicht zu übertreiben. Selbst wenn die agile Bewegung ganz sicher nie zu einer Selbstmord-Sekte werden wird - bereits das bewusste oder unbewusste Ausgrenzen anderer Menschen wäre schon nicht mehr im Sinn der Idee.

Montag, 1. November 2021

Kommentierte Links (LXXX)

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

Steve Denning: Why ‘Big Bang’ Agile Transformations Are A Bad Idea

Die meisten Menschen die schon einmal in einer agilen Transformation mitgearbeitet haben werden Steve Denning vermutlich zustimmen: ein gesamtes Unternehmen in einem einzigen Grossprojekt umzubauen ist eine eher schlechte Idee, vor allem wenn damit ein einziger Stichtag verbunden ist, ab dem auf einmal alles anders funktionieren soll als vorher. Die Realität ist aber, dass es immer wieder versucht wird, derartige Vorhaben passen einfach zu gut zu den Planungs- und Budhetierungs-Routinen grosser Organisationen. Denning macht etwas Verdienstvolles und versachlicht diese Diskussion indem er reale Fälle betrachtet, darunter auch den der ING, der in den letzten Jahren häufig als Beispiel für eine gelungene Transformation genannt wird.

Bent Flyvbjerg: Make Megaprojects More Modular

Ein häufiges Argument gegen kleine, flexible Planungs- und Durchführungsprozesse ist, dass diese nur in eher kleinen Vorhaben möglich wären, in grossen gäbe es zu viele zu berücksichtigende Faktoren und Abhägigkeiten, die einen langem Planungsvorlauf und eine sich eng daran orientierende Ausführung erfordern würden. Bent Flyvbjerg, ein Oxford-Professor dessen Forschungsschwerpunkt Grossprojekte sind, widerspricht dem deutlich. An drei Beispielen (dem Bau einer Autofabrik, dem Bau einer Ubahn-Linie und der Entwicklung eines Satelliten) zeigt er auf, dass die in vielen agilen Teams üblichen Praktiken auch im Grossen anwendbar sind - wenn man es denn will.

Marty Cagan: Process People

Die aufkommende Product Operations-Bewegung scheint irgendetwas bei Marty Cagan getriggert zu haben. Mit Verweis auf sie eröffnet er eine alte Debatte erneut - braucht man wirklich diese ganzen Leute die sich nur um Projekt- und Prozessmanagement kümmern und keine "echte Arbeit" machen? Jenseits dieses steilen Aufhängers ist der Artikel durchaus ausgewogen (er macht am Ende klar, dass man diese "Prozessmenschen" trotz allem braucht), er zeigt aber drei zentrale Probleme der eher prozesslastigen Ansätze auf: 1.) in vielen Firmen sind Prozessmanager (oder Scrum Master, ProductOps, etc) eher Management-unerfahren, was der Bedeutung nicht gerecht wird, 2.) häufig werden dorthin nur Tätigkeiten abgeschoben die anderen Managern lästig sind, und 3.) formalisierte Prozesse neigen dazu ein Eigenleben zu entwickeln. Man kann ihm da nur schwer widersprechen.

Mike Cohn: Are Fixed-Price Projects Agile?

Irgendwann ist mal der Mythos in die Welt gesetzt worden, dass agile Produktentwicklung und fester Preisrahmen nicht kompatibel wären. Im agilen Vorgehen müsste man sich schliesslich immer anpassen können wenn die Realität sich ändert, was mit einem Fixpreis nicht möglich wäre. Mike Cohn zeigt in seinem Blog auf, dass das sehr wohl möglich ist, und das nicht nur auf praktischer sondern auch auf theoretischer Ebene. Zuerst macht er die richtige Feststellung, dass der kategorische Auschluss bestimmter Finanzierungskonstellationen selbst nicht sonderlich agil wäre, danach untersucht er das Gründungsdokument der agilen Softwareentwicklung, das agile Manifest, nach Unvereinbarkeitserklärungen. Spoiler: er findet keine.

Jeff Patton: Keep actual effort and outcome visible

Man könnte denken, dass irgendwann alle Möglichkeiten ein Board zu gestalten (das Informations-Werkzeug, nicht das Gremium) entdeckt worden sind. Tatsächlich gibt es aber immer wieder neue Ideen, die der Anwendung zusätzliche Dimensionen hinzufügen können. Diesesmal von Jeff Patton, mit dem Ziel im Produktmanagement Aufwand und Ergebnis miteinander zu verknüpfen.