Schläferzellen

Bild: Pexels / Burst - CC0 1.0

Es ist nur ein einziger Satz aus einem Bericht vom Peter Drucker Forum 2018, aber es lohnt sich länger über ihn nachzudenken. Er steht in einem Absatz in dem die immer stärker werdende Verbreitung von "Human-Centered Management" beschrieben wird und lautet "'Sleeper cells' of the new way of managing have sprung up in many more organizations." Aber was soll uns das sagen?

Zunächst zur Begrifflichkeit. Sleeper Cell (Schläferzelle) bezieht sich in diesem Zusammenhang auf eine Frühphase revolutionärer Bewegungen. Gruppen von Menschen kommen mit neuen, radikalen oder ungewöhnlichen Ideen in Berührung, die zu diesem Zeitpunkt noch nicht anerkannt, nicht zulässig oder stigmatisiert sind. Bedingt dadurch erfolgt die Beschäftigung damit zunächst zurückgezogen im privaten oder informellen Raum.

Wenn die neuen Ideen schliesslich in der öffentlichen Diskussion oder sogar der Umsetzung ankommen werden die bis dahin ruhigen (schlafenden) Gruppen aktiv und sorgen dafür, dass (von aussen betrachtet) aus dem Nichts eine Unterstützerbasis entsteht auf die sich der entstandene Veränderungsprozess stützen kann. Beispiele dafür sind der Prager Frühling oder der Arabische Frühling¹.

Auch im Rahmen von Management und Menschenführung kommen Schläferzellen vor, wenn auch mit einer sehr unterschiedlichen Dichte und Beteiligung, je nachdem um welche Denkrichtung es geht. Während prozess- und hierarchiezentrierte Ansätze von den potentiell Betroffenen eher skeptisch gesehen werden haben team- und menschenzentrierte Frameworks wie XP und Scrum aufgrund ihrer Soft Power-Faktoren eine sehr hohe Anziehungskraft.

Wenn eine Organisation sich dazu entschliesst es mit Agilität zu versuchen gibt es daher in der Regel den oben beschriebenen Effekt: scheinbar aus dem Nichts entstehen (vor allem in der IT) Gruppen die bereits Vorwissen mitbringen, sich an der Umsetzung und Gestaltung des Veränderungsprozesses beteiligen wollen und den Finger in die Wunde legen wenn er sich in die falsche Richtung entwickelt.

Für die Veränderung ist das ein doppelter Glücksfall. Zum einen ist sie von Beginn an in Teilen der Organisation verankert, wodurch sie eine ganz andere Wirkungskraft entfalten kann als ein rein von oben getriebenes Vorgehen. Zum anderen wird frei Haus eine Validierungsmöglichkeit geliefert. Ob es mit dem Veränderungswillen ernst gemeint ist kann man jetzt u.A. daran erkennen ob sich die "erwachten Schläfer" beteiligen dürfen oder nicht.

Und selbst wenn die Veränderungsbemühungen fehlschlagen oder sich festfahren sollten bleibt Positives zurück: die Zahl der Zellen die wieder zurück in den Schlafmodus gehen hatte die Chance deutlich zuzunehmen. Bei der nächsten Aktivierung ist der initiale Schwung dadurch nochmal grösser.


¹Es gibt auch den Fall von destruktiven Schläferzellen, aber das wäre ein anderes Thema.

Delivering twice the value in half the time

Bild: Pixabay / Annca - CC0 1.0

Weitgehend unbemerkt von der Öffentlichkeit hat sich irgendwann in den letzten Wochen eine unscheinbare aber bedeutsame Änderung ergeben: eines der bekanntesten Versprechen von Scrum wird anscheinend nicht mehr in seiner ursprünglichen Form weiterverwendet. Die Rede ist von doing twice the work in half the time, bekannt geworden als Titel eines Buches von Scrum-Mitbegründer Jeff Sutherland. Stattdessen spricht er seit kurzem von delivering twice the value in half the time. Ein kleiner aber feiner Unterschied.

Die Aussage "Doing twice the work", die seit je her von Scrum Practitionern kritisch gesehen wird, impliziert, dass die Einführung von Scrum zu einem höheren Durchsatz führt. Egal welche Tätigkeiten ein Team durchführt, es wird in die Lage versetzt noch mehr davon zu leisten. Man spricht im Englischen in diesem Zusammenhang von der Erhöhung des Output. Was nicht klar ist (und hier setzt die Kritik an der Formulierung an) ist, ob der durch diese Tätikeiten erzeugte Output überhaupt einen Sinn ergibt.

Wer in grossen Organisationen arbeitet kennt das Risiko - viele Teams erzeugen Arbeitsergebnisse von fragwürdigem Wert: Konzepte die an der Realität vorbeigehen, Statistiken die Offensichtliches oder Irrelevantes messen, Funktionalitäten die die Kunden nicht brauchen, etc. Davon mehr zu bekommen hilft niemandem weiter. Und selbst wenn Sutherlands Buch inhaltlich nichts derartiges fordert, der Titel verführt zu diesem Fehlschluss.

Besser ist es, bei jeder bisher durchgeführten Tätigkeit die Sinnfrage zu stellen. Je mehr an Elfenbeintürmen, Junk Charts, Bloatware, etc. weggelassen werden kann, desto mehr Zeit bleibt für die Arbeit an wirklich wichtigen Themen. Um es mit den Worten des Manifests für agile Softwareentwicklung zu sagen: Simplicity - the art of maximizing the amount of work not done - is essential. Viele der Bestandteile von Scrum (Definition of Done, Sprintziel, User Stories, etc.) zielen genau darauf ab.

Diese Art von werthaltigen und sinnstiftenden Ergebnissen nennt man im Englischen Outcome. Da für ihre Fertigstellung im Idealfall nur die nötigste Arbeit verrichtet und alles Unnötige unterlassen wurde, sind der Aufwand und die Zeit die investiert werden müssen deutlich niedriger als im Fall einer Output-orientierten Arbeitsweise. Daher macht die Aussage delivering twice the value in half the time absolut Sinn. Richtig angewandt kann Scrum dafür sorgen, dass in weniger Zeit mehr Mehrwert entsteht.

Ganz aus der Welt bekommen wird man das "Doing twice the work" zwar wohl nicht mehr, zukünftig kann man aber jedem der es falsch versteht zeigen, dass die Formulierung weiterentwickelt wurde. Ganz im Sinn von Inspect & Adapt.

Just in Time vs. Just in Case

Irgendwo ist dieses Video durch meinen Twitterfeed gerauscht. Eine kurze Erklärung des Just in Time-Prinzips (Produktion nur nach Bedarf, ohne Lagerhaltung), mit netten, z.T. amüsanten, Visualisierungen. Man kann es sich gut als Einführung in das Thema anschauen.



Ein interessanter Ansatz für die Vermittlung dieser Idee ist dabei die Gegenüberstellung eines zweiten Prinzips: Just in Case. Die deutsche Übersetzung Für alle Fälle zeigt worum es geht - etwas mehr Zeit, Material und Personal als nötig hilft im Zweifel dabei, ungeplante und unvorhersehbare Aufwände zu bewältigen. Da beide Ansätze ihre Vorteile haben wird es in den meisten Fällen auf eine Abwägung herauslaufen. Und um die griffig beschreiben zu können ist das Gegensatzpaar Just in Time und Just in Case gut geeignet.

Kommentierte Links (XXXXIII)

• Johannes Schartau: Fight Zombie Product Ownership with the Product Ownership Evolution Model

  Eigentlich wollte ich ja schon länger etwas zum Product Ownership Evolution Model (POEM) von Oliver Winter und Tim Klein schreiben. Johannes Schartau hat mir das freundlicherweise abgenommen. Für die Details verweise ich einfach mal auf ihn, an dieser Stelle soll die Visualisierung reichen, die Tim und Olli freundlicherweise unter einer Creative Commons-Lizenz zur Verfügung gestellt haben:
  
  

• Mark Schwartz: Your First Four Steps in Transforming Enterprise IT Governance

Ein Blick aus der Adlerperspektive. Was Mark Schwartz beschreibt ist letzten Endes nichts anderes als Kanban. Reduziere die Anzahl der Initiativen (bzw. des Work in Progress), verkürze die Durchlaufzeiten, schliesse Vorhaben so schnell wie möglich ab, fokussiere Dich bei den Ergebnissen auf die Erzeugung von Geschäftswert und die Validierung von Annahmen. Dass das auch der Ebene ganzer Konzerne möglich ist zeigt eine der Stärken von Kanban auf - es lässt sich auf jede Ebene skalieren.

• Tobbe Gyllebring: What if demonizing “waterfall” pulled the rug out from under our Agile?

  Ein interessanter Denkansatz. Tobbe Gyllebring geht davon aus, dass agile Vorgehensweisen vor allem dann wirksam und verständlich sind wenn man das klassische Wasserfallmodell als Kontrast parat hat, weil man dieses noch erleben musste, bzw. durfte. Das ist zwar nicht völlig falsch, die Frage ist aber was die Konsequenz wäre. Dysfunktionale Strukturen (wieder)einzuführen nur um Kontextwissen zu erzeugen wäre sicher über das Ziel hinausgeschossen. Vielleicht sollte man bewusst eine Karrierestation dort einlegen wo man noch nicht so weit ist und man deshalb lernen kann wie es nicht geht? Eine gewagte Idee.
  

• Heidi Araya: Why Agile Works

  Einmal mehr ein klassischer Erklär-Artikel. Angereichert um einige gute weiterführende Links fasst Heidi Araya ein "Best of" aus Agile, Kanban, Lean Startup, technischer Exzellenz und Kundenorientierung zu einer verständlichen Storyline zusammen. Falls wieder jemand nach einer schriftlichen Zusammenfassung fragt ist das hier ein guter Kandidat. Jetzt müsste ich nur noch die Motivation und die Zeit finden das ins Deutsche zu übersetzen ....

• Angela Merkel: Projekte nicht so umsetzen wie wir das gewöhnt sind

  Sollte es noch eines weiteren Beweises bedurft haben, dass agile Softwareentwicklung im Mainstream angekommen ist - hier ist er. Iteratives und incrementelles Arbeiten wird in verständlicher Sprache vorgestellt. Im deutschen Bundestag. In der Generaldebatte des Bundeshaushalts 2019. Von der Bundeskanzlerin persönlich.

Gesetz der Penetranz der negativen Reste

Bild: Public Domain Pictures / Ian Bunyan - CC0 1.0

Alleine der Name ist so schräg, dass man versucht ist herauszufinden was sich dahinter verbirgt. Das "Gesetz der Penetranz der negativen Reste" setzt sich mit dem Phänomen auseinander, dass die Lösung von Problemen bei vielen Menschen nicht dazu führt, dass sie mit ihrer Gesamtsituation zufriedener sind. Im Gegenteil bleibt der Grad der Unzufriedenheit durchgehend gleich, er konzentriert sich lediglich auf einen immer kleineren Problem-Restbestand.

Der Philosoph Odo Marquard, Schöpfer des Begriffs, definiert ihn so: Wo Fortschritte … wirklich erfolgreich sind und Übel wirklich abschaffen, da wecken sie selten Begeisterung. Sie werden vielmehr selbstverständlich, und die Aufmerksamkeit konzentriert sich dann ganz und gar auf jene Übel, die übrigbleiben. Da wirkt das Gesetz der zunehmenden Penetranz der Reste: ... Wer – fortschrittsbedingt – unter immer weniger zu leiden hat, leidet unter diesem Wenigen immer mehr.

Ursprünglich stammt dieses "Gesetz" aus Beobachtungen im Bereich der Medizin, wo sich trotz immer besserer Gesundheit der Gesamtbevölkerung die Sorgen um die eigene Gesundheit halten und auf immer nachrangigere Aspekte konzentrieren. Zum Teil kann es dort sogar in Extreme wie Medikalisierung und Pathologisierung umschlagen. Übertragen lässt es sich aber auch auf die Organisationsentwicklung, bzw. die zu dieser gehörenden Optimierungsprozesse.

Geht man davon aus, dass auch hier Fortschritte dazu führen, dass die verbleibenden Probleme pathologisiert und mit dauerhaft gleichbleibender Energie bekämpft werden, hat man eine Erklärung für den in vielen Organisationen anzutreffenden Drang zur "Über-Optimierung". Die scheinbare Irrationalität, mit der selbst kleinste Einspar- und Effizienzpotentiale hartnäckig verfolgt werden, wird plötzlich erklärbar.

Das Problem ist, dass es hier anders als beim Gesundheitsempfinden nicht bei Übersensibilität und Hypochondrie bleibt. Das Gesetz der Penetranz der negativen Reste kann schwerwiegende wirtschaftliche Folgen haben: nicht nur wegen des immer unverhältnismässiger werdenden Verhältnisses zwischen Optimierungs-Aufwand und Ertrag, sondern auch wegen der früher oder später fast zwangsläufig auftretenden Beeinträchigung elementarer Funktionen.

Getrieben von dem Drang auch kleinste Dysfunktionen aufzuspüren ist in vielen Organisationen ein derart engmaschiges und aufwändiges Reporting und Controlling entstanden, dass die Erfüllung der damit verbundenen Vorgaben einen Grossteil der Arbeitsleistung bindet. Die wertschöpfenden Tätigkeiten gehen dagegen immer weiter zurück, mitunter soweit, dass die erwirtschafteten Gewinne die entstandene Bürokratie nicht mehr finanzieren können.

Um die damit verbundenen Folgen (die im schlimmsten Fall bis zur Insolvenz reichen können) abzufedern empfiehlt sich eine regelmässige Überprüfung aller zur Zeit laufenden Optimierungsmassnahmen. Welches Ziel sollen sie erfüllen, welcher wirtschaftliche Effekt soll damit erreicht werden und wie hoch sind die dem gegenüberstehenden Verwaltungs- und Bürokratiekosten? Und bei lokalen Optimierungen: was sind deren Auswirkungen auf das Gesamtsystem?

Wenn es gelingt durch solche Evaluierungen die Stellen zu identifizieren, an denen das Gesetz der Penetranz der negativen Reste zu Überoptimierungen geführt hat, kann deren Abschaffung befreiend wirken. Je nach Kontext kann die dadurch mögliche (Wieder)Zunahme an Effektivität und Flexibilität sogar so gross sein, dass ihre Rücknahme bereits die Effekte einer agilen Transition hat, ganz ohne Scrum Master, Standup Meetings & Co.

DoD Memory

Bild: Pxhere / Rawpixel - CC0 1.0

When life gives you lemons - make lemonade. Gemäss diesem englischen Sprichwort haben wir (ich und ein von mir gecoachter Scrum Master) diese Woche eine neue Übung für die nächste Retrospektive entwickelt. Angelehnt an das Memory-Spiel ist der vorläufige Name DoD Memory, denn auch hier geht es um einen Test des Erinnerungsvermögens.

Zu den Hintergründen: das Team um das es geht leidet unter einer Sonderform der agilen Demenz - die eigene Definition of Done (DOD) gerät regelmässig in Vergessenheit. Selbst wenn sie in Retrospektiven oder gesonderten Workshops neu erstellt oder überarbeitet wird ist es nur eine Frage der Zeit bis sich niemand mehr an sie erinnern kann und demzufolge auch niemand mehr an sie hält. Aus den Augen, aus dem Sinn, wie man in einem anderen Sprichwort so schön sagt.

DoD Memory funktioniert jetzt so: der Scrum Master (oder jeder andere der sich berufen fühlt) kann in einer Retrospektive darum bitten, dass jedes Teammitglied alle Teile der DoD an die es sich erinnern kann aufschreibt - am besten in Stillarbeit. Die Ergebnisse werden gesammelt und dann mit der tatsächlichen DoD verglichen (die zu diesem Zweck verfügbar sein sollte).

Sollte es jetzt der Fall sein, dass Teile der Definition of Done keinem einzigen Teammitglied eingefallen sind stellt sich die Frage was das für das Team bedeutet. Da davon ausgegangen werden kann, dass nicht präsente Teile der DoD nicht angewendet werden, kann zur Debatte gestellt werden ob sie nicht gestrichen werden sollten. Gewissermassen wäre das die Anpassung der Regeln an die Realität. Alternativ kann überlegt werden wie die DoD präsenter gemacht werden kann.

Geschieht das gibt es zwei mögliche Endszenarien. Entweder gelingt es durch die Thematisierung in Retrospektiven und durch abgeleitete Massnahmen die DoD zu verinnerlichen oder sie schrumpft nach und nach zusammen bis nur noch der Rest übrig ist an den sich jeder erinnern kann. Beides hat Vorteile. Bei Bedarf kann natürlich auch wieder eine Erweiterung stattfinden, die dann aber irgendwann auf die selbe Art validiert werden sollte.

Letztendlich können vergleichbare Übungen auch mit anderen Vereinbarungen durchgeführt werden, etwa der Definition of Ready oder der Teamcharta. Auch in diesen Fällen ist es ein guter Weg um der agilen Demenz entgegenzuteten, die auch in den besten Teams um sich greifen kann.

Ein Bild sagt mehr als 1000 Worte (XXIII)

Bild: Geek & Poke - CC BY 3.0

Und falls das eine Bild doch nicht reichen sollte um zu erkennen worum es hier geht - hier gibt es Kontext.

Wie Angst lähmen kann

Bild: Wikimedia Commons / J. M. Garg - CC BY-SA 4.0

Zu den deprimierendsten Erfahrungen als Agile Coach gehört es, mit dem Auftrag zur Veränderungsbegleitung bei einem Team zu erscheinen, ihm das theoretische und methodische Rüstzeug mitzugeben, erste Verbesserungspotentiale aufzuzeigen und dann zu hören "Nein, das machen wir nicht, das werden die uns nie erlauben." Gegen diese Stimmung anzukämpfen ist schwierig aber notwendig, denn wenn sie nicht verschwindet sind echte Veränderungen unwahrscheinlich.

Das Problem ist, dass es sich bei einem Grossteil dieser scheinbaren Verbote um keine offiziellen Regeln handelt sondern um inoffizielle. Es ist also nirgendwo festgehalten, dass man eine bestimmte Handlung (Überstunden ablehnen, selbst Entscheidungen treffen, Anforderung hinterfragen, etc.) nicht durchführen darf. Trotzdem wird oft angenommen, dass ein Verbot besteht und allein das in Erwägung ziehen eines nicht konformen Verhaltens wird vehement negiert.

Dort wo derartige Verhaltensweisen an den Tag gelegt werden kann mit hoher Wahrscheinlichkeit davon ausgegangen werden, dass das als verboten angenommene Verhalten irgendwann in der Vergangenheit bestraft worden ist. Alleine die Erinnerung daran (und die Angst vor einer neuen Bestrafung) kann dann dafür sorgen, dass mit allen Kräften versucht wird eine Wiederholung dieser Ereignisse zu verhindern. Für den psychologisch Interessierten: es ist die Übertragung des berühmten Rhesusaffen-Experiments von Gordon R. Stephenson auf den Menschen.

In einer solchen Situation ist es mit einem gut gemeinten Versuch es doch einfach nicht mehr getan. Was nötig ist, ist die Schaffung eines Safe Space, also einer Umgebung in der es sichergestellt ist, dass es nicht zu einer Bestrafung kommen wird - und zwar auch dann nicht (genauer gesagt gerade dann nicht!) wenn das Ergebnis nicht den Erwartungen entspricht oder ungeplante Seitenauswirkungen auf andere Bereiche hat. Nur wenn das gelingt kann es zu Verhaltensänderungen kommen.

Was ist für die Schaffung eines solchen Safe Space nötig? Zuerst das Ansprechen des Root Cause, also der in der Vergangenheit stattgefundenen Bestrafung¹.Wenn sie aufgrund einer damals noch gültigen Regel stattgefunden hat muss klar gemacht werden, dass diese Regel nicht mehr in Kraft ist, wenn sie ohne derartige Grundlage stattgefunden hat muss das als Fehler eingestanden werden. Und diese Aussage muss von der Hierarchiebene kommen von der aus die Bestrafung stattgefunden hat oder von einer höheren.

Als nächstes macht es Sinn festzuhalten, dass die aktuellen Regeln ein bestimmtes Verhalten nicht nur zulassen sondern sogar ermutigen. Idealerweise findet das nicht nur durch eine Anpassung des dritten Absatzes der vierten Seite des achten Kapitels des Prozesshandbuches statt sondern durch plakatives Aufhängen an einer zentralen Stelle, etwa als Banner mit der Aufschrift "Wir dürfen und sollen Nein sagen."

Falls nötig kann auch vereinbart werden was der Rahmen ist innerhalb dessen ohne Sorgen gehandelt werden kann. Dass Selbstorganisation nicht grenzenlos sein kann sollte eigentlich offensichtlich sein, und dass diese Grenzen nicht festgelegt wurden ist oft ein Grund für unbewusste Überschreitungen und ein als Strafe empfundenes nachträgliches Festsetzen. Was an dieser Stelle wichtig ist: ist der Rahmen zu eng gesetzt wird er im Zweifel als einengend und einschüchternd empfunden werden.

Zuletzt kann es helfen wenn die Respektierung der gewährten Freiheiten (und das Nicht-Stattfinden von Bestrafungen) regelmässig validiert wird. Wie das vor sich gehen kann wird von Fall zu Fall unterschiedlich sein müssen, möglich ist z.B. das Durchführen von Experimenten in einem iterativ immer grösser werdenden Rahmen oder ein anlassgetriebener Lessons Learned-Prozess. In jedem Fall sollten aber positive Beispiele hervorgehoben und erörtert werden.

Klar sollte sein, dass all diese Massnahmen in den meisten Fällen nicht nötig sein sollten. Sie machen vor allem dort Sinn wo in einem Unternehmen eine Angstkultur herrscht, die es abzuschaffen gilt, und die man erkennt an Sätzen wie "Nein, das machen wir nicht, das werden die uns nie erlauben."


¹Es gibt auch Fälle in denen das Management bestreitet, dass es eine Bestrafung gab, bzw. eine stattgefundene Handlung nicht als Bestrafung sehen will. Das sind dann nochmal ganz eigene Probleme.