The Golden Age of Agile Coaching

Alleine der Titel ist grossartig, aber auch unabhängig davon ein sehenswerter Vortrag, der viele Aspekte dessen berührt was man heute unter dem Begriff "Agile Coach" versteht.

The Golden Age of Agile Coaching - Shane Hastie from Agile Alliance on Vimeo.

Das Urteil des Dodo

Grafik: Flickr / Biodiversity Heritage Library - Public Domain

Welcher agile Ansatz ist denn jetzt der Richtige? Ist es Scrum oder Kanban? LeSS oder SAFe? Lean Startup oder Extreme Programming? Derartige Fragestellungen findet man häufig, vor allem in Unternehmen die gerade ihre ersten Schritte in diese Richtung machen. Die Frage scheint auch nachvollziehbar zu sein, schliesslich soll die Lösung ja zum Problem passen. Und doch - beantwortet wurde sie bis heute nicht, welches Framework in welcher Situation am besten hilft bleibt offen¹.

Wie kann man am besten mit dieser unbefriedigenden Unklarheit umgehen? Hier hilft einmal mehr der Blick über den Tellerrand. Auch in anderen Wissensgebieten kann nicht klar gesagt werden welcher Ansatz der beste oder hilfreichste ist, und eines das einen näheren Blick lohnt ist die Psychotherapie. Wie im Fall der agilen Frameworks bestehen auch hier verschiedene miteinander konkurrierende Ansätze. Die Frage nach dem Besten konnte auch hier lange nicht beantwortet werden. Bis 1936.

Die vom amerikanischen Psychologen Saul Rosenzweig vorgestellte Lösung lautete: alle Ansätze sind richtig. Für eine bessere Kommunizierbarkeit gab er dieser Erkenntnis einen Namen - The Dodo Bird Verdict (Das Urteil des Dodo), benannt nach einer Figur aus Alice im Wunderland, deren Schiedsspruch nach einem Wettrennen lautete "Everybody has won and all must have prizes."

Um von der Fachwelt akzeptiert zu werden brauchte Rosenzweig natürlich mehr als einen salomonischen Spruch, weshalb er das Urteil des Dodo mit der wissenschaftlichen Veröffentlichung Some implicit common factors in diverse methods of psychotherapy im American Journal of Orthopsychiatry untermauerte. Wie schon am Titel zu erkennen lautete dessen These, dass die verschiedenen Methoden deshalb gleich wirksam wären, weil sie alle auf den gleichen Grundlagen aufbauen.

Die Parallele zu den agilen Frameworks ist offensichtlich. Auch hier gibt es bei aller Unterschiedlichkeit geimnsame Grundlagen, durch die alle verbunden werden: Akzeptanz der Nichtvorhersehbarkeit der Zukunft, incrementelle Auslieferung, Pull-Prinzip, Delegation von Entscheidungskompetenz, Bereitschaft zur ständigen Anpassung. Und auch hier ist es so, dass jedes Vorgehen das sich an diesen Grundlagen orientiert in vergleichbarer Form erfolgreich sein wird.

Die Frage bei der Auswahl des Vorgehens sollte demnach nicht sein welches Framework das passende ist sondern ob es so umgesetzt wird, dass es den darunterliegenden Ideen gerecht wird. Wenn das der Fall ist kann das Urteil des Dodo auch bei der Methodenwahl angewandt werden.


¹Natürlich gibt es Menschen die behaupten die Antwort zu wissen, aber die verdienen entweder mit einem bestimmten Framework Geld oder ihre Expertise beruht lediglich auf anekdotischer Evidenz

Vom Risiko, sich einem Guru anzuvertrauen

Bild: Wikimedia Commons / André Zehetbauer - CC BY-SA 2.0

Es ist eine lang bekannte Tatsache, dass man fast alles mit einem Fussball-Vergleich erklären kann. Die Geschehnisse um Bundesliga und Nationalmannschaft sind in der deutschen Gegenwartskultur so präsent, dass alles was man aus diesem Bereich als Beispiel nehmen kann sofort anschlussfähig ist. Spätestens seit dieser Woche ist diese Liste von Narrativen um einen Punkt länger geworden. Man kann jetzt auch die Risiken verdeutlichen die entstehen wenn eine Organisation zu bereitwillig einen vermeintlichen Guru damit betraut grosse Veränderungen voranzutreiben.

Der Name mit dem sich das von jetzt an verdeutlichen lässt ist Jürgen Klinsmann. Seitdem er in den Jahren 2004 bis 2006 die deutsche Nationalmannschaft trainierte gilt er als jemand der alte Strukturen aufbrechen und mit neuen Ansätzen zum Erfolg kommen kann. Gleichzeitig gilt er seit seinen Engagements bei Bayern München (2008/2009) und Hertha BSC (2019/2020) aber auch als jemand der mit seinen Methoden seine Umgebung massiv überfordern und letztendlich sogar lähmen kann. Die verschiedenen Medienberichte nach seinen Amtszeiten lassen ein Bild erkennen in dem man Parallelen zu vielen anderen anfangs gefeierten und dann gescheiterten Change-Gurus wiederfindet.

Zu Beginn seiner beiden Amtszeiten stand jeweils etwas das eigentlich positiv ist, eine grosse Vision. Alles sollte moderner, besser und ganzheitlicher werden, und das nicht in irgendeiner Zukunft sondern möglichst schnell und radikal. Das Problem dabei war auch nicht diese Vision sondern das mit ihr kommunizierte Urteil über die jüngere Vergangenheit, der das genaue Gegenteil attestiert wurde. Nicht mehr zeitgemäss sei hier gearbeitet worden, unprofessionell und kleingeistig. Die Reaktion darauf war vorhersehbar: aus der Gruppe derer die ihre bisherige Leistung herabgewürdigt sahen gab es Widerstand.

Die Reaktion auf derartige Widerstände war dann nicht etwa, dass darauf eingegangen wurde, stattdessen wurden alle die die grosse Vision nicht vorbehaltlos zu ihrer machen wollten als störend und behindernd empfunden und von Klinsmann auf das Abstellgleis geschoben. Bei beiden Vereinen gab es gleich reihenweise Spieler und Angestellte die plötzlich ihren Stammplatz oder ihre Anstellung verloren. Auch das erzeugte vorhersehbare Reaktionen: Verunsicherung, passiven Widerstand und Rückzug auf weniger angreifbare Positionen. Ein stetiges Absinken von Stimmung und Leistungsfähigkeit war die Folge.

Statt diese Entwicklung als Anlass zu nehmen sich selbst zu hinterfragen wird aus beiden Vereinen über eine gegenteilige Reaktion Klinsmanns berichtet. Noch mehr Veränderungen, noch mehr Entscheidungsfreiheit und noch weniger Rücksprachen soll er eingefordert haben. Und als diese ihm (nachvollziehbarerweise) nicht gegeben wurden war das für ihn der Grund dafür, dass es nicht weiterging. Ein Projizieren aller Problemursachen nach aussen also, fast immer ein Indikator dafür, dass ein Veränderungs-Vorantreiber die Bodenhaftung verliert. In beiden Fällen folgte dann schnell das Ende.

So weit, so gut - die Moral von der Geschichte ist also, dass zu radikal und zu egozentrisch vorangetriebene Veränderungen scheitern müssen? Nun, ganz so einfach ist es auch nicht. Zum Gesamtbild gehören nämlich auch die beiden anderen Trainerstationen Klinsmanns, die bei den Nationalteams Deutschlands und der USA. Die Methoden waren hier ähnlich, die Resultate aber deutlich besser. In Deutschland gilt er als heimlicher Vater des späteren Weltmeistertitels, in Amerika konnte er die Kontinentalmeisterschaft gewinnen, in beiden Verbänden wird er als grosser Modernisierer anerkannt.

Die eigentliche Lehre die man aus dieser Fussball-Geschichte ziehen kann ist die: was an einem Ort geklappt hat muss keineswegs an einem anderen Ort genauso gut funktionieren, im Gegenteil. Es kann sogar sein, dass die Erfolgsmethode und der grosse Anführer die andernorts spektakuläre Erfolge hatten beim Versuch das zu wiederholen ein Trümmerfeld erzeugen. Statt sich einem vermeintlichen Guru anzuvertrauen ist es im Zweifel also besser nach einem eigenen Weg zu suchen. Das ist zwar weniger glamourös, dafür aber auch mit deutlich weniger Risiko behaftet.

Wie junior darf ein Scrum Master sein?

Bild: Pexels / Kyla Daw - CC0 1.0

Ein erkennbarer Trend der letzten Jahre ist der, dass der Scrum Master (bzw. dessen Entsprechungen) zu einem Ausbildungsberuf wird. Wie bei allen anderen IT-nahen Jobs ist es auch hier so, dass der Fachkräftemangel es schwierig bis unmöglich macht genug geeignete Kandidaten für alle offenen Stellen zu finden. Um den zu begegnen finden in vielen Firmen Umschulungen und Ausbildungen statt,¹ was die Frage nach den Auswahl- und Zulassungskriterien mit sich bringt. Einer der wichtigsten Aspekte dabei ist das Alter, bzw. die Berufserfahrung. Sollten die angehenden Scrum Master Berufs- und/oder Lebenserfahrung mitbringen oder kommen auch Berufseinsteiger und Mitarbeiter mit erst wenigen Jahren im Job in Frage?

In vielen Fällen wird diese Frage so beantwortet, dass eher jüngere Mitarbeiter in die Ausbildungen geschickt werden. Gründe dafür gibt es mehrere. Zum einen gilt Agilität noch immer als etwas Neues und damit auch irgendwie Jugendliches (was man oft an den Ausschreibungen erkennt), des Weiteren gibt es die noch immer verbreitete Ansicht, dass das Lernen und ausgebildet Werden nur an den Anfang der Karriere gehört. Auch wird häufig davon ausgegangen, dass langgediente Kollegen schon so sehr in festen Denkspuren unterwegs sind, dass sie sich mit Neuerungen schwer tun. Zuletzt sind Nachwuchskräfte einfach billiger (solange man nur das Gehalt betrachtet) und passen so besser ins Budget. Aber - so nachvollziehbar diese Begründungen auch sein mögen, die Entscheidung für die Jugend sollte kritisch hinterfragt werden.

Um die Rolle des Scrum Masters ausüben zu können ist in nicht unwesentlichem Ausmass Vorwissen nötig. Der Scrum Guide erwähnt unter den Standard-Tätigkeiten einige, deren Bewältigung ohne Erfahrungen kaum möglich ist. "Ensuring that goals, scope, and product domain are understood [...] as well as possible", "Understanding product planning in an empirical environment" und "Helping the Development Team to create high-value products" sind drei Beispiele dafür, gleichzeitig zeigen sie auch gut auf, dass das Vorwissen nicht zwingend aus bisherigen Scrum Team-Mitgliedschaften kommen muss. Man kann es auch auf andere Weise erworben haben, erworben haben sollte man es aber.

Noch wichtiger wird die Erfahrung in einem zweiten Bereich. Gleich drei mal wird im gerade erwähnten Abschnitt des Scrum Guides definiert, dass der Scrum Master als Coach tätig sein muss, und zwar sowohl für die einzelnen Mitglieder des Entwicklungsteams als auch für die gesamte Organisation. Und obwohl es keine allgemein gültige Definition von Coaching gibt ist in praktisch jeder Beschreibung explizit oder implizit enthalten, das der Coach sein Charisma zu einem grossen Teil aus seiner Berufs- und Lebenserfahrung bezieht. Er muss nicht zwangsläufig ein alter Mann mit langem weissen Bart sein, er sollte aber glaubhaft vermitteln können in seinem Feld über breites Wissen zu verfügen, wenn er von seinen Coachees akzeptiert werden soll.

Ein dritter Grund dafür, dass Scrum Master eine gewisse Seniorität haben sollten ist der, dass von ihnen erwartet wird ihre Firmen zu führen und zu verändern. Auch hier ist der Scrum Guide eindeutig: "Leading [...] the organization in its Scrum adoption", "Planning Scrum implementations within the organization" und "Working [...] to increase the effectiveness of the application of Scrum in the organization" sind klare Beschreibungen von (Change-)Management-Tätigkeiten. Die können zwar in der Theorie von jedem verantwortet werden, die Übertragung von derartiger Verantwortung an unerfahrene Kollegen ist aber sehr unwahrscheinlich (siehe auch Ist der Scrum Master ein Manager?).

All das spricht also dafür, dass es eher erfahrenere Kräfte sein sollten, die die neue Rolle übernehmen. Selbst wenn es beim Nachwuchs natürlich auch Ausnahme-Erscheinungen geben mag - die meisten eher junioren Kollegen dürften aus den genannten Gründen Schwierigkeiten haben ihre Rolle auszuüben. Es bleibt die letzte Frage - kann man diese Tätigkeiten dann nicht aus ihr herausnehmen? Die Antwort darauf findet sich ebenfalls im Scrum Guide: "Although implementing only parts of Scrum is possible, the result is not Scrum". Mit anderen Worten: man kann das zwar machen, sollte dann aber seine Erwartungshaltung an das Ergebnis herunterschrauben.


¹Es gibt auch Firmen die glauben, dass man für den Job nur den zweitägigen Zertifizierungskurs braucht. Die haben andere Probleme.

Agile Bauprojekte (III)

Bild: Wikimedia Commons / China News Service - CC BY 3.0

So tragisch der Ausbruch des Corona-Virus in China auch gewesen ist, aus Projektmanagement-Perspektive hat er zu einem interessanten Fallbeispiel geführt. In weniger als zwei Wochen sind in Wuhan, dem Ort an dem die Seuche ausgebrochen ist, zwei Krankenhäuser komplett neu errichtet worden. Auch die Gründe dafür, dass das in derartiger Rekordzeit gelungen ist sind nachvollziehbar, denn bedingt durch die weltweite Aufmerksamkeit die ein solcher Virus auf sich zieht fand eine intensive Berichterstattung in den Medien statt, unter anderem in der New York Times, der BBC, auf QZ.com, in der South China Morning Post und bei Xinhua. Folgende Faktoren scheinen die schnelle Baugeschwindigkeit möglich gemacht zu haben:

Zweckbau statt Show-Architektur

Einige der verheerendsten Bauprojekte sind vor allem deshalb aus dem Ruder gelaufen weil der Architekt besonders schön bauen wollte, was dann in der Umsetzung besonders aufwändig wurde. Die schornsteinfreie Entrauchungsanlage am Berliner Flughafen, die Kelchstützen im Stuttgarter Bahnhof, der Verzicht auf rechte Winkel in der Elbphilharmonie - keine derartige Idee dürfte in Wuhan auch nur erwogen worden sein, was die Errichtung ungemein vereinfacht haben dürfte.

Einfache Bauweise

Die Krankenhäuser sind nicht nur Zweckbauten, es sind einfache Zweckbauten. Die Gebäude sind kastenförmige, zweigeschossige Flachbauten ohne Keller. Damit waren keine Ausschachtungsarbeiten nötig, die tragenden Wände müssen kein grosses Gewicht aushalten, es gibt keine breiten oder hohen Hallen mit komplizierter Statik. Das ist simpel und schnell zu planen und zu bauen. Auch weitere Aufwände wie die Entsorgung der ausgebaggerten Erde und der Transport und Aufbau hoher und stabiler Gerüste sind entfallen.

Focussierung

Ähnlich wie das im Jahr 2003 während der SARS-Epidemie gebaute Xiaotangshan Hospital in Peking dienen die neuen Krankenhäuser nur der Bekämpfung einer einzigen Krankheit. Bedingt dadurch kann vieles entfallen was in normalen Krankenhäusern vorhanden sein muss: OP-Räume, Radiologie-Anlagen, medizinische Labore und Entbindungsstationen mussten nicht gebaut werden, wodurch die Komplexität des Bauvorhabens noch einmal reduziert wurde.

Modularisierung

Durch die einfache und focussierte Architektur wurde ein weiterer Beschleunigungsfaktor möglich: der Grossteil der beiden Gebäude wurde aus vorgefertigten Bauteilen errichtet, die parallel an anderen Orten angefertigt wurden und vor Ort nur noch zusammengebaut werden mussten. Eine Bauweise die auch in Deutschland bekannt ist, die im Osten verbreiteten Plattenbauten wurden so errichtet (daher auch der Name → aus Platten zusammengebaut).

Standardisierung

Das gerade erwähnte Xiaotangshan Hospital ist aus einem weiteren Grund von Bedeutung: durch seine seinerzeit ähnlich schnelle Errichtung gab es Erfahrungswerte die als Blaupause für die Neubauten verwedet werden konnten. Die Voraussetzung dafür war allerdings, dass die Behandlung und Pflege von SARS- und Corona-Virus-Patienten mit den gleichen Anlagen und Geräten möglich ist. Das scheint in diesem Fall auch so gegeben gewesen zu sein.

Entbürokratisierung (Priorisierung)

Die beschleunigten Genehmigungs- und Finanzierungsverfahren haben sicher auch damit zu tun gehabt, dass durch die zuvor genannten Faktoren das Ausmass der Komplexität und der nötigen Qualitätssicherung deutlich reduziert werden konnte. Gleichzeitig muss es aber auch so gewesen sein, dass der Teil auf den nicht verzichtet werden konnte Vorrang vor allen anderen Vorhaben hatte. Ganz wesentlich dürfte diese klare Priorisierung mit der ausgerufenen Notlage zu tun haben.

Skalierung

Auf vielen Bildern kann man erkennen, dass Arbeiten so weit wie möglich parallelisiert wurden. Alleine auf dem oben zu sehenden Bild befinden sich über 30 Baufahrzeuge, auf anderen Bildern sind zahllose Arbeiter zu sehen die gleichzeitig Beton giessen, Dachplanen ausrollen oder sonstige parallel ausführbare Tätigkeiten durchführen. Man kann davon ausgehen, dass zwei Voraussetzungen dafür nötig waren: ein immenses Budget und eine boomende Bauindustrie, mit vielen ausgebildeten Arbeitern und geeigneten Maschinen. Beides war in diesem Fall vorhanden.

Verzicht auf Nachhaltigkeit

Positiver formuliert: hier wurde mit einem MVP-Gedanken im Kopf gebaut. Noch einmal zum Referenz-Beispiel des Xiaotangshan Hospitals. Nach dem Abklingen der SARS-Epidemie wurde es anscheinend weitgehend aufgegeben und stand leer, was auch nachvollziehbar ist. Viele der funktionalen und ästhetischen Beschränkungen die eine schnelle Errichtung möglich machen grenzen auch die Nachnutzung ein. Andererseits stand hier eben die schnelle Seuchenbekämpfung im Mittelpunkt und nicht nachhaltiges Bauen.

---

Natürlich ist der Bau der Kankenhäuser in Wuhan ein Extrembeispiel, dass nur im Rahmen extremer Rahmenbedingungen möglich war und daher nur begrenzt in andere Kontexte übertragbar ist. Es zeigt aber auch, dass in kürzester Zeit erstaunliches möglich ist wenn Willen und Dringlichkeit da sind. In die "agile Terminologie" übertragen - der Bau eines ganzen funktionierenden Kankenhauses hat gerade mal einen Sprint gedauert. Das ist mehr als beachtlich.

Anekdotische Evidenz

Bild: Pexels / Fauxels - CC0 1.0

Wann immer eine Gruppe Agile Coaches, Unternehmensberater und Scrum Master zusammensitzt um darüber zu diskutieren wie man agile Transformationen ganzer Unternehmen durchführen kann, wird man eines mit Sicherheit erwarten können: lebhafte Erfahrungsberichte. Anders wird es dagegen aussehen wenn um deren Repräsentativität geht und um die empirische Fundierung. Nur in extrem seltenen Fällen hat jemand mehr als zehn Transformationen über einen längeren Zeitraum in einer Position mit Gesamtüberblick begleitet, die meisten werden sogar auf weniger als fünf kommen.¹

Den an dieser Stelle naheliegenden Exkurs zu den Hauptgütekriterien statistischer Werte kann man sich angesichts dieser Zahlen gleich ersparen, zu offensichtlich ist es, dass die Menge zu gering ist um allgemeingültige Erkenntnisse abzuleiten. Die daraus folgende spannende Frage: wer könnte denn über die notwendige Menge an Erfahrungen verfügen? Ein altgedienter Berater mit jahrzehntelanger Projekterfahrung? Auch das eher nicht, alleine wegen der üblichen Karrieren. Den einfachen Juniors und Consultants fehlt noch der Überblick, die Partner und Associates sind schon wieder zu weit weg vom Geschehen. Im Mittelbau gibt es zwar relevante Erfahrung, aber dort verbleibt kaum jemand lang genug.

Es bleibt eine andere Möglichkeit: wenn schon kein Einzelner über repräsentative Erfahrungswerte verfügt - vielleicht kommen im kollektiven Gedächtnis von Unternehmen genug zusammen? Schön wärs, aber vermutlich ist auch das nicht der Fall. Vor dem Hintergrund, dass in nahezu jedem Einzelfall einzigartige Konstellationen bedeutender Einflussfaktoren vorliegen (Demografie der Belegschaft, Regulierungsintensität, Unternehmenskultur, Unternehmensaufbau, Zustand der Systemlandschaft, Branchen-Besonderheiten, aktuelle Management-Moden, etc.) kann bezweifelt werden, dass irgendwo auf dieser Welt eine Datenbasis vorliegt aus der man brauchbare Erkenntnisse ableiten kann.

Sollte das aber der Fall sein, dann würde es sich bei allen Erfahrungsberichten und bei aller daraus abgeleiteten Expertise um nicht mehr halten als um das was man in den Sozialwissenschaften Anekdotische Evidenz nennt. Und hinter diesem Begriff steckt etwas wovon eigentlich strikt abzuraten ist: das Ableiten allgemeingültiger Aussagen aus eigenen Erlebnissen oder (noch schlimmer) aus Berichten von Einzelfällen bei denen man selbst nicht zugegen war und deren Dokumentation lediglich aus oberflächlichen Wiedergaben besteht. Eigentlich sollte all das auch eine Selbstverständlichkeit sein, da manche Anekdoten aber zu gut klingen gibt es mittlerweile ganze agile Pseudo-Frameworks, die nur auf anekdotischer Evidenz beruhen (Spotify, anyone?).

Es bleibt die Frage: wenn es keine verlässlichen Erfahrungswerte für agile Transitionsforhaben gibt, wie sollen sie dann organisiert werden? Die naheliegende Antwort - agil. Wie immer wenn die Zukunft ungewiss ist wird es das beste Vorgehen sein sich auch über längere Zeiträume per Inspect & Adapt voranzutasten. Und um das zu können ist es erforderlich die Transformation in kleine, auch allein Mehrwert stiftende Pakete zu unterteilen und zu diesen dann regelmässig das Feedback der betroffenen einzuholen und dieses ins weitere Vorgehen einfliessen zu lassen. Dieses Vorgehen mag zwar nicht den Charme der eloquent vorgetragenen Erfolgs-Anekdote haben, dafür aber eine wesentlich grössere Erfolgswahrscheinlichkeit.


¹Unternehmensweite Transformationen dauern mehrere Jahre, so dass man alleine bei zwei oder drei von ihnen problemlos ein Jahrzehnt verbringen kann.

Kommentierte Links (LVIII)

• Holger Schmidt: „Noch ist das Gerede von Industrie 4.0 Unsinn“

Hier wird Einiges an Content geboten. Sowohl der verlinkte Artikel als auch das dort eingebettete Video sind sehenswert für jeden der davon ausgeht, dass Deutschland (oder sonst irgend ein Land auf der Welt) seine produzierende Wirtschaft schon auf die so genannte "Industrie 4.0" umgestellt hat. Der Grund dafür ist, dass die dafür notwenige Datenerhebung und Datenzusammenführung noch immer in fast keinem Unternehmen stattfindet. Nicht etwa weil das nicht gewollt ist sondern weil die (meistens Jahrzehnte alten) Anlagen einfach nicht so gebaut sind, dass das möglich wäre. Passend dazu auch dieser Artikel von Frank Thelen in dem er davon ausgeht, dass Tesla von den deutschen Autobauern kaum noch einzuholen ist - weil es anders als diese grossen Wert auf Datenerhebung und -auswertung legt.

• Willem-Jan Ageling: Scrum didn’t work for us, so we went back to PRINCE2 / PRINCE2 didn’t work for us, so we went back to Scrum

  Hier wird der Finger in eine Wunde gelegt, die in mehr als einer Hinsicht schmerzt. In diesen zwei fast identischen Artikeln zeigt Willem-Jan Ageling auf, dass die Einführung von Agilität in grossen Organisationen an der selben Unwilligkeit sich an Prozesse zu halten scheitert wie zuvor die Einführung von eher klassischen Management-Vorgehen (Stichwort Konzern-Anarchismus). Und mehr als das - auch dass diesen ihre scheinbare Erfolglosigkeit genauso wenig vorgehalten werden kann wie den agilen Frameworks ihre oft scheiternde Umsetzung. Es ist in den meisten Fällen nie ernsthaft versucht worden. Ein ernsthafter Vergleich dieser Ansätze dürfte daher in den meisten Fällen unmöglich sein - in ihrer eigentlich angedachten Form kennt man beide oft nur vom Hörensagen.

• Nadja Kupsa / Gerald Hüther: "Kinder machen sich aus Liebe zu Eltern selbst unglücklich"

  Zunächst ein scheinbar abseitiges Thema - was hat kindliche Entwicklung mit Agile, Scrum, Kanban, Change Management und dem ganzen Rest zu tun? Erstaunlich viel. Gerald Hüther gibt hier einen hochinteressanten Einblick in die Entstehung und die Folgen von Konformitätsdruck. Kurz zusammengefasst: er ist nicht grundsätzlich schlecht, hat aber häufig die negative Auswirkung, dass das eigene (Kreativ)Potential nicht mehr abgerufen werden kann. Was das für Folgen auf Wirtschaft und Gesellschaft haben kann wird an Beispielen erläutert, und auch einen Lichtblick gibt es: dank der Neuronalen Plastizität kann man Deformationen noch bis zum Lebensende ausgleichen.

•  Naomi Stanford: Decaf, pragmatic and real resistance

  Dass es keinen Widerstand gegen Veränderungen gibt sollte Allgemeinwissen jedes Menschen sein, der sich mit Organisationsentwicklung beschäftigt. Widerstand gegen vom Betroffenen als negativ wahrgenommene Veränderungen gibt es aber, und Naomi Stanford versucht sich an einer Kategorisierung.
  
  • "Entkoffeinierter Widerstand" ist abgeleitet von entkoffeiniertem Kaffe - er fühlt sich ähnlich an, entfaltet aber keine nachhaltige Wirkung. Im Wesentlichen besteht er aus mehr oder weniger lautem und sarkastischen Anzweifeln der Wirksamkeit.
  • Pragmatischer Widerstand ist der Versuch irrationale oder untereinander widersprüchliche Arbeitsanweisungen so zu umgehen, dass produktives Arbeiten wieder möglich ist. Erinnert stark an Luhmanns brauchbare Illegalität.
  • Echter Widerstand ist das, was der umgangssprachlichen Definition von Widerstand am ehesten entspricht, von der Auflehnung und Verweigerung bis hin zum Whistleblowing. In der Wirklichkeit sehr selten anzutreffen, da es mit der Gefahr von Statusverlust und Karrierenachteilen verbunden ist.
  Erwähnenswert ist an Stanfords kurzer Liste die wissenschaftliche Fundierung. Sowohl das Konzept des "entkoffeinierten" als auch das des pragmatischen Widerstands beruhen auf Publikationen in denen das Thema weiter vertieft wird.

• Ray Arell: Viable Organizations with Beer

  Zugegeben, dieser Artikel ist vor allem wegen seines Namens verlinkt. Lesenswert ist er aber trotzdem. Ein weniger Clickbait-artiger Titel hätte darauf verwiesen, dass es hier um das Viable Systems Model geht, das 1972 von Stafford Beer entwickelt wurde. Um noch mehr Klickbait einzubringen - es geht in ihm um Management-Kybernetik.

Kaizen Folder

Bild: Pixabay / Vargazs - CC0 1.0

Ein von mir gecoachtes Team probiert gerade eine neue Idee aus um seine Prozessverbesserungen besser zu strukturieren und nachvollziehbarer zu machen: es legt einen Kaizen-Ordner/Kaizen Folder an. Der Hintergrund ist der, dass dort seit einigen Monaten nach Kanban gearbeitet wird und nach und nach immer weitere Verbesserungsideen erprobt werden sollen. Der Ordner soll dabei zwei Zwecke erfüllen - zum einen soll er als Archiv und Erinnerungsstütze dienen um zu verhindern, dass Erfahrungen und Erkenntnisse irgendwann in Vergessenheit geraten, zum anderen soll er es anderen Teams ermöglichen sich inspirieren zu lassen und von den bereits gemachten Erfahrungen zu profitieren.

Wie immer kann und soll das Format in Zukunft angepasst werden können wenn es nötig und sinnvoll ist, der erste Entwurf sieht aber so aus, dass das folgende Template für die im Ordner gesammelten Ideen verwendet werden wird:

Sprechender Titel
Kategorie
Problembeschreibung
Lösungshypothese
Erfolgskriterien
Umsetzung seit / von-bis
Wenn beendet: warum

Dieses Format ist zu Beginn bewusst schlicht gehalten und kann zukünftig noch ergänzt werden, beispielsweise um Metriken, Umsetzungsaufwände, betroffene Stakeholder, etc. Die Idee ist aber, dass die Struktur organisch wachsen kann, so dass sie zu Beginn nicht zu komplex oder überladen wirkt, was für die Anwender abschreckend sein könnte.

Ein Beispiel für die Anwendung wäre dieses hier:

Titel
"Ready to pull" sichtbar machen

Kategorien
Bessere Visualisierung, Besserer Arbeitsfluss

Problembeschreibung
Es ist nicht erkennbar ob die Arbeit in einer Spalte, bzw. Phase abgeschlossen ist

Lösungshypothese
Eine Drehung des Tickets um 90° ist als Kennzeichnung ausreichend

Erfolgskriterien
Keine Unsicherheiten/Diskussionen im Standup Meeting mehr

Umsetzung seit
Januar 2020

Solange es sich um Verbesserungen des physischen Kanban-Boards handelt bietet es sich an auch Fotos mit abzulegen, durch die neben der Idee auch die Art der Umsetzung besser nachvollziehbar wird. Andere Elemente die man einfügen kann wären Formatvorlagen, Erfahrungsberichte, Feedbacks oder Verweise auf zusammenhängende oder ähnliche Prozessverbesserungen. Begrenzungen gibt es hier nicht, es ist allerdings ratsam zu Beginn immer eine reduzierte Übersicht wie die oben genannte zu haben, um die relevanten Informationen schnell überblicken zu können.

Der Kaizen Folder wird in diesem Fall digital sein, was die Vorteile hat, dass parallele Zugriffe möglich sind, dass von anderen Standorten aus zugegriffen werden kann und dass eine Suchfunktion existiert. Bei Vorlieben für haptisches Arbeiten spricht aber auch nichts gegen einen physischen Ordner, der in einem Regal im Teamraum stehen kann.