Freitag, 30. November 2018

Kommentierte Links (XLIII)

Bild: Pixabay / Bru-nO - Lizenz

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

Dienstag, 27. November 2018

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.

Donnerstag, 22. November 2018

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.

Montag, 19. November 2018

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.

Donnerstag, 15. November 2018

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 Bestrafung1.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."


1Es 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.

Montag, 12. November 2018

Management 3.0

Bild: Pixabay / Monfocus - Lizenz
Einer der kleineren, trotzdem aber immer erfolgreicher werdenden agilen Ansätze ist das so genannte Management 3.0. Was das ist und wo es herkommt wäre eine Geschichte für sich, an dieser Stelle soll es aber zuerst nur um den Namen gehen. Schon hinter ihm versteckt sich nämlich ein für das Verständnis des Frameworks zentraler Punkt. Er definiert nicht nur was Management 3.0 ist, sondern auch was es nicht ist.

Wie man sich denken kann ist es eine Differenzierung von anderen Management-Praktiken. Dabei setzt es sich zuerst ab von der "herkömmlichen" Art Menschen und Unternehmen zu führen. In diesem Kontext wird diese Management 1.0 genannt und ist geprägt durch Hierarchiedenken, Herrschaftswissen, Command & Control und ähnlichen problematischen Vorgehensweisen.

Warum diese Vorgehensweisen problematisch sind ist aus einer agilen Perspektive klar: Hierarchien verhindern, dass sich die ausführende Ebene verantwortlich fühlt (und benimmt), Herrschaftswissen hält die Mitarbeiter dumm und führt so zu unklugen Entscheidungen, Command und Control verlagert den Ziel des Arbeitens weg von der Sinnerfüllung und hin zur Vorgabenerfüllung. So weit, so bekannt.

Darüber hinaus wird davon ausgegangen, dass es noch eine zweite Art von Management Praktiken gibt, die zwar in ihren Zielen etwas weiter ist, diese aber mit den bisher üblichen Methoden umsetzen will und aus diesen Gründen zwangsläufig daran scheitert. Letztendlich ist er damit nur der bessere unter den schlechten Ansätzen. Für ihn gibt es den Namen Management 2.0.

In der Realität sieht er so aus, dass z.B. Selbstorganisation angestebt wird, die aber dadurch umgesetzt werden soll, dass die dazu (angeblich) nötigen Strukturen den Mitarbeitern ungefragt übergestülpt werden. Klassiker in diesem Bereich sind die von oben angeordneten Einführungen von SAFe oder (Pseudo-)Spotify, was meistens nichts anderes ist als die Ersetzung alter Hierarchien und Kommandostrukturen durch neue.

Auch der Versuch eine neue Unternehmenskultur von oben vorgegeben und zentral gesteuert einzuführen ist eine Ausprägung von Management 2.0. Alleine die Idee, dass man Kultur durch Anordnung verändern könnte ist ein Missverständnis. Wenn dann noch paternalistische Aspekte dazukommen ("die müssen zu ihrem Glück gezwungen werden", "die werden noch verstehen warum das gut ist", etc.) ist kaum noch ein Unterschied zu Management 1.0 erkennbar. (siehe auch: agiler Marxismus und Leninismus)

Management 3.0 ist dagegen der Versuch alle Ebenen in Veränderungen und Entscheidungen einzubeziehen, und zwar nicht nur als Betroffene sondern als Beteiligte. Um das zu erreichen gibt es eine Vielzahl von Praktiken und Techniken die in ihrer Gesamtheit das Management 3.0-Framework ausmachen (z.B. Merit Money und Delegation Poker). Ihnen allen ist gemeinsam, dass sie nicht angeordnet sondern gemeinsam durchgeführt werden sollen.

Mit der Benennung 3.0 erfolgt damit nicht nur eine Differenzierung zum "traditionellen" Management sondern ganz wesentlich auch zu denen, die zwar eigentlich das Richtige wollen, die Transition aber durch Bevormundung der Mitarbeiter und undifferenziertes Copy & Paste anderswo erfolgreicher Methoden umsetzen wollen. Ihnen die Management-Typen 1.0, 2.0 und 3.0 zu erklären kann schmerzhaft aber hilfreich sein und ist daher zu empfehlen.

Freitag, 9. November 2018

Struktur, die aus Post-Its entsteht

Alberto Brandolini hat völlig recht wenn er sagt, dass das Identfizieren und Modellieren von Strukturen und Prozessen am besten mit bunten Zetteln auf einer grossen Wand stattfinden kann. Seine Art das zu tun nennt er Event Storming. Selbst wenn nicht alles davon in jeden Kontext passt, inspirieren lassen kann man sich durch seine Ideen auf jeden Fall.


Dienstag, 6. November 2018

Prozessverbesserung alleine ist keine Lösung

Bild: Wikimedia Commons / Johannes Martin Conrad - CC BY 3.0
Kann sich noch jemand an den Spruch "pünktlich wie die Bundesbahn" erinnern? Lange ist es her, dass das der Normalfall war. Angesichts von Verspätungsquoten von 30 % allein im Fernverkehr versucht die Bahn AG gerade gegenzusteuern. Mit dem so genannten Deutschlandtakt sollen Züge besser aufeinander abgestimmt werden, mit weiteren Massnahmen soll das Ein- und Austeigen schneller und effizienter gemacht werden. Das Ziel: mehr Pünktlichkeit.

Um die Erwartungen von Anfang an zu dämpfen: pünktlich werden die Züge auf diesem Weg nicht werden. Ein bisschen werden die Verspätungen mit Sicherheit zurückgehen, zum grössten Teil aber bestehenbleiben. Denn so gut die Prozessverbesserungen auch sein mögen, dass Hauptproblem werden sie nicht lösen können - die veralteten und immer wieder ausfallenden technischen Systeme.

Man kennt es aus den Durchsagen am Bahnsteig. Weichenstörungen unterbrechen die Fahrt, Signalstörungen verhindern die Einfahrt in die Bahnhöfe, defekte Oberleitungen bringen Züge zum Stillstand, Waggons mit ausgefallenen Klimaanlagen müssen ausgetauscht werden, defekte Schranken dürfen nur im Schrittempo passiert werden - solange das alles nicht in den Griff bekommen wird kann auch der beste Prozess nicht helfen.

Die Parallelen zu IT-Projekten und -Abteilungen sind offensichtlich. Häufig wird die Einführung von Scrum oder Kanban mit grossen Hoffnungen verbunden, die dann an der veralteten Technik und Systemlandschaft scheitern. Computer haben zuwenig Diskspace, Test- und Entwicklungsumgebungen müssen manuell eingerichtet werden, Telefonkabel aus den 70er Jahren verlangsamen die Datenübertragung, etc. etc.

Wie beim Beispiel der Bahn heisst das nicht, dass Prozessverbesserungen nichts bringen. Starre Planungen und Bürokratie zu beseitigen ist immer eine Verbesserung. Ohne die begleitenden Modernisierungen von Software und Hardware wird ihre Wirksamkeit aber deutlich eingeschränkt bleiben. Erst durch eine Kombination dieser Faktoren kann es zum befreienden grossen Sprung nach vorne kommen.

Diese Themen anzusprechen kann in vielen Unternehmen zum Offenbarungseid führen: Agilität sei als Ansatz gewählt worden weil davon ausgegangen wurde, dass die Umstellung von Meetings und Rollen mit geringem Aufwand möglich ist, für darüber hinausgehende Modernisierung wäre aber kein Geld da. Das würde doch auch bestimmt ohne gehen, oder? Derartige Aussagen sind häufiger als man denken sollte.

Die Antwort darauf kann nur eine sein: Das kann man zwar so machen, aber dann sollte man seine Erwartungshaltungen deutlich herunterfahren.

Samstag, 3. November 2018

Wie technikfern darf ein Scrum Master oder Agile Coach sein? (II)

Bild: Pexels / Tim Gouw - Lizenz
Die agile Welt ist ein Dorf. Sobald man einige Scrum- oder Kanban-Projekte ausserhalb der IT gemacht hat wird man schnell zum gefragten Ansprechpartner zu diesem Thema. Der Grundtenor klingt dabei immer ähnlich: "Ich interessiere mich ja sehr für Agilität, Scrum Master oder Agile Coach wäre was für mich. IT ist aber nicht so mein Ding. Wie finde denn ich Jobs in anderen Bereichen?" Nun ja.

Es ist nicht so als würde es diese Jobs nicht geben (zwar nicht viele, aber es gibt sie). Ich habe bereits Teams coachen dürfen die mit Scrum oder Kanban im Vertrieb, in der Hardwarefertigung, im Kundenservice und im Change Management gearbeitet haben, dazu kommen immer mehr Beispiele aus anderen Bereichen, zum Beispiel gibt es in meiner Heimatstadt Bonn sogar Scrum im Schulunterricht.

Das letzte dieser Beispiele zeigt aber auch direkt das erste Problem auf: selbst wenn manche Anwendungsgebiete IT-fern sind, einfach zugänglich sind sie aber trotzdem nicht unbedingt. Es darf eben nicht jeder an einer Schule unterrichten, dafür muss man vorher an einer Universität gewesen sein und Lehramt studiert haben. Auch in anderen Fällen stösst man schnell an Grenzen formaler Art, die nicht einfach zu überwinden sind.

Nun engt sich damit die Zahl in Frage kommender Jobs zwar weiter ein, aber es gibt sie, oder? Die Antwort: ja, aber. Sie existieren natürlich, in sehr vielen Fällen allerdings nur temporär. Agilität in Service- oder Hardware-Bereichen findet häufig da statt, wo Innovationsarbeit geleistet wird. Für Experimente, Prototypen und MVPs lohnt sich agiles Arbeiten, sobald die Serienfertigung oder -durchführung beginnt eher nicht mehr.

Scrum Master- oder Agile Coach-Stellen sind in solchen Kontexten nur zeitweise nötig. Derartige nicht-IT-Projekte leihen sich eine solche Person daher in der Regel vorübergehend aus, und zwar von da wo es sie bereits gibt - eben aus der IT. Die Alternative, das Vorhalten eines permanenten Scrum Master- oder Coach-Pools, würde eine Nachfrage voraussetzen die es in den meisten Firmen nicht gibt.

Ist die Suche nach einer Position ausserhalb der IT also völlig hoffnungslos? Das zwar nicht, realistisch betrachtet ist die Wahrscheinlichkeit einen zu finden aber sehr gering, zumindest wenn es eine langfristige Beschäftigung sein soll. Was am ehesten sein kann ist, dass sich eine temporäre Stelle finden lässt, die man mit etwas Glück besetzen kann. Es fragt sich nur - was passiert wenn dieses Projekt vorbei ist?

Die eine Möglichkeit wäre das Entlanghangeln von einer temporären Stelle zur nächsten. Nicht unmöglich aber sehr schwierig - so viele derartige Jobs gibt es auch nicht. Die andere Möglichkeit wäre, eine Beschäftigung im agilen nicht-IT-Bereich als Vorstufe für einen Einstieg in die IT zu benutzen. Aufgrund des Fachkräftemangels ist das nicht einmal unrealistisch, allerdings kommt man dann an der Beschäftigung mit der Technik nicht mehr vorbei. Dieser Umstände sollte man sich bewusst sein.