Mittwoch, 30. Juni 2021

Kommentierte Links (LXXVI)

Grafik: Pixabay / The Digital Artist - CC0 1.0

Jutta Eckstein, Eric Abelen, Hendrik Esser: Overcoming One-Size-Fits-All Budgeting

Zu den Fallstricken die eine agile Transition scheitern lassen können gehört auch die Budgetierung. Wenn diese weiterhin so verläuft als wäre die Zukunft vorhersehbar und planbar helfen alle neuen Prozesse, Rollen und Regeln wenig bis gar nicht. Der Ansatz von Jutta Eckstein, Eric Abelen und Hendrik Esser ist naheliegend, dürfte aber den meisten klassisch geprägten Unternehmen sehr schwerfallen: wenn es mit hoher Wahrscheinlichkeit dazu kommen wird, dass die Realität sich anders entwickelt als geplant, sollten lediglich grobe Rahmen und Grenzwerte gesetzt werden, innerhalb derer die Umsetzungs-Verantwortlichen weitgehende Freiheit haben. Die Voraussetzung dafür ist, wie so oft, Vertrauen. Aber dort wo das nicht gegeben ist, ist die Budgetierung auch nicht das grösste Problem.

Jeff Kavanaugh, Rafee Tarafdar: Break Down Change Management into Small Steps

Zum Thema agiles Change Management habe ich selbst schon einiges geschrieben, Jeff Kavanaugh und Rafee Tarafdar geben dem Ganzen aber einen schönen neuen Namen: Microchange Management. Hinter diesem Begriff verbirgt sich ein Framework das ähnlich aufgebaut ist wie OKRs oder agiles Backlog-Management - grosse Vorhaben werden so lange in immer kleinere heruntergebrochen bis diese in kurzen Zeiträumen umsetzbar sind, und selbst in diesen Zeiträumen findet in kurzen täglichen Synchronisationsmeetings ein kontinuierliches Abarbeiten und Überprüfen statt, bei Bedarf auch ein Anpassen von Zielen und Massnahmen. Wie bei den anderen oben genannten Vorgehen dürfte auch hier gelten: einfach zu erklären, anspruchsvoll in der Umsetzung und lohnend wenn es gelingt.

Emma Garofalo: What Is Chaos Engineering?

Ein schöner Spruch den ich vor kurzem mitbekommen habe geht so: "Chaos Engineering ist das was früher Extreme Programming war. Alle ahnen, dass es für die agile Softwareentwicklung einen grossen Sprung nach vorne bedeuten kann, aber weil die meisten Agile Coaches zu wenig Ahnung von Technik haben kann es keiner erklären, und darum macht es fast niemand." Man muss es eingestehen - völlig abwegig ist dieser Spruch nicht, aber gerade deshalb ist das was Emma Garofalo hier macht um so verdienstvoller: sie erklärt das Konzept so, dass auch Nicht-Techniker es verstehen können.

Marcus Raitner: Agilität ist wie Fahrradfahren

Das Erlernen agiler Arbeitsweisen mit dem Erlernen des Fahrradfahrens zu verbinden ist nicht immer unumstritten, gerade in Bezug auf Scrum gibt es den einen oder anderen unpassenden Vergleich. Der den Marcus Raitner hier anbringt ist dafür um so passender: genau wie man das Radfahren nicht auf einem Downhill-Track im Gebirge bei aufziehendem Gewitter lernen sollte, sollte man auch das Arbeiten in agilen Frameworks nach Möglichkeiten nicht in Stress- oder Krisenphasen zu erlernen versuchen. Wesentlich zielführender ist es, die ersten Versuche dort zu machen wo Aufwand und Auswirkungen noch überschaubar sind, so dass man ohne grosse Sorgen Experimente wagen kann.

Thomas Knüwer: Home Office - es ist alles noch viel schlimmer

In den Filterblasen der IT-Branche, der agilen Community und der Medienbranche gibt es in den letzten Monaten die Tendenz zu einer starken Verklärung des Heimarbeit, oft verbunden mit der Aussage, dass diese Art zu arbeiten in nahezu jeder Hinsicht besser wäre als die Präsenzarbeit im Büro. Das Problem dabei - es handelt sich fast ausschliesslich um nicht statistisch validierte Meinungsbilder, bestenfalls angelehnt an anekdotische Evidenz. Thomas Knüwer hält dem eine ganze Reihe von Studien und Statistiken gegenüber die ein ganz anderes Bild aufzeigen. Das heisst zwar nicht, dass Heimarbeit grundsätzlich schlecht wäre (das wäre nur ein anderes überzogenes Meinungsbild), es zeigt aber, dass man sich durchaus kritischer mit diesem Thema beschäftigen sollte als es häufig der Fall ist.

Montag, 28. Juni 2021

Agile Bauprojekte (VI)

Das ist ein interessantes Praxisbeispiel: ein Manager der amerikanischen Firma Clark Pacific stellt vor, wie dort mit Hilfe von Scrum und Lean Management Gebäude gebaut werden. Der Schlüssel ist einmal mehr die Nutzung vorgefertigter Bauteile, von vor Ort "nur noch" zusammengesetzt werden müssen. Der Anspruch ist dabei, dass erste Räume bereits genutzt werden können während andere Teile des Gebäudes sich noch frühen Planungs- oder Bauphasen befinden.



Es ist kein Konferenzvortrag, sowohl rhetorisch als auch grafisch hält er mit anderen hier eingebundenen Videos daher nicht ganz mit, wegen des seltenen Themas lohnt sich das Ansehen aber trotzdem. Und die eingebundenen Bilder von Baufortschritten, Kanban-Boards und Meetings geben interessante Einblicke in die gelebte Praxis.

Freitag, 25. Juni 2021

Regression zum Rand (II)

Die Regression zum Rand, also die bei komplexen Vorhaben häufig zu betrachtende immer stärker zunehmende Abweichung der Umsetzungsaufwände von der ursprünglichen geschätzten Grösse, hatte ich bereits erwähnt. Zurückkehend auf den Wirtschaftswissenschaftler Bent Flyvberg beschreibt sie ein grundlegendes Phänomen, wie dieses im Einzelfall zu Stande kommt bleibt aber offen (was auch zwangsläufig ist, je nach Art des Vorhabens kann das sehr unterschiedliche Gründe haben).


Was schon eher definiert werden kann sind die Gründe die eine Regression zum Rand in einer ihrer Kategorien wahrscheinlich werden lassen, und aus einer von ihnen bringe ich mehr als ein Jahrzehnt Erfahrung mit, so dass ich mir hier ein Urteil anmasse - die Rede ist von grossen IT-Projekten, und wer schon in ihnen gearbeitet hat weiss, dass immer stärker werdende Ausschläge bei Kosten und Zeit in ihnen nicht nur häufig sondern typisch sind.


Dass das so ist liegt an einem in sehr vielen grösseren Organisation vorzufindenden Verhaltensmuster: wenn einzelne Phasen oder Meilensteine länger dauern oder mehr kosten als gedacht führt das nur selten zur Aktualisierung des Gesamtplans.1 Statdessen wird dieser unverändert gelassen und es wird versucht die Verspätung, bzw. Kostenüberschreitung dadurch auszugleichen, dass später folgende Arbeitsabschnitte schneller oder billiger durchgeführt werden.


Auch hier lohnt es sich noch einmal genauer hinzublicken, denn bei der Entscheidung zukünftig schneller und billiger zu arbeiten zu wollen kommen andere Argumente zum Tragen als man denken sollte. Wichtig ist nicht, dass es machbar ist, wichtig ist, dass es wünschenswert ist, weil man sich dadurch eine grosse Neuplanung ersparen kann. Das kann so weit gehen, dass es für das "schneller und billiger" nichtmals eine Machbarkeitsanalyse gibt (mehr zu den dahinter stehenden Motivationen steht hier).


Als Folge landen bei den Teams widersprüchliche Anweisungen: auf der einen Seite sollen Zeit und Geld gespart werden, auf der anderen Seite sind Abstriche bei Umfang, Qualität und Geschwindigkeit nicht vorgesehen. Nachfragen werden entweder mit Plattitüden beantwortet (z.B. "don't work harder, work smarter") oder mit kaum kaschierten Aufforderungen Überstunden zu machen (ein Klassiker: "man muss auch mal bereit sein die Extrameile zu gehen").


Die damit konfrontierten Teams reagieren in der Regel zu Beginn mit Protesten, wenn diese nichts bringen aber meistens damit, dass "die aus Management-Perspektive unsichtbare Arbeit" (Architektur, Dokumentation, Testabdeckung, etc.) in spätere Phasen verschoben wird. Manchmal geschieht das heimlich (mehr dazu hier), manchmal aber auch ganz offen ("das ziehen wir gerade wenn wir wieder Zeit haben"), oft mit Schein-Rationalisierungen als Begründung ("alles erst ganz zum Schluss zu testen ermöglicht uns ja auch die Nutzung von Skaleneffekten").


Kurzfristig kann ein derartiges Vorgehen zwar durchaus für Beschleunigung sorgen, mittel- und langfristig wird aber das Gegenteil bewirkt: durch das Fehlen von Architektur, Dokumentation, Testabdeckung und Ähnlichem dauern alle folgenden Arbeiten deutlich länger. Zum Einen bedeutet das, dass "die Zeit in der man Dinge wieder geradeziehen kann" nie kommt, zum Anderen, dass immer neue Verspätungen entstehen, die in Summe immer grösser werden. Die Regression zum Rand hat damit begonnen.


Zeit für gute Nachrichten. Erstens: die Die Regression zum Rand ist kein Naturgesetz, man kann sie brechen, wenn es wirklich möchte. Und Zweitens: in Lean Management und agiler Produktentwicklung findet man die Werkzeuge dafür, z.B. Andon oder Scrumble. Alle laufen auf das Selbe hinaus - das Entgleisen von Plänen führt nicht dazu, dass man versucht das Wunschergebnis zu erzwingen, sondern dazu, dass jedes mal (!) alle Arbeiten angehalten werden (!!) bis die Ursache gefunden und behoben ist.


Natürlich bedeutet das, dass man sich ggf. schon sehr früh von den ursprünglich geplanten Zieldaten verabschieden muss, genau wie von der Hoffnung den Rückstand doch irgendwie aufholen zu können. Und dafür braucht es das Bewusstsein, dass diese Hoffnung fast immer hochgradig unrealistisch ist und der Versuch sie wahr werden zu lassen alles eher noch schlimmer macht als irgendwie besser (hier hift es  übrigens sehr, eine gesunde Fehlerkultur zu haben).


Für alle die dazu bereit sind gibt es die dritte gute Nachricht zum Schluss: sie werden das Gegenteil der Regression zum Rand erleben, die Regression zur Mitte. In ihr folgt immer wieder auf Überschreitungen von Kosten und Zeiträumen eine ähnlich grosse Unterschreitung, was möglich wird durch die Effektivitäts- und Effizienzgewinne die durch die ständigen und sofortigen Behebungen aller Probleme entstehen. Das ist doch mal eine Verheissung.


1Was meistens nicht an den handenden Personen liegt, sondern daran, dass die Prozesse so designed sind, dass das Ändern grosser Pläne extrem aufwändig ist oder für die eigene Karriere negative Auswirkungen hat

Dienstag, 22. Juni 2021

Definition of Done (II)

Bild: Pixabay / Alexas Fotos - CC0 1.0

Unter den verschiedenen Elementen von Scrum gehört die Definition of Done (DoD) zu denen, die schon direkt ab der Einführung eine bemerkenswerte Wirkung entfalten können. Statt in Abnahmen lange darüber zu diskutieren ob etwas wirklich fertig ist (oft mit so wolkigen Begründungen wie "gesunder Menschenverstand" oder "war schon immer so") kann man das anhand einer kompakten Kriterienliste entscheiden. Mit der obligatorischen Einschränkung: wenn man sie im richtigen Rahmen einsetzt.


Bei vielen Teams führt die Definition of Done dazu, dass viele Arbeitspakete durch mehrere Sprints gezogen werden müssen bevor sie fertig sind. Das ist für die an der Umsetzung Beteiligten frustrierend, für die Kunden und Auftraggeber enttäuschend und kann im schlimmsten Fall dazu führen, dass das ganze methodische Vorgehen als unsinnig empfunden und abgelehnt wird. Könnte es also sein, dass Scrum sich mit der DoD selbst aushebelt? Klare Antwort: nein.


Um mit dem Offensichtlichsten anzufangen - in richtig umgesetztem Scrum ist es gar nicht möglich, dass die Definition of Done dazu führt, dass Arbeitspakete durch mehrere Sprints gezogen werden. Für den Fall dass das Ziel eines Sprints nicht mehr erreichbar ist muss dieser nämlich abgebrochen werden, und wenn das mehrfach passiert kann sogar die komplette Produktentwicklung ausgesetzt werden um die Ursachen zu beheben. Der Fehler liegt also in der Umsetzung - aber wo?


Ein Klassiker unter den möglichen Ursachen sind Definitions of Done die so unscharf formuliert sind, dass sie ihren ursprünglichen Zweck (Klarheit darüber ob etwas fertig ist) nicht mehr erreichen können. Beispiele die ich schon gesehen habe sind "die Entwicklung ist zur allgemeinen Zufriedenheit abgeschlossen" oder "allen relevanten Neuerungen sind in angemessenem Detailgrad dokumentiert". Man kann sich vorstellen, dass es hier sehr unterschiedliche Interpretationen gibt.


Eine weitere häufige Fehlkonstruktion ist eine falsche Zusammenstellung des Teams. Wenn diese nicht crossfunktional sind (oder wenn mache Funktionen nicht in erforderlichem Ausmass zur Verfügung stehen) können die so entstehenden Abhängigkeiten dazu führen, dass die Definition of Done im Sprint nicht erreichbar ist, ganz einfach deshalb weil die benötigten Spezialisten nicht oder erst zu spät verfügbar sind.


Ebenfalls oft anzutreffen ist ein Grund der eigentlich gar nichts mit der DoD zu tun hat, nämlich eine unrealistisch hohe Menge an Arbeit im Sprint. Derartig überlastete Teams versuchen häufig einen "Teilerfolg" zu erzielen, indem sie Arbeiten die zur Erfüllung der jeweiligen Kriterien nötig sind (Dokumentation, Regressionstests, etc.) in spätere Sprints verlagern. Dann die DoD dafür verantwortlich zu machen dass Arbeit nicht im Sprint fertig wird ist aber nur eine Ausrede.


Diese und weitere Beispiele machen folgendes klar: wenn eine Definition of Done dazu führt, dass Anforderungen nicht innerhalb eines Sprints umgesetzt werden können liegt das nicht an der Vorgabe selbst, sondern daran dass es nicht passende Rahmenbedingungen oder eine fehlerhafte Umsetzung gibt. Die gute Nachricht: beides kann man ändern - man muss es nur wollen.

Freitag, 18. Juni 2021

Der agile Virus

Grafik: Pixabay / Alexandra Koch - CC0 1.0

Eine Metapher die im Umfeld agiler Arbeitsweisen immer wieder benutzt wird ist die des so genannten Virus (z.B. hier, hier und hier). Sicherlich eine nicht ganz unproblematische Begriffswahl, (alleine weil aus ihr nicht sofort hervorgeht, dass sie positiv gemeint ist) auf jeden Fall aber eine die bei näherer Betrachtung einige Eigenheiten agiler Transformationen aufzeigen kann. Welche das sind? Die Folgenden:


Zunächst das Offensichtliche: genau wie der Virus Körperzellen infizieren und umprogrammieren kann, können agile Enthusiasten ihre Teams erstaunlich weitgehend in Richtung neue Arbeitsweisen umwandeln. Zum Teil auf dem offiziellen Weg (z.B. durch die Einführung von Scrum), zum Teil aber auch inoffiziell und zunächst unbemerkt, etwa dadurch, dass zu Beginn nur die Arbeit visualisiert wird oder durch die Etablierung regelmässiger Lessons Learned-Termine. Beides kann Eigendynamiken auslösen.


Eine weitere Eigenschaft von Viren ist es, dass die Zellen in die sie sich begeben haben nicht nur intern anders funktionieren als vorher, sondern dass sie auch neue Viren produzieren, die dann wiederum andere Zellen verändern. Auch hier ist die Analogie offensichtlich. Wer schon einmal in einem agil arbeitenden Team gute Erfahrungen gemacht hat wird wenn er versetzt wird versuchen die hier gelernten Praktiken mitzunehmen und sie auch im neuen Team einzusetzen.


Auch die Reaktionen der jeweiligen Umgebung weisen Parallelen auf. Genau wie das Immunsystem des Körpers versucht erkannte Viren auszuschalten versuchen oft auch die "Immunsysteme von Organisationen" die durch die Agilität entstehenden Veränderungen einzudämmen, zum Beispiel durch Standardisierung, Regulierung oder das Entfernen von als riskant wahrgenommenen Elementen (wie den "zu grossen" Entscheidungsspielräumen der Teams).


Die Reaktion eines Virus auf ein erstarkendes Immunsystem ist schliesslich, dass es durch Mutation so genannte "Fluchtvarianen" ausbildet, die so neu sind, dass sie zunächst nicht erkannt werden. Die Entsprechung in der Welt der Agilität wäre eine Hinwendung agiler Teams zu neuen Frameworks wie Popcorn oder Fast, sobald die bestehenden (meistens Scrum und Kanban) so stark reguliert wurden, dass sie ihren ursprünglichen Zweck nicht mehr erfüllen können.


Wie zu Beginn gesagt, ganz unproblematisch ist die Metapher des agilen Virus nicht, sie hilft aber dabei, agile Transitionsvorhaben aus einem anderen Blickwinkel zu betrachten. Und um zuletzt eine Frage zu beantworten die mir ein Manager tatsächlich einmal gestellt hat: nein, eine wirksame Impfung dagegen gibt es nicht.

Montag, 14. Juni 2021

Ein Bild sagt mehr als 1000 Worte (XXXI)

 Vor mehr als fünf Jahren war das hier der erste Beitrag der Serie Ein Bild sagt mehr als 1000 Worte. Scheinbar ein nicht zu verbessernder Klassiker. Scheinbar. Bis jemand in Wales auf die Idee kam an einer ähnlichen Stelle ein Hinweis-Schild aufzustellen. Und diese neue Variante ... wie die Briten sagen: it keeps on giving. Alle Assoziationen zu bürokratischen Organisationen sind möglich.


Donnerstag, 10. Juni 2021

Warum die Menschen nicht zurück ins Büro wollen

Bild: Wikimedia Commons / Peter Bennet - CC BY 3.0

Wenn grosse Organisationen ihre Angestellten für eine längere Zeit ins Home Office geschickt haben (sei es wegen Pandemien, Bauarbeiten, Überbelegung der Büros oder aus anderen Gründen) kommt es gegen Ende dieser Phasen oft zu interessanten Meinungsbildern. Auf der einen Seite gibt es eine starke Unzufriedenheit mit der Ineffektivität und sozialen Isolation die Heimarbeit mit sich bringt, auf der anderen Seite einen starken Widerwillen gegen die Rückkehr zur durchgehenden Präsenzarbeit.


Warum das so ist dürfte sich zwar von Fall zu Fall unterscheiden, nachdem ich in den letzten 15 Jahren eine ganze Reihe derartiger Fälle erlebt habe, habe ich aber eine These entwickelt: dass viele Menschen mittlerweile eine grosse Skepsis gegenüber der Präsenzarbeit haben liegt stark daran, dass das was sie unter diesem Namen kennengelernt haben in Wirklichkeit etwas ganz anderes ist, nämlich schlecht umgesetzte Remote- oder Hybrid-Arbeit.


Um das zu erklären bedarf es zunächst einer Definition: in der Kreativ- und Wissensarbeit findet Wertschöpfung in der Regel nicht durch einzelne Personen statt sondern durch die Zusammenarbeit in Gruppen oder Teams. Präsenzarbeit muss in diesem Kontext also bedeuten, dass alle Beteiligten gemeinsam vor Ort sind. Sind auch nur Teile des Teams an einem anderen Ort wird die Arbeit aller Beteiligten automatisch zu Remote-Arbeit, da die Abwesenden ja einbezogen werden müssen.


Und auch das muss definiert werden: "an einem anderen Ort" bedeutet eben nicht nur in einem anderen Land, einem anderen Standort oder zu Hause in der Wohnung. Es schliesst alles ein was nicht in Sicht- oder Rufweite (oder zumindest mit wenigen Schritten erreichbar) ist. Als Faustregel in der Wissensarbeit kann gelten: sobald andere Teammitglieder nicht mehr direkt ansprechbar sind sondern angerufen, angemailt oder angechattet werden müssen kann von Präsenzarbeit nicht mehr die Rede sein.


An dieser Stelle wird das Problem vieler grosser Organisationen offensichtlich. In den einen werden Mitarbeiter zu Projektteams zusammengefasst, die weiterhin bei ihren entsendenden Einheiten sitzen. In anderen wurden feste Arbeitsplätze abgeschafft, so dass man sich täglich einen neuen suchen muss - mit der Folge dass es für Teams schwer wird genug nebeneinanderliegende freie Plätze zu finden. Beides hat eine Verteilung der Teams über verschiedene Räume, Stockwerke oder Gebäude-Flügel zur Folge.


Selbst innerhalb eines Gebäudekomplexes führt diese geografische Verteilung dazu, dass mit den Kollegen auf dem gleichen Weg kommuniziert wird wie mit denen in anderen Standorten oder Ländern, also über Calls, Chats oder Mails. Der Vorteil des gemeinsamen Standorts schrumpft darauf zusammen, dass man einfacher Präsenzmeetings organisieren kann - was aber gemeinsame Präsenzarbeit nur zum Teil ersetzt und ausserdem oft an zu wenigen verfügbaren Meetingräumen scheitert.


Soweit zum ersten Teil der These: was für Präsenzarbeit gehalten wird ist in vielen Fällen nichts anderes als Remote-(Zusammen-)Arbeit mit Kollegen die irgendwo verstreut im Gebäudekomplex sizen. Aber es kommt noch ein zweiter Teil dazu, einer dessen Auswirkungen weitgehend unterschätzt werden - es ist nicht nur Remote-Arbeit sondern Remote-Arbeit unter schlechten Bedingungen, was deutliche Auswirkungen auf Effektivität und Ergebnisqualität hat.


Anders als zu Hause, wo man zwar einsam aber ungestört ist, führt das in Grossraum- und Gruppen-Büros stattfindende Zusammensitzen mit den Mitgliedern anderer Teams dazu, dass deren Telefonate und Video Calls mit ihren ebenfalls verstreut sitzende Teammitgliedern einen ständigen Hintergrundlärm erzeugen, gegen den nur noch Schallschutz-Kopfhörer helfen. Da es dadurch unmöglich gemacht wird ansprechbar zu sein verschwindet die direkte Kommunikation fast völlig. Dazu kommt der Stress.


Letztendlich ist es eine Loose-Loose-Situation: um rechtzeitig im Büro sein zu können fallen mit früh Aufstehen und langen Fahrtzeiten die negativen Effekte der Präsenzarbeit an, gleichzeitig bleiben nicht nur deren mögliche Vorteile aus, sondern die zwangsweise auch vor Ort stattfindende de facto-Remote-Arbeit ist sogar stressiger und unkomfortabler als sie es von zu Hause aus wäre. Wer kann es den Menschen verdenken wenn sie nicht zurück ins Büro wollen?


Heisst das also, dass es bei dauerhaftem Arbeiten von zu Hause aus bleiben soll? Auch nicht wirklich, denn hier entstehen andere Probleme. Besser wäre es in der Präsenzarbeit für Bedingungen zu sorgen die dazu führen, dass sie ihren Namen wirklich verdient hat. Und dafür müsste man nicht einmal besonders innovativ sein, man müsste nur das beherzigen was schon vor einem Vierteljahrhundert als gut erkannt wurde. Es wäre höchste Zeit die Büros entsprechend umzubauen, dann kommen die Mitarbeiter auch wieder gerne dorthin.

Montag, 7. Juni 2021

Air Sandwich

Bild: Wikimedia Commons / Matthias Süßen - CC BY-SA 4.0

Zu den Tätigkeiten die ein Agile Coach ausüben kann gehört eine die man als "Auditierung" agil arbeitender Projekte oder Unternehmen bezeichnen könnte. In den meisten derartigen Fällen ist die dahinterstehende Motivation die, dass die Umstellung des Arbeitsmodus nicht zu den Verbesserungen geführt hat die erhofft waren, und dass das Unternehmen herausfinden möchte ob es bei der Umstellung etwas falsch gemacht hat. Und zu den häufigsten Fehlern die dabei gefunden werden gehört das so genannte "Air Sandwich".


Erstmals geprägt von der amerikanischen Strategieberaterin Nilofer Merchant in ihrem 2009 erschienenen Buch The New How: Creating Business Solutions Through Collaborative Strategy beschreibt dieser Begriff einen der klassischen Gründe dafür, dass grosse Veränderungsvorhaben wirkungslos bleiben - das fehlende Herunterbrechen des grossen Plans auf ein Detail- und Abstraktions-Niveau das auf der Ausführungsebene umsetzbar ist. Mit ihren Worten:


An Air Sandwich is a strategy that has clear vision and future direction on the top layer, day-to-day action on the bottom, and virtually nothing in the middle.


Am Beispiel einer nicht gut verlaufenden Umstellung auf agiles Arbeiten würde das so aussehen: in der obersten Unternehmensebene ist grundsätzlich verstanden, dass schnelle Liefer- und Reaktions-Zyklen wichtig sind, und deren Implementierung wird angeordnet. Im Idealfall würde jetzt in der Mitte die Operationalisierung beginnen, zum Beispiel in Form eines Rückbaus von Silos und Hierarchien, so dass auf der unteren Ebene selbstorganisierte, crossfunktionale Produktteams entstehen können.


In der Realität ist es dagegen häufig so, dass die Anordnung schneller und flexibler zu werden in der Mitte auf die dort vorhandene Luftschicht (das Air Sandwich) trifft, ungebremst durch diese hindurchfällt und weiter unten auf der Umsetzungsebene einschlägt. Da in diesem Szenario die Hierarchien und starken Aufgabenteilungen aber nicht verändert worden sind (das hätte in der Mitte passieren müssen) kommt es dort nur zu symbolischen Veränderungen, wie z.B. Scrum in Komponententeams.


Eine populäre Deutung für das Air Sandwich ist, dass die in der Mitte liegenden Management-Schichten kein Interesse haben sich selbst ändern zu müssen, weshalb sie derartige Anweisungen einfach nach unten durchreichen. Sie sagt aber meistens mehr über das Menschenbild des so Urteilenden aus als über die Realität. Eine wahrscheinlichere Erklärung ist aber, dass das Gesamtsystem so konstruiert wurde, dass es durch die Umsetzung organisatorischer Veränderungen an seine Grenzen gebracht wird.


Zur Erklärung: in den meisten klassischen Organisationen ist es eben nicht die Aufgabe der mittleren Schichten Organisationsveränderungen durchzuführen, stattdessen haben sie vor allem eine Kommunikationsfunktion: auf dem Weg von oben nach unten werden Ziele und Anweisungen immer weiter ausdetailliert und auf die verschiedenen Empfänger aufgeteilt, auf dem Weg nach oben werden Rückmeldungen und Ergebnis-Berichte immer weiter zusammengefasst und vereinheitlicht.


Um zu verhindern dass eine Umstellung auf agiles Arbeiten durch ein Air Sandwich wirkungslos wird sind demnach zwei Dinge elementar: zum einen muss allen Beteiligten klar werden, dass in der Mittelschicht nicht nur die Veränderungs-Vision nach unten durchkommuniziert werden muss, sondern dass in diesem Rahmen auch organisatorische Veränderungen geplant und durchgeführt werden müssen. Zum anderen muss klar sein, dass viele klassische Mittelschichten darin weder Expertise noch Erfahrung haben1.


Natürlich sind derartige Überlegungen und Erkenntnisse zunächst einmal frustrierend, da durch sie klar wird, dass Veränderungsbemühungen schwieriger sind als gedacht und meistens eine Unterstützung durch externe Experten benötigen. Auf der anderen Seite bewahren sie aber auch davor, dass als einziges Ergebnis das entsteht was in Air Sandwiches in beliebiger Menge erzeugt werden kann: heisse Luft.


1Es gibt zwar Change Management-Einheiten, aber das ist nochmal ein eigenes Thema.

Freitag, 4. Juni 2021

Lots of systems all over the place

Wer häufiger in der agilen Filterblase unterwegs ist kennt Woody Zuill vor allem als Pionier des Mob Programming und der NoEstimates-Bewegung, in diesem Talk redet er aber über das Management. Genauer gesagt darüber, welche Fehlannahmen, Fehlwahrnehmungen und unhinterfragten Handlungsmuster dazu führen, dass viele Management-Entscheidungen trotz guter Intention keine Verbesserungen zur Folge haben, sondern eher das Gegenteil.



Angesichts des Themas ist es übrigen um so bemerkenswerter welche Art von Präsentation er benutzt, die ist nämlich weit, weit weg von dem was Manager üblich zu sehen bekommen. Aber wer weiss, vielleicht ist gerade das gar nicht so schlecht.