Montag, 28. November 2022

Chesterton's Fence

Bild: Rawpixel - CC0 1.0

Beim Navigieren und Unbestimmtheit und Komplexität ist es immer hilfreich, ein Set an hilfreichen Verhaltens- und Erkenntnis-Grundsätzen parat zu haben. Als Schutz vor Affekthandlungen und verzerrten Wahrnehmungen können sie dazu beitragen weniger voreilige und wenig durchdachte Entscheidungen zu treffen. Einer dieser Grundsätze ist Chesterton's Fence, benannt nach dem britischen Schriftsteller und Philosophen Gilbert Keith Chesterton.


Chesterton (dem man eine Vorliebe nachsagte, seine Erkenntnisse in Form von Sprichwörtern und Allegorien festzuhalten) wollte mit seinem Zaun-Vergleich seine Leser davor bewahren, bei Reform- oder Erneuerungsvorhaben vorschnell die bisher vorhandenen Regeln und Prozesse abzuschaffen, ohne darüber nachzudenken aus welchem (möglicherweise noch immer relevanten) Grund sie ursprünglich eingeführt wurden. Er lautet stammt aus seinem Buch The Thing und lautet folgendermassen:


In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, 'I don't see the use of this; let us clear it away.' To which the more intelligent type of reformer will do well to answer: 'If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.


Was beim Lesen dieser Passage aus Chestertons Buch auffällt ist, dass er sich dem Phänomen der voreiligen Veränderung in zwei Dimensionen annähert. Zum einen der des zu reformierenden Sachverhalts. Wer die Gründe für die Einführung der vorhandenen Regeln und Prozesse nicht kennt nimmt nur einen Teil des Systems wahr das er verändern will, mit der Folge, dass die Veränderung unabsehbare Wechselwirkungen auslösen können, ggf. mit negativen Folgen.


Wichtiger ist aber die andere Dimension, die des Menschen der die Veränderungen anstösst. Die in solchen Momenten häufige Aussage "darin sehe ich keinen Sinn" zeigt für Chesterton eben nicht auf, dass dort keiner ist, sondern dass demjenigen der sie ausspricht ein Erkenntnis-Kurzschluss unterläuft: er geht davon aus, dass etwas das er selbst nicht wahrnimmt nicht existieren kann. Er unterliegt damit einem individualistischen Fehlschluss und baut seine weiteren Handlungen auf diesem auf.


Chesterton's Fence ist damit ein Aufruf zu mehr Selbstreflexion. Bevor man sich an die Reformierung eines komplexen Systems begibt sollte man sich immer fragen, ob die Wahrnehmung von dessen Ist-Zustand wirklich der Realität entspricht oder eher von eigenen Annahmen und gedanklichen Abkürzungen geprägt ist. Tut man das nicht besteht nicht nur das Risiko, dass ungewollte Ergebnisse eintreten, man wird auch von denen überrascht werden und ihre Entstehung nicht verstehen.

Donnerstag, 24. November 2022

Agile bureaucracy (and Hope)

Ich hätte schon früher eine Karriere als Vortragsredner anstreben sollen, die Ideen hätte ich gehabt. Vor über sechs Jahren habe ich über organisatorische Schulden geschrieben, und jetzt sind sie ein Ausgangspunkt auf den Jurriaan Kamer seinen hörenswerten Vortrag aufbaut. Zum Ansehen empfohlen.



Was man ihm hoch anrechnen muss ist, dass er es nicht beim Anprangern von Missständen belässt. Er versucht auch herauszuarbeiten was man besser machen kann, und das an konkreten Beispielen aus Firmen die ihre Arbeitsweisen bereits umgestellt haben.

Montag, 21. November 2022

Die häufigsten Fehler bei einer Kanban-Einführung (II)

Bild: Wikimedia Commons / Anick Marie - CC BY-SA 2.0

Dass es bei der Einführung von Kanban gibt es so einiges gibt, auf das man achten muss, dürfte hoffentlich klar sein, sowohl in Bezug darauf woran man auf jeden Fall denken sollte, als auch in Bezug auf das was man besser lassen sollte. In der letzten Kategorie findet sich aber auch etwas das viele überraschend finden - man sollte am Anfang besser keine Work in Progress-Limits (WIP-Limits) einführen. Wenn überhaupt ist das ein späterer Schritt, zu Beginn macht er fast nie Sinn.


Auf den Einen oder Anderen mag das verwirrend wirken. Sind WIP-Limits nicht ein zentraler Teil von Kanban? Und funktioniert die Einführung von Kanban nicht so, dass man alle Arbeit auf einem Board visualisiert und dann begrenzt wie viel davon gleichzeitig durchgeführt wird, damit das was begonnen wird dadurch schneller fertig werden kann? Die Antwort: ja und nein. Ja WIP-Limits sind zentral, und nein, man sollte sie nicht so früh einführen, selbst wenn das gut gemeint ist.


Am einfachsten zu verstehen ist das in dem Fall, in dem alle bisherigen Arbeitspakete einfach auf ein To Do-In Progress-Done-Board gepackt werden. Dann wird sich dort gleichzeitig Arbeit aus verschiedenen Be- oder Verarbeitungsphasen befinden, mit einem gemeinsames WIP-Limit für alle. Dieses würde aber einzelne Gruppen wie z.B. die UX-Designer in die Untätigkeit zwingen, wenn andere, etwa die Tester, so viel parallele Arbeiten durchführen, dass dadurch die Obergrenze erreicht ist.


Aber auch bei ausdifferenzierteren Systemen, wie z. B. Design-Umsetzung-Test-Rollout können frühe WIP-Limits kontraproduktiv sein. Es kann zwar nicht mehr der zuletzt genannte Fall vorkommen, in dem sich verschiedene Phasen gegenseitig blockieren, in einem System das seine Umstellung auf Kanban gerade erst begonnen hat wird es aber noch Abhängigkeiten nach aussen geben, z.B. zu einer Einheit die Testdaten so langsam bereitstellt, dass ein WIP-Limit auch hier Leerlauf erzwingen würde.


Man kann sich noch weitere vergleichbare Konstellationen vorstellen, die zentrale Erkenntnis ist aber klar: wenn eine Organisationseinheit ihre Rahmenbedingungen nicht selbst unter Kontrolle hat erzwingen Work in Progress-Limits im Zweifel nicht mehr Focus und schnelle Fertigstellung sondern führen zu erzwungener Untätigkeit und zu Konflikten mit anderen Einheiten, auf deren Zulieferung oder Beteiligung man angewiesen ist um die selbstgesetzte (den anderen ggf. gar nicht bekannte) Obergrenze zu halten.


Die bessere Reihenfolge im Rahmen einer Umstellung auf Kanban wäre daher, zuerst die Arbeit zu visualisieren (was schon schwieriger ist als man denken sollte), dann den Beteiligten das Wissen und die Berechtigungen geben um ihre Rahmenbedingungen zu verändern und dann erst über WIP-Limits nachzudenken. Es kann (und sollte) dann natürlich auch zu ihnen kommen, der Punkt an dem das passiert liegt dann aber nicht mehr am Anfang sondern deutlich später.


Um zuletzt ein häufiges Gegenargument gleich abzufangen: ja, man könnte es für eine Übergangszeit zulassen, dass die WIP-Limits regelmässig verletzt werden und währenddessen daran arbeiten, dass das irgendwann nicht mehr nötig ist. Das hätte aber eine (unbewusste) Erziehung zur Normverletzung zur Folge, und das ist etwas wovon man jeder Organisation nur dringend abraten kann, wenn sie nicht in ganz andere Probleme geraten will.

Donnerstag, 17. November 2022

Conway's Law

Bild: Pixabay / Succo - Lizenz

Wenn irgendwo über gute und schlechte Software-Architektur diskutiert wird, wird mit grosser Wahrscheinlichkeit früher oder später das so genannte Conway's Law erwähnt werden, und zwar entweder als Antipattern das man unbedingt vermeiden sollte oder als häufig anzutreffender Wildwuchs, der möglichst schnell zu beseitigen ist. Einigkeit besteht aber immer darüber, dass es etwas Schlechtes ist. Es lautet folgendermassen:


Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

Auf Deutsch: Organisationen die IT-Systeme entwerfen neigen dazu, die System-Designs so zu gestalten, dass sie Kopien ihrer Kommunikationsstrukturen sind.


Dieses "Gesetz" verdanken wir Melvin Conway, einem amerikanischen Software-Entwickler, der die Beobachtung auf der es beruht bereits in den 60er Jahren machte. Popularisiert (und mit seinem heutigen Namen versehen) wurde Conway's Law erst ein Jahrzehnt später von Frederick Brooks in seinem bis heute häufig zitierten Buch The Mythical Man Month. Und gültig und in vielen Organisationen zu beobachten ist es bis heute.


Dass Conway's Law immer wieder auftritt erklärte Conway damit, dass in grossen Organisationen häufig eine nur eingeschränkte Sicht auf Abläufe und Strukturen vorliegt. Eine Abteilung erkennt zwar wer ihr Informationen übergibt (z.B. ein Manager) oder wer sie von ihr entgegennimmt (z.B. eine nachgelagerte Organisationseinheit), wo sie ursprünglich entstehen, wo sie letztendlich enden oder durch welche anderen Stationen sie gehen ist aber nicht nachvollziehbar.


Bedingt dadurch wird bei vielen Digitalisierungs- oder Automatisierungs-Vorhaben immer nur an den Bereichen gearbeitet die bekannt sind, also zwischen der eingehenden und ausgehenden Kommunikationsschnittstelle liegen. Da das nicht nur in einer Abteilung stattfindet, sondern tendenziell jede so vorgeht, entsteht nach und nach für jede der Abteilungen ein entsprechendes IT-System, so dass die Systemlandschaft am Ende dem Organisationsaufbau entspricht.


Dieser Effekt mag auf den ersten Blick unproblematisch erscheinen, er ist es aber nicht. Wenn z.B. zwei Abteilungen unabhängig voneinander eine Übersicht über die Firmenkunden erhalten, sie aufgrund von Conway's Law in verschiedenen Systemen ablegen und sie nur um die jeweils eigenen Informationen zu Verkäufen, Verträgen, Beschwerden, etc. erweitern, dann wird eine firmeweite Sicht auf die Kundenbeziehungen unmöglich.


Auch weitere Probleme sind leicht vorstellbar. Verschiedene Abteilungen können z.B. die selben Daten benötigen, die dadurch von Kunden oder Kollegen redundant in verschiedene Systeme eingegeben werden müssen, sie können unterschiedliche Dateiformate verwenden, die nicht in andere Systeme übertragbar sind oder sie können unterschiedliche Vorgaben für Datenmengen oder IT-Sicherheit haben, durch die die verschiedenen Systeme inkompatibel werden.


Zuletzt werden Änderungen von übergreifender Bedeutung schwierig und aufwändig. Soll etwa in alle personenbezogenen Datensätze das neue Information "Arbeitsadresse" eingeführt werden muss ermittelt werden an welchen Stellen das nötig ist und ob es überall gleich umgesetzt werden kann, dazu muss die zeitgleiche Umsetzung koordiniert werden, möglichweise einschliesslich der Auflösung von Planungs- und Priorisierungskonflikten. All das kostet Zeit und Geld.


Um diese Auswirkungen zu vermeiden sollte versucht werden die Ursachen für Conway's Law zu beseitigen, indem Digitalisierungs- oder Automatisierungs-Vorhaben immer aus einer übergreifenden Perspektive konzipert werden. Um das zu erreichen gibt es zwei grundlegend unterschiedliche Ansätze: man kann zentrale Kontroll- und Koordinationsinstanzen schaffen, oder die Code Ownership auflösen und allen Einheiten erlauben übergreifend am Gesamtsystem zu arbeiten.


Der klassische Weg in den meisten Organisationen ist der erste, also die zentrale Kontroll- und Koordinationsinstanz, die versucht den zentralen Überblick zu wahren. Aus einer "agilen Weltsicht" ist dagegen die zweite besser, die aber eine Reihe von Voraussetzungen erfordert: übergreifendes System- und Business-Verständnis der Entwicklungsteams, Clean Code, hohe Testabdeckung und eine Einigung auf gemeinsame Standards in Formatierung, Programmierung, etc.


Egal welche Variante (oder Kombination der beiden) man bevorzugt, auf Eines kann sich aber so gut wie jeder einigen: alles ist besser als Conway's Law einfach hinzunehmen - dafür sind seine negativen Auswirkungen zu offensichtlich und zu schwerwiegend.

Montag, 14. November 2022

Ein Bild sagt mehr als 1000 Worte (XXXIV)

Grafik: monkeyuser.com - License

Zugegeben, es sind zwei Bilder. Aber darüber sehen wir heute einmal hinweg. Was mir ein Entwickler-Team einmal zu diesen beiden auf den ersten Blick schlichten Zeichnungen gesagt hat: it keeps on giving, oder mit anderen Worten - man entdeckt immer weitere Details die erkennbar an Phänomene aus dem echten Leben angelehnt sind.

Freitag, 11. November 2022

Warum agil? Discovery, Delivery, Reparatur, Resilienz

Bild: Andy Mabbett / Wikimedia Commons - CC BY-SA 3.0

Sinn- und Zweck-Fragen sind immer wieder erhellend. Im Umfeld agiler Transformationen ist eine von ihnen ein grosser Klassiker: die nach dem Grund wegen dem dort überhaupt agil gearbeitet werden soll. Häufig gibt es die generische Antworten, dass mehr Flexibilität oder höhere Reaktionsgeschwindigkeit angestrebt würden. Auf die Folgefrage wofür genau die nötig sind kommt dann häufig nicht mehr viel. Dabei gibt es gleich mehrere gute Antwortvarianten, z.B. Discovery, Delivery, Reparatur und Resilienz.


Bevor wir dazu kommen aber eine schnelle Definition: als Agilität wird hier die Fähigkeit verstanden in kurzen Abständen reaktions- und lieferfähig zu sein, sonst nichts. Allen die noch mehr darunter verstehen, wie z.B. Humanismus, (Basis-)Demokratie, New Work oder Achtsamkeit, seien zuerst dieser und dieser Artikel empfohlen. Ihre Kernaussage: wie alle Begriffe sollte man auch den der Agilität nicht überfrachten, wenn er benutzbar bleiben soll. Und damit zurück zu den vier Varianten.


Discovery

Um es als Beispiel-User Story zu formulieren:1 Als Startup möchte ich in kurzen Abständen reaktions- und lieferfähig sein, um Kundenbedürfnisse die ich neu entdecke schnell bedienen zu können. Einer der grossen Klassiker unter den Anwendungsfällen der Agilität - ein neues Produkt entsteht erst nach und nach in zu Beginn noch rudimentären Umfängen, und erst wenn mit denen validiert wird, dass es Nutzungs- und Zahlungsbedeitschaft gibt, kommt die nächste Umfangs-Erweiterung. Wenn nicht wird die Entwicklung eingestellt. Umgekehrt kann es auch sein, dass die Neuentdeckung von Nutzern oder Bedürfnissen dazu führt, dass Produktentwicklungsziele schnell dorthin ausgerichtet werden. Das klassische Framework dafür ist Lean Startup.


Delivery

Beispiel-User Story: Als Unternehmen im gesetzlich regulierten Umfeld möchte ich in kurzen Abständen reaktions- und lieferfähig sein, um meine Produkte schnell an neue Vorschriften anpassen zu können. Zunächst weniger intuitiv verständlich, bei etwas Nachdenken macht es aber Sinn. Stark regulierte Branchen wie z.B. der Banken- und Versicherungs-Sektor müssen mitunter im Monatsrhythmus neue Vorschriften in ihren automatisierten Prozessen abbilden. Starre Planung und unflexible Umsetzung sorgen oft dafür, dass Stichtage nicht eingehalten werden können, mit Strafen durch die Aufsichtsbehörden als Folge. Ausgerechnet dort wo es starke Regulierungen gibt wird daher in immer mehr Firmen versucht agil zu arbeiten. Die Methoden-Klassiker sind dabei Scrum und SAFe.2


Reparatur

Beispiel-User Story: Als Konzern mit veralteter, fehleranfälliger Software möchte ich in kurzen Abständen reaktions- und lieferfähig sein, um die häufig auftretenden Fehlfunktionen schnell reparieren zu können. Man mag es sich kaum vorstellen, aber in vielen Behörden und Unternehmen gibt es Anwendungen die seit dreissig oder vierzig Jahren in Betrieb sind, oder noch länger. In den meisten derartigen Fällen führen unentdeckte Bugs, übersehene Seiteneffekte oder historisch gewachsene Komplexität zu ständig auftretenden Funktionsfehlern. Wenn zentrale oder profitable Geschäftsprozesse davon betroffen sind ist es von kritischer Bedeutung, dass Ressourcen schnell umgeplant und Reparaturen zeitnah und unbürokratisch stattfinden können. Methodisch können einige DevOps-Aspekte sehr hilfreich sein.


Resilienz

Beispiel-User Story: Als von ständigen Disruptionen betroffenes Unternehmen möchte ich in kurzen Abständen reaktions- und lieferfähig sein, damit ich die Schäden durch externe Störungen begrenzen kann. Ein mit dem letzten verwandter Fall, mit dem Unterschied, dass die Probleme nicht (versehentlich) selbst erzeugt wurden sondern von aussen kommen. Das kann der neue und innovative Wettbewerber sein, aber auch Naturkatastrophen, Hackerangriffe oder Netzausfälle. Die Agilität wird hier gebraucht um diese Störungen früh zu erkennen, ihre Auswirkungen schnell zu begrenzen und möglichst schnell Kompensations- und Wiederherstellungsmassnahmen einleiten zu können. Das vermutlich am besten geeignete agile Framework ist Chaos Engineering.


Im Zweifel wird es auch noch weitere Herausforderungen geben wegen denen Agilität erstrebenswert ist, der allergrösste Teil wird sich aber einer dieser vier zuordnen lassen. Und dort wo das nicht möglich ist, ist es eine gute Idee genau zu prüfen ob nicht eine eher unsinnige Motivation der eigentliche Treiber ist (z.B. "Ich als Manager möchte überall schnell durchregieren können, wenn ich eine meiner monatlichen spontanen Eingebungen habe." oder "Wir wollen Modernität vortäuschen um Bewerber anzulocken".).


Und natürlich wird es immer wieder vorkommen, dass gleich mehrere der hier genannten Gründe für das Streben nach Agilität vorliegen, und zwar parallel. Das macht das Leben zwar nicht einfacher, es bietet aber immerhin einen kleinen Trost: mit der Einführung passender agiler Arbeitsweisen kann man in mehreren dieser Bereiche gleichzeitig für Verbesserungen sorgen.



1Die Debatte ob man User Stories aus der Perspektive eines Unternehmens formulieren sollte (eigentlich nicht) ignorieren wir heute einfach.
2Es gibt natürlich noch andere Konstellationen in denen Delivery im Focus steht, das hier ist nur ein Beispiel

Dienstag, 8. November 2022

Überstunden

Bild: Unsplash / Jonas Leupe - Lizenz

Zu den unschönsten Momenten im Leben eines Angestellten (oder eines von einem Auftraggeber abhängigen Freiberuflers) gehört es, wenn er direkt oder indirekt zu Überstunden aufgefordert wird, schlimmstenfalls verbunden mit der Drohung, bei der Nicht-Erreichung eines in normaler Arbeitszeit nicht zu erreichenden Ziels gefeuert oder nicht weiterbeauftragt zu werden. Als Betroffener ist man maximal genervt und frustriert. 


Trotzdem kommt es immer wieder dazu, die aktuelle Deadline für die an Twitters Bezahlfunktion arbeitenden Teams dürfte z.B. jetzt schon ein Klassiker unter den derartigen Fällen sein. Je nachdem wie abhängig vom Job oder wie beeinflussbar die zu Überstunden aufgeforderten Menschen sind kann es in solchen Konstellationen nicht nur zu einem späten Feierabend kommen sondern sogar zum Extrem: zum Übernachten am Arbeitsplatz, um möglichst viel Zeit dort verbringen zu können.



Was manchmal in solchen Fällen diskutiert wird - ist das nicht ein notwendiger Teil einer agilen Arbeitsweise? Muss man nicht immer wieder Überstunden schieben, wenn es notwendig ist (oder versprochen wurde) regelmässig Ergebnisse abzuliefern? Die Antwort darauf kann nur ein sehr verhaltenes "kommt drauf an" sein, denn selbst wenn es Fälle geben mag in denen das so ist - in den meisten erreicht man eher den gegenteiligen Effekt.


Um mit dem Grundsätzlichen zu beginnen: Agil zu arbeiten bedeutet, dass man schnell und ergebnisorientiert auf Veränderungen reagiert (responding to change over following a plan). Das bedeutet aber gerade nicht, dass Liefertermine und Lieferumfänge auch bei sich unerwartet ändernden Rahmenbedingungen eingehalten werden müssen, im Gegenteil. Da diese Termine und Umfänge Teil des initialen Plans sind wäre ein Beharren auf ihnen sogar hochgradig un-agil.


Natürlich kann es Grenzfälle geben. Die Leitmesse zu der ein Produkt fertig sein muss, wenn es dieses Jahr noch auf den Markt soll, oder den Stichtag an dem eine gesetzliche Regulierung in Kraft tritt, der eine IT-gestützte Dienstleistung entsprechen muss. Wichtig ist dann aber, dass sie nur in Ausnahmen auftreten und dass sie tatsächlich derartig harte Ursachen haben. In den meisten Fällen trifft das aber nicht zu, da ist die zentrale Motivation, dass Planänderungen einfach nicht gewünscht sind.


Diese Änderungsunwilligkeit wird dann häufig (schein-)rationalisiert, und das auch noch mit Argumenten die scheinbar zur Idee der Agilität passen: die Lead Time oder Time to Market soll kurz sein, die Verzögerungskosten (Cost of Delay) gering, das Kundenfeedback möglichst früh verfügbar. All das sind auch gute Ziele, was in einer solchen Argumentation häufig übersehen wird, ist aber der Preis der zu zahlen ist, wenn man sie mit Überstunden zu erreichen versucht.


Wie vermutlich jeder aus eigener Erfahrung bestätigen kann neigen überarbeitete, übermüdete und gestresste Menschen dazu mehr Fehler zu machen als solche die ausgeschlafen und ausgeglichen sind. Und diese Fehler führen zwangsläufig zu einem von zwei Effekten: entweder muss alles vor dem Release wieder in Ordnung gebracht werden (wodurch Zusatzaufwände entstehen, die alles verlangsamen) oder fehlerhafte Produkte gehen live, mit Fehlfunktionen und Hotfixes auf Produktion als Folge.


Vor allem dort wo regelmässig Überstunden gemacht werden häufen sich derartige Mehraufwände, und das oft in einem derartigen Ausmass, dass der scheinbare Zeitgewinn durch Überstunden ausgeglichen oder sogar in sein Gegenteil verkehrt wird. Zieht man ausserdem in Betracht, dass regelmässige Überstunden fast immer zu Abwanderung der Mitarbeiter in andere Unternehmen führen (verbunden mit Zusatzkosten für Recruiting und Onboarding) verschwindet der Business Case fast völlig.


Jedem Entscheidungsträger kann man daher nur raten es sich dreimal zu überlegen was er tut bevor er zu Überstunden aufruft. So verlockend die Aussicht auch sein mag damit irgendetwas kurzfristig zu erreichen - langfristig werden diejenigen Unternehmen erfolgreicher sein, die ihren Mitarbeitern ein ruhiges, kontinuierliches und steressfreies Arbeiten ermöglichen.





Donnerstag, 3. November 2022

Before you Scale - Descale

Mir ist gerade aufgefallen, dass es auf dieser Seite noch kein Video von mir gibt - bis jetzt. Das hier ist mein Vortrag vom Scaling Agile Summit im letzten Sommer, den ich auf dem Telekom Agilista-Barcamp wiederholt habe, wo er freundlicherweise aufgenommen wurde. Das Thema ist eines das mich schon lange begleitet und beschäftigt, die agile Skalierung.



Ich weiss nicht ob es daran liegt, dass ich zu dem Zeitpunkt Corona-positiv und dadurch etwas unkonzentriert war, aber ich höre in meinem Vortrag viel zu viele Ähs. Da muss ich noch an mir arbeiten

Montag, 31. Oktober 2022

Kommentierte Links (XCIII)

Bild: Pixabay / Buffik - 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.

Alexander Schatten: Getting Nothing Done

Der Titel sagt es ganz passend - wir bekommen nichts mehr fertig, oder zumindest keine Grossvorhaben mehr. Das was Alexander Schatten hier an sich ewig hinziehenden Infrastruktur- und IT-Projekten zusammenträgt ergibt eine beeindruckende und bedrückende Liste. Nicht besser wird der Gesamteindruck durch die von ihm identifizierten Gründe: langsamer werdender technischer Fortschritt, Überregulierung, mutlose und politisch getriebene Entscheidungsfindung sowie die abnehmende Fähigkeit die nötigen Ressourcen für grosse Projekte zur Verfügung stellen zu können. Ich würde noch einen hinzufügen: die Unwilligkeit und Unfähigkeit einmal beschlossene Pläne nachträglich anzupassen.

Stefan Kühl: Komplexität – Das Irrtum der Vereinfacher

Ein interessanter, aber sicher auch kontroverser Artikel. Stefan Kühl geht in ihm davon aus, dass alle Massnahmen, die zur Vereinfachung eines komplexen Systems führen sollen, ihr Gegenteil erreichen und in Wirklichkeit alles nur noch komplexer machen, bis zum Kontrollverlust. Als Beschreibung der Realität ist das durchaus zutreffend, fast alle Vereinfachungsprogramme die man in grossen Organisationen vorfinden kann sind eher Verschlimmbesserungen. Widersprechen würde ich allerdings beim Determinismus - man kann Komplexität sehr wohl reduzieren, allerdings muss dafür versucht werden das angestrebte Ziel zu vereinfachen und nicht nur die zu seiner Erreichung eingesetzten Techniken und Prozesse.

Jason Yip: My take on why goal cascades are harmful and what to do instead

In diesem Blogpost fasst Jason Yip gut zusammen was die Probleme der so genannten "kaskadierenden Ziele" sind, die von ganz oben vorgegeben und dann durch alle Hierarchieebenen durchgereicht werden: Entkoppelung von Entscheidungskompetenz und Umsetzungskompetenz, langsame Durchführung, Ausblendung von (sinnvollen) Eigendynamiken der unteren Ebenen und Vernachlässigung von lokal wichtigen Nebenzielen. Sein Gegenvorschlag: von ganz oben sollten eher abstrakte Leitlinien und Produktvisionen kommen, die dezentral in Ziele heruntergebrochen werden, die dann regelmässig dezentral aufeinender abgestimmt werden können.
PS: Der Blogpost ist auch die Fortführung eines gleich benannten Artikels von John Cutler, der ebenfalls zum Lesen empfohlen ist.

Carl Rogers: The Five Orders of scaling agile teams

Die erste Regel der agilen Skalierung erfreut sich mittlerweile einer gewissen Popularität. Sie lautet schlicht Lass es sein. Für die möglichen weiteren Regeln gibt es zwar viele Ideen, eine Übereinkunft darauf welche es sein sollen existiert aber nicht. Diese Variante von Carl Rogers hätte das Potential zu weiter Verbreitung, weshalb ich hier zu ihrer Bekanntheit beitragen will:
1. Don’t scale
2. Create independence
3. Create interdependence between teams
4. Create interdependence between products
5. Manage dependencies between work to be done

Wichtig für das Verständnis - diese Regeln bilden eine Art Eskalationshierarchie: nach jeder von ihnen sollte man sich nur dann richten, wenn alle davor ausprobiert wurden und nicht funktioniert haben.

Chris Combe: Add skills not people to your cross-functional teams

Aus diesem Artikel von Chris Combe könnte man möglicherweise eine weitere Skalierungsregel ableiten: wenn in einem Team bestimmte Fähigkeiten fehlen füge erst dann neue Teammitglieder hinzu wenn die bestehenden sich das Wissen nicht aneignen können. Warum die Vergrösserung eine eher schlechte Idee ist erklärt er dabei mit Hilfe zahlreicher Referenzen und Verweise, die jeweils zu weiteren lesenswerten Texten führen.

Donnerstag, 27. Oktober 2022

Impediments

Bild: Flickr / WSDOT - CC BY-NC-ND 2.0

Fragt man einen beliebigen Scrum Master aus welchen Tätigkeiten sein Beruf eigentlich besteht wird mit Sicherheit eine dabei sein: das Beseitigen von Impediments. Nachfragen was mit diesem Begriff gemeint ist führen dann aber erstaunlich häufig zu dem Punkt an dem nicht mehr näher erläutert werden kann was er bedeutet, nur dass er irgendwie alles umfasst was irgendwie problematisch ist wird meistens genannt. Dabei ist es eigentlich gar nicht so kompliziert.


Als erstes ist es wichtig zu verstehen, dass dieser Begriff oft deshalb mystifiziert wird, weil er ein eher selten vorkommendes Fremdwort ist. Englische Muttersprachler tun sich da leichter, weil es für sie ein ganz normales Wort ist - Impediment bedeutet übsetzt Hindernis oder Behinderung, und genau das ist in Scrum damit auch gemeint: irgendein Hindernis, das dazu führt, dass das von ihm betroffene Team in seiner Arbeit verlangsamt oder blockiert wird.


Auch das ist natürlich noch unkonkret, es lässt sich aber konkretisieren. Man muss sich nur fragen welche verschiedenen Kategorien von Behinderungen es geben kann von denen Teams üblicherweise betroffen sind. Aus denen ergeben sich dann auch unmittelbar die notwendigen Gegenmassnahmen, mit deren Durchführung oder Veranlassung der jeweilige Scrum Master dann (unter anderem) beschäftigt ist. Hier ist eine (sicherlich unvollständige) Übersicht:


Fehlende Personalkapazität

Einer der grossen Klassiker. Entweder sind zu wenige Leute im Team um in der gewünschten Geschwindigkeit voranzukommen oder die Teammitglieder sind nur in Teilzeit verfügbar und zum Teil an anderer Stelle verplant. In solchen Situationen ist es hilfreich den Personalverantwortlichen mit Hilfe valider Statistiken (Velocity, Lead Times, Durchschnittszeit in Meetings, etc) aufzeigen zu können, dass ohne mehr Kapazität die angestrebten Ziele nicht rechtzeitig erreicht werden können.


Fehlende Skills

Kann in verschiedenen Ausprägungen vorkommen. Entweder müssen bestimmte Tätigkeiten extern vergeben werden oder sie dauern bei interner Ausführung länger als möglich. Auch hier lässt sich das Problem mit Hilfe von Statistiken aufzeigen, sei es in Form der Wartezeiten auf externe Zulieferungen oder in Form hoher Aufwände für Analyse und Bugfixing. Beides ist normalerweise auf Dauer teurer als eine Weiterbildung oder eine Vergrösserung des Teams um Experten sein würden.


Fehlende Ressourcen

Ressourcen sind hier nicht als menschliche Mitarbeiter verstanden sondern als sonstige benötigte Mittel. Von der Entwicklungs- und Test-Umgebung über leistungsfähige Rechner, angemessene Arbeitsplätze, ausreichend vorhandene Meetingräume und Büromaterialien bis hin zu banalen aber notwendigen Dingen wie Klopapier in den Toiletten - ohne all das sind die Effektivität und Effizienz eines Teams stark eingeschränkt, was sich den Budget-Verantwortlichen in der Regel auch einfach erklären lässt.


Fehlende Genehmigungen

Von der fehlenden Genehmigung mit Kunden zu sprechen bis zur fehlenden Genehmigung auf Produktion zu deployen ist hier vieles möglich, und in der Regel wird es nicht aus bösem Willen verweigert sondern aus Angst vor Kontrollverlust. Hier sollte nicht nur aufgezeigt werden, dass Genehmigungs-Bürokratie diesen Kontrollverlust erst recht herbeiführt, sondern auch, dass Scrum mit seiner Transparenz und seiner kurzfristigem Umsteuerbarkeit sogar für mehr Kontrolle sorgen kann - wenn man die Teams machen lässt.


Falsche Priorisierungen

Selbst wenn falsch und richtig bei Backlog-Priorisierungen schwierige Begriffe sind - wenn Refactoring, Bugfixing, Testautomatisierung und Ähnliches immer wieder zugunsten neuer Features wegpriorisiert werden wird es unvermeidbar zu Problemen kommen. Die Aufgabe an dieser Stelle muss sein, dem (vermutlich technikfernen) Product Owner begreiflich zu machen, dass er bei diesem Vorgehen nicht schneller zu neuen Features kommt sondern langsamer, da alles umständlicher und fragiler wird.


Externe Störungen

Die in der Regel am schwersten zu beseitigende Art von Impediment, da diejenigen die versuchen in laufende Sprints oder am Product Owner vorbei Aufgaben an die Entwickler zu geben oder Priorisierungen zu ändern in der Regel Stakeholder und Manager mit Einfluss, Budget- und Personalverantwortung sind. Im Besten Fall lassen sie sich davon überzeugen, dass sie so nicht helfen sondern stören, im schlimmsten Fall bedarf es einer Eskalation zu ihren Vorgesetzen.


Interne Störungen

Die Art von Impediment mit der sich viele Scrum Master am schwersten tun, selbst wenn sie hier den grössten Handlungsspielraum haben. Vom narzisstischen Entwickler der Code Ownership will bis zu den Teammitgliedern die sich über Nichtigkeiten zerstritten haben - die möglichen Ursachen für zwischenmenschliche Probleme sind zahllos. Hier darf jeder Scrum Master sich als Konflikt-Moderator, Vermittler und Mediator beweisen um die beteiligten Egos wieder zusammenzubringen.


Wie oben gesagt, diese Aufzählung ist mit Sicherheit unvollständig, sie gibt aber eine Idee davon was gemeint ist wenn von der Beseitigung von Impediments die Rede ist. Sie zeigt durch ihre grosste thematische Breite auch auf was den Job des Scrum Masters so anspruchsvoll macht, denn in allen diesen Themen muss er in der Lage sein mitzureden. Dass das oft nicht der Fall ist, ist übrigens auch einer der Gründe dafür, dass sich viele so schwer damit tun zu beschreiben was Impediments sind.


So gesehen ist die Frage aus welchen Tätigkeiten der Beruf eines Scrum Masters eigentlich besteht auch ein guter Test. Wenn er erklären kann mit welchen Impediments er zu tun hat und wie er ihnen begegnet kann man ein Grundvertrauen in ihn haben. Kann er das nicht ist das ein Hindernis bei dessen Bewältigung man ihn unterstützen sollte, bevor er sich der anderen annehmen kann.

Montag, 24. Oktober 2022

Kulturelles Kapital

Bild: Pexels / Fauxels - Lizenz

Noch einmal zum Thema der Organisations-, bzw. Unternehmens-Kultur. Dass es sich bei ihr um die Gesamtmenge verschiedener Glaubenssätze, Handlungsmaximen, Artefakte und weiterer Bestandteile handelt habe ich bereits aufgeschrieben, heute soll es um eine Vertiefung gehen. Konkret um das Konzept des kulturellen Kapitals, das davon ausgeht, dass Kultur ein Mittel sein kann, das sich erarbeiten und gewinnbringend einsetzen lässt.


Zum ersten Mal formuliert wurde diese Idee 1983 im Aufsatz Ökonomisches Kapital, kulturelles Kapital, soziales Kapital vom französischen Soziologen Pierre Bordieu, der mit ihr versuchte die Analyse wirtschaftlicher Zusammenhänge auch auf das Thema Kultur anwendbar zu machen. Er übertrug dazu die Idee des wirtschaftlichen Kapitals, also der Ressourcen, die den Menschen für die Verfolgung ihrer Ziele zur Verfügung stehen.


Für Bordieu kommt kulturelles Kapital in drei Zuständen vor: inkorporiertem Zustand, d.h. in den Gehirnen der Menschen, in objektiviertem Zustand, z.B. in Büchern, Maschinen, oder Computerprogrammen, in denen kulturelle Praktiken Spuren hinterlassen haben, und schließlich in institutionalisiertem Zustand, also in Strukturen oder Prozessen, in deren Gestaltung oder Umsetzung sich kulturelle Besonderheiten erkennen lassen.


Egal in welcher dieser drei Formen, kulturelles Kapital entsteht zunächst durch menschliche Tätigkeiten, etwa durch Lernen, Interaktion, Sozialisation, Akkulturation oder das Einarbeiten kultureller Besonderheiten in Arbeitsergebnisse. In allen Fällen kommt es aber im Anschluss zu einer Verstetigung und Sichtbarmachung (z.B. durch bestimmte Begriffsverwendungen), durch welche die Zugehörigkeit der Menschen, Werke und Institutionen zur jeweilen Kultur erkennbar werden.


Sobald das passiert ist entsteht auch eine soziale Auswirkung: andere Angehörige der jeweiligen Kultur erkennen die verbindenden Gemeinsamkeiten. Basierend darauf entstehendt bei ihnen ein Gefühl der Gemeinschaft und Gemeinsamkeit, das zur Folge hat, dass diesen Menschen, Werken und Institutionen bereits im Voraus ein höheres Mass an Anerkennung, Vertrauen und Unterstützung gewährt wird als anderen, die nicht der gleichen Kultur zugehörig sind.


Der Aufwand der in die Erzeugung von kulturellem Kapital geflossen ist zahlt sich in der Folge aus, da der Vorschuss an Anerkennung, Vertrauen und Unterstützung dazu führt, dass geringere Aufwände in Erklärungen, Einbeziehungen, Überzeugungsversuche und weitere Tätigkeiten zur Gewinnung von Vertrauen und Unterstützung inverstiert werden müssen. Auch die Wahrscheinlichkeit von verdecken Widerständen und dadurch verursachten Effizienzverlusten geht zurück.


Wichtig ist für Bordieu aber, dass der Aufbau dieses Kapitals nicht erst dann beginnen darf wenn man seine positiven Auswirkungen benötigt. Da in der bis dahin vergangenen Zeit Aspekte einer anderen Kultur die Aussenwahrnehmung dominieren würden (irgendeine Form von Kultur ist immer da) wäre die Folge, dass ein paradoxer, d.h. in sich widersprüchlicher Eindruck entstehen würde, der eine eher verunsichernde und Ablehnung erzeugende Wirkung hätte.


Es gibt aber auch solche [Güter], die nur aufgrund eines sozialen Beziehungs- oder Verpflichtungskapitals erworben werden können. Derartige Beziehungen oder Verpflichtungen können nur dann kurzfristig, zum richtigen Zeitpunkt, eingesetzt werden, wenn sie bereits seit langem etabliert und lebendig gehalten worden sind, als seien sie ein Selbstzweck. Dies muß außerhalb der Zeit ihrer Nutzung geschehen sein, also um den Preis einer Investition von Beziehungsarbeit, die notwendigerweise langfristig angelegt sein muss.


Am Ende ist es auch das worauf es ankommt wenn an Organisations- oder Firmenkultur gearbeitet werden soll. Wenn dafür gedachte Aufwände freigegeben werden, muss allen Beteiligten bewusst sein, dass dahinter ein Business Case steckt, dass der aber ein eher langfristiger ist, der auch langfristige kontinuierliche Inverstitionen erfordert. Sind die gegeben kann kulturelles Kapital aufgebaut werden und zum Erfolg beitragen. Wenn nicht - dann nicht.

Freitag, 21. Oktober 2022

Das 'ING Model'

Wer im Umfeld der (mehr oder weniger) agilen Bank- oder Versicherungs-IT arbeitet wird vermutlich vom so genannten "ING Model" gehört haben, benannt nach dem niederländerlischen Bank- und Versicherungskonzern gleichen Namens. Es entspricht im Wesentlichen dem berühmt-berüchtigten Spotify Model, mit der Ergänzung, dass auch die Fachabteilungen in den verschiedenen Squad-Einheiten aufgehen. Eine weitere Gemeinsamkeit von Spotify und ING, die in diesem Vortrag von Gijs Meijer und Marcin Pakulnicki vorgestellt wird: in beiden Firmen ist das jeweils nach ihnen benannte Framework nicht mehr im Einsatz.



Genauso interessant ist das was bei der ING stattdessen zum dominierenden Ansatz geworden ist: Micro-Teams, Einheiten von nur drei oder vier Mitgliedern, die nicht langfristig stabil sind, keine Produkte oder Features fest verantworten und deren Arbeit stark auf bestimmten technischen Entwicklungspraktiken beruht. Auch das ist sicher nur eine Momentaufnahme, wenn auch eine Interessante. Und das Video hier ist eine gute Empfehlung für alle Bank- und Versicherungsmitarbeiter, deren Management gerade das "ING Model" einführen möchte und besser wissen sollte was das (nicht) ist und warum es am Ort seiner Entwicklung bewusst nicht mehr eingesetzt wird.

Dienstag, 18. Oktober 2022

Infantilisierung

Bild: Pixabay / Carina Chen - Lizenz

Zu den Sätzen die man früher oder später von ziemlich jedem Agile Coach hören wird, gehört die Aufforderung, Menschen wie Erwachsene zu behandeln. Das erscheint auf den ersten Blick nicht wie etwas Besonderes, was sonst sollte man bei (erwachsenen) Menschen auch tun? Im Arbeitskontext ist aber oft das genaue Gegenteil der Fall, und zwar nicht nur in klassischen Command & Control-Strukturen sondern erstaunlicherweise auch dort wo agil gearbeitet wird. Menschen werden hier infantilisiert.


Zum gemeinsamen Verständnis eine Definition: als Infantilismus bezeichnet man in der Psychologie das Stehenbleiben oder Zurückfallen auf der Entwicklungsstufe eines Kindes, sowohl bezogen auf die körperliche als auch auf die geistige Entwicklung. In Abgrenzung dazu ist die Infantilisierung die Herbeiführung dieses Zustandes durch den Betroffenen selbst oder die Zuschreibung kindlicher Eigenschaften durch Andere. Hier geht es um den zuletzt genannten Fall.


Im Arbeitskontext macht sich diese Form der Infantilisierung dadurch bemerkbar, dass Menschen die geistige Reife abgesprochen wird den Sinn und die Notwendigkeit von Massnahmen und Regeln zu verstehen. In einer Weiterführung dieser Gedanken wird zudem unterstellt, dass sie aufgrund dieser fehlenden Reife ohne externe Hilfe ständig falsche Entscheidungen treffen würden. Infolgedessen wird angenommen, sie müssten "vor sich selbst gerettet" und ggf sogar "zu ihrem Glück gezwungen" werden.


Die häufigste Verbreitung finden derartige Glaubenssätze im Umfeld von Top Down- und Command & Control-Management. Hier trifft man immer wieder auf die Überzeugung, dass ganze Gruppen von Kollegen Informationen nicht verstehen oder die Tragweite ihrer Handlungen nicht abschätzen könnten, weshalb sie "an die Hand zu nehmen" wären. Wichtig dabei ist, dass das nicht nur eine Haltung des Managements gegenüber Untergebenen ist, sie kann auch umgekehrt verlaufen (siehe Unterwachung).


Aber auch in weiten Teilen der agilen Community sind infantilisierende Zuschreibungen weit verbreitet. Die häufig geäusserte Schnelldiagnose, dass jemand der nicht alle Umstellungen mitmachen will noch kein agiles Mindset hätte, ist nichts anderes als Infantilisierung: es wird ihm unterstellt auf einer frühen geistigen Entwicklungsstufe stehengeblieben zu sein und nicht zu wissen was gut für ihn ist. Auch die häufige Pauschalunterstellung von "Widerstand gegen Veränderungen" geht in diese Richtung.


Eine besondere Form der Infantilisierung durch große Teile der agilen Community findet schliesslich auch hier gegenüber Managern statt. Wer auf einem beliebigen Meetup das Thema "Agilität und Management" aufbringt wird fast immer zu hören bekommen, dass "die Manager" von Trotz, Angst vor Veränderungen, Unsicherheit und Ählichem getrieben sind wenn sie sich den Umstrukturierungen in ihren Unternehmen in den Weg stellen. Wer darauf achtet wird Management-Infantilisierung in vielen Firmen finden.


Egal auf welcher Ebene, all diese Formen sind ein starker Indikator dafür, dass derjenige der anderen kindliche Verhaltensmuster unterstellt, selbst grosse Defizite in Menschenkenntnis, Systemanalyse oder Mustererkennung hat. Die meisten Menschen haben wenig gegen einen vorgegebenen Arbeitsmodus (agil oder nicht-agil) wenn sie in ihm einen Sinn erkennen. Tun sie das nicht ist das Hinterfragen von Ansatz und Rahmenbedingungen meistens zielführender als die Menschen "zu ihrem Glück zu zwingen".


Um es mit einem praktischen Ratschlag zu Ende zu bringen: in einer sich agil transformierenden Organisation nach Formen von Infantilisierung zu suchen und sie Denen die sie durchführen zu spiegeln kann ein wirkungsvoller Hebel sein. Wenn sie in verschiedenen Bereichen und Hierarchiestufen verbreitet ist handelt es sich nämlich um einen Teil der Organisationskultur, der alle weiteren Massnahmen kontaminieren kann wenn nicht zuerst an ihm gearbeitet wird.

Donnerstag, 13. Oktober 2022

Frameworks und Pattern Libraries

Bild: Pxhere - CC0 1.0

Wenn es etwas gibt worauf sich die Vertreter der meisten agilen Vorgehensmodelle einigen können, dann dass das was sie jeweils vertreten auf keinen Fall eine Methode ist. Anders als diese wollen sie keine Detailvorgaben machen wer wann was mit welchem Ziel zu tun hat, sondern mehr Freiheit bei der Umsetzung lassen. Wie sie stattdessen bezeichnet werden sollten ist dagegen weit weniger klar. Vor allem ein Begriff wird dabei häufig herangezogen aber auch abgelehnt - der des Frameworks.


Um zu verstehen warum dieser Begriff immer wieder kontrovers diskutiert wird hilft ein Blick auf seinen Bedeutungs-Ursprung, den physischen Rahmen (englisch: Frame), z.B. den einer Tür oder eines Bildes. Dieser hat zwei Funktionen: zum einen stützt und verstärkt er das eingerahmte Objekt, also die Tür oder die Leinwand, zum anderen begrenzt er es aber auch. Es darf nicht grösser sein als der Rahmen, wenn das Gesamtkonstrukt funktionieren soll.


Abgeleitet davon haben die agilen Prozess- oder Methoden-Frameworks eine ähnliche Funktion: zum einen bilden sie eine tragende Stuktur für die bewusst frei gestaltbar gelassenen Bestandteile, die in der Umsetzung für grosse Flexibilität sorgen, zum anderen setzen sie aber auch klare Grenzen die nicht überschritten werden dürfen, und zwar in Form eines nicht verhandelbaren Mindestbestandes an Rollen, Regeln oder Prozessen.


Beispiele dafür finden sich vor allem in den zwei bekanntesten Frameworks, Scrum und SAFe. So heisst es in den Schlussbemerkungen des Scrum Guide: "The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices." Die beiden Funktionen eines Rahmens finden sich hier klar erkennbar wieder.


Auch im Scaled Agile Framework (SAFe), dass den Framework-Begriff sogar in seinem Namen trägt, kann man die beiden Rahmenfunktionen finden. Zum einen definiert Essential SAFE "the minimal set of roles, events, and artifacts required to continuously deliver business solutions via an Agile Release Train (ART)", umgeben wird es aber von einer riesigen Menge optionaler und frei gestaltbarer Elemente, durch die jede Umsetzung anders aussehen kann.


Was vielen "agilen Freigeistern" an dieser Stelle aufstösst ist die Rigidität mit der Mindestanforderungen wie der Scrum Master (in Scrum) oder der Release Train (in SAFe) eingefordert werden. Das wird als zu einengend empfunden, bis zu dem Punkt an dem diesen beiden Frameworks sogar abgesprochen wird überhaupt noch agil zu sein (für Beispiele dafür braucht man nur nach "Scrum is not agile" oder "SAFe is not agile" zu googeln).


Das häufig bevorzugte Gegenmodell sind Ansätze die keine festen Bestandteile vorgeben und nur noch aus einer Ansammlung optionaler Good Practices bestehen. Der Klassiker in dieser Hinsicht ist Kanban,1 von dem eine Vielzahl möglicher Varianten besteht, aber auch DevOps, Extreme Programming und sogar Disciplined Agile sehen sich eher als Baukästen, die zwar ein klares Ziel haben, aber keinen Mindestbestande an Rollen, Regeln oder Prozessen vorgeben.


Der englische Begriff der diese Idee vermutlich am besten umschreibt ist die "Pattern Library", unter anderem zu finden im Unfix Model von Jürgen Appelo. Genau wie bei den als Vorbild dienenden Software Libraries oder Design Pattern Libraries gibt es zwar auch hier vorgefertigte Teile, die von den Anwendern aber beliebig ausgewählt, kombiniert oder angepasst werden können, bis das Ergebnis den jeweiligen Erfordernissen entspricht. Maximale Freiheit und Variabilität also.


Was erwähnt werden muss ist aber auch, dass die durch die Benutzung methodischer Pattern Libraries gegebenen Freiheiten mit einem Risiko verbunden sind. Ohne die Absicherung durch die in den Frameworks vorgegebenen Mindeststandards kann es zu bewussten oder versehentlichen (Wieder-)Einführungen von Wasserfall- oder Top-Down-Management-Elementen kommen. Das ist zwar nicht zwangsläufig, aber eben auch nicht auszuschliessen.


Ob eine Organisation ihren agilen Arbeitsmodus auf Basis eines Frameworks oder einer Pattern Library aufbauen will muss angesichts dieser Vor- und Nachteile jede selbst entscheiden. Überhaupt diese Differenzierung zu kennen kann aber schon bei zielführenden Überlegungen helfen. Und im Zweifel gilt die alte agile Handlungsmaxime: beides ausprobieren und dadurch schlauer werden.



1Die Debatte ob Kanban agil, lean oder etwas ganz Anderes ist klammern wir an dieser Stelle aus.

Montag, 10. Oktober 2022

The agile Bookshelf: Radical Product Thinking

Bild: Pexels / Cottonbro - Lizenz

Die meisten Frameworks denen man im Kontext agiler Produktentwicklung begegnet sind erkennbar von Methodikern und Prozess-Menschen für eben solche verfasst worden. Ein Framework von und für Produktmanager oder Product Owner ist dagegen eher selten. Einer dieser seltenen Fälle ist Radical Product Thinking von Radhika Dutt. Der Inhalt ist deckungsgleich mit ihrem 2018 erschienenen gleich benannten Buch, daher ist das hier gleichermassen eine Methoden- und Buchbesprechung.


Der erste Teil des Buchs ist eine Abrechnung mit dem im Produktmanagement weit verbreiteten Antipattern überwiegend kurzfristig zu denken und zu planen. Dutt bezeichnet das als den Iterations-orientierten Ansatz (Iteration led). Ihm stellt sie als Gegenmodell den Visions-orientierten Ansatz gegenüber (Vision led), der zwar ebenfalls in kurzen Abständen lieferfähig sein will, das aber einer langfristigen Produktvision unterordnet.


Über diese Kurzfristigkeits-Orientierung hinaus identifiziert sie noch sieben weitere häufige Missstände, die sie als Produkt-Krankheiten (Product Diseases) bezeichnet und in einem eigenen Kapitel ausführlich beschreibt:

  1. Hero Syndrome
    Tritt auf wenn der Aufbau des eigenen (Helden-)Status zum eigentlichen Ziel wird. Scheitert meistens, da eben nicht jeder der nächste Steve Jobs wird.
  2. Strategic Swelling
    Ist gekennzeichnet durch eine ständig zunehmende Sammlung und Ausarbeitung möglicher Entwicklungsoptionen, von denen aber keine umgesetzt wird.
  3. Obsessive Sales Disorder
    Eine durchgehende Konzentration auf kurzfristig mögliche Geschäftsabschlüsse, selbst wenn das auf Kosten der eigentlich geplanten langfristigen Ausrichtung geht.
  4. Hypermetricema
    Übermässige Fixierung auf Metriken jeglicher Art, ohne darüber nachzudenken welche Messungen sinnvoll sind und welche nicht.
  5. Locked-In-Syndrome
    Die zu frühe Festlegung auf spezifische technische Lösungen, mit der Folge, dass diese kaum noch geändert werden können, selbst dann nicht wenn das sinnvoll wäre.
  6. Pivotitis
    Ein Ausweichverhalten, durch das versucht wird jedem Hindernis aus dem Weg zu gehen, selbst wenn das auf Kosten von Klarheit und Nachvollziehbarkeit geht.
  7. Narcissus Complex
    Das Erheben der eigenen Erfahrungswirklichkeit zum allgemeinen Massstab, mit der Folge, dass die Zielgruppenorientierung verschwindet.

Was diese Product Diseases noch einmal verstärkt, ist ihre Tendenz zu jeweils mehreren gleichzeitig aufzutreten, die sich gegenseitig verstärken können.


Dieser Problemlage werden verschiedene Lösungsansätze gegenübergestellt, angefangen von einer innovativen Definition dessen, was ein Produkt überhaupt ist (ein Werkzeug um die Welt zum Besseren zu verändern) bis hin zu sehr konkreten, zum Teil sogar mit spezifischen Templates und Anleitungen verknüpften Umsetzungsschritten (diese Templates kann man sich über die zum Buch gehörende Website auch in digitaler Form zuschicken lassen).


Konkret empfieht Radhika Dutt mit der Formulierung der Produktvision zu beginnen, daraus die Strategie abzuleiten, aus dieser die Priorisierung der zu erledigenden Aufgaben und aus dieser dann die Umsetzungsschritte. Um sicherzustellen, dass das nicht versehentlich in die oben genannten Produkt-Krankheiten umschlägt empfiehlt sie dazu die Entwicklung einer Unternehmenskultur, welche die Mitarbeiter dazu bringt ihre Tätigkeit im grossen Kontext zu sehen.


In dieser kompakten Zusammenfassung klingt das zwar banal und abstrakt, im Buch wird es aber durch die zahlreichen Praxisbeispiele und Umsetzungs-Empfehlungen plastisch und inspirierend. Ein Beispiel dafür ist die Radical Product Thinking-spezifische Produktvision, die sich durch eine konkrete Fokussierung auf Zielgruppen-Wünsche und -Probleme von den anderen, häufig sehr schwammig formulierten Visionen abzugrenzen versucht:


Wenn heute [folgende Zielgruppe] versucht [folgenden Bedarf zu befriedigen] tut sie das indem sie [auf folgende bestehende Lösung zurückgreift]. Das ist nicht akzeptabel, weil [die bestehende Lösung folgende Schwächen hat]. Wir streben eine Situation an in der [diese Schwächen beseitigt sind]. Wir führen diese Situation herbei durch [folgendes Produkt].


Besonders hervorzuheben sind ausserdem verschiedene Analyse-Werkzeuge. In verschiedenen Quadranten oder Canvases lassen sich bestimmte Variablen eintragen, deren Wechselwirkungen sichtbar machen und Potentiale und Probleme identifizieren. Sowohl für die Strategie-Entwicklung als auch für Priorisierungen, Kultur-Analysen und viele andere Bereiche lassen sich auf diese Weise neue Aspekte feststellen und Handlungsoptionen erkennen.


Trotz dieser vielen konkreten Anregungen und Anleitungen hat Radical Product Thinking aber auch bewusst freigelassene Lücken. Beispielsweise geht das Buch nicht darauf ein, wie die Kreativ-, Produktions- und Lieferprozesse abzulaufen haben. Dank dieser Zurückhaltung ist dieses Framework mit anderen, eher Prozess-orientierten kompatibel. Eine Kombination mit allen Agile- und Lean-Ansätzen, aber auch klassischem Projektmanagement ist daher problemlos möglich.


Die Haupt-Zielgruppe dürften natürlich die jeweiligen Produktmanager und Product Owner einer Entwicklungsorganisation sein, auch den Agile Coaches, Scrum Mastern und Delivery Managern ist es aber zu empfehlen. Wie viel aus diesem Buch übernommen wird muss natürlich jeder selbst entscheiden, es aufmerksam zu lesen kann man aber jedem empfehlen.

Donnerstag, 6. Oktober 2022

Jidōka

Bild: Wikimedia Commons / Toyota Commemorative Museum of Industry and Technology - CC BY-SA 3.0

Ich fürchte, ich muss mal wieder mit japanischen Fremdwörtern um mich werfen. Heute geht es um Jidōka (自働化), einen Begriff der (wie viele andere aus dieser Sprache) nur schwer zu übersetzen ist. Autonome Automation (Autonomation), intelligente Automation oder Automation mit menschlichem Antlitz sind Übersetzungsversuche, die aber alle nur teilweise korrekt und nur schwer verständlich sind. Dabei ist das dahinterstehende Prinzip eigentlich recht einfach.


Jidōka geht aus von der Erkenntnis, dass bestimmte Reparaturen oder Überprüfungen zwar nur von Menschen vorgenommen werden können, dass komplizierte oder komplexe Systeme aber so unübersichtlich sind, dass ein Mensch gar nicht überblicken kann an welcher Stelle Reparaturen oder Überprüfungen gerade nötig sein könnten. Um das zu beheben werden Maschinen oder Programme erstellt, die den Menschen auf Anomalien hinweisen können.


Das älteste und vielleicht bekannteste Beispiel dafür ist der Webstuhl, der von Toyoda Sakichi, dem Gründer der Firma Toyota, erfunden wurde. Um zu verhindern, dass fehlerhafte Stoffe produziert wurden, überprüfte ein Mechanismus ob die zur Verarbeitung geleiteten Fäden angespannt waren. War das nicht der Fall wurde der Webvorgang angehalten und ein Arbeiter benachrichtigt, der dann überprüfen konnte ob ein Faden gerissen war und neu eingespannt werden musste.


Derartige Jidōka-Mechanismen wurden später zu einem der Grundpfeiler des Toyota Production System, in dem sie durch das automatisierte Anhalten sich ungewöhnlich verhaltender Maschinen und Fertigungsstrassen dabei helfen Produktionsfehler zu verhindern. Zusammen mit Andon (行灯), den von Menschen ausgelösten Fertigungsstops, gehören sie zu den wichtigsten Qualitätssicherungs-Massnahmen im Lean Management.


Über diese Fertigungs-Ursprünge hinaus kommt Jidōka mittlerweile (allerdings in der Regel ohne diesen Namen) auch in rein digitalen Anwendungen oder in kombinierten Hardware/Software-Produkten vor. Ein Beispiel dafür sind die Warnungen und Not-Abschaltungen von sich überhitzenden Mobiltelefonen, ein anderes die im FinOps-Framework vorhandenen Verhinderungs-Mechanismen von unbeabsichtigt steigenden Cloud-Kosten.


Durch die auf diese Art deutlich beschleunigten Reaktionszeiten ist Jidōka sowohl in der Hardware-Fertigung als auch in der Software-Entwicklung ein guter Weg zu mehr Agilität, Flexibilität und Resilienz. In vielen Fällen ist dieses Konzept sogar so selbstverständlich geworden, dass es gar nicht mehr als bewusst eingerichtete Massnahme auffällt. Vermutlich ist das einer der stärksten Indikatoren für den auf diese Weise erzeugten Mehrwert.


Zuletzt noch einmal zu der Übersetzung. Wenn autonome Automation, intelligente Automation oder Automation mit menschlichem Antlitz nicht wirklich zutreffende Übersetzungen sind, was wäre dann eine? Die vermutlich zutreffendste Erläuterung kommt aus der Wikipedia: "Der Begriff geht auf ein Wortspiel Taiichi Ōnos zurück, der im Begriff Jidoka (自動化 für Automation) dem darin enthaltenen Wort für Bewegung (動) das Personenradikal 人 mit der Bedeutung „Mensch“ hinzufügte." Nun ja. Vielleicht muss man auch nicht bei Allem versuchen es ins Deutsche zu übertragen.

Montag, 3. Oktober 2022

Outcome-basierte Produkt-Planung

Die Unterscheidung zwischen Outcome und Output ist einer der grossen Klassiker wenn es darum geht, den Unterschied zwischen klassischer und agiler Produktentwicklung zu erklären. Jeff Gothelf gelingt das in diesem Vortrag recht gut, einschliesslich der verschiedenen Implikationen die sich daraus ergeben.



Interessant ist darüber hinaus die zweite Hälfte seiner Ausführungen, in der es darum geht wie eine Outcome-basierte Planung für eine Produktentwicklung aussehen kann. Das dreht sich stark um Roadmaps und OKRs, allerdings auf einer Art wie sie (leider) noch in kaum einem Unternehmen vorzufinden ist.

Freitag, 30. September 2022

Kommentierte Links (XCII)

Bild: Pixabay / Buffik - 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.

Stefan Kühl: Die paradoxe Tragik erfolgreicher Unternehmen

Auf den ersten Blick ist die Aussage dieses Artikels widersinnig: Unternehmen die in der Vergangenheit bereits erfolgreich Veränderungen hinter sich gebracht haben sollen bei neuen Veränderungen eher unflexibel sein? Bei näherer Betrachtung ergibt diese These von Stefan Kühl aber Sinn. Eine Veränderung erfolgreich durchlaufen zu haben bedeutet fast immer, dass die mit dem Umbruch verbundene Phase der Unklarheit und Instabilität in eine neue Stabilität überführt werden konnte. Und wenn die sich gefestigt hat verschwindet damit auch die Flexibilität. Um diese zu erhalten müsste auch weiterhin eine ständige Anpassung und Veränderung stattfinden - auch eine Veränderung von Teilen dessen was gerade erst eingeführt wurde. Das aber würde dazu führen, dass dieser schon wieder anzupassende Wandel nicht mehr als gelungen gilt. So kommt es zur scheinbaren Widersinnigkeit: wer ständige Veränderung nicht hinter sich lässt gilt als nicht erfolgreich, wodurch Unternehmen die sich erfolgreich verändert haben sich mit der nächsten Veränderung schwertun werden.

Jurgen Appelo: Consider your options for reteaming

Mit seinem Unfix-Model hat Jurgen Appelo dem Thema des (Dynamic) Reteaming einen neuen Anstoss gegeben, der er hier nochmal verstärkt. Sein Ratschlag ist, sich vor einem grösseren Reteaming zu überlegen welche Ausgangs- und Zielstruktur die Teams haben, bzw. haben sollen. Anhand einer Anordnung auf den beiden Achsen Statisch/Dynamisch und Generalistisch/Spezialisiert kommt er zu vier Typen: All-round (Statisch+Generalistisch), Focused (Statisch+Spezialisiert), Ad-hoc (Dynamisch+Generalistisch) und Flexibel (Dynamisch+Spezialisiert). Was über diese Einteilung hinaus interessant ist sind seine Beispiele aus Unternehmen in denen es verschiedene dieser Team-Typen gibt, die dort verschiedene, dem jeweiligen Typ entsprechende Aufgaben wahrnehmen.

Dina Smith: Stop Feeling Guilty About Delegating

Dieser Text von Dina Smith richtet sich eigentlich an Manager, kann aber auch für Mitglieder selbstorganisierter Teams wertvoll sein. In ihm wird das Thema der Delegation, also des Abgebens von Tätigkeiten oder Verantwortung an andere, aus einer ungewöhnlichen Perspektive betrachtet: der eines Menschen der sich unwohl fühlt wenn er Aufgaben an andere abgibt die er (vermeintlich) auch selbst erledigen könnte. Das ist nicht nur für derartige Personen hilfreich (denen vermittelt wird, dass das Delegieren häufig die bessere Option ist als das selber machen), es hilft auch den anderen dabei einen nicht-delegierenden Kollegen mit anderen Augen zu sehen. Der Grund dafür ist nämlich nicht immer der Wunsch Kontrolle, Herrschaftswissen oder Ähnliches anzuhäufen, häufig ist es auch die Sorge andere zu überlasten oder zu verstimmen. Mit dieser Sicht im Hinterkopf in Gespräche über Delegation zu gehen kann zu anderen und besseren Ergebnissen führen als sonst.

Dmytro Yarmak: From agile coach to the military officer - breaking stereotypes about leadership in the army

Da ich versuche auf Feedback einzugehen ist der erste hier stehende Link nachträglich durch einen anderen ersetzt worden. Ursprünglich hatte ich hier einen interaktiven, lehrreichen Twitter-Thread verlinkt, da er aber ohne Twitter-Account nicht gelesen werden kann verlinke ich stattdessen einen besser zugänglichen, bemerkenswerten Artikel von Dmytro Yarmak. In ihm bringt er zwei Welten zusammen die auf den ersten Blick so gar nicht zusammenzupassen scheinen - die eines Agile Coach und die eines Offiziers der ukrainischen Armee im Abwehrkapf gegen den russischen Angriffskrieg. Wenn das was er dort beschreibt auch nur in Ansätzen repräsentativ ist, ist diese Armee in bemerkenswertem Ausmass offen für moderne Führungstechniken.

David Brooks: The Immortal Awfulness of Open Plan Workplaces

Wer hier schon länger mitliest weiss, dass ich gegenüber Grossraumbüros eher kritisch bin. In meiner Erfahrung kommt es fast nie zu den Vorteilen die man sich von ihnen versprochen hat (einzige Ausnahme sind die Einsparungen von Mietkosten), dafür treten reihenweise Nachteile auf. Auch David Brooks ist dieser Überzeugung, die er allerdings mit zahlreichen Quellen untermauert. Wer auf der Suche nach Argumenten gegen diese Art der Bürogestaltung ist kann auf die Links in seinem Artikel klicken und wird dort fündig.

Dienstag, 27. September 2022

Beyond Budgeting

Bild: Pixabay / StevePB - Lizenz

Die agile Produktentwicklung hat Vieles nachhaltig verändert: den Umgang mit Abnehmern und Kunden, die Durchführung der Qualitätssicherung, die handwerklichen Praktiken der Softwareentwicklung und vieles mehr. Ein zentraler Bereich der Unternehmensführung ist allerdings eher unberührt geblieben - der Budgetierungsprozess. Glücklicherweise gibt es aber hier einen kompatiblen, zeitgleich entstandenen Ansatz, der diese Lücke füllen kann. Die Rede ist von Beyond Budgeting.


Ähnlich wieim Fall von #NoEstimates steht hinter Beyond Budgeting eine überzeugte (und in verschiedenen Firmen hoch erfolgreiche) Community, nach aussen sorgt die etwas unglückliche Namensgebung aber dafür, dass es oft gar nicht erst zu einer näheren Beschäftigung mit diesem Ansatz kommt. Dabei soll hier keineswegs der Budgetierungsprozess abgeschafft werden, er soll erhalten bleiben, nur eben deutlich verbessert.


Dieser Verbesserungsbedarf wird aus verschiedenen problematischen Aspekten der klassischen Budgetierung abgeleitet. Dazu gehört vor allem die Fixierung auf die Planung für jeweils das nächste Kalenderjahr, die am Anfang zu langfristig und am Ende zu kurzfristig ist, aber auch weitere übliche Praktiken, etwa die in dieser Jahresplanung oft enthaltene Vermischung von Prognosen und Zielen oder die Kopplung von Gehaltsbestandteilen an aus diesen Jahreszielen abgeleitete persönliche Ziele.


Über diese Budgetierungs-nahen Grundlagen hinaus sind nach und nach weitere Kritikpunkte an häufigen Elementen des traditionellen Budget-Managements in Beyond Budgeting aufgenommen worden, etwa an dem Nicht-Weitergeben von Informationen in die Belegschaft, an zu detaillierter Regulierung von Arbeitsprozessen, an zu bürokratischen Reporting-Strukturen und an der Optimierung auf interne Effizienz statt auf Nutzen für den Endkunden.


Bei der Antwort auf die Frage wie all das besser organisiert werden könnte bleibt Beyond Budgeting absichtlich unklar, da zu konkrete Empfehlungen in vielen Einzelfällen nicht passen würden, zumindest wurden als Richtlinie aber zwölf leitende Prinzipien verfasst:

  1. Purpose
    Engage and inspire people around bold and noble causes; not around short-term financial targets
  2. Values
    Govern through shared values and sound judgement; not through detailed rules and regulations
  3. Transparency
    Make information open for self-regulation, innovation, learning and control; don’t restrict it
  4. Organisation
    Cultivate a strong sense of belonging and organise around accountable teams; avoid hierarchical control and bureaucracy
  5. Autonomy
    Trust people with freedom to act; don’t punish everyone if someone should abuse it
  6. Customers
    Connect everyone’s work with customer needs; avoid conflicts of interest
  7. Rhythm
    Organise management processes dynamically around business rhythms and events; not around the calendar year only
  8. Targets
    Set directional, ambitious and relative goals; avoid fixed and cascaded targets
  9. Plans and forecasts
    Make planning and forecasting lean and unbiased processes; not rigid and political exercises
  10. Resource allocation
    Foster a cost conscious mind-set and make resources available as needed; not through detailed annual budget allocations
  11. Performance evaluation
    Evaluate performance holistically and with peer feedback for learning and development; not based on measurement only and not for rewards only
  12. Rewards
    Reward shared success against competition; not against fixed performance contracts

Um die Idee greifbarer zu machen gibt es mittlerweile neben diesen Leitlinien aber auch verschiedene Good Practices, die in verschiedenen Büchern zu diesem Thema nachzulesen sind.


Die naheliegende erste Praktik ist eine rollierende Planung anstelle einer Kalenderjahr-basierten. Das kann in der Realität so aussehen, dass zwar fünf Quartale im Voraus geplant wird, dass diese Planungen aber nach jedem Quartal überprüft und angepasst werden. Dadurch entfernt sich die Umsetzung nie länger als drei Monate von der Planung, gleichzeitig wird vermieden, dass der Planungsvorlauf zu Jahresende nur noch wenige Wochen beträgt.


Ebenfalls häufig ist die Entkoppelung von Prognose und Zielsetzung. In den Prognosen für den jeweiligen Planungszeitraum wird nur berücksichtigt was wahrscheinlich ist, das was wünschenswert ist (die Ziele) wird in einem zweiten, getrennten Dokument festgehalten. Das gilt auch dann (und sogar ganz besonders dann) wenn die wahrscheinlichen Zahlen unschön oder sogar bedrohlich sind. Sie zu verändern nur weil andere Zahlen schöner wären ändert schliesslich die Sachlage nicht.


Auch bei den Zielen (sowohl bei Geschäftszielen als auch bei Zielen von Personen oder Personen-Gruppen) ist eine kontinuierliche Setzung und Nachverfogung besser als eine Orientierung am Jahresrhythmus. Das bedeutet nicht zwingend, dass sie nur für kürzere Umsetzungszeiträume gesetzt werden, z.B. für Monate oder Quartale. Sie können auch für längere Zeiträume gesetzt werden, müssen dann aber in kurzen Zyklen immer wieder überprüft und an aktuelle Entwicklungen angepasst werden.


Auch bei der Art der Zielsetzung bevorzugt Beyond Budgeting eigene Wege. Statt zahlengebundener Ziele (z.B. Gewinn-Volumen oder Anzahl an Geschäftsabschlüssen) findet man eher relative Ziele, also solche, deren Zielsetzung es ist besser zu sein als eine Vergleichsgruppe. Das kann bedeuten, dass eine ganze Firma sich das Ziel setzt besser zu sein als der Marktdurchschnitt, es kann aber z.B. auch bedeuten, dass eines von 50 Vertriebsteams sich das Ziel setzt zu den besten 10 zu gehören.


Neben diesen sind zahllose weitere Praktiken möglich, die von Unternehmen zu Unternehmen unterschiedlich sein können. Auch die Entwicklung eigener Ideen ist möglich, solange sie den oben genannten Prinzipien nicht wiedersprechen. Und da sich die Communities von Beyond Budgeting und agiler Produktentwicklung in den letzten Jahren angenähert haben umfasst das auch mögliche Kombinationen von beidem (auch dazu gibt es in verschiedenen Büchern Beispiele).


Für jeden der in seiner Organisation die agile Transition ganzheitlich vorantreiben will ist Beyond Budgeting daher ein sehr zu empfehlender Ansatz. Und wenn die Namensgebung als zu kontrovers wahrgenommen werden sollte - man kann es auch agile Budgetierung nennen, wichtig ist, dass die dahinter stehenden Ideen umgesetzt werden, nicht der Name.