Donnerstag, 8. April 2021

Alternative Metriken für eine agile Transition

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

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


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


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


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

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


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

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


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

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


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

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


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

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


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

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


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

Montag, 5. April 2021

Agile Rhapsody

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



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

Mittwoch, 31. März 2021

Kommentierte Links (LXXIII)

Grafik: Pixabay / The Digital Artist - CC0 1.0

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 sindaber 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.


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 - CC0 1.0

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 - CC0 1.0

Ü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