Kommentierte Links (CXIV)

Grafik: Pixabay / Geralt - Lizenz

Das Internet ist voll von Menschen, die interessante, tiefgründige oder aus anderen Gründen lesenswerte Artikel schreiben. Viele dieser Texte landen bei mir, wo sie als „Food for Thought“ dazu beitragen, dass auch mir die Themen nicht ausgehen. Wie am Ende jedes Monats gibt es auch diesesmal wieder eine kommentierte Übersicht über die erwähnenswertesten.

Christiaan Verwijs: Why Science Is Essential To Professionalize Our Community

Es ist einer der grossen Schwachpunkte der agilen Community: es gibt sehr viele starke Meinungen über das für und wieder der verschiedenen Frameworks und Praktiken, nur in den seltensten Fällen sind sie aber durch belastbare und reproduzierbare Empirie validiert. Christiaan Verwijs erklärt warum das problematisch ist, zeigt auf welche Möglichkeiten es gibt, die eigenen Ansichten mit Fakten zu untermauern und weist auf ein grundlegendes Problem hin: anders als in anderen Berufen gibt es bei Product Ownern, Scrum Mastern, Agile Coaches keine nichtkomerziellen Organisationen, die für die Einführung und Beibahaltung derartiger Arbeitsweisen sorgen könnten.

Benjamin Huser-Berta: Limit Work in Progress without Work In Progress Limits (Teil I, Teil II)

Kanban ist vermutlich das am häufigsten missverstandene agile Framework (die Debatte ob es agil oder lean ist sparen wir uns an dieser Stelle). Die meisten Menschen verwechseln es mit dem blossen Kanban-Board, und selbst die, die verstehen, dass mehr dahinter steckt, kennen darüber hinaus häufig nur die Praktik der Limitierung paralleler Arbeit. Benjamin Huser-Berta zeigt eine weitere auf, die Messung und Regulierung des Total Work Item Age (TWIA), also des durchschnittlichen Alters der im System befindlichen Arbeitspakete. Beim Durchlesen dürfte auch klar werden, warum TWIA eher unbekannt ist - damit zu arbeiten erfordert Aufwand und Disziplin.

Hauke Friederichs: Mit billiger Hightech gegen die Russen

Die Verteidigung der Ukraine gegen den russischen Angriffskrieg hat an vielen Stellen den verdrängten Fakt wieder erkennbar gemacht, dass das agile Arbeiten Wurzeln und Parallelen in der Kriegsführung hat (siehe hier, hier und hier). Hauke Friedrichs hebt am Beispiel von für die Ukraine arbeitenden deutschen Rüstungsfirmen eine weitere hervor: bei der Entwicklung von neuen Waffen- und Abwehrsystemen sind einfache, flexible Praktiken dringend nötig, wenn sie zeitnah zum Einsatz kommen sollen. Schnelle, unbürokratische Entwicklung, enger Austausch mit den Anwendern, modularer Aufbau und kontinuierliche Weiterentwicklung. Die Parallelen zur agilen Produktentwicklung sind unübersehbar.

Michael Küsters: The Scrum Master as a Trash Collector

Ein interessanter Ansatz zum Reframing der Rolle des Scrum Masters. Statt seine Rolle durch die Einführung dessen zu definieren, was Scrum einer Organisation zusätzlich hinzufügt (Rollen, Regeln, Praktiken, Meetings, etc) stellt Michael Küster bei seiner Betrachtung in den Mittelpunkt, was der Scrum Master abschaffen sollte: Bürokratie, Redundanzen, Ineffizienz, Stress und weitere verbreitete Zeit- und Geldfresser. Mein erster Gedanke - würde sich diese Sichtweise im Management verbreiten, würde das automatisch zu einer ganz anderen Legitimation vieler Massnahmen führen.

Maarten Dalmijn: Scrum's Built-in 'Get Out of Jail Free Card' Against Criticism

Was Maarten Dalmijn hier macht, ist die Enttarnung vieler Verteidungen von schlecht funktionierendem Scrum als No true Scotsman-Fehlschlüsse. Sie alle drehen sich darum, dass angeblich nicht die Methode selbst im jeweiligen Zusammenhang unpassend war, sondern dass sie lediglich falsch oder halbherzig umgesetzt wurde. Hätte man es "richtig" gemacht, wäre alles ganz anders gekommen. Das ist natürlich bequem, geht aber an der Realität vorbei. Scrum ist nicht überall die ideale Lösung, manchmal gibt es andere Ansätze die besser passen.

Nein, das ist nicht die Unternehmenskultur

Unter Unternehmensberatern gibt es einen alten Witz: wenn man etwas über die Kultur eines Unternehmens wissen will, dann sollte man sich zuerst ihre offizielle Beschreibung zeigen lassen - denn dann weiss man zumindest wie sie nicht ist. Das ist sicher zynisch, das ist aber auch in den meisten Fällen wahr, denn die offiziellen Unternehmenskulturen stimmen nur selten mit denen, die tatsächlichen im Alltag gelebt werden, überein.

Bevor wir auf die Gründe dafür eingehen, ein kurzer Hinweis: es ist in diesem Zusammenhang egal auf welchem Weg die offizielle Unternehmenskultur entstanden ist, wie sinnvoll oder menschenfreundlich sie erscheint, wie sehr sich die Belegschaft mit ihr identifiziert oder wie stark und häufig sie betont oder verlangt wird. Es gibt strukturelle Gründe die praktisch immer dafür sorgen, dass offizielle und gelebte Kultur sich unterscheiden. Hier sind sie:

Kultur ist ausdifferenziert und nicht in wenigen Schlagwörtern beschreibbar

Die meisten offiziellen Beschreibungen von Unternehmenskulturen bestehen nur aus wenigen Werten, Prinzipien oder Umgangsregeln. Selbst wenn diese zutreffen sollten, würden sie aber nur einen Teil der jeweiligen Kultur beschreiben, zu der ausserdem noch Glaubenssätze, Verhaltens- und Deutungsmuster, mündliche Überlieferungen (wisst Ihr noch, damals in Projekt Omega ...), sprachliche Besonderheiten, Traditionen und viele weitere Dinge gehören, die insgesamt ganze Bücher füllen würden.

Kultur ist nicht nur positiv

Was praktisch alle offiziellen Kulturbeschreibungen gemeinsam haben ist, dass sie ausschliesslich positive Aspekte beschreiben: Verlässlichkeit, Solidarität, freundlicher Umgang, Leistungsbereitschaft, etc. In der Realität gehören zu praktisch jeder Kultur aber auch negative Aspekte, die häufig sogar mit den positiven zusammenhängen: Sorgfalt führt z.B. oft zu Perfektionismus, Experimentierfreude zu Unvorsichtigkeit, und so weiter. Ohne diese Aspekte sind Kulturbeschreibungen unvollständig.

Kultur ist nicht überall im Unternehmen gleich

Schon in kleinen Unternehmen existieren verschiedene (Teil-)kulturen, die sich zum Teil deutlich unterscheiden: Innendienst und Aussendienst, Entwicklung und Marketing oder Management-Ebene und Umsetzungs-Ebene weichen mitunter so stark voneinender ab, dass von einer gemeinsamen Kultur kaum noch die Rede sein kann. Und in Grossorganisationen kann jedes Ressort oder sogar jede Abteilung eine eigene Kultur haben, die mit der offiziellen nur in Teilen übereinstimmt.

Kultur ist nicht stabil

Mit anderen Worten: selbst wenn die offizielle Unternehmenskultur einmal mit der tatsächlich gelebten übereinstimmen sollte, wäre das nur eine Momentaufnahme. Kommende und gehende Kollegen, steigender Wettbewerbsdruck mit darauf folgenden Verteilungskämpfen um knapper werdende Ressourcen, technische Entwicklungen, gesellschaftliche Trends und vieles mehr tragen ununterbrochen dazu bei, dass Kultur sich verändert - weg von der offiziellen Beschreibung.

Kultur ist subjektiv

Zuletzt: egal was Teil einer offiziellen Unternehmenskultur ist, verschiedene Menschen werden diese Begriffe unterschiedlich verstehen. Gerade die häufig verwandten Schlagworte wie Respekt, Verantwortung, Offenheit, Gemeinsamkeit und Ähnliche sind so generisch, dass sich unterschiedliche Deutungen nicht verhindern lassen. Die Folge ist, dass zwar alle die Kultur mit den gleichen Worten beschreiben, das dahinterliegende Verständnis aber weit auseinandergehen kann.

Es würden sich vermutlich noch weitere Gründe dafür finden lassen, dass die offizielle und die tatsächlich gelebte Unternehmenskultur sich praktisch immer unterscheiden, aber auch aufgrund der hier bereits genannten dürfte klar sein: es ist so. Das macht die offiziellen Kulturbeschreibungen zwar nicht schlecht, es sorgt aber dafür, dass sie (wenn überhaupt) nur Teilaspekte oder Vergangenheitsformen beschreiben, und nicht das was im Alltag anzutreffen ist.

Man muss die schönen Kulturprogramme und -darstellungen auch deshalb nicht abschaffen, man kann sie durchaus beibehalten, wenn auch mit einer wichtigen Ergänzung: allen sollte bewusst sein, dass es sich bei ihnen nicht um eine aktuelle Zustandsbeschreibung handelt, sondern um ein ambitioniertes Zielbild, auf das man zwar hinarbeiten kann, das man aber nicht in Gänze oder dauerhaft erreichen kann. Wenn alle sich auf dieses ständige gemeinsame Hinarbeiten einigen, dann hat eine offizielle Unternehmenskultur einen Sinn. Sonst nicht.

Deine Muda: Overthinking

Bild: Pexels / Thirdman - Lizenz

Zehnter Teil der Deine Muda-Serie. Neben den sieben klassischen Mudas (無駄), also den nicht gewinnbringenden (und aus diesem Grund zu vermeidenden) Tätigkeiten des Toyota Production System, können auch weitere Mudas identifiziert werden. Welche das sind kann je nach Unternehmen und je nach Kontext unterschiedlich sein, weshalb diese hier nicht den Anspruch erheben kann, kanonisch zu sein. Ressourcenverbrauchend und nicht gewinnbringend ist sie trotzdem: das Overthinking.

Zuerst ein Übersetzungsversuch. Für den Begriff Overthinking gibt es keine exkte Entsprechung in der deutschen Sprache, eine sinngemässe Übersetzung wäre "länger über etwas nachdenken als sinnvoll ist" oder "unverhältnismässig lange über etwas grübeln". In beiden Übersetzungs-Varianten ist die Muda-Natur bereits offensichtlich enthalten, bei näherer Betrachtung lassen sich aber ausserdem noch verschiedene Problem-Dimensionen erkennen.

Zum einen kostet ein unnötig langes Nachdenken die Beteiligten (Arbeits-)Zeit und damit ihr Unternehmen auch Geld. Das führt entweder dazu, dass sie nicht mehr für andere Tätigkeiten verfügbar sind (dazu gleich mehr) oder es hat zur Folge, dass zur Kompensation dieser Ausfälle weitere Menschen eingestellt werden müssen. Der zweite Fall wird nochmal schwerwiegender dadurch, dass diese Einstellungen (plus Koordination, Bezahlung etc.) weitere Verwaltungsaufwände erzeugen.

Zum anderen kann es zum Phänomen der Verzögerungskosten (Cost of Delay) kommen. Wird die durch das Overthinking entstehende Mehrarbeit nicht durch zusätzliches Personal kompensiert, schieben sich andere Tätigkeiten zwangsläufig nach hinten, wodurch sich Einnahmen verzögern (und dadurch kleiner ausfallen) können, Geschäfts-Chancen verschwinden können oder zusätzliche Zinsen auf alte oder neue Kredite anfallen können, die zur Kompensation ausfallender Einnahmen nötig werden.

Angesichts dieser Nachteile stellt sich die Frage, warum das Overthinking in vielen (vor allem grossen) Organisationen so weit verbreitet ist. Die Antwort kann natürlich je nach Einzelfall eine andere sein, häufige Gründe sind meiner Erfahrung nach aber Perfektionismus, Machbarkeits- und Steuerbarkeits-Illusionen, Risiko-Aversion (häufig verbunden mit knappen Budgets, deren Verwendung man unter Kontrolle halten will) und fehlende Systemsicht.

Um die nicht gewinnbringende, aber ressourcenverbrauchende Muda des Overthinking in den Griff zu bekommen, ist es daher erfolgsversprechend, zu untersuchen ob eine diese zugrundeliegenden Ursachen gegeben ist, um diese zu thematisieren und möglichst zu beseitigen. Selbst dann wenn das nicht gelingt, kann aber alleine die Erkenntnis der problematischen Effekte ausreichend sein, um ein Zurückfahren der Grübel-Aufwände auf ein sinnvolles Mass zu verursachen.

Agile vs Lean

Eine Frage, die unter Methodikern und Theoretikern gerne und ausgiebig diskutiert wird, die man als Berater aber auch immer wieder beim Kunden gestellt bekommt, ist die nach dem Unterschied zwischen Agil und Lean. Ist das nicht irgendwie ähnlich oder sogar identisch? Dreht sich nicht beides darum, das eigene Vorgehen durch ständige Verbesserung so zu optimieren, dass man effektiver, effizienter und reaktionsfähiger wird?

Bevor ich eine Antwort darauf versuche, ein Disclaimer: weder Agil noch Lean sind abschliessend definiert. Es gibt zwar das Manifest für agile Softwareentwicklung als zentrales Dokument, das aber nur sehr abstrakte Richtlinien vorgibt, und auf der Lean-Seite das ebenfalls nur Richtlininien vorgebene Toyota Production System. Darüber hinaus gibt es auf beiden Seiten nur noch optionale Praktiken und Sekundärliteratur. Aus all dem sind aber Definitionen ableitbar.

Der offensichtlichste Unterschied dürfte der Einsatzbereich sein. Agil wird fast ausschliesslich in der Produktentwicklung gearbeitet,¹ also dort, wo sich die Herausforderungen aus (noch) unklarer Anwender-Akzeptanz, technischer Machbarkeit, etc. ergeben. Lean ist im Gegensatz dazu vor allem in der seriellen Fertigung verbreitet,² die Herausforderungen hier sind Betrieb und Stabilisierung extrem grosser und fehleranfälliger Fertigungsstrassen, Lieferketten, o.ä.

Beiden Arten von Herausforderung wird versucht mit ähnlichen Mitteln beizukommen, die auf der agilen Seite unter dem Schlagwort Inspect & Adapt zusammengefasst werden und auf der Lean-Seite unter den Begriffen Kontinuierliche Verbesserung (KVP) oder Kaizen. Beides dreht sich um ständige Optimierungen. Was aber grundsätzlich unterschiedlich ist, ist das im Mittelpunkt dieser Bemühungen stehende Objekt: im Fall von Agil ist es das Produkt, im Fall von Lean ist es der Prozess.

Im Fall von agilem Arbeiten sieht das konkret so aus, dass in den Inspect & Adapt-Terminen entweder neue oder geplante Funktionen mit Anwender-Vertretern oder Stakeholdern begutachtet werden (z.B. im Sprint Review) oder dass in ihnen überlegt wird, was getan werden kann um diese gemeinsame Begutachtung in kurzen Zyklen zu ermöglichen oder beizubehalten (z.B. in der Retrospektive). Es können natürlich auch andere Aspekte zur Sprache kommen, die sind aber im Vergleich sekundär.

Umgekehrt geht es in den KVP- und Kaizen-Events in erster Linie darum, den Erstellungsprozess eines Produkts (oder Teilprodukts) schneller, ressourcenschonender, weniger störungsanfällig oder vorhersagbarer (in Bezug auf Durchlaufzeiten oder Wartungsintervalle) zu gestalten.³ Auch hier ist es möglich, dass Impulse für die Produktentwicklung entstehen, die werden dann aber nicht selbst realisiert sondern in die vorgelagerten (agil arbeitenden) Produktentwicklungsprozess weitergeleitet.

Wie immer gibt es natürlich auch hier Grauzonen und Uneindeutigkeiten. Wenn es z.B. im Rahmen einer auf die Fertigungsprozesse bezogenen Kostensparmassnahme dazu kommt, dass ein anderer Werkstoff verwendet wird als bisher, dann kann das auch zu einer Veränderung des Produkts führen (das dann z.B. leichter ist). Und einen "historisch gewachsenen" Begriff wie Lean Startup hätte man im Rückblick besser "Agile Startup" genannt, um Missverständnisse zu vermeiden.

Im Grossen und Ganzen ist die Gleichung Agil = kontinuierliche Produkt-Optimierung und Lean = kontinuierliche Prozess-Optimierung aber gut geeignet um zu erkennen mit was man es gerade zu tun hat. Aufbauend darauf kann es dann auch leichter werden, Handlungsfelder, Zuständigkeiten und Handlungsoptionen zu definieren, aufzuteilen oder zusammenzulegen. Auch das sollte übrigens Teil einer kontinuierlichen Optimierung sein.

¹Der Begriff "Produkt" ist hier weit gefasst und enthält neben physischen Produkten auch digitale Produkte, Dienstleistungsprodukte, etc.
²Und in Umfeldern mit stark standardisierten Tätigkeiten, z.B. Systemgastronomie oder Callcenter
³Anders als man denken könnte ist das nichts womit man irgendwann fertig ist, sondern eher einen ständiges Austarieren

Ein Bild sagt mehr als 1000 Worte (XLII)

Bild: Comic Agile - CC BY-NC 4.0

Wer agiles Arbeiten nur mit digitalen Tools kennt, wird angesichts dieses Comics vielleicht etwas ratlos sein. Alle die es mit Post Its an Wänden kennen wissen, dass er witzig ist und dass es wahr ist.

Das agile Mindset (II)

Bild: Pexels / Yan Krukau - Lizenz

Ein Hoch auf die Wissenschaft! Diesesmal in Person von Karen Eilers, die an der Universität Kassel eine Wirtschaftsinformatik-Dissertation mit dem klangvollen Titel The Agile Mindset – Why it Matters, What it is, and How to Measure it verfasst hat. Was sie in diesem Rahmen an Erkenntnissen gewinnen konnte und wie sie diese zusammengetragen hat, hat sie in einem ausführlichen Gespräch in dem Podcast Agile World News erzählt.

An dem hier beschriebenen Ansatz gibt es einiges, das ich bemerkenswert finde, bereits angefangen damit, dass versucht wird dem Begriff "Mindset" seine Unschärfe zu nehmen. Es wird anerkannt, dass er sehr offen interpretiert werden kann und sehr unklar zu anderen Begriffen wie "Einstellung", "Haltung" und "Mentalität" abgegrenzt ist. Die hier gewählte Definition mag vielleicht nicht jeder teilen, aber zumindest gibt es hier eine. Eine sachliche Diskussion wird dadurch überhaupt erst möglich.

Ebenfalls erwähnenswert finde ich, dass das agile Mindset (Vorhandensein, Ausprägungen, etc.) in diesem Ansatz nicht mehr etwas ist, dass von aussen durch Zuschreibung oder "Diagnose" entsteht (was dort wo man es versucht fast zwangsläufig zu übergriffigem Verhalten führt). Stattdessen wird davon ausgegangen, dass es bei allen agil arbeitenden Menschen irgendwie vorhanden ist und nur noch durch Empirie identifiziert werden muss (vereinfacht gesagt: was oft genannt wird gehört dazu).

Die vier Themengebiete, die in der Dissertation am häufigsten identifiziert wurden und die in ihr daher als typisch oder konstituierend für ein agiles Mindset gelten, sind Lern-Orientierung, kollaboratives Arbeiten, Co-Creation mit den Kunden und Selbstorganisation. Das klingt passend zu dem Arbeitsmodus, den man meistens unter der Bezeichnung "agil" vorfindet, ist aber auch darüber hinaus spannend: letztendlich handelt es sich um eine Selbstbeschreibung (und damit Selbstwahrnehmung) der agilen Community.

Lern-Orientierung

Wenig erstaunlich. Lernorientierung ist u.a. das, was man in agilen Teams auch als Growth Mindset bezeichnen würde, also die Anerkennung der Tatsache nicht alles zu wissen, die Bereitschaft sich neues Wissen anzueignen, z.B. in Reviews, Retrospektiven, etc.

Kollaboratives Arbeiten

Ebenfalls erwartbar, da in den meisten agilen Teams Teil der täglichen Arbeit: gemeinsame Meetings, gemeinsame Arbeit an Anforderungen und ähnliche Praktiken beseitigen Kopfmonopole und Flaschenhälse und machen so den Arbeitsfluss schneller und resilienter.

Co-Creation mit den Kunden

Spannend, da hier etwas (aus meiner Sicht richtigerweise) als wesentlich beschrieben wird, was in der Realität oft nur eingeschränkt stattfinden kann. Hier könnte weitergeforscht werden, ob das Wunsch oder Wirklichkeit ist (vor allem in grossen Organisationen werden oft Kunde und Auftraggeber verwechselt).

Selbstorganisation

Ebenfalls ein wichtiges und richtiges Thema, bei dem ein tieferes Erforschen interessant wäre. Obwohl sich tatsächlich praktisch alle agil arbeitenden Teams als selbstorganisiert bezeichnen dürften, sind das Verständnis dieses Begrifft und die Ausgestaltung in der Realität extrem vielfältig.

Über diese ersten Einordnungsversuche hinaus ist für mich noch etwas weiteres auffällig: die vier identifizierten Kernbereiche sind sehr stark auf den Ebenen der Einzelpersonen und der sozialen Beziehungen in Umsetzungsteams angesiedelt. Die Aspekte der technischen Agilität aus DevOps, XP, etc. und der wirtschaftsnahen Business-Agilität kommen nicht vor, was ein Hinweis darauf sein könnte, dass vor allem Scrum Master (o.Ä.) und nur wenige Entwickler und Manager befragt wurden.

Die Arbeit bietet also einiges an Erkenntnissen, aber auch einiges an weiteren Forschungspotentialen und Denkanstössen. Es ist zu hoffen, dass diese Themen in Kassel und anderswo weitergeführt werden, so dass sich die Diskussion um das agile Mindset weg von starken Meinungen und hin zu gesicherten Ergebnissen bewegen kann. Denn auch das ist etwas, was für mich zu einem agilen Mindset gehören sollte: der Drang, empiriebasiert zu arbeiten.

Compliance & Regulatory Standards are NOT Incompatible with Modern Development

Das was Charity Majors in diesem Vortrag als "moderne Softwareentwicklung" bezeichnet, ist das was ich als Agilität bezeichnen würde: kleine Incremente schnell auf Produktion bringen um schnelles Feedback zu bekommen und schnell darauf reagieren zu können. Und genau wie ich scheint sie regelmässig mit der Aussage konfrontiert zu werden, dass das in regulierten Branchen nicht möglich wäre. Um so dankbarer kann man ihr dafür sein, dass sie klarstellt, dass das sehr wohl geht.

Für alle, die keine Geduld haben, sich die ganzen 40 Minuten ihres Videos anzusehen, habe ich eine Empfehlung: ab Minute 14:27 klickt sie sich in einem Schnelldurchlauf von 30 Sekunden durch 13 Folien, auf denen dargestellt wird, wie 13 verschiedene Firmen ihre Entwicklungsprozesse gleichzeitig modern und compliant gehalten haben (es emfiehlt sich, das Video auf jeder Folie kurz zu stoppen). Man sieht daran, dass es geht - man muss es nur wollen und machen.

Die Evolution der OKRs

Sobald ein agiles Framework ein gewisses Alter überschritten hat, entstehen in der Regel nach und nach verschiedene Varianten, die anfangs noch aufeinander aufbauen, später aber parallel zueinander existieren. Das ist bei Scrum und bei Kanban so gewesen, und es ist auch bei Objectives und Key Results (OKR) so. Da die neueren OKR-Varianten sich z.T. zu erstaunlich schwerfälligen Prozessframeworks entwickelt haben, lohnt ein Blick zurück - denn eigentlich ist es ursprünglich anders gedacht gewesen.

Wie immer bei derartigen Übersichten ist auch diese hier subjektiv, sie umfasst aber meiner Meinung nach die wichtigsten Spielarten und Entwicklungsstufen, bzw. die wichtigsten Vordenker. In der Realität dürften darüber hinaus noch zahlreiche Abwandlungen und Mischtypen anzutreffen sein, diese Liste hier dürfte aber die relevanten umfassen (wenn ich etwas übersehen haben sollte, freue ich mich über einen Hinweis, der hier abgegeben werden kann). Aber zur Sache, hier sind die Evolutionsstufen:

MBOSC (Management by Objectives and Self-Control)

Eine Früh- oder Vor-Version der heutigen OKRs, beschrieben in den 50er Jahren von Peter Drucker in seinem Buch The Practice of Management. Mit dezentraler Planung, Trennung von abstrakten Zielen und konkreten Ergebnissen und mit Zyklen von weniger als einem Jahr waren die Grundzüge der heutigen Praktiken bereits enthalten. Unter dem Namen Management by Objectives (MBO) wurde Druckers Ansatz leider später zu einem jährlichen Kontroll- und Budgetierungsinstrument verfremdet (siehe hier).

Ursprüngliche OKRs (Intel MBOs)

Die Ursprungsversion, entwickelt in den 70er Jahren von Intel-CEO Andy Grove und beschrieben in seinem Buch High Output Management. Grove definierte neben den abstrakten Zielen (Objectives), den konkreten Ergebnissen (Key Results) und den kurzen Zyklen (maximal ein Jahr) kaum Vorgaben zur Umsetzung, entwickelte aber schon die Idee "kaskadierender Objectives", die auf den unteren Hierarchie-Ebenen in Teilziele heruntergebrochen werden, und von denen jede eigene Key Results hat.

"Die" OKRs (Google OKRs)

Die Variante, die berühmt geworden ist. Der ehemalige Intel-Mitarbeiter John Doerr führte die OKRs bei Google ein, wo sie um weitere Teile ergänzt wurden, u.a. um die Begrenzung des Zyklus auf ein Quartal, um die Differenzierung in "committed" und "aspirational OKRs", die Einführung gemeinsamer OKRs für mehrere Teams und um eine nachträgliche Bewertung in Ampelfarben. Das von vielen anderen Firmen kopierte Google OKR Playbook findet sich abgedruckt in Doerrs Buch Measure What Matters.¹

Silicon Valley OKRs

Die verschiedenen Unternehmen des Silicon Valley, die als erste den OKR-Ansatz von Google übernommenen haben, haben ihn mit der Zeit ebenfalls weiterentwickelt. Die bekanntesten Praktiken findet man zusammengefasst in Cristina Wodkes Buch Radical Focus, zu ihnen gehört u.a. die Beschränkung auf nur ein einziges, nach Möglichkeit firmenweites Objective pro Zyklus,² die dezentrale Erarbeitung der Key Results durch die Teams und die Einführung regelmässiger OKR-Meetings.

Scrumifizierte OKRs

Wer auf die Idee gekommen ist, die OKR-Meetings analog zu denen aus Scrum zu organisieren, lässt sich vermutlich nicht mehr feststellen, aber er hat einen Trend gesetzt. OKR-Plannings, OKR-Dailies/Weeklies, OKR-Reviews und OKR-Retrospektiven sind mittlerweile weit verbreitet, und für die Organisation und Moderation dieser Termine gibt es einen an den Scrum Master oder Agile Coach angelehnten OKR Master oder OKR Coach.³

Agile Industrial Complex OKRs

Dass angessichts dieser Geschichte einer immer stärkeren Formalisierung auch das Kommerzialisierungs-Potential gestiegen ist, dürfte wenig überraschen. Der agil-industrielle Komplex hat seit ca 2020 auch die OKR-Idee mit weiteren Regeln, Rollen, Formulierungs-Templates, prozessunterstützender Software und Ähnlichem überflutet, die dann in den Trainings und Zertifizierungsprüfungen auftauchen können. Genau wie im Fall von Scrum und Kanban übrigens mit teuren aber meistens überschaubaren Ergebnissen.

Gerade vor dem Hintergrund dieser letzten "Evolutionsstufe" ist es nicht verwunderlich, dass OKRs vor allem in grossen Organisationen eher als Management-Mode wahrgenommen werden und weniger als etwas Sinnvolles. In derartigen Fällen können die hier verlinkten Grundlagen-Bücher gegebenenfalls Klarheit bringen. Aus ihnen lässt sich erkennen, was der eigentliche Kern der Idee ist, und bei was es sich um Overhead handelt, der auch weggelassen werden kann.

¹Das Playbook ist übrigens nicht mehr ganz aktuell, Google hat seinen OKR-Ansatz seitdem weiterentwickelt
²Daher auch der Name des Buchs
³Möglicherweise ist der Hintergrund der, dass Scrum ursprünglich keinen mittelfristigen Planungshorizont hatte, und Scrum Teams sich diese mit Hilfe von OKRs gesetzt haben. Das wäre dann seit dem 2020 in Scrum aufgenommenen Produktziel eigentlich obsolet.

Larman's Law (III)

Bild: Pixabay / kirill_makes_pics - Lizenz

Mit der Zeit haben sich viele Menschen Gedanken über die ungeschriebenen Gesetze der Organisationsentwicklung gemacht und versucht sie (auf manchmal seriöse, manchmal aber auch eher zynische Art) auf Papier zu bringen. Besonders produktiv war dabei Craig Larman, der Erfinder von LeSS, der insgesamt fünf Gesetze verfasst hat, die er Larman's Laws of Organizational Behavior genannt hat. Heute soll es hier um das Dritte von ihnen gehen. Es lautet:

[...] any change initiative will be derided as “purist”, “theoretical”, “revolutionary”, "religion", and “needing pragmatic customization for local concerns” - which deflects from addressing weaknesses and manager/specialist status quo.

Diese Gesetzmässigkeit, die als Ergänzung zu Larmanns erstem Gesetz gedacht ist (demzufolge Organisationen unbewusst darauf optimiert sind, Management- und Spezialistenpositionen zu schützen), ist tatsächlich eine, die in vielen, vor allem grossen, Firmen zu beobachten ist. Im Hinblick auf Veränderungsvorhaben jeglicher Art ist sie problematisch, wie im Fall des ersten Gesetzes findet man bei näherer Betrachtung aber auch nachvollziehbare Aspekte.

Ein Grossteil aller Veränderungsvorhaben krankt daran, dass versucht wird, Dinge die in einem völlig anderen Kontext entwickelt wurden, Eins zu Eins auf die eigene Organisation zu übertragen. Im schlimmsten Fall kann das zu Stilblüten führen wie der, dass ein italienischer Konzern versucht, das Organisationsmodell eines schwedischen Startups unverändert auf sich zu übertragen. In solchen Fällen wäre weniger Dogmatismus und mehr Anpassung gut.

Problematisch wird dieses an sich sinnvolle Vorgehen aber, wenn der andere Kontext und die dadurch nötigen Anpassungen instrumentalisiert werden, um die geplanten Neuerungen so weit wie möglich zu unterlaufen, und zwar auch dann wenn sie umsetzbar und sinnvoll wären. Aussagen wie "Wir können nicht 'Agile by the Book' machen, wir sind in einer gesetzlich regulierten Branche" sind Klassiker unter den als Realismus getarnten Ausreden, die in solchen Situationen immer wieder vorgebracht werden.

Das was den Umgang mit derartigen Unterlaufungsversuchen schwierig macht, ist ihre scheinbare Rationalität. Nicht nur erscheinen sie auf den ersten, flüchtigen Blick vernünftig, ihre scheinbare Praxisnähe ermöglicht es demjenigen der sie vorbringt im Umkehrschluss, die von ihm abgelehnten Ansätze als realitätsfern, ideologisch oder ähnliches zu diskreditieren. Genau diese Verhaltensweisen werden in Larmanns zweitem Gesetz beschrieben.

Der beste Umgang mit derartigen Situationen ist es, sich gar nicht erst auf die Diskussion einzulassen, ob ein neuer Ansatz dogmatisch ist oder nicht. Zielführender und erfolgsversprechender ist es, in Erinnerung zu rufen, welche aktuellen Missstände durch ihn beseitigt werden sollen, und dass eine Debatte über angeblichen Dogmatismus nur dazu führen würde, dieses Problem, bzw. dessen Lösung aus den Augen zu verlieren. So wird eine Rückkehr zur Sachlichkeit ermöglicht.