Donnerstag, 16. Mai 2024

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.

Montag, 13. Mai 2024

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.

Donnerstag, 9. Mai 2024

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.

Montag, 6. Mai 2024

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


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,2 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.3


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.



1Das Playbook ist übrigens nicht mehr ganz aktuell, Google hat seinen OKR-Ansatz seitdem weiterentwickelt
2Daher auch der Name des Buchs
3Mö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.

Freitag, 3. Mai 2024

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.

Dienstag, 30. April 2024

Kommentierte Links (CXIII)

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.

Jeff Gothelf: Why is it so hard to admit there’s uncertainty in our work?

Meine Theorie ist, dass ein grosser Teil der oft fehlenden Akzeptanz agilen Arbeitens darin begründet ist, dass die Menschen es sich nicht eingestehen wollen, in einer nur eingeschränkt planbaren Arbeitsumgebung tätig zu sein. Jeff Gothelf geht an dieser Stelle tiefer ins Detail und versucht zu ergründen, warum das schwerfallen kann. Verkürz gesagt: weil (das Eingeständnis von) Ungewissheit unangenehm ist und weil man einmal geäusserte Annahmen und Zusagen ungerne zurücknimmt. Warum man einen guten Grund hat, diese inneren Widerstände zu überwinden, begründet er gleich mit - wer von Anfang an von Ungewissheit ausgeht, wird sein Vorhaben resilienter organisieren, wodurch es nicht so schnell aus der Bahn geworfen werden kann.

Charles Lambdin: What Does 'Iterate' Mean?

Es ist ein Vergehen, dessen sich jeder berufliche Spezialist früher oder später schuldig macht - man benutzt bestimmte Fachbegriffe irgendwann ganz automatisch, ohne darüber nachzudenken wie sie eigentlich ursprünglich gemeint waren. Einer dieser Begriffe, der im Rahmen von agilem Arbeiten immer wieder genutzt wird, ist das Iterieren. Charles Lambdin hat sich die Mühe gemacht und ist dem Ursprung dieses Wortes nachgegangen, mit der überraschenden Erkenntnis, dass er bereits von den Verfassern des Manifests für agile Softwareentwicklung uneinheitlich benutzt worden ist. Vielleicht ist das auch einer der Gründe dafür, dass sich der alternative Begriff des Sprints durchgesetzt hat.

Michael Mankins, Patrick Litre: Transformations That Work

Ein Longread, aber einer, der die investierte Zeit lohnt. Michael Mankins und Patrick Litre haben zu dem Thema der Unternehmenstransformationen (agil, digital, etc) geforscht und kommen zu erstaunlichen Zahlen: die Hälfte der von ihnen befragten Unternehmen hat in den letzten fünf Jahren mehrere derartige Veränderungsprogramme durchlaufen, von denen führten aber nur zwölf Prozent wirkliche Veränderungen herbei. Interessant ist, was diese kleine Erfolgsgruppe gemeinsam hat - die Transformationsvorhaben waren keine zeitlich begrenzten Projekte sondern wurden langfristig und als Teil der täglichen Arbeit beschlossen und umgesetzt, sie waren nicht mit Sparprogrammen verbunden, die Organisation wurde nicht durch zu viele gleichzeitige Veränderungen gestresst, und es wurden ambitionierte Ziele gesetzt, den unteren Ebenen aber Freiheiten in der Ausgestaltung gelassen.

Maarten Dalmijn: Why OKRs Often Slowly Wither Away

Was Maarten Dalmijn hier über OKRs schreibt, trifft auch auf jede andere Form von agilem Arbeiten zu: damit es funktionieren kann sind bestimmte Rahmenbedingungen nötig. Sind diese noch nicht vorhanden, wird die neue Vorgehensweise nicht die gewünschten Ergebnisse bringen, sondern nach und nach wieder absterben. In diesem Problem liegt aber auch bereits die Lösung: wenn man die notwendigen Vorbedingungen einmal verstanden hat, kann man sich fragen, was man tun kann um sie herbeizuführen. Daran zu arbeiten sorgt dann oft für mehr Agilität als die Einführung von OKRs (oder Scrum, oder sonstwas) selbst.

Biplab Subedi: 5 Product Discovery Pitfalls Leading to Scrum Failures

Als letztes mal wieder eine kleine Liste. Biplab Subedi hat fünf häufige Product Discovery-Fehler zusammengetragen, wegen denen eine Scrum-Einführung schiefgehen kann. Hier sind sie:
1. Inadequate Time for the Problem Space
2. Discovery Solely for Estimation
3. Discovery Without Past Evidence
4. Discovery for a Quarter or More
5. Separation of Responsibilities in Discovery and Delivery
Mehr Detailsgibt es drüben bei ihm. Ich würde nur noch ergänzen, dass er sich Fälle bezieht, in denen Product Discovery tatsächlich nötig ist. Es gibt auch Fälle, in denen das nicht so ist.

Donnerstag, 25. April 2024

Agile Success Stories: das Warnsignal

Bild: Pexels / Andrea Piacquadio - Lizenz

Leider ist es so, dass viele "agile Methodiker" (Agile Coaches, Scrum Master, etc.) mit der Zeit eine eher negative Weltsicht entwickeln. Das ist auch menschlich verständlich, wer sich ständig mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue und Konzern-Trolle beschäftigen muss, kann leicht in Frustration abrutschen. Um nicht selbst in dieses Muster verfallen, möchte ich dagegenhalten, indem ich ab und zu selbst erlebte "agile Erfolgsgeschichten" veröffentliche.


Die heutige kleine Geschichte habe ich in einem grossen Industriekonzern erlebt, der in mehreren Grossprojekten seine Anlagensteuerung und -überwachung digitalisierte und modernisierte. Diese Projekte waren zu Beginn alle nach Wasserfall durchgeführt worden, das in dem ich zeitweise war, war eines der ersten in denen agil gearbeitet wurde - unter misstrauischer Beobachtung übrigens, da es das verbreitete Vorurteil gab, dieser Arbeitsmodus wäre unzuverlässig und unsicher.


Wie man sich denken kann hakte es an einigen Stellen, unter anderem waren viele Stakeholder lange nicht bereit an den Sprint Reviews teilzunehmen, solange noch nicht alle Anforderungen vollständig umgesetzt waren.1 Erst eine Management-Intervention konnte das ändern, und so liessen sich ein Vierteljahr vor dem Go Live eines neuen Überwachungssystems endlich einige der zukünftigen Anwender vom Entwicklungsteam den bisher fertiggestellen Umfang vorführen.


Einer dieser zukünftigen Anwender war deren Teamleiter, ein Ingenieur namens Xin Mi.2 Mit strengem Blick verfolgte er die Vorführung, stellte mehrfach Nachfragen und machte sich jedesmal kopfschüttelnd Notizen, wenn er über ein Feature hörte, dass es erst in einem der kommenden Sprints umgesetzt werden würde. Irgendwann wurde er dann plötzlich hektisch und aufgeregt. Laut auf deutsch, englisch und chinesisch schimpfend stürmte er aus dem Raum, immer wieder "das geht so nicht" rufend.


Sein Problem: die Überwachungs-Ergebnisse des neuen Systems wurden in Echtzeit auf einem Bildschirm angezeigt. Was niemand dem Entwicklungsteam gesagt hatte war aber, dass der nur einer von über 20 auf einer ganzen Bildschirm-Wand sein würde. Was Xin Mi zurecht anmerkte - der davor sitzende so genannte Operator könnte eine auf nur diesem einem Bildschirm angezeigte Störungsmeldung leicht übersehen, und auch der Warnton war so leise, dass er in einem solchen Raum überhört werden könnte.


Etwas irritiert von dem Ausmass des Dramas überlegte das Team sich im folgenden Planning eine Lösung: der Warnton wurde lauter und durchdringender und um den Bildschirm wurde bei Störungen ein rot blinkender Rahmen angezeigt, um den Blick dorthin zu lenken. Die Umsetzung passte auch irgendwie noch in den nächsten Sprint hinein. Der immer noch aufgebrachte Xin Mi war zwar nicht bereit, während des Sprints darüber zu reden, zum nächsten Sprint Review kündigte er sich aber an.


Diesesmal tauchte er in Begleitung mehrerer Manager auf und verhielt sich wieder überraschend. Direkt zu Beginn verlangte er die Agenda umzustellen und mit der Störungsmeldung zu beginnen. Leicht irritiert gab das Entwicklungsteam diesem Wunsch nach und führte die Ergänzungen des letzten Sprints vor. Xin Mi, der gerade angesetzt hatte, den mitgebrachten Managern zu erklären, wie schlimm alles wäre, war völlig perplex. Dass sein Problem plötzlich gelöst war, war für ihn unbegreiflich.


Sein verdattertes Schweigen wurde von den Entwicklern falsch interpretiert und für Unzufriedenheit gehalten, also machten sie ein weiteres Angebot: Wenn Warnton oder Signalfarbe nicht passen würden könnte man auch das im nächsten Sprint noch ändern, jetzt, da die Funktionen da wären, wäre das kein Problem mehr. Für Xin Mi war das zu viel. Mit Tränen in den Augen stand er auf, bedankte sich überschwänglich und entschuldigte sich für sein bisher ablehnendes Verhalten.


Zum Hintergrund: in den bisherigen Wasserfallprojekten waren auch kleinste Änderungen der Anforderungen nur mit erheblichen bürokratischen Aufwänden machbar gewesen. Da neue Funktionen in den alten Anwendungen nur zweimal pro Jahr released wurden, waren diese Releases aufwändig und fehleranfällig, was dazu geführt hatte, dass zusätzliche Änderungen möglichst abzulehnen waren. Für jemanden der aus einer solchen Welt kommt, sind Auslieferungen alle zwei Wochen unvorstellbar.


Obwohl (oder vielleicht gerade weil) die hier beschriebene Anpassung nicht besonders gross war, war ihre schnelle und unkomplizierte Umsetzung für Xin Mi ein Erweckungserlebnis. Er wurde zum begeisterten Teilnehmer der Sprint Reviews und zum grössten Fürsprecher des agilen Arbeitens in seiner Abteilung und zog sogar zeitweise in das Büro des Entwicklungsteams, um so einen noch engeren und intensiveren Austausch haben zu können. Ein Stakeholder wie man ihn sich wünscht.


Geschichten wie seine (von denen ich einige erlebt habe) kann man sich immer wieder vor Augen führen, wenn andere Dinge nicht funktionieren wie gehofft. Sie sind nicht so imposant wie ein grosses Kulturwandel- oder Skalierungsprogramm, in Summe aber für die Akzeptanz und den Erfolg agiler Produktentwicklung viel, viel wichtiger. Und dieser eine Moment, in dem aus Wut Unglaube und aus Unglaube Begeisterung und Dankbarkeit wurde, ist einer, der im Gedächtnis hängen bleibt.



1Was natürlich den Zweck dieses Termins konterkarierte
2In Wirklichkeit hiess er anders, Xin Mi ist für diese kleine Geschichte sein Pseudonym

Montag, 22. April 2024

Aufklärung

Bild: Wikimedia Commons / Emil Doerstling - Public Domain

Man soll ja die Feste feiern wie sie fallen, daher an dieser Stelle herzliche Glückwünsche an Immanuel Kant zum 300. Geburtstag. Wie jeder andere Europäer und Amerikaner sind wir bewusst oder unbewusst von seinem Wirken geprägt, z.B. in unserer Arbeit in der agilen Produktentwicklung durch seine Erkenntnistheorie. Um den Rahmen nicht zu sprengen möchte ich mich aber heute auf etwas Kleineres beschränken: mein Kant-Lieblingszitat, gefunden in seinem Artikel Was ist Aufklärung?:


Wenn denn nun gefragt wird: leben wir jetzt in einem aufgeklärten Zeitalter? so ist die Antwort: Nein, aber wohl in einem Zeitalterder Aufklärung.
Immanuel Kant: Was ist Aufklärung?, S.9


Was Kant damit meint ist, dass die Benennung der Zeit, in der er lebte, als Aufklärung keineswegs bedeutete, dass objektives, rationales Denken sich allgemein durchgesetzt hatte und Unwissen und Falschannahmen der Vergangenheit angehörten. Stattdessen war es für ihn lediglich so, dass den Menschen die Möglichkeit eröffnet wurde, sich Objektivität und Rationalität zu erarbeiten. Dieser dauerhafte Erarbeitungs-Prozess war für ihn Aufklärung.


Wer möchte kann hierin Parallelen zu der Arbeit der heutigen (agilen) Unternehmensberater, Agile Coaches und Scrum Master erkennen. Auch am Anfang unserer Arbeit steht in der Regel ein Unwissen über Systeme, Befindlichkeiten und Dynamiken, auch wir versuchen durch Datengetriebenheit und Empirie Licht in dieses Dunkel zu bringen,1 und auch uns ist (hoffentlich) bewusst, dass diese Aufgabe kaum durch uns final abschliessbar ist.


Diese Erkenntnis kollidiert natürlich immer wieder mit dem verständlichen Wunsch unserer beruflichen Umgebung, irgendwann mit den Veränderungen fertig zu sein, um "wieder in Ruhe arbeiten zu können". Zu vermitteln, dass das praktisch nicht möglich ist, und dass die Entdeckung und Untersuchung immer neuer Probleme und die Validierung immer neuer Lösungen von Dauer sein müssen, ist einer der anspruchsvollsten Teile unseres Berufs.


Ob die Berufung auf Kant bei der Vermittlung dieser Erkenntnis von Nutzen ist, sei dahingestellt, je nach Kontext wird die Antwort eine andere sein. Für jeden, der sich mit Geistes- oder Philosophiegeschichte beschäftigt hat, mag es aber ein schöner Gedanke sein, dass wir in gewisser Weise das weiterführen, was Kant und seine Zeitgenossen begonnen haben. Und dass seine Gedanken in uns weiterleben ist sicher auch ein passendes Geburtstagsgeschenk für ihn.



1Licht in das Dunkel bringen ist auch die ursprüngliche Bedeutung des Wortes "Aufklärung"