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:

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.

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.

Pierre Bordieu, 1983: Ökonomisches Kapital, kulturelles Kapital, soziales Kapital

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.

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.

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

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,¹ 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.

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.

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.

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.