Mittwoch, 31. März 2021

Kommentierte Links (LXXIII)

Grafik: Pixabay / The Digital Artist - Lizenz

Henning Kagermann, Wolfgang Wahlster: Zehn Jahre Industrie 4.0

Mit dem Begriff Industrie 4.0 geht es mir vermutlich so wie anderen Leuten mit dem Begriff Agil - ich ahne, dass eine grundsätzlich gute Idee dahintersteckt, nehme aber vor allem Buzzwords wahr. Um so dankbarer bin ich, dass die beiden Erfinder sich zum zehnjährigen Jubiläum des initialen Artikels Industrie 4.0: Mit dem Internet der Dinge auf dem Weg zur 4. industriellen Revolution die Zeit genommen haben noch einmal aufzuschreiben was genau ihre Intention war. Die zwei zentralen Aussagen sind dabei "Die Vernetzung von Menschen, intelligenten Objekten und Maschinen, die Nutzung serviceorientierter Architekturen, die Komposition von Diensten und Daten aus unterschiedlichen Quellen zu neuen Geschäftsprozessen" und "Eine besseren und sinnvolleren Mensch-Maschine-Kooperation ohne Angst vor Kontrollverlust". Noch immer leicht sperrige Sätze, aber solche die man voll unterschreiben kann.

Ross Clanton, Amy Walters: Culture and Leadership

Mit diesem Artikel haben Clanton und Walters ihre Serie The Seven Domains of Transformation zu einem würdigen Höhepunkt und Ende geführt. Das was sie hier über Incentivierung, Fehler- und Lernkultur, Lern- und Austauschformate und zu überwindende alte Gewohnheiten schreiben ist zwar nicht grundlegend neu, es fasst aber viele gute Ideen und bewährte Konzepte gut lesbar zusammen. Auch der häufige Gegensatz von "Bottom up-" und "Top Down"-Initiativen im Change Management wird angesprochen, mit der originellen aber in der Umsetzung anspruchsvollen Lösung, dass dabei das (überzeugende) Zielbild von oben vorzugeben ist, die Umsetzung aber von unten zu erfolgen hat. Insgesamt ein guter Impuls nicht nur zum selber Lesen sondern auch zum Weitergeben an alle Führungskräfte.

Rob Cross, Heidi K. Gardner, Alia Crocker: For an Agile Transformation, Choose the Right People

Die Frage mit welchen Mitarbeitern man ein agiles Pionier-, Transformations- oder Vorzeigeteam besetzen sollte ist einer der grossen Klassiker wenn Unternehmen ihre Strukturen und Prozesse beweglicher machen wollen. Rob Cross, Heidi K. Gardner und Alia Crocker haben dazu einige lesenswerte Gedanken zusammengefasst, darunter auch solche die der gängigen Mehrheitsmeinung widersprechen. Dass derartige Teams nicht ausschliesslich aus zu hundert Prozent verfügbaren Personen zusammengesetzt werden sollten erscheint zum Beispiel zuerst widersinnig, wenn man bedenkt, dass die besten Leute aber (zumindest zu Beginn) nicht ganz zu haben sein werden macht es durchaus Sinn. Ein kleiner Zusatz-Ratschlag: der Artikel erhält ausklappbare Textboxen - auch die sind durchaus einen näheren Blick wert.

Rajiv Prabhakar: Wie sich Softwareverrottung verhindern lässt

Die Lösung die sich Rajiv Prabhakar überlegt hat könnte man auch mit einem Wort zusammenfassen: Refactoring. Sein Text geht allerdings auf verschiedene Details vertieft ein, so dass es trotzdem Sinn macht ihn zu lesen. Zum Einen gibt er anschauliche Beispiele dafür wie "Software Rot" entsteht (btw: gibt es dafür nicht eine bessere Übersetzung als "Softwareverrottung"?) und mit welchen Kosten und Risiken sie verbunden ist, zum Anderen hat er einen durchaus kontroversen Lösungsvorschlag: in bestehenden Systemen sollte permanent irgendetwas verändert werden, selbst wenn es dafür keine fachliche oder technische Notwendigkeit gibt. Der Grund dafür es trotzdem zu tun ist der, dass dadurch im kollektiven Gedächtnis der Organisation das für Erhaltung und Betrieb relevante Wissen ständig aufgefrischt wird. Das wirklich Verrückte daran ist aber nicht seine Idee selbst - es ist die Vermutung, dass das tatsächlich die insgesamt wirtschaftlichste Lösung sein könnte.

Barry O’Reilly: The Metrics Of Digital Transformation: Small Steps to Outcome-Based Innovation

Ein Beitrag der Vieles in sich vereint. Eine traurige Bestandsaufnahme grosser Transformationsforhaben, einen Seitenhieb gegen SAFe, einen Aufruf zur Subversivität, Plädoyers für Transparenz und Datengetriebenheit, ein Hoffnung machendes Praxisbeispiel und einen Ausblick in eine bessere Zukunft. Da sollte für jeden etwas dabei sein.

Montag, 29. März 2021

Biggest Bottleneck Ever Given

Bild: Wikimedia Commons / NASA - Public Domain
Es ist immer hilfreich wenn man komplexe Sachverhalte mit nachvollziehbaren Analogien erklären kann, selbst wenn diese auf eher unerfreulichen Ereignissen beruhen. Seit März 2021 sind wir um eine solche Analogie reicher, und zwar aufgrund eines der folgenschwersten Verkehrsunfälle der Menschheitsgeschichte. Sein Schaden dürfte in die Milliarden gehen, aber immerhin - durch ihn können wir die Risiken von Flaschenhälsen in Wertströmen so anschaulich erklären wie nie zuvor.


Gegenstand dieser Geschichte ist das Container-Frachtschiff Ever Given, das am 23.03. beim Passieren des Suez-Kanals so unglücklich von einem Sandsturm getroffen wurde, dass es sich quer stellte und an beiden Enden auf Grund lief, wodurch der Kanal, die bedeutenste Wasserstrasse der Welt, tagelang blockiert wurde. Zahllosen anderen Schiffen blieben dadurch nur zwei Möglichkeiten: bis zur Befreiung der Ever Given warten oder den zehn Tage längeren Umweg um Afrika nehmen.


Verschiedene Aspekte lassen sich für Vorträge oder Workshops verwerten. Zunächst ein häufig übersehener: ein Flaschenhals ist nicht zwingend die einzige Stelle durch die ein Wertstrom fliessen kann, es ist aber die schnellste oder wirtschaftlichste. Andere können zwar existieren (in diesem Fall die Route um Afrika) gleichwertige Alternativen sind sie allerdings wegen der mit ihnen verbundenen zusätzlichen Aufwände nicht.


Ein weiterer Punkt der sich anhand der Suez-Blockade gut vermitteln lässt ist das mit Flaschenhälsen verbundene Risiko: ein einziger feststeckender "Liefergegenstand" kann weitreichende Auswirkungen haben. Darüber hinaus lassen sich auch Schwarze Schwäne mit ihr veranschaulichen, also Risiken die praktisch nicht vorhersehbar waren. Dass ein so grosses Schiff hier auf Grund laufen könnte war aus gutem Grund nicht zu ahnen - bis 2018 gab es einfach noch keine in dieser Grössenordnung.


Ebenfalls gut mit diesem Beispiel zu erklären sind die beiden eigentlich abstrakten Konzepte von totem Kapital und Cost of Delay. Dass die Ladungen der über 350 an ihrer Weiterfahrt gehinderten Frachtschiffe dem Wirtschaftskreislauf entzogen (und damit "tot") sind dürfte auch für Nicht-Wirtschaftswissenschaftler offensichtlich sein, und für die Verspätungskosten gibt es sogar eine Zahl: mehr als zehn Milliarden dürfte der wirtschaftliche Gesamtschaden am Ende betragen.


Bild: ESA, Contains modified Copernicus Sentinel data 2021 - CC BY-SA 3.0 IGO


Es sind aber nicht nur die negativen Seiten von Flaschenhälsen die sich anhand des Unfalls der Ever Given erzählen lassen, auf der anderen Seite sind es auch die möglichen Arten mit diesem Risiko umzugehen. Die naheliegendste davon dürfte sein, den Engpass zu erweitern, etwa im Fall des Suez-Kanals durch eine zweite Fahrrinne. Das ist zwar in der Umsetzung teuer, im Vergleich zu möglichen Unfallkosten (siehe oben) aber ggf. zu rechtfertigen. (Nachtrag 11.05.: so ist es gekommen)


Auch die Sinnhaftigkeit kleinerer Lieferpakete lässt sich hier darstellen: zum einen würde bei vielen kleineren Schiffen nur ein Teil des zu liefernden Werts von einem blockierten Flaschenhals betroffen sein, zum Anderen kann davon ausgegangen werden, dass diese kleineren Fahrzeuge nur einen Teil der Engstelle blockieren würden - oder aufgrund ihrer geringeren Grösse äusseren Einflüssen (wie dem Sandsturm) eine viel kleinere Angriffsfläche bieten würden.


Wie alle Analogien hat natürlich auch die der Suez-Blockade ihre Grenzen, als plakativer und leicht nachvollziehbarer Einstieg in den Themenkomplex Flaschenhälse und Wertströme ist sie aber definitiv verwendbar. Ein vertiefteres Eingehen ist danach ja noch immer möglich. Und als eingängiges Schaubild dürfte die quer im Kanal steckende Ever Given geeignet sein wie wenige sonst.



Donnerstag, 25. März 2021

Krabbenkörbe

Bild: Wikimedia Commons / USEPA - CC0 1.0

Zu den einfachsten und stärksten Metaphern für die Schwierigkeiten die die Menschen sich gegenseitig bereiten gehört die des Krabbenkorbes. Die in einer solchen Falle gefangenen Krabben versuchen zwar zu entkommen, da jede sich an den jeweils anderen hochziehen und auf ihnen abstützen will behindern sie sich gegenseitig aber so sehr, dass alle gefangen bleiben. Die Übertragung auf die Gesellschaft liegt nahe: statt sich gegenseitig zu helfen ziehen die Menschen sich gegenseitig herunter.


Allerdings: so offensichtlich diese Deutung auf den ersten Blick auch erscheinen mag, bei einer näheren Betrachtung bietet sich ein ungleich komplizierteres Bild. Zum einen sind die Menschen zum Glück deutlich besser als ihr Ruf, zum anderen ist es aber leider doch so, dass sich in der Realität (und hier vor allem in der Arbeitswelt) immer wieder Krabbenkörbe beobachten lassen. Das wirkt zunächst widersprüchlich, lässt sich aber erklären.


Zunächst zur Natur des Menschen. Selbst wenn es unbestreitbar ist, dass es missgünstige und zur Sabotage neigende Charaktere gibt, sind in der Biologie, Psychologie und Soziologie immer wieder Belege dafür gefunden worden, dass es auch einen weitverbreiteten Drang zum selbstlosen Helfen gibt, der sich in vielfältiger Form manifestiert, von der religiös begründeten Nächstenliebe über staatliche Sozial- und Stipendiensysteme bis hin zu den unterstützenden Positionen in Mannschaftssportarten.


Die gleichzeitig beruhigende und beunruhigende Erkenntnis die sich hieraus ziehen lässt: dort wo es zu den Effekten des gegenseitigen Herunterziehens kommt handelt es sich um kein naturgegebenes Schicksal, die Ursache muss an anderer Stelle liegen. Und wenn die menschliche Natur wegfällt bleibt eigentlich nur ein anderer möglicher Entstehungsgrund übrig - das die Menschen umgebende soziale System, das durch seine Rahmenbedingungen das Verhalten seiner Angehörigen formt.


Hat man sich einmal auf diesen Gedanken eingelassen wird man vor allem in grossen Organisationen zahlreiche Beispiele finden, etwa dort wo Softwareentwicklungs-Organisationen in Programmier- und Test-Abteilungen getrennt sind. Während dort ein Entwickler in der Regel für einen möglichst frühen Code Freeze belohnt wird erhält der Tester seine Anerkennung oft dafür, dass er bis zum letztmöglichen Zeitpunkt nach Fehlern sucht. Und derartig gegenläufige Ziele sind kein Einzelfall.


Einkaufs-Mitarbeiter werden meistens angehalten externe Arbeitskräfte möglichst billig einzukaufen, während intern möglichst gute (und damit teure) externe Kollegen gebraucht werden. Von Vertriebs-Einheiten werden hohe Umsätze durch neue Features verlangt, während die Teams in der Anwendungs-Entwicklung mehr Ressourcen für Refactoring brauchen um ihre Stabilitätsziele zu erreichen. Etc. Die aus diesen und vergleichbaren Fällen entstehende gegenseitige Behinderung ist absehbar.


Auf den ersten Blick scheint diese Betrachtung tragisch zu sein, werden hier doch eigentlich altruistische Mitmenschen durch Systemzwänge in eine gegenseitige Sabotage getrieben, die sie von sich aus nie anstreben würden. Auf den zweiten Blick ist das Erkennen dieser Zusammenhänge aber Grund zum Optimismus: es ist möglich die Krabbenkorb-Mentalität verschwinden zu lassen - man muss dafür nur die Rahmenbedingungen verändern.

Montag, 22. März 2021

Hybrid

Bild: Pixabay / Krefe - Lizenz

Es ist fast schon ein Naturgesetz. Bei praktisch jeder Unternehmenstransformation in Richtung Agilität kommt früher oder später jemand auf die Idee, dass man doch auch ein "hybriden" Ansatz wählen könnte. Gemeint ist damit in der Regel eine Mischung aus klassischen und agilen Vorgehensweisen, gewissermassen "das Beste aus beiden Welten". Das mag auf den ersten Blick auch verlockend wirken, zeugt in Wirklichkeit aber nur von einem grossen Missverständnis.


Um zu verstehen warum das so ist, ist ein Schritt zurück nötig, zur Frage was Agilität eigentlich bedeutet. Kurz gesagt: es ist die Fähigkeit in kurzen Abständen Mehrwert zu liefern und auf Änderungen zu reagieren. Und da davon ausgegangen wird, dass die Rahmenbedingungen sich ständig ändern muss ständig aufs Neue daran gearbeitet werden agil zu werden oder zu bleiben. Mit anderen Worten - es ist ein Zielbild. Das kann sowohl mit den bestehenden Prozessen und Strukturen erreicht werden als auch mit neuen, Hauptsache es funktioniert.


Im Gegensatz dazu sind die meistens als "klassisch" bezeichneten Ansätze deutlich stärker deskriptiv ausgestaltet. In ihnen wird in zum Teil erstaunlichem Detaillierungsgrad vorgegeben wer wann was zu tun hat, wie und wo er das zu dokumentieren hat, wem er davon zu berichten hat und was dieser mit den erhaltenen Informationen zu tun hat. Die Einhaltung dieser Vorgaben wird in den meisten Organisationen regelmässig überprüft und eine Abweichung sanktioniert.


Was durch diese Gegenüberstellung klar wird ist, dass "Agil" und "Klassisch" nicht nur unterschiedliche Methoden sind sondern grundsätzlich verschiedene Konzepte. Agilität definiert sich durch einen Zielzustand, der mit sich ständig ändernden Mitteln verfolgt und wiederhergestellt werden muss, klassische Vorgehensmodelle legen dagegen sehr klar die Abläufe und Strukturen fest, die bereits im hier und jetzt dem finalen Zielbild entsprechen und sich nur noch möglichst wenig ändern sollen.


Bedingt durch diese Unterschiede führt der Versuch hybride Ansätze zu etablieren in praktisch allen Fällen in nicht lösbare Konflikte. Einen Umsetzungsweg zur selben Zeit zu standardisieren und ihn möglichst offen und flexibel zu lassen ist einfach nicht möglich. Im Ergebnis wird entweder eine der beiden Seiten sich durchsetzen oder es wird zu einem ständigen Hin und Her kommen, auf Kosten von Nerven und Ressourcen.


Diese Zusammenhänge zu erkennen und zu vermitteln kann übrigens nicht nur vorbeugend sinnvoll sein. Die meisten festgefahrenen oder scheiternden Transitionsvorhaben befinden sich ebenfalls wegen dem (sicher gut gemeinten) Versuch hybrid vorzugehen in diesem Zustand. Sich davon zu lösen kann der entscheidende Schritt sein um wieder Fahrt aufzunehmen.

Donnerstag, 18. März 2021

Agile Manufacturing

Bild: Wikimedia Commons / Ron Clausen - CC BY-SA 4.0

Man kann sich das Erstaunen vorstellen mit dem am Anfang auf dieses "agile Arbeiten" reagiert wurde. Kleine, selbstorganisierte Teams, flache Hierarchien, direkte Kommunikation und reaktive, datengetriebene Verbesserungsprozesse passten auf den ersten Blick so gar nicht zu den bewährten Strukturen. Aber sobald die Effektivitätsgewinne sichtbar waren gab es kein Halten mehr - sogar grosse Traditionskonzerne wollten plötzlich agil sein, an Hochschulen wurde zu dem Thema gelehrt und publiziert und selbst die staatliche Wirtschaftsförderung sah in Agilität die Zukunft der Wirtschaft.


Jetzt zur Preisfrage: wann haben sich die hier beschriebenen Ereignisse zugetragen? Ab 2001, nach dem Verfassen des Agilen Manifests? Ab 2011, nachdem mit SAFe und LeSS die ersten Skalierungsframeworks entstanden sind? Oder zu einer ganz anderen Zeit? Die überraschende Antwort ist die dritte - der Trend setzte deutlich früher ein, nämlich ca. 1990. Und noch überraschender: der Anwendungsschwerpunkt war (noch) nicht die IT sondern die Fertigungsindustrie, in der "Agile Manufacturing" betrieben wurde. Kaum jemand weiss von dieser erste Blütezeit der Agilität, und doch hat sie existiert und es selbst in namhafte Medien wie die New York Times, den Chicago Tribune und das MIT Sloan Review geschafft.


Was aus diesen Artikeln hervorgeht ist eine erstaunlich grosse Verbreitung. Unter anderem haben Ford, Motorola, Boeing, Apple, Siemens, IBM, General Motors, General Electric, Goodyear und Chrysler in ihren Fabriken agil gearbeitet, das amerikanische Verteidigungsministerium hat diese Arbeitsweise zum Bestandteil von Ausschreibungen gemacht und an Universitäten sind ganze Forschungsinstitute entstanden die sich wissenschaftlich mit diesem Thema auseinandergesetzt haben. Sogar die staatlichen Wirtschaftsförderungen in Amerika, der europäischen Union und Japan scheinen das Konzept gekannt und gefördert zu haben.


Auch inhaltlich entsprach der Begriff der Agilität schon weitgehend dem was wir heute darunter verstehen. Die Berichte beschreiben zwar auch einiges was man heute eher in die Konzepte der Lieferketten-Optimierung, des Lean Management und der Digitalisierung einordnen würde, die übergreifende Idee ist aber die, die bis heute aktuell ist: Agilität als die Fähigkeit schnell und mit wenigen Reibungsverlusten auf sich ändernde Rahmenbedingungen zu reagieren. Und Umsetzungs-Elemente wie Teams von maximal 10 Mitgliedern und die Nutzung von Monitoring-Ergebnissen zur Prognostizierung von Wartungsbedarf könnten so auch aus Scrum und DevOps kommen.


Angesichts dieser scheinbaren Kontinuität ist es um so erstaunlicher, dass die Verwendung des Namens Agile Manufacturing Ende der 90er Jahre scheinbar aufgegeben wurde. Ab ca dem Jahr 2000 sind kaum noch Veröffentlichungen und Medienberichte zu finden, in der jüngeren Vergangenheit gar keine mehr. Über die Gründe kann nur spekuliert werden. Vielleicht wurde Agilität durch das agile Manifest nur noch als IT-Idee wahrgenommen, vielleicht wurde sie in der Fertigungsindustrie nach einer zu starken Hype-Phase als Mode-Phänomen verworfen, vielleicht wurden die Prinzipien und Praktiken aber auch so sehr zur Normalität, dass sie keinen Namen mehr brauchten. Man weiss es nicht.


Was heute aufgrund dieses damals stattgefundenen "kollektiven Anmesie-Vorfalls" zu beobachten ist, ist jedenfalls vor dem Hintergrund der Geschichte hoch paradox - jedesmal wenn eine der alle paar Jahre wiederkehrenden Initiativen durch die Unternehmen läuft, dass doch auch die Hardware-Fertigung agile Vorgehensweisen übernehmen könnte, wird dem an vielen Stellen mit Skepsis begegnet. Es wäre doch gar nicht klar ob ein "so neumodischer" und "aus der IT kommender" Ansatz sich hier umsetzen liesse. Dass in Fabriken bereits agil gearbeitet wurde als in der IT noch niemand diesen Begriff benutzte überrascht dann fast jeden der davon hört.


Zwar braucht es die "historische Untermauerung" nicht um in diesen Diskussionen die Vorteile der agilen Frameworks herauszustreichen, die sprechen bereits ausreichend für sich. Das was man aber machen könnte ist, die Ereignisse der 90er Jahre für die begleitende Kommunikation zu nutzen. "Take agile back to the roots", "Agile is coming home" oder "Don't follow the hypes, stick to Agile Manufacturing" wären doch grossartige Kampagnen-Slogans, oder?.

Montag, 15. März 2021

Das Problem mit SAFe (III)

Bild: Pexels / Andrea Piacquadio - Lizenz

Über die Herausforderungen und Fallstricke die sich ergeben wenn man versucht das Scaled Agile Framework (SAFe) in einem Grossunternehmen einzuführen1 ist mittlerweile so viel gesagt worden, dass man darüber ganze Bücher schreiben könnte. Die meisten davon würden sich aber sehr einseitig um die Debatte drehen ob ein Konstrukt mit so viel Regulierung und so vielen Rollen überhaupt agil sein kann2 und einen weiteren, vermutlich sogar tiefgreifenderen Aspekt dabei erstaunlich vernachlässigen.


Es handelt sich um die Frage ob die oft negative Wahrnehmung von SAFe nicht mittlerweile Züge einer selbsterfüllenden Prophezeihung hat. Von der überwältigenden Mehrheit der vom Konzept der Agilität überzeugten Angehörigen der unteren Hierarchie-Ebenen schlägt SAFe heute eine hohe Skepsis entgegen, zum Teil sogar eine vehemente Ablehnung.3 Wie berechtigt das ist, ist dabei gar nicht relevant, wichtig ist die Wahrnehmung selbst.


Deren mittlerweile weite Verbreitung resultiert darin, dass auf Team- oder Abteilungsebene selbstorganisierte Optimierungsbemühungen praktisch nie dazu führen, dass dort SAFe als Lösungs- oder Verbesserungs-Option für Koordinations- oder Alignment-Probleme genannt wird. Wenn es diskutiert wird dann fast ausschliesslich auf Betreiben von Beratern oder Managern. Aus Sicht der umsetzenden Einheiten kommt es damit "von Aussen".


Wer bereits Change Management in grossen Organisationen betrieben hat wird das an derartigen Stellen entstehende Risiko kennen: das Gefühl von Aussen eine ungewollte Änderung aufgedrückt zu bekommen kann zu Abstossungsreaktionen führen, manchmal in Form von aktivem Widerspruch und Widerstrand, oft durch passive und ausweichende Handlungsmuster wie dem ständigen Melden von Verständnis-Poblemen, Dienst nach Vorschrift und brauchbarer Illegalität.


Alle Varianten sind bereits für sich genommen problematisch, im Kontext des agilen Arbeitens, das stark auf freiwillige Kooperation und Eigeninitiative aller Beteiligten angewiesen ist, sind sie es nochmal in besonderer Form. Die in vielen SAFe-Umsetzungen zu findenden hohen Ausmasse am Konfliktlastigkeit, Ineffektivität und Ineffizienz lassen sich in weiten Teilen damit erklären, ggf. noch verschärft durch Versuche die Einführung zu erzwingen oder den Mitarbeitern ihre Bedenken auszureden.


Heisst das, dass eine Einführung von SAFe dort wo es diese Skepsis gibt unmöglich ist? Nein, natürlich nicht, das wäre auch zu deterministisch. Um die selbsterfüllende Prophezeihung zu vermeiden kann es aber sehr sinnvoll sein vor (!) einer Entscheidung für dieses Framework mit allen Beteiligten die Gründe für und gegen agile Skalierung zu besprechen und gemeinsam nach einem passenden Ansatz zu suchen. Der kann dann SAFe sein, aber ggf. auch ein anderer, dem deutlich weniger Skepsis entgegenschlägt und mit dem man dadurch einfacher und schneller seine Probleme lösen kann.


1Für kleinere Einheiten ist es nicht gedacht 
2Was weniger einfach zu beantworten ist als viele denken
3Eine Entwicklung die durch skeptische Äusserungen vieler "Thought Leader" befeuert wird

Donnerstag, 11. März 2021

Agile Prozesse

Grafik: Pixabay / Geralt - Lizenz

"Wir haben keinen Prozess, wir arbeiten agil", ist einer der grossen Klassiker, den man von vielen Teams hört wenn man sie fragt wie sie ihre Arbeitsabläufe organisieren. Häufig wird diese Aussage ergänzt durch eine zweite: "Wir arbeiten stattdessen nach Scrum." (oder Kanban oder XP). Eine schwierige Selbstwahrnehmung. Selbst wenn sie für einen Agilisten auf den ersten Blick naheliegend wirkt - tatsächlich zeugt sie von einigen Missverständnissen.


Um mit dem naheliegendsten anzufangen: natürlich gibt es einen Prozess. Sobald man eine Tätigkeit ausübt die auch nur in Ansätzen widerholbare oder vergleichbare Ergebnisse erzeugt wird es fast zwangsläufig sein bestimmte Schritte regelmässig zu wiederholen. In einem berechenbaren Umfeld kann das z.B. standardisierte Akkord-Arbeit sein, in einem unberechenbaren Umfeld ein schneller Wechsel von kleinteiliger Mehrwerterzeugung und schnellen Überprüfungs- und Anpassungsschritten.


Was beidem gemeinsam ist (und allen dazwischen liegenden Abstufungen auch) - es handelt sich dabei um einen Prozess im wahrsten Sinne des Wortes, also eine Aneinanderreihung definierter Ver- oder Bearbeitungsschritte mit dem Ziel ein Produkt oder eine Dienstkeistung zu erzeugen. Selbst die häufig postuliertes Alternative "ich überlege einfach bei jeder neuen Aufgabe was das sinnvollste Vorgehen sein könnte" ist bei näherer Betrachtung nichts anderes.


Was lediglich die Besonderheit im zuletzt genannten Beispiel (und bei Scrum, Kanban, XP, etc.) ausmacht ist, dass diese Prozesse relativ minimalistisch sind. Es gibt nur wenige harte Regeln wie die Lieferung in Sprints oder die  WIP-Limits, und es bleibt den Anwendern selbst überlassen wie deren Einhaltung sichergestellt wird. Das wirkt wie laissez-faire, ist aber im Grunde besonders rigoros - der Hintergrund dieser Freiheit ist, dass jedes Mittel zulässig sein soll um die harten Regeln einhalten zu können.


Dass darin kein Prozess gesehen wird liegt an einem zweiten Missverständnis: dem, dass Prozesse immer umfassend und detailliert sein müssen. Das gibt es zwar auch, dieser Typ, der starre Prozess, ist aber nur einer von mehreren. Er macht nur innerhalb von bestimmten Rahmenbedingungen Sinn, vor allem innerhalb des oben genannten hochgradig berechenbaren und in seinem Verhalten vorhersagbaren Umfelds.


Dort wo die Rahmenbedingungen unberechenbarer sind macht ein anderer Typ Sinn, der agile Prozess, der dann nochmal in zwei Untertypen zerfällt: der erste ist ebenfalls bereits weiter oben genannt, in ihm sind wenige Parameter hart vorgegeben, der Weg zu ihrer Erreichung aber nicht. Im anderen ist auch der Prozess selbst Gegenstand seines eigenen Verbesserungs- und Anpassungsfortschritts.1 Beides wird durch einen möglichst geringen Detaillierungsgrad einfacher.


Um noch mit einem letzten grossen Missverständnis aufzuräumen: häufig wird zwar die Notwendigkeit schlanker Prozesse anerkannt, die Benennung als Agiler Prozess aber nicht, mit der Begründung, dass die Verfasser des Agilen Manifests sich doch gerade von Prozessen hätten freimachen wollen. In solchen Diskussionen empfiehlt sich immer ein Verweis auf die zweite Seite des Manifests. Auf ihr werden agile Prozesse mehrfach erwähnt.


1Häufige Anwendungs-Varianten dieser zwei Typen sind Scrum und Kanban

Montag, 8. März 2021

Inselgigantismus

Bild: Wikimedia Commons / Padanus - CC0 1.0

Zu den vielen Besonderheiten der Natur die sich als Analogie auf Organisationen übertragen lassen gehört auch die, dass seit langem auf Inseln lebende Tierpopulationen mit der Zeit eine Körpergrösse entwickeln die deutlich über der von vergleichbaren Tieren auf dem Festland liegt. Bekannte Beispiele dafür sind die Galapagos-Schildkröte, der Elefantenvogel und der Dodo, es gibt aber auch zahllose weniger bekannte wie die Riesenratte, den Schreckens-Igel und den Riesengecko.


Die Forschung geht davon aus, dass praktisch alle dieser riesenhaften Arten eine vergleichbare Entstehungsgeschichte haben: zu dem Zeitpunkt an dem ihre Inseln besiedelt wurden oder sich vom Festland trennten gab es dort weder Raubtiere vor denen sie fliehen mussten noch knappe Nahrungsvorräte die sie als erstes erreichen mussten. Klein, schnell und wendig zu sein war damit kein evolutionärer Vorteil mehr.


Die Übertragung auf die Wirtschaft ist naheliegend - überall dort wo Unternehmen über längere Zeiträume keinem Wettbewerb oder keiner Bedrohung ausgesetzt sind (weil sie ein Monopol haben, der Markt schwer zugänglich ist, etc.) gibt es die Tendenz zu starkem Wachstum, sowohl in Bezug auf die Personalstärke als auch in Bezug auf Regeln und Prozesse.


Dieser "organisatorische Inselgigantismus" ist dabei abzugrenzen von dem Phänomen, dass vorher nötige und wertschöpfende Einheiten durch Digitalisierung und Automatisierung unnötig werden. Das gibt es auch, es hat aber einen anderen Hintergrund. Es geht hier explizit um ein imposantes aber unnötiges Wachstum, mit Schwerfälligkeit und hohem Ressourcenverbrauch als Folge.


Dass eine solcher Entwicklung problematisch ist dürfte intuitiv nachvollziehbar sein, ein Blick auf die tierischen Inselgiganten zeigt aber die potentiell verheerenden Folgen auf: überall dort wo die Ökosysteme der von ihnen bewohnten Inseln mit anderen verbunden wurden waren sie den plötzlich entstehenden Wettbewerben und Bedrohungen nicht gewachsen. Fast alle Inselgiganten-Spezies stehen heute vor dem Aussterben.


Vor einer noch nicht so dramatischen, aber bereits bedrohlichen Situation stehen heute viele Unternehmen. Ähnlich wie die frühen Handlungsreisenden und Siedler die bis dahin getrennten Ökosysteme miteinander verbanden öffnen heute Handelsabkommen und verbesserte Transport- und Kommunikationstechnologien die Märkte und machen sie für innovative und bewegliche Wettbewerber zugänglich. Organisatorischer Inselgigantismus ist jetzt ein Problem.


Zum Glück endet an dieser Stelle die Analogie. Galapagos-Schildkröte, Elefantenvogel und Dodo waren in ihrer biologischen Form gefangen, sie waren den neuen Bedingungen hilflos ausgeliefert. Organisationen können sich dagegen auch in kurzen Abständen verändern, gesundschrumpfen und beweglich machen - wenn sie es denn wollen.

Freitag, 5. März 2021

The agile Bookshelf: The Culture Map

Bild: Pixabay / Geralt - Lizenz

Indirekt ist The Culture Map von Erin Meyer bereits hier auf dieser Seite thematisiert worden, und zwar bei der Besprechung ihres zweiten Buches, No Rules Rules, das sie gemeinsam mit Reed Hastings veröffentlicht hat. Dessen zehntes Kapitel greift die verschiedenen Dimensionen von Kultur auf, die das Hauptthema von The Culture Map sind und dient als Beispiel für ihre Anwendung.


Allen die von diesem Kapitel neugierig geworden sind (und natürlich allen anderen auch) kann das Lesen von Meyers Hauptwerk nur nahegelegt werden. Angereichert mit zahllosen Beispielen aus ihrer Forschung und ihrem persönlichen Erleben werden zentrale Unterschiede zwischen verschiedenen Landeskulturen herausgearbeitet und nachvollziehbar gemacht, so dass viele Begegnungen mit Menschen aus anderen Ländern dadurch in neuem Licht erscheinen.


Natürlich sind unter den aufgeführten Beispielen einige der grossen Klassiker, darunter die unterschiedliche Wertigkeit von Pünktlichkeit in Mitteleuropa und Südasien oder die unterschiedliche Direktheit von Feedback in französisch-sprachigen und englisch-sprachigen Ländern, aber auch solche die man nicht erwartet hätte: etwa dass deutsche und amerikanische Manager sich (aus jeweils unterschiedlichen Gründen) gegenseitig als hierarchisch und unflexibel empfinden.


Diese und weitere Unterschiede werden von Meyer acht verschiedenen Dimensionen zugeordnet, in denen sie die verschiedenen Kulturen jeweils irgendwo auf einer Skala zwischen zwei Glaubens-, bzw. Handlungsmustern einordnet:

  • Kommunikation - wenig kontextspezifisch oder hoch kontextspezifisch?
  • Feedback - direkt oder indirekt?
  • Führungsstil - egalitär oder hierarchisch?
  • Entscheidungsprozesse - im Konsens oder direktiv?
  • Argumentieren - beispielhaft/spezifisch oder ganzheitlich/systemisch?
  • Vertrauen - basierend auf persönlichem Bekanntheitsgrad oder auf Qualität der Zusammenarbeits-Ergebnisse?
  • Konfliktaustragung - konfrontativ oder ausweichend/umschreibend?
  • Zeitempfinden - linear/präzise oder flexibel?

Diese Einordnung (die wie alle derartigen Modelle im Einzelfall problematisch, in der Gesamtbetrachtung aber hilfreich sein kann) kann nicht nur von ihr übernommen sondern auch für die eigene Gruppe/das eigene Unternehmen individuell erstellt werden um Hinweise darauf zu erhalten wo in der Kommunikation mit anderen Gruppen Probleme auftreten könnten.


Um ganz zum Schluss noch die Kurve zum Hauptthema dieser Seite zu bekommen: Ein interessanter Aspekt taucht eher versteckt in diesem Buch auf, es ist der der "kulturellen Agilität" (culturally agile). Unter ihm versteht Meyer die Fähigkeit sich schnell und ohne grosse Missverständnisse und Reibungsverluste an die kulturellen Besonderheiten der Gesprächs- oder Geschäftspartner anpassen zu können. Sicherlich eine erstrebenswerte Fähigkeit.

Dienstag, 2. März 2021

Scrum goes Pop Music

Ein weiterer Beleg für die Soft Power of Scrum: Chad Beider, ein amerikanischer Agile Coach, hat begonnen bekannte Musikstücke mit einem neuen, auf Scrum bezogenen Text zu versehen und neu aufzunehmen. Im Moment sind das drei (neben den beiden die hier eingebunden werden noch ein drittes, dessen Weihnachts-Thema aber nicht mehr zur Jahreszeit passt). Hoffen wir dass bald noch weitere dazukommen.