Kommentierte Links (LXXVIII)

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.

Kevin Oakes: Let Your Top Performers Move Around the Company

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

Maarten Dalmijn: 11 Laws of Software Estimation for Complex Work

Den szenischen Einstieg in den Artikel und die darauf folgende Anekdote aus dem Leben eines Product Owners kann man lesen, man kann aber auch direkt zu den "11 Gesetzen der Aufwandsschätzungen in der Softwareentwicklung" springen die Maarten Dalmijn zusammengetragen hat, auch für sich genommen sind sie lesenswert.

1. The work still takes the same amount of time regardless of the accuracy of your estimate
2. No matter what you do, estimates can never be fully trusted
3. Imposing estimates on others is a recipe for disaster
4. Estimates become more reliable closer to the completion of the project. This is also when they are the least useful
5. The more you worry about your estimates, the more certain you can be that you have bigger things you should be worrying about instead
6. When you suck at building software, your estimates will suck. When you’re great at building software, your estimates will be mediocre
7. The biggest value in estimating isn’t the estimate but checking if there is a common understanding
8. Keeping things simple is the best way to increase the accuracy of estimates
9. Building something increases the accuracy of estimates more than talking about building it
10. Breaking all the work down to the smallest details to arrive at a better estimate means you will deliver the project later than if you hadn’t done that
11. Punishing wrong estimates is often like punishing a kid for something they don’t and can’t know yet

Wer Erfahrungen in klassischem Produktmanagement und klassischer Produktsteuerung hat wird erkennen, dass für jeden der so sozialisiert wurde diese 11 Gesetze hochgradig unintuitiv sind. Um so wichtiger sind die Erklärungen die hier zu jedem von ihnen geboten werden.

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

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

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

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

Uno de Waal: Implementing Scrum in an Editorial Workflow

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

The Daily Scrum Song

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

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

Product Operations

Bild: Pexels / RF._.studio - Lizenz

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

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

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

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

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

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

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

Zum weiteren Einarbeiten in das Thema bieten sich an:

• Pendo Product Collective: The Rise of Product Ops
• Melissa Perri (Podcast): Answering Questions about Complex Product Problems
• Christine Itwaru: Why Product Operations is the Next Iteration in Product Management
• Joshua McLaughlin: Product Operations - From zero to one
• Cheryl Michael: Why Product Leaders Need Product Operations

Software is still eating the world

Grafik: Pxfuel - Lizenz

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

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

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

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

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

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

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

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

Grafik: Pixabay / Revzack - Lizenz

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

I. Bau Deine Reputation auf

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

II. Verteile vergiftetes Lob

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

III. Prangere vermeintliche Unzulänglichkeiten an

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

IV. Hebe einzelne bekannte Negativ-Beispiele hervor

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

V. Immunisiere Dich

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

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

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

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

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

Chaos

Bild: Pixabay / Geralt - Lizenz

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

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

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

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

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

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

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

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

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

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

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

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

The agile Bookshelf: Dynamic Reteaming

Bild: Pixabay / Metsik Garden - Lizenz

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

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

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

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

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

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

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

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

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

Stacey Matrix

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

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

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

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

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

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

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

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

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

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

Brauchbare Illegalität als Organisationskultur

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

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