Donnerstag, 25. April 2024

Agile Success Stories: das Warnsignal

Bild: Pexels / Andrea Piacquadio - Lizenz

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


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


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


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


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


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


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


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


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


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


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



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

Montag, 22. April 2024

Aufklärung

Bild: Wikimedia Commons / Emil Doerstling - Public Domain

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


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


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


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


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


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



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

Donnerstag, 18. April 2024

Coding Will Never Be The Same Again

Wenn die Rede darauf kommt, wie sehr der Einsatz von KI die Softwareentwicklung beschleunigen und verbessern kann, stösst die Vorstellungskraft vieler Menschen an ihre Grenzen. Ryan Salva ist so freundlich und führt live auf der Konferenzbühne der YOW-Konferenz 2023 anhand des GitHub Copilot vor, wie man sich das vorstellen kann. Beeindruckend.



Die spannenden Fragen, die diese Vorführung aufwirft: wenn über Retrieval Augmented Generation Code von anderen Entwicklern bezogen oder dieser auf Basis von Reinforced Learning from Human Feedback automatisiert modifiziert wird, wie kann verhindert werden, dass das Model versehentlich durch schlechten Code kontaminiert wird? Wie sicher sind die hier nur kurz zu sehenden Absicherungen gegen Bugs, Urheberrechtsverletzungen und anstössige Inhalte wirklich? Und wie kann verhindert werden, dass die Einfachheit der Codegenerierung dazu führt, dass im Überschwang der Gefühle so viel erzeugt wird, dass die Codebase unnötig aufgebläht wird? Die Antworten darauf werden wesentlich beeinflussen, ob mit KI wirklich bessere, schnellere Ergebnisse möglich werden, oder ob die Aufwände einfach nur an andere Stellen verlagert werden. Hoffen wir auf das erste.

Montag, 15. April 2024

KI und Agilität (Probleme und Potentiale)

"Die Zukunft hat bereits begonnen, alles ist jetzt anders und unsere Art zu arbeiten wird sich fundamental ändern." Ungefähr das können wir uns regelmässig anhören, seit 2022 die KI-Anwendungen auf den Massenmarkt gekommen sind.1 Auch für die agile Produktentwicklung wurden und werden derartige Vorhersagen gemacht, und nachdem mittlerweile einige Zeit verstrichen ist, können wir ein erstes Zwischenfazit ziehen: was ist an neuen Möglichkeiten dazugekommen und wie sinnvoll sind die?


Meine (sehr subjektive) Übersicht ist in sechs Kategorien gegliedert: Gefährlicher Blödsinn, Quellenfreie Blaupausen und Banalitäten, Kleine Produktivitäts-Hacks, Grosse Macht und grosse Verantwortung, Riesiges Potential, aber nur schwer umsetzbar und Jenseits der Vorstellungskraft. Man sieht, es ist von allem etwas dabei, ungefähr angeordnet entlang einer Skala zwischen Unsinn und Grossartig. An der können wir uns bei der Betrachtung entlanghangeln.


Gefährlicher Blödsinn

Fangen wir mit dem grössten Quatsch an, dem Scrum Master-Chatbot, der Meetings moderieren oder bei der Formulierung von User Stories helfen kann. Diese Programme sind nicht nur deshalb problematisch, weil sie nicht in der Lage sind, Kontext, Emotionen und nonverbale Signale zu erkennen, sie setzen auf vollständig falschen Prämissen auf, nämlich auf denen, dass der Scrum Master alle Meetings moderiert oder dass alle Anforderungen User Stories sein müssen. Sie richten mehr Schaden als Nutzen an.


Quellenfreie Blaupausen und Banalitäten

"Wie strukturiert man ein Refinement Meeting?" oder "Wie ist ein Kanban-Board aufgebaut?" Derartige Fragen kann man sich von einem Chatbot beantworten lassen. Das ist auch schön und gut, allerdings bewegen sich derartige Fragen auf dem grundlegendsten Einsteiger-Level, wo sie mit dem Risiko verbunden sind, unreflektiert als (im Zweifel unpassende) Blaupause verwandt zu werden. Dazu kommt noch ein weiterer Punkt: ohne Quellenangabe ist nicht klar, wie seriös die ursprüngliche Quelle ist.


Kleine Produktivitäts-Hacks

Ab hier fängt es an, sinnvoll zu werden. Ein KI-Chatbot kann ein Meeting aufzeichnen und zusammenfassen, er kann erste Entwürfe für Präsentationen erstellen und Visualisierungen anfertigen. Unabhängig davon, dass das nur wenig mit Agilität im eigentlichen Sinn zu tun hat, kann es natürlich Zeit sparen. Zumnindest im Moment aber nur im geringen Ausmass, da die Ergebnisse noch so schlecht sind, dass man sie manuell überarbeiten muss.


Grosse Macht und grosse Verantwortung

Auf diesem Punkt ruhen zur Zeit die grössten Hoffnungen: einer KI wird eine Anforderung gegeben und sie erzeugt in Sekunden den Quellcode, alternativ kann sie menschengeschriebenen Code reviewen oder bereinigen. Das kann den Inspect & Adapt-Prozess bemerkenswert beschleunigen, zu beachten ist aber, dass eine KI nur so gut sein kann wie der Durchschnitt ihres Trainingsmaterials. Es besteht daher das Risiko, dass sie unzeitgemässe oder unsichere Software erzeugt.2 Das sollte sorgfältig überprüft werden.


Riesiges Potential, aber nur schwer umsetzbar

Stellen wir uns eine KI vor, der man Aussagen, Fragen und Feedback von tausenden Mitarbeitern schicken kann und die daraus die wesentlichen Züge der Unternehmenskultur extrahiert. Oder eine andere, die aus internen Entwicklungsmetriken bisher unentdeckte Zusammenhänge ablesen kann. Das könnte dabei helfen, Change- und Optimierungsprogramme um ein Vielfaches wirksamer zu machen. Das Problem: kaum ein Unternehmen hat die dafür nötigen Daten in ausreichender Qualität vorliegen.3


Jenseits der Vorstellungskraft

Man muss sich eines bewusst machen: die technische Entwicklung hat gerade erst angefangen. Genau wie bei den ersten Smartphones noch nicht absehbar war, dass sie einmal als Fahrkarte oder Fernbedienung benutzt werden könnten, wird sich bei den KI-Anwendungen ebenfalls noch Einiges ergeben, was jetzt noch nicht absehbar ist. Aber das bedeutet natürlich auch, dass es hier noch nicht besprochen und bewertet werden kann. Das dauert noch.


Zusammengefasst kann man sagen, dass zwar grosse Potentiale erkennbar sind, die wirkliche Revolution der (agilen) Arbeitswelt aber noch ausgeblieben ist. Zum Teil liegt das daran, dass der Einsatz von KI zum Teil in nicht zielführenden Zusammenhängen stattfindet, zum anderen daran, dass die für einen wirklich disruptiven Einsatz notwendigen Voraussetzungen oder Sicherheitsvorkehrungen noch fehlen. Aber das soll nicht heissen, dass es auch so bleiben muss.


Ein häufiges Muster bei technologischen Innovationen ist, dass die kurzfristigen Effekte überschätzt, die langfristigen aber unterschätzt werden. Sollte das auch hier der Fall sein, wird sich das erst in einigen Jahren bemerkbar machen. Bis dahin sollte man zwar technologie-offen bleiben, die Erwartungen an umwälzende Veränderungen aber auf ein realistisches Mass herunterfahren.



1Da der Begriff unscharf ist: gemeint sind hier vor allem Large Language Models.
2Aus diesem Grund sind derartige Anwendungen in vielen Unternehmen zur Zeit intern noch nicht zugelassen.
3Nein, wirklich nicht. Die Daten in Tracking-Tools wie Jira oder Polarion sind in der Regel unvollständig und nur in den seltensten Fällen aktuell gehalten, und die Fragen in Feedback-Tools sind fast immer durch vorgegebene Kategorien, Längenbegrenzungen oder vorgegebene Antwortoptionen suggestiv gestaltet.

Donnerstag, 11. April 2024

Ausbalancierte Product Ownership

Bild: Pexels / Ivan Rebic - Lizenz

Eine der vermutlich ältesten Debatten im Umfeld von Scrum und anderen agilen Ansätzen dreht sich um die Frage, wie gross der Entscheidungsspielraum eines Product Owners (oder vergleichbarer Projektmanagement-Rollen) ist. Darf er wirklich alles entscheiden, bis hin zur möglichen Einstellung seines Produkts, oder ist er lediglich dafür zuständig die Wünsche seiner Stakeholder zu sammeln und zu einem in sich stimmigen Ganzen zusammenzufügen?


Die Antwort ist natürlich auch hier "kommt darauf an", allerdings mit einer gewissen Ausdifferenzierung. Statt einem dieser beiden Extremtypen zu entsprechen, befinden sich die meisten Product Owner irgendwo auf einer dazwischenliegenden Skala, und auch das nicht stationär sondern je nach Kontext mal hier und mal dort. Das ist auch bereits mehrfach beschrieben worden, vielleicht am eingängigsten vom Produktmanagement-Experten Roman Pichler.


In seinem Text Be a Balanced Product Leader, Not a Feature Broker or Product Dictator gibt er den beiden Extremtypen Namen, nämlich genau die im Titel genannten: der Feature Broker hat kaum Gestaltungswilllen oder Gestaltungskompetenz und beschränkt sich darauf, zwischen den Stakeholdern so lange zu vermitteln, bis eine gemeinsame Priorisierung aller Anforderungen entstanden ist. Der Product Dictator hat Gestaltungswilllen und Gestaltungskompetenz und entscheidet alles komplett alleine.


Warum die Extreme schädlich sind, dürfte offensichtlich sein. Das "Produkt" eines Feature Brokers wird schnell zu einem inkonsistenten Sammelsurium von Kompromisslösungen werden, das eines Product Dictators wird zwar in sich stimmig sein, im Zweifel aber vor allem ihm selbst gefallen und nicht notwendigerweise auch den Kunden oder Anwendern. Der "Ausbalancierte Product Owner" befindet sich in der Mittel und hat Züge von beiden, hält sie aber im vernünftigen Rahmen.


Was Pichler ergänzend anmerkt ist, dass jeder Product Owner sich des Risikos bewusst sein sollte, sich unbewusst zu sehr in eine der beiden Richtungen zu bewegen. Vor allem wenn das in kleinen, für sich genommen unscheinbaren Schritten geschieht, kann man das irrige Gefühl haben, sich nicht aus der Mitte wegbewegt zu haben, während die Umgebung einen mittlerweile als einen der beiden Extremtypen wahrnimmt (und unter den damit verbundenen Dysfunktionen leidet).


Es ist daher ratsam, von Zeit zu Zeit zu überprüfen, wo auf der Skala zwischen Feature Broker und Product Dictator man sich befindet. Ob man das durch Selbstreflektion, Überprüfung festgelegter Kriterien oder Feedback von anderen macht kann von Fall zu Fall unterschiedlich sein, wichtig ist aber, dass es überhaupt stattfindet. Nur so kann man sicherstellen, in einer ausbalancierten Rollenausprägung zu bleiben (oder in sie zurückzukehren).

Montag, 8. April 2024

Macht der Scrum Master sich selbst überflüssig?

Bild: Pexels / Zen Chung - Lizenz

Zu den Mythen, die sich mit der Zeit um das Scrum-Framework gebildet haben, gehört der, dass der Scrum Master sich mit der Zeit selber überflüssig macht und irgendwann nicht mehr benötigt wird. Auf den ersten Blick erscheint das auch wie eine naheliegende Idee, bei näherer Betrachtung hat sie aber durchaus problematische Aspekte. Es lohnt sich, näher zu betrachten wo diese Aussage herkommt, wie sie gemeint ist und was für Folgen sie haben kann.


Um mit dem Einfachsten zu beginnen: in keinem der offiziellen Scrum-Dokumente befindet sich eine auch nur entfernt ähnliche Aussage. Weder in der aktuellen Version des Scrum Guide, noch in einer der älteren Versionen, noch in einem der Konferenz-Papers mit denen Ken Schwaber und Jeff Sutherland ihren Ansatz am Anfang bekannt gemacht haben ist die Rede davon, dass der Scrum Master irgendwann nicht mehr gebraucht werden könnte (wer nachlesen will - hier sind alle dieser Dokumente verlinkt).


Der Urheber ist also irgendjemand, der nicht an der Entwicklung von Scrum beteiligt war, überspitzt könnte man sagen: ein Mensch mit einer starken Privat-Meinung. Wer genau das gewesen ist, lässt sich wahrscheinlich nicht mehr rekonstruieren, man kann aber zumindest sagen, wer diese Idee vermutlich bekannt gemacht und popularisiert hat - Geoff Watts, ein bekannter englischer Scrum Master, in seinem 2013 erschienen Buch Scrum Mastery: From Good To Great Servant-Leadership.


My second piece of advice is to go into the role of ScrumMaster with the intention of making the role of ScrumMaster for this team unnecessary. Create such a high-performing, self-organising team, with such a good relationship with the product owner, with such a keen understanding of the Scrum framework (and the principles behind the framework) that they don’t need any facilitation (of either process or people) and have no impediments left to remove. In other words, be so great that they don’t need you anymore. I’m not saying this will definitely happen, but the more you aim for it, the more quickly your team will develop and the better your team will perform.
Geoff Watts: Scrum Mastery (2.Auflage), S.27


Wie man aus diesem Abschnitt herauslesen kann, beschreibt Watts ein Idealbild, dessen Erreichung eher unwahrscheinlich ist. Das tatsächliche Ziel ist dabei weniger die Selbstabschaffung sondern die konstante Arbeit daran, das Scrum Team selbstorganisiert zu machen und ihm diese Selbstorganisation zu erhalten. Indirekt wird gleichzeitig vor dem häufigen Antipattern gewarnt, bestimmte Tätigkeiten in der Scrum Master-Rolle zu monopolisieren (was andere negative Folgen mit sich bringen würde).


Dass das Idealbild eines Scrum Teams ohne Scrum Master nur schwer zu erreichen ist, hat übrigens handfeste Gründe: Vieles von dem, was in dieser Rolle gemacht wird, erfordert ein Heraustreten aus den Alltagsabläufen und eine Konzentration auf langfristige Ziele. Da gerade in Scrum mit seinen kurzen Sprints aber ein permanenter kurzfristiger Lieferdruck herrscht, wäre eine Verdrängung der Langfrist- durch die Kurzfrist-Ziele hochwahrscheinlich, wenn sie von den selben Personen verantwortet werden (kurzfristige Verpflichtungen fühlen sich immer dringender an als langfristige).


Gleichzeitig ist es eine wichtige Eigenschaft des Scrum Masters, überparteilich zu sein, um bei Konflikten (z.B. zwischen den Entwicklern oder zwischen Product Owner und Stakeholdern) vermitteln zu können.1 Ohne ihn fällt diese Vermittlerrolle weg, und wird aufgrund des fehlenden Kontextwissens nur eingeschränkt durch einen externen Moderator oder Mediator ersetzt werden können. Schlimmstenfalls kommt es nur zu Schein-Konsensen, oder solchen die nicht lange halten.


Trotz dieser Faktoren wäre das Setzen des Scrum Master-Selbstabschaffungs-Ziels zunächst unproblematisch, da es aufgrund seiner Langfristigkeit kaum ins Gewicht fällt, wenn es auf absehbare Zeit nicht erreicht wird. Zu einem Problem wird es aber, wenn dieses Ziel in die Einsatz- und Budgetplanungen integriert wird. Und vor allem grosse Firmen versuchen genau das immer wieder, was verschiedene problematische Folgen mit sich bringt.


Zum einen werden in vielen Fällen keine internen Scrum Master-Positionen geschaffen, da man die ja "nur vorübergehend braucht". Das schwächt diese Rolle, es sorgt für eine hohe Fluktuation (aus Sorge vor Scheinselbstständigkeit sind externe Besetzungen meistens befristet) und macht sie zu einem primären Ziel von Sparprogrammen, da der Abbau von externem Personal einer der einfachsten und schnellsten Wege ist, um Kosten (scheinbar) zu senken.


Zum anderen führt auch bei internen Scrum Mastern die Idee, dass diese irgendwann überflüssig werden, zu "Optimierungsversuchen". Eine immer wieder anzutreffende Variante ist die Deckelung der Zeit, in der ein Team Anspruch auf diese Rolle hat (z.B. auf ein Jahr), eine andere besteht daraus, dass sie ab dem Überschreiten bestimmter Zeiträume nur noch in Teilzeit zur Verfügung steht, um in der restlichen Zeit ein weiteres Team übernehmen zu können (und irgendwann zwei weitere, und drei, etc.).


Beide Varianten führen dazu, dass sowohl die Teams als auch die Scrum Master unter einen permanenten Rechtfertigungsdruck gesetzt werden und immer wieder erklären müssen, warum sie das Selbstorganisations-Ziel noch immer nicht erreicht haben. Das zieht kontinuierlich Zeit und Energie von den wichtigen Aufgaben ab (und was passiert, wenn das Ziel, ohne Scrum Master klarzukommen, mit einem Gehaltsbestandteil verbunden wird - man kann es sich denken. Nichts Gutes jedenfalls).


Zusammengefasst: das Ziel, dass der Scrum Master sich selbst überflüssig macht, ist kein offizieller Teil von Scrum, und es ist nie ein Teil davon gewesen. Dort wo es propagiert wird, wird es als ein kaum zu erreichender Idealzustand verstanden, das eigentliche Ziel ist ein ganz anderes. Und dort wo es missverstanden wird oder den falschen Menschen in die Hände fällt, kann es Fehler im Systemdesign, Ressourcenverschwendung und ständigen Stress zur Folge haben.


Das alles ist wirklich schade, da die Grundidee eigentlich gut und erstrebenswert klingt. Aufgrund der damit verbundenen Risiken sollte man es sich allerdings mehrfach überlegen, bevor man sie in der eigenen Firma äussert. Im Zweifel startet man dadurch eine Dynamik, die sich nur schwer wieder einfangen lässt und ohne Notwendigkeit Konflikte verursacht.



1Gemeint ist Überparteilichkeit in Konflikten, die nicht seinen aus der Rolle ableitbaren Auftrag betreffen. Ist der betroffen, ist die Situation nochmal eine andere.

Donnerstag, 4. April 2024

Sturgeon's Law

Wenn wir über Sturgeon's Law (Sturgeons Gesetz) reden, müssen wir damit beginnen, dass es häufig verwechselt wird, und zwar mit einer anderen Beobachtung, die ebenfalls auf den amerikanischen Autor Theodore Sturgeon zurückgeht - mit Sturgeon's Revelation (Sturgeons Offenbarung). Allerdings bauen die beiden aufeinander auf, um das Gesetz zu verstehen muss man also die Offenbarung kennen. Beginnen wir also mit ihr. Sie lautet in aller Schlichtheit:


Ninety percent of everything is crap (Neunzig Prozent von allem ist Mist)
Theodore Sturgeon, Sturgeon's Revelation


Dieses Statement benötigt Kontext. Sturgeon war ein früher Fantasy- und Science Fiction-Autor und lebte in einer Zeit, als diese Genres noch neu waren und von Kritikern als künstlerisch wenig anspruchsvoll betrachtet wurden. Von ihnen wurden zuerst alle Science Fiction und Fantasy als "zu Neunzig Prozent Mist" bezeichnet, was Sturgeon dazu brachte, sie mit der Qualität der restlichen Literatur zu vergleichen. Dabei entstand seine Erkenntnis, dass auch bei der maximal zehn Prozent wirklich gut waren.1


Angesichts dieser Vergleichbarkeit stellte sich für Sturgeon eine Folgefrage: warum war das Ansehen der neuen Genres so viel schlechter? Seine Antwort (und gewissermassen seine zweite Erkenntnis) war, dass sie nicht mit dem Durchschnitt der bisherigen Literatur verglichen wurden, sondern mit den Klassikern und Bestsellern. Diesen Vergleich konnten sie natürlich nur verlieren. Sturgeon's Law (von dem es verschiedene Varianten gibt) sollte derartig unfaire Vergleiche verhindern:


Nothing is always absolutely so. [...] The best science fiction is as good as the best fiction in any field (Nichts kann undifferenziert beurteilt werden [...] Betrachtet man nur die besten Science Fiction-Werke, sind sie ähnlich gut wie die besten Werken anderer Stilrichtungen)
Theodore Sturgeon, Sturgeons Law


So weit, so naheliegend, aber was haben diese eher literaturwissenschaftlichen Überlegungen mit der Welt der Prozesse und Methoden zu tun, um die es auf dieser Seite schwerpunktmässig geht? Mehr als man denkt, denn Sturgeon's Law lässt sich hierher übertragen. Auch neue Methoden werden ständig entwickelt (z.B. POPCORN oder FAST) und oft auf die erwähnte ungerechte Art mit den bereits existierenden, fertig ausentwickelten Ansätzen verglichen. Sturgeon würde auch dem widersprechen.


Ein Vergleich neuer und bestehender Methoden macht nur Sinn, wenn die Vergleichsobjekte der beiden Gruppen basierend auf ähnlichen Kriterien ausgewählt wurden
Sinngemässe Übertragung von Sturgeons Law


Dementsprechend können bewusst rudimentäre neue Ansätze, wie die gerade erwähnten, nur mit den vergleichbar minimalistischen unter den bewährten Vorgehensweisen verglichen werden, z.B. den sieben Mudas. Umgekehrt wären die passenden Vergleichswerte für die klassischen, schwergewichtigen Projektmanagement-Methodiken von PMI und Prince2 nicht einfache Frameworks wie Scrum oder Extreme Programming, sondern eher die "agilen Schwergewichte" wie SAFe oder Disciplined Agile.2


Natürlich verhindert eine derartige Zuordnung von äquivalenten Vergleichsobjekten viele der aus starken Unterschieden ableitbaren Pauschalurteile, wie z.B. "das ist doch viel zu umfangreich" oder "da wird doch ganz Vieles gar nicht bedacht". Genau das ist aber der Vorteil, den die Anwendung von Sturgeons Law bringt - man muss jetzt ähnlich grosse, ähnlich weit ausentwickelte Ansätze einander gegenüberstellen. Ihre Unterschiede (bzw. deren Fehlen) werden dadurch deutlich besser erkennbar.


PS: Unabhängig von Sturgeons Erkenntnissen und Handlungsempfehlungen kann man natürlich Vorlieben für schwer- oder leichtgewichtige Frameworks haben, das ist jedem unbenommen. Diese untereinander zu vergleichen ist aber häufig ein Vergleich von Äpfeln mit Birnen, und daher meistens nur wenig zielführend.



1Natürlich ist diese Zahl hochgradig subjektiv, aber dass ein Großteil aller erschienenen Bücher nur kleine Auflagen hat, liegt auch an der Qualität
2Und im Vergleich zwischen den agilen Frameworks müsste man z.B. FAST an dem ähnlich grossen Scrum messen, statt an dem deutlich grösseren SAFe

Montag, 1. April 2024

Kommentierte Links (CXII)

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

John Cutler: How to Learn and Practice Product Management in a Feature Factory

Zu den am weitesten verbreiteten Antipattern zur agilen (oder einfach nutzerorientierten) Produktentwicklung gehören die so genannten Feature Factories, in denen eine möglichst schnelle Implementierung neuer Funktionen wichtiger ist als die Überprüfung, ob sie auch vom Markt nachgefragt werden. Wie John Cutler mit voller Berechtigung anmerkt, kann man aber selbst in einer solchen Umgebung daran arbeiten, bessere Praktiken zu entwickeln und anzuwenden (er nennt exemplarisch 10, es gibt sicher noch weitere). Bestenfalls verbessert man dadurch das Unternehmen in dem man ist, schlimmstenfalls lernt man, was man nach einem Wechsel im nächsten machen kann.

Robert Ruzitschka: “We” instead of “I” - The team as the smallest unit of delivery

Von den Antipattern zu einer good Practice: Robert Ruzitschka betont richtigerweise, dass die Wertschöpfung in der Anwendungsentwicklung vor allem auf Teamebene staatfindet, und das besonders gut in solchen, darauf verzichten, einzelnen, besonders erfahrenen Mitgliedern eine herausgehobene Rolle zuzugestehen. Nicht etwa, weil das im Einzelfall nicht zielführend wäre (im Gegenteil, wer erfahrener ist, erledigt Aufgaben oft schneller und besser), sondern wegen der Folgen für das Gesamtsystem. Selbst wenn sich es nicht wollen, werden solche "Superstar-Entwickler" zu Flaschenhälsen und Risiko-Faktoren (→ Bus-Faktor). Teams mit breiter Wissens- und Verantwortungsverteilung sind deutlich resilienter.

Dmitry Bagdasaryan: Cultural Intelligence in Hi-Tech Leadership - Navigating Global Business Dynamics

In meinem Psychologiestudium habe ich mich zwar auch mit dem Thema der Intelligenz befasst, die hier von Dmitry Bagdasaryan beschriebene Unterart der Kulturellen Intelligenz kannte ich aber noch nicht. Verkürz gesagt verbirgt sich hinter diesem Begriff die Fähigkeit eines Menschen, sich in kulturell divers aufgestellten Situationen und Umfeldern aufmerksam, verständnisvoll und anpassungsfähig zu verhalten. Vor dem Hintergrund, dass auf kulturellen Missverständnissen und Konflikten beruhende Verzögerungen und Fehlentwicklungen teuer sein können, ist das eine Eigenschaft, an der zu arbeiten sich lohnt.

Randy Silver: The Secret Weapon of Great Leaders: Effective Delegation

Vor einiger Zeit habe ich über die Autonomie-Falle geschrieben, in die jeder zu tappen droht, der Entscheidungen an Menschen delegiert, die dafür nicht vorbereitet sind. Randy Silver hat darüber nachgedacht, was das Ergebnis einer solchen Vorbereitung sein sollte, und kommt dabei auf die folgenden drei Punkte:
1. Den Menschen muss klar sein, wie Entscheidungsprozesse funktionieren
2. Den Menschen muss klar sein, woran sie richtige Entscheidungen erkennen
3. Den Menschen muss klar sein, warum sie die Richtigen sind, um diese Entscheidungen zu treffen
Klingt total selbstverständlich, ist aber leider nicht immer gegeben.

Tanner Wortham: Guessing Is Not a Viable Strategy

Da hat Tanner Wortham völlig recht, strategische Entscheidungen sollte man nicht auf Vermutungen (oder in seinen Worten auf Raten) aufbauen. In einer Umgebung, in der aufgrund ständiger Veränderungen auch Erfahrungswerte kaum möglich sind, sind auch diese keine Option - was bleibt also? Die Antwort: ein vorsichtiges aber entschlossenes Vorantasten durch kontrollierte Experimente. Woran man erkennt, dass man ein solches vor sich hat, beschreibt er anhand von sechs nützlichen Lackmustests.

Donnerstag, 28. März 2024

Entgleiste Meeting-Moderation


Das hier ist eines der Videos, bei denen der alte Spruch stimmt: das Lachen bleibt einem im Hals stecken. Entdeckt habe ich es in den Kommentaren eines Linkedin-Posts, in dem die These aufgestellt wurde, dass Retrospektiven bestenfalls sinnlose Zeitverschwendung sind und schlimmstenfalls eine an Mobbing grenzende Zwangs-Infantilisierung erwachsener Menschen. Das Bittere daran ist, dass es viele Teams gibt, in denen genau das der Fall ist. Das Video ist verstörend nah an einer häufigen Realität.


Anzutreffen sind derartige Katastrophen-Termine immer dann, wenn der Scrum Master, Agile Coach oder Design Thinking-Facilitator den anderen gegen ihren Willen "spielerische Elemente" aufzwingt, unter denen sie eher leiden als von ihnen in irgendeiner Form zu profitieren. Alleine ich habe über die Jahre eine mittlere zweistellige Anzahl derartig entgleister Meeting-Moderationen erlebt, einige davon noch verheerender als hier zu sehen (!) - und alle aus bestem Willen heraus so durchgeführt (was das Ganze um so tragischer macht).


Das soll natürlich nicht heissen, dass Ice Breaker und Gamification per se schlecht wären, viele Teams lieben sie. Genau darin steckt aber ein entscheidender Punkt: wer solche Elemente als Moderator nutzen möchte, sollte genau darauf achten, ob die Teilnehmer sie wollen oder sich davon zumindest nicht gestört fühlen - sowohl grundsätzlich als auch im jeweiligen Einzelfall. Immer dann, wenn das nicht der Fall ist, kann man nur dringend raten, damit sofort aufzuhören. Wenn nicht, wird man das Gegenteil dessen erreichen, was eigentlich beabsichtigt ist.

Dienstag, 26. März 2024

Wie und wann man in Scrum Stakeholder einbinden kann

Bild: Pexels / Theo Decker - Lizenz

Auf die Frage nach den Rollen, bzw. Verantwortlichkeiten, in Scrum werden die meisten Kenner dieses Frameworks ohne zu Zögern mit den Entwicklern, dem Product Owner und dem Scrum Master antworten. Das ist auch grundsätzlich richtig, lässt aber eine vierte aus, die im Scrum Guide (Version von 2020) immerhin dreizehn mal an verschiedenen Stellen genannt wird: die der Stakeholder, also der (team-externen) Interessenvertreter. Wie kommt es, dass diese Gruppe so häufig übergangen wird?


Eine Antwort darauf ist, dass die Stakeholdern im Scrum (scheinbar) nicht am Sprint beteiligt sind. Bei oberflächlicher Betrachtung kann es so erscheinen, als würden sie nur als "Publikum" im Sprint Review erscheinen. Bei näherer Betrachtung können sie aber durchaus stärker eingebunden werden. Zum einen aufgrund der Vorgaben des Scrum Guide selbst, zum anderen durch verschiedene Praktiken, mit denen die bewusst offen gelassenen Lücken von Scrum gefüllt werden können.


Die Stakeholder im Sprint Planning

Um mit einer kleinen Überraschung zu starten - die mögliche Mitwirkung der Stakeholder im Planning steht im Scrum Guide. The Scrum Team may also invite other people to attend Sprint Planning to provide advice. heisst es dort. Eine Möglichkeit, von der viel zu selten Gebrauch gemacht wird.


Die Stakeholder im Daily Scrum

Es ist kein offizieller Teil von Scrum, aber eine häufige Praxis: Daily Scrum Meetings finden öffentlich statt, so dass jeder, der ein Interesse hat, als Zuschauer teilnehmen kann. Häufig reicht das bereits als ein Kommunikationsinstrument aus, ggf. ergeben sich daraus auch Themen für Folgegespräche.


Die Stakeholder im Backlog Refinement

In Scrum ist das Refinement nicht notwendigerweise ein Meeting sondern eine Tätigkeit, in deren Rahmen Backlog-Einträge erstellt, präzisiert und priorisiert werden. Analog zum Sprint Planning können dabei Experten und Kundenvertreter bei Bedarf einbezogen werden.


Die Stakeholder in der Sprint Review-Vorbereitung

Nirgendwo steht, dass die Stakeholder erst im Review-Meeting die Sprint-Ergebnisse sehen dürfen. Oft gilt sogar ein je früher, desto besser, da dadurch mehr Zeit bleibt die Features auszuprobieren, Feedback vorzubereiten und, falls die Zeit das zulässt, sogar noch Änderungswünsche zu platzieren.1


Die Stakeholder im Sprint Review

Nochmal zum Scrum Guide. Ihm zufolge wird den Stakeholdern im Review nicht nur das Ergebnis gezeigt und sie geben nicht nur Feedback, sie erarbeiten darüber hinaus zusammen mit dem Scrum Team nächste Schritte und passen gemeinsam die Planung an. Es ist eine aktive, mitentscheidende Rolle.2


Die Stakeholder in der Sprint Retrospektive

Der seltenste Beteiligungsfall: Retrospektiven sind im Normalfall strikt Scrum Team-intern, um dort vertraulich und in psychologischer Sicherheit auch an schwierigen Themen arbeiten zu können. Aber wenn es dabei um die Zusammenarbeit mit Anderen geht, können die auch gezielt eingeladen werden.


Spezielle Stakeholder-Termine

Über die offiziellen Scrum-Events hinaus kann es Sinn machen, weitere Stakeholder-Termine einzurichten. Welche das sind kann je nach Bedarf unterschiedlich sein, es sollten nur nicht zu viele werden. Und übrigens: auch das Scrum of Scrums ist bei näherer Betrachtung ein Stakeholder-Meeting.


Noch einmal zusammengefasst: wer in den Stakeholdern nur das Publikum für die Sprint Reviews sieht, wird nicht das volle Potential von Scrum nutzen. Sie können (und sollen) an verschiedenen Stellen ihre Expertise einbringen und in diesem Rahmen aktiv mit den drei anderen Rollen, bzw. Verantwortlichkeiten, zusammenarbeiten. Und dort wo das noch nicht passiert sollte der Scrum Master tätig werden. Zu dessen Aufgaben gehört nämlich laut Scrum Guide removing barriers between stakeholders and Scrum Teams.



1Das geht natürlich nur, wenn nicht erst alles am letzten Tag fertig wird. Nochmal eine eigene Geschichte
2Um zu zeigen wie weit das gehen kann: vor der Verschlankung von 2020 stand im Scrum Guide sogar, dass im Review Budgets neu festgelegt werden können

Donnerstag, 21. März 2024

Vollständige Tätigkeit

Bild: Pexels / Yan Krukau - Lizenz

Ein Hoch auf die Wissenschaft! Diesesmal sind es Arbeits- und Organisationspsychologen der Universität Halle, die eine verbreitete Annahme überprüft haben, so dass man diese jetzt auf der Basis valider Empirie vertreten kann. Die Rede ist von End-to-End-Verantwortung, oder "Vollständiger Tätigkeit", wie sie hier genannt wird, und von den Auswirkungen, die diese Art von ganzheitlicher Beschäftigung mit einem Thema auf Menschen haben kann.


Das Konstrukt der „vollständigen Tätigkeit“ als Ziel guter Arbeitsgestaltung heisst der Forschungsbericht, der auf Basis von 800 Betrachtungen und Interviews entstanden ist, durchgeführt mit Menschen unterschiedlichster Berufsgruppen. In dieser Forschung wurde überprüft, welche so genannten Beanspruchungsfolgen (vereinfacht gesagt Auswirkungen auf die Psyche) unterschiedliche Ausmasse der Verantwortung über die eigene Tätigkeit haben (siehe auch hier).


Ein erstes Ergebnis ist, dass "unvollständige Tätigkeiten", die jeweils nur einen Teil einer Wertschöpfung umfassen, eher zu negativen als zu positiven Beanspruchungsfolgen führen. Da in diesem Vorgehen zahlreiche Abhängigkeiten zu anderen Gruppen bestehen, empfand die Mehrheit der untersuchten Personen ständigen Zeitdruck, der Versuch allen Abhängigkeiten gerecht zu werden führte ausserdem zu ständigen Kontextwechseln und Unterbrechungen. Insgesamt entstanden Ineffektivität und Ineffizienz.


Umgekehrt führten "vollständige Tätigkeiten", die grosse Teil der Wertschöpfung umfassen, eher zu positiven als zu negativen Beanspruchungsfolgen. Das in diesem Vorgehen mögliche eigenständige Zielsetzen, Planen und Kontrollieren führte bei der Mehrheit der untersuchten Personen zu mehr Engagement, Zufriedenheit und Commitment, was sich in Form von gesteigerter Kreativität und Effizienz auch auf die Arbeitsleistung auswirkte.


Eine wichtige Differenzierung ergab sich dabei durch das Ausmass der kognitiven Beanspruchung, die durch die jeweiligen Anforderungen des End-to-End-verantwortlichen Arbeitens entstand. Wurde dieses als zu hoch empfunden, konnte es auch bei "vollständigen Tätigkeiten" zu eher negativen als positiven Beanspruchungsfolgen kommen, da dann erneut negative Treiber wie Zeitdruck und Stress auftreten können (zwar aus anderen Gründen, aber mit den selben Folgen).


Übertragen auf die Gestaltung beruflicher Stellen bedeutet dass, dass sich diese idealerweise in der Mitte eines Spannungsfeldes zwischen möglichst umfassender Verantwortung und noch bewältigbarer kognitiver Belastung befinden sollten (wobei diese "Mitte" in den meisten Fällen eher ein beweglicher als ein fixer Punkt sein dürfte). "Agile Praktiken" wie das Pull-Prinzip, Inspect & Adapt und das Automatisieren repetitiver Tätigkeiten könnten bei dieser Gestaltung wesentliche Erfolgsfaktoren sein.

Montag, 18. März 2024

Ein Bild sagt mehr als 1000 Worte (XXXXI)

Grafik: Design Thinking! Comics

Den Vergleich von Produktentwicklungs-Vorhaben mit einer Acherbahnfaher kenne ich schon länger, aber noch nicht in dieser schönen Visualisierung.

Donnerstag, 14. März 2024

Confidence Meter

Grafik: Itimar Gilad - CC BY-SA 4.0

Würde man die Entwicklungsteams dieser Welt diejenigen Fragen nennen lassen, die am schwersten zu beantworten sind, würde eine mit ziemlicher Sicherheit weit oben landen: "Wie sicher seid Ihr, dass Euer Produkt am Markt erfolgreich sein wird?" Vor allem wenn etwas neu entwickelt wird (also in der IT eigentlich immer) ist eine wirklich sichere Antwort aufgrund fehlender Erfahrungswerte kaum möglich, gleichzeitig ist die Antwort "Kann man nicht sagen" natürlich auch unbefriedigend, schliesslich müssen Investitions- oder Abbruch-Entscheidungen ja irgendwann getroffen werden. Ein Dilemma.


Ein Weg um aus diesem Dilemma zu entkommen und zu realistischen Zuversichts-Werten zu kommen ist das Confidence Meter von Itimar Gilad. Mit seiner Hilfe lässt es sich die Bewertung aus verschiedenen Einfluss-Faktoren ableiten, und das nicht etwa nur auf Basis von Bauchgefühl, sondern auf der Grundlage überprüfbarer und in ihrer Gewichtung abgestufter Erkenntnisse, bzw. Ergebnisse. Dadurch ist dieser daraus summierte Wert nicht nur differenzierter, er ist auch weniger anfällig für unrealistisch optimistische Selbsttäuschungen und Manipulationen. Die (vereinfachten) Faktoren sind:


Individuelle Überzeugungen (Zuversichtswert 0,1)

Damit fängt alles an. Irgendjemand (Person oder Gruppe) hat die initiale Idee und glaubt daran, dass aus ihr etwas Grosses werden kann. Das ist wichtig und darf nicht geringgeschätzt werden, eine auch nur irgendwie geartete Erfolgswahrscheinlichkeit lässt sich aber kaum daraus ableiten.


Ein Pitch Deck (Zuversichtswert 0,1)

Sich selbst überzeugt zu haben ist ein erster Schritt, als nächstes gilt es andere zu überzeugen. Überlicherweise geschieht das mit einer Präsentation der (angenommenen) Potentiale und Vorteile. Die zu erstellen verhilft zu strukturierteren Annahmen, zu mehr aber noch nicht.


Aktuelle Trends, Moden und Buzzwords (Zuversichtswert 0,1)

Man kann hier einen beliebigen Hype einsetzen: Digital, Mobil, KI, was auch immer. Darauf aufzuspringen erscheint naheliegend und verlockend, eine auch nur irgendwie geartete Erfolgswahrscheinlichkeit lässt sich aber noch immer kaum daraus ableiten.


Unterstützende Meinungen (Zuversichtswert 0,5)

Ab hier wird es schon ein ganz kleines bisschen objektiver. Wenn auch andere Personen der Meinung sind, dass die Idee Potential haben könnte, ist das eine erste Bestätigung. Und wenn diese Personen auch noch über Budgets oder sonstige Ressourcen verfügen, um so besser.


Schätzungen und Planungen (Zuversichtswert 0,5)

Nehmen wir an, dass Budget da ist, jetzt kann überlegt werden, wie und wann es investiert wird. Das kann sehr dabei helfen, die Umsetzbarkeit zu beurteilen (ein durchaus wichtiger Punkt), ob das Produkt am Markt erfolgreich sein wird, ist aber noch immer sehr ungewiss.


Anekdotische Evidenz (Zuversichtswert 1)

An dieser Stelle gibt es zum ersten Mal eine kleine empirische Validierung. Irgendwo ist ein (angeblich) vergleichbares Vorhaben erfolgreich gewesen. Darin steckt im Zweifel noch viel Hören-Sagen, aber zumindest ist es zum ersten Mal etwas, das über Vermutungen und Hoffnungen hinausgeht.


Marktforschung (Zuversichtswert 3)

Mit Marktforschung wird Hören-Sagen durch eine erste, noch abstrakte, Bedarfsermittlung ersetzt. Ob die potentiellen Kunden und Nutzer aus diesem möglichen Bedarf eine konkrete Kaufentscheidung ableiten werden ist unklar, zumindest hat man sie jetzt aber erstmals überhaupt befragt.


Kunden-, bzw. Anwender-Wünsche (Zuversichtswert 3)

Ab hier wird es konkreter. Konfrontiert mit den ersten Entwürfen des zukünftigen Produkts können potentielle Kunden und Nutzer Wünsche, Erwartungen und Nutzungs-Absichten äussern. Noch keine Erfolgsgarantie, aber ein starker Indikator.


Ergebnisse von Kunden-, bzw. Anwender-Tests (Zuversichtswert 5)

Aus dem starken wird an dieser Stelle ein sehr starker Indikator. Test- und Focus-Gruppen bekommen Prototypen oder MVPs zur Verfügung gestellt und können Rückmeldung zur Benutzungs-Erfahrung und zum wahrgenommenen Mehrwert geben, ggf sogar schon zur Kauf-Absicht.


Echte Verkaufs- und Nutzungsdaten (Zuversichtswert 10)

In diesem letzten Stadium hat der Verkauf bereits begonnen und die ersten Zahlen zu Absatz und Nutzung wurden bereits ermittelt. Die Indikatoren werden jetzt nach und nach durch Beweise abgelöst, die Erfolgswahrscheinlichkeit ist klar abzusehen oder sogar bereits ermittelt.


Wie oben gesagt, diese Übersicht ist etwas vereinfacht, hinter den einzelnen Faktoren stecken nochmal Bandbreiten und Gewichtungen. Die Details dazu (inclusive einer Tabelle mit Berechnungsformeln) hat Itimar Gilad freundlicherweise auf seiner Website zur Verfügung gestellt. Wichtig ist aber, dass sich am Ende aus den Ausgangswerten der einzelnen Faktoren eine Gesamtsumme bildet, die einen realistischen, kaum verfälschbaren Zuversichtswert auf einer Skala zwischen 1 und 10 abbildet.


Was bei näherer Betrachtung dieses Modells auffällt ist, dass sich hohe Zuversichtswerte erst relativ spät, bzw. kurz vor dem Markteintritt ergeben können. Das ist für alle, die möglichst früh möglichst viel Sicherheit haben wollen, natürlich ärgerlich. Auf der anderen Seite ist es aber auch die harte Wahrheit - frühe Sicherheit gibt es bei neuen Produkten nicht. Wer nicht bereit ist das zu akzeptieren, dem werden auch Tools wie dieses hier nicht helfen.

Montag, 11. März 2024

Kollabierende methodische Modelle

Wenige Innovationen der letzten Jahrzehnte dürften so mit Hoffnungen und Erwartungen überladen sein wie die generative künstliche Intelligenz (in Form von Programmen wie Chat GTP, Gemini, o.Ä.). Um so ironischer dürfte es sein, dass wir durch sie etwas lernen können, was so niemand erwartet haben dürfte: wir können anhand der Evolution dieser Technologie erkennen, warum methodische Vorgehensweisen dem starken Risiko ausgesetzt sind, mit der Zeit unbrauchbar zu werden. Aber der Reihe nach.


Im Frühling 2023 veröffentlichten britische und kanadische Forscher die Studie The Curse of Recursion: Training on Generated Data Makes Models Forget. In ihr belegten sie folgendes Phänomen: wenn eine künstliche Intelligenz (KI) nur zu Beginn auf Basis bestehender Datensätze trainiert wird, dann aber ihre auf dieser Basis generierten Ergebnisse wiederum zu dem Trainingsmaterial hinzugefügt werden, dann wird die Qualität der Ergebnisse mit zunehmender Zeit immer schlechter.


Der Grund dafür ist Folgender: die Generierung erfolgt (stark vereinfacht) durch die Ermittlung der Durchschnittswerte aus bestimmten thematisch zusammengehörigen Teilen des Trainingsmaterials. Dadurch gehen Nuancen und Kontext verloren, Trends und verbreitete Missverständnisse entwickeln dagegen ein überproportionales Gewicht. Fliessen die so erzeugten Ergebnisse wieder in das Traininingsmaterial ein, entsteht eine immer stärker werdende Verfälschungs-Dynamik.


Das Ergebnis dieser Dynamik ist der irgendwann stattfindende Modell-Kollaps (Modell steht hier stellvertretend für die KI-Programme): die generative KI hat mit der Zeit so viel fehlerhaftes Material erstellt, dass das Trainingsmaterial in einem derartigen Ausmass davon kontaminiert ist, dass die ursprünglichen, unkontaminierten Bestandteile in Relation dazu in den Hintergrund treten. Und auf Grundlage dieser fehlerhaften Basis entstehen ab jetzt im Wesentlichen falsche Ergebnisse.


Jetzt zur Übertragung auf methodische Vorgehensweisen. Auch diese beruhen zu Beginn (sofern sie seriös sind) auf empirisch erhobenen Erfahrungswerten und sind so in der Realität verankert. Auf dieser Basis entehen aber auch hier Ergebnisse (Konferenzbeiträge, Fachpublikationen, etc.), die populäre Irrtümer, Durchschnitte und Moden verstärkt abbilden. Und wenn das wieder in die Weiterentwicklung der Methodik einfliesst, droht der Kollaps dieser (mentalen) Modelle auch an dieser Stelle.


Die Folge dieser kollabierenden methodische Modelle sind deren zunehmende Entkoppelungen von der Realität, oft in Form von immer trivialer und esoterischer werdenden Frameworks und Methoden. Transaktionale Führung, Selbstorganisation, Purpose oder ähnlich generische Konzepte werden undifferenziert und kontextbefreit zu Universallösungen erhoben, Management-Moden wie das "Spotify Model" oder OKRs werden mit unrealistischen Erfolgsversprechen verbunden, etc, etc.


Ein Weg, der aus dieser Situation herausführen kann, lässt sich übrigens erneut aus den Trainings der generativen KIs extrahieren. Diese führen nämlich dann wieder zu besseren Ergebnissen, wenn die selbsterzeugten Inhalte bewusst nicht in das Ausgangsmaterial weiterer Trainings aufgenommen werden (bzw. dort wo das bereits passiert ist wieder aus ihm entfernt werden), um so die sich selbst verstärkenden Verfälschungs-Kreisläufe gar nicht erst entstehen zu lassen.


Auf die Methodenwelt übertragen würde das bedeuten, Management-Moden, generische oder vereinfachte Ideen und stark kontextspezifische Fallstudien bewusst nicht in die Weiterentwicklung von Vorgehensmodellen einfliessen zu lassen und sich stattdessen auf empirische Validierung und wissenschaftliche Evidenz zu stützen. Inwiefern Organisationen wie das Project Management Institute oder Scaled Agile Inc. wohl dazu bereit wären, kann jeder für sich selbst zu bewerten versuchen.

Donnerstag, 7. März 2024

Reed Hastings on the Netflix Culture

Dass Netflix eine agile Vorzeigefirma mit einer ganz besonderen Unternehmenskultur ist, weiss man spätestens seit No Rules Rules, dem Buch seines CEO Reed Hastings. In diesem Interview in der Stanford Graduate School of Business erzählt er, wie sich sein Unternehmen und seine Kultur in den letzten Jahren weiterentwickelt haben und geht dabei auch auf einige Aspekte ein, die in seinem Buch noch nicht vorgekommen sind (z.B. den Einsatz künstlicher Intelligenz).



Für alle denen das noch nicht reicht, gibt es noch einen weiteren Einblick in die Netflix-Kultur, der aus einem etwas anderen Blickwinkel stattfindet. Kathryn Koehler hat in dieser Firma den bemerkenswerten Titel eines "Director of Productivity Engineering" und kann einiges zu ihrer Leistungskultur und deren Wandel in den letzten Jahren sagen. Zum Interview mit ihr geht es hier.

Montag, 4. März 2024

Conway's Coaching

Bild: Freerangestock / Rawpixel - License

Wenn sich Unternehmen einmal darauf eingelassen haben, ihren Mitarbeitern Coaches zur Seite zu stellen, kommt es immer wieder in der Folgezeit zu Ausdifferenzierungen dieser Rolle. In der Regel durch ein Präfix gekennzeichnet, entwickeln sich "Spezialisten-Coaches" für bestimmte Themengebiete, vom Quality Coach über den DevOps Coach bis zum Leadership Coach kann alles Mögliche dabei sein. Das ist auch erstmal ok, wie so oft kann man bei näherer Betrachtung aber Erstaunliches erkennen.


Viele der verschiedenen ausdifferenzierten Coach-Rollen werden weniger aufgrund von Nachfrage, Unternehmensstrategie oder sonstigen übergreifenden Notwendigkeiten und Zielen definiert, sondern aufgrund eines ganz anderen Kriteriums: der Organisationsstruktur. Sie werden innerhalb der vorhandenen Bereiche oder Abteilungen aufgebaut, deren Themengebiet dadurch auch zu ihrem Coaching-Gebiet wird. Zum Beispiel ist der Quality Coach in der Regel Teil einer Quality Assurance-Einheit.


Das ist zunächst einmal weder gut noch schlecht, und auch nicht ungewöhnlich. Die Tendenz, dass Organisationen ihre Organisationsstruktur auf alles mögliche übertragen ist so verbreitet, dass dieses Phänomen sogar als "Gesetzmässigkeit" formuliert wurde, Conways Law. Ihm zufolge ist diese Übertragung sogar zwangläufig und findet praktisch jedes mal statt, wenn neue Systeme (vor allem technischer, aber auch sozialer Art) erschaffen werden.


Was diese "Gesetzmässigkeit" problematisch macht, ist, dass eine anhand der Organisationsstruktur vorgemommene Aufteilung nicht immer den gegebenen Notwendigkeiten entspricht, und ihnen mitunter sogar zuwiederläuft. Statt zusammengehörende Aspekte gemeinsam zu betrachten und basierend darauf zu entscheiden, welcher von ihnen den grössten Handlungsbedarf (bzw. in diesem Fall Coaching-Bedarf) hat, verengt sich der (Coaching-)Fokus unverhältnismässig stark auf einen Teilbereich.


Wer solche Konstellationen erlebt hat, wird es vermutlich kennen: der Product Coach hilft den Product Ownern bei Roadmaps und Kunden-Interaktionen, lenkt die Aufmerksamkeit seiner Coachees aber selten auf technische Probleme. Der Agile Coach dringt auf regelmässige Auslieferung, selbst wenn der Release-Zyklus durch eine jährliche Leitmesse vorgegeben ist, der QA Coach fördert durch seine ausschliessliche Arbeit mit den Testern unbewusst deren Separierung von den Entwicklern, etc. etc.


Wird diese Entwicklung erkannt, ist es ein häufiger Reflex, alle Coaches in zentralen Einheiten, oft "Coach Pool" genannt, zusammenzuziehen, die z.B. in HR oder Change Management verortet sind. Das scheint zunächst sinnvoll, da Gesamtsicht und Gesamtzuständigkeit entstehen, kann aber auch wieder in Conway's Law enden, da die jetzt übergeordnete zentrale Einheit ebenfalls Partikularinteressen hat, die den übergreifenden Unternehmenszielen ggf. nicht entsprechen.1


Ebenfalls zu beachten ist, dass es auch sinnvolle Erwägungen gibt, die dazu führen, dass Conway's Law auch bei der Definition spezialisierter Coaching-Rollen stattfindet. In Fach- oder Spezialisten-Abteilungen verortete Coaches können bei ihrer Ausbildung und Weiterentwicklung von der hier vorhandenen Expertise profitieren, die in einer zentralen, organisationsübergreifenden Einheit naturgemäss nur schwach ausgeprägt sein kann.


Aus meiner Erfahrung ist ein anderer Weg besser: die "Spezialisten-Coaches" verbleiben zwar zum Zweck des Expertise-Aufbaus in ihren ursprünglichen Einheiten, sie bilden aber organisationsübergreifend eine Querschnittsorganisation, in der Einsatzplanung, Austausch, Abstimmung und das Setzen von gemeinsamen Standards stattfinden können, mit dem Ziel, dass trotz Spezialisierung eine Einheits-übergreifende Sicht auf die Gesamtorganisation und ihre Bedürfnisse und Notwendigkeiten möglich ist.


Wichtig dabei: wir sprechen immer noch von ausdifferenzierten Rollen, wie Quality Coach, DevOps Coach, etc. Bei Team Coaches mit fester Teambindung kann eine stärkere lokale Verankerung Sinn machen, das wäre aber nochmal ein eigenes Thema.


1Ein häufiges Phänomen ist z.B. der Versuch einer "Optimierung" der Einsatzplanung, wodurch Coaching-Quantität auf Kosten von Coachin-Qualität gewonnen wird.

Donnerstag, 29. Februar 2024

Kommentierte Links (CXI)

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

Jenny Fernandez, Kathryn Landis, Julie Lee: Why Collaboration Is Critical in Uncertain Times

Obwohl es in diesem Artikel mehrerer Autoren des Harvard Business Review um das Thema der Zusammenarbeit geht, ist der Betrachtungswinkel weniger ein soziologischer oder systemtheoretischer und mehr ein psychologischer. Basierend auf mehreren wissenschaftlichen Studien beschreiben sie das Phänomen, dass Führungskräfte und Mitarbeiter in Krisensituationen dazu neigen, stärker miteinander zu konkurrieren, weniger Informationen zu teilen und mehr einsame Entscheidungen zu treffen. Da diese (auf unbewussten Mechanismen beruhenden) Muster aber zu tendenziell schlechteren Ergebnissen führen, ist es sinnvoll ihnen durch bewusst herbeigeführte, die Zusammenarbeit stärkende Massnahmen zu begegnen. Auch diese Massnahmen stellt der Artikel vor.

Prateek Singh: The Non-Issue of Team Size aka The Incomplete Understanding of Complete Graphs

Die Grafik mit der bei gleichmässig steigender Teamgrösse exponentiell steigenden Zahl an Kommunikations-Verbindungen (siehe hier) dürfte eine der am häufigsten gezeigten sein, wenn es darum geht zu begründen, warum agile Teams eher klein sein sollten. Prateek Singh stellt allerdings die Aussagekraft dieser Darstellung in Frage, da er die Idee eines (grossen) Teams in dem jeder mit jedem kommuniziert in der Realität für kaum vorfindbar hält. Für realistischer hält er die Herausbildung von Kommunikations-Knoten (Hubs), durch die der Kommunikationsaufwand sich deutlich reduzieren lässt. In einem solchen Setting stellt die Grafik nur noch die möglichen Kommunikations-Verbindungen her, nicht mehr die nötigen. Damit hat er natürlich recht, ein Team möglichst klein zu halten ist aber aus vielen Gründen trotzdem erstrebenswert, so lange es nicht auf Kosten der Crossfunktionalität geht.

Jason Knight: 5 Different Types of Debt That Can Hinder Your Product Organisation

Über Technische Schulden und Organisatorische Schulden habe ich bereits selbst etwas geschrieben (hier und hier), Jason Night fügt diesem Konzept noch drei weitere Dimensionen hinzu: die Produkt-Schulden, die Visions-Schulden und die Einnahmequellen-Schulden. Allen ist gemeinsam, dass es sich um ursprünglich aus guten Gründen (bzw. aus der Not heraus) getroffene Entscheidungen handelt, die aber in einer langfristigen Betrachtung Inkonsistenz, Ineffizienz oder Ineffektivität zur Folge haben, die mit z.T. grossem Aufwand korrigiert werden müssen (dieser Aufwand ist das "Zurückzahlen" der Schulden, daher die Analogie). Grundsätzlich gilt: diese verschiedenen Arten von Schulden sind nicht per se schlecht, sie müssen aber bewusst aufgenommen und planmässig abgebaut werden.

Tim Ottinger: Definition-by-Dysfunction

Wer Twitter und Linkedin nach Meinungen zu den agilen Frameworks (oder zur Agilität im Allgemeinen) durchsucht, wird einen bestimmten Typ erstaunlich häufig finden: kategorische und z.T. hochemotionale Ablehnungen, die aber auf Aspekten beruhen, die in keinem einzigen Framework enthalten sind (Sprints mit unrealistisch hoher Arbeitsmenge, Unterlassen von Planung und Dokumentation, alberne Spiele in Retrospektiven, etc.). Tim Ottinger gibt diesem Phänomen einen Namen: Definition by Dysfunction (sinngemäss übersetzt: eine Vorstellung die auf einem dysfunktionalen Kennenlern-Kontext beruht). Dafür, dass die Erkenntnis, einer Definition by Dysfunction aufgesessen zu sein, erhellend sein kann, ist er selbst ein gutes Beispiel - ursprünglich ein Gegner von Scrum, findet er den Ansatz mittlerweile (seit er ihn in Original kennt) gut.

Jason Zinoman: How Taylor Tomlinson Nailed Her Closing Joke

Auch ausserhalb der "agilen Blase" gibt es die Idee kontinuierlicher incrementeller Überprüfung und Verbesserung. Dieses Beispiel hier ist besonders anschaulich: Jason Zinomann, ein Journalist der New York Times, hat die Komikerin Taylor Tomlinson in den neun Monaten vor einem großen, für das Fernsehen aufgezeichneten Auftritt begleitet und dabei dokumentiert, wie einzelne Elemente ihres finalen Auftritts immer wieder in kleineren Auftritten erprobt, basierend auf dem Feedback des Publikums optimiert und danach erneut erprobt wurden. Ohne den Begriff zu nennen (und vermutlich ohne sich dessen bewusst zu sein) ist das die Anwendung agiler Praktiken bei der Entwicklung eines Bühnenprogramms.

Montag, 26. Februar 2024

Warum gerade viele Scrum Master und Agile Coaches ihren Job verlieren

Bild: Pexels / Antoni Shkraba - Lizenz

In vielen Unternehmen ist gerade ein scheinbar paradoxes Nebeneinander von zwei Phänomenen zu beobachten. Zum einen ist  mittlerweile allgemein anerkannt, dass Firmen agil (d.H. in kurzen Abständen Liefer- und Reaktionsfähig) sein müssen, um Umbrüchen wie Wirtschaftskrisen, Covid19 oder dem Aufstieg von KI-Anwendungen begegnen zu können. Zum anderen trennen sich gerade viele Firmen von ihren Scrum Mastern, Agile Coaches und sonstigen "agilen Methodikern". Wie passt das zusammen?


Spricht man mit Managern in diesen Unternehmen, ist die meistens von ihnen kommende Erklärung eine, die für besagte Methodiker nicht besonders angenehm ist: ja, Agilität ist wichtig und wird (wenn auch z.T. unter anderen Namen) weiter angestrebt. Dass trotzdem gleichzeitig Scrum Master- und Agile Coach-Stellen abgebaut werden liegt daran, dass aus Unternehmenssicht nicht erkennbar ist, dass diese in nennenswertem Ausmass zu diesem Ziel (agil zu werden oder zu bleiben) beitragen.


Diese Bewertung ist heftig und muss darum eingeordnet werden. Zum einen gibt es natürlich auch viele Firmen, in denen nicht so gedacht wird und in denen die agilen Methodiker weiterhin eine hohe Wertschätzung erfahren. Des Weiteren beruhen derartig negative Beurteilungen mitunter auf Unwissen oder hidden Agendas. Die schiere Menge der Fälle legt aber nahe, dass auch solche dabei sind, in denen diese negative Aussenwahrnehmung gerechtfertigt ist.1


Wenn wir unterstellen, dass diese Rollen grundsätzlich Sinn machen (ein Argument dafür findet sich hier), stellt sich jetzt die Frage, was in so vielen Firmen falsch läuft. Was sind die Gründe dafür, dass Scrum Master und Agile Coaches dort nicht dazu beitragen, die Produktentwicklung agiler zu machen? Die Gründe dürften vielfältig sein, nachdem ich in zahlreichen Unternehmen bestimmte Muster immer wieder erlebt habe, wage ich aber die Hypothese, dass die folgenden Ursachen eine zentrale Rolle spielen:


Fehlende Methoden-Expertise

Eine der irritierendsten Beobachtungen zu Beginn: viele Methodiker haben nur ein erstaunlich dünnes Methodenwissen. Häufig beschränkt es sich auf Scrum (und selbst das manchmal nur oberflächlich2), Kanban wird auf ein Task-Board mit WIP-Limits reduziert, von SAFe sind nur die inneren Mechaniken der Release Trains bekannt, etc. Das engt nicht nur den eigenen Werkzeugkasten ein, es führt auch zum Verlust des Status als Experte für Agilität und Organisationsentwicklung.


Fehlende technische Expertise

Um einem häufigen Einwand direkt zu begegnen - nein, ein Scrum Master oder Agile Coach muss keinen Code schreiben können. Er sollte aber zumindest auf einer abstrakten Ebene verstanden haben, was Continuous Integration, Feature Toggles, Code Coverage und Software Architektur mit Agilität zu tun haben. Ist das nicht der Fall, wird er viele Impediments und Wissenslücken in seiner Umgebung nicht erkennen und damit auch nicht beheben können.


Fehlende fachliche Expertise

Auch hier eine direkte Erwiderung auf einen häufigen Einwand - ja, das ist das Themengebiet des Product Owners. Aber: die Beratung des Product Owners gehört zu den expliziten Aufgaben des Scrum Masters. Und zumindest dort wo Elemente der Fachlichkeit mit dem agilen Vorgehen zu kollidieren drohen (z.B. im Fall von Vorgaben durch gesetzliche Regulierung) müssen diese bekannt und verstanden sein, um ein mit ihnen kompatibles und trotzdem agiles Vorgehensmodell entwickeln zu können.


Fehlende wirtschaftliche Expertise

Dass viele Scrum Master und Agile Coaches dieses Themengebiet nicht als ihres ansehen ist ein schwerwiegendes Missverständnis. Time to Market, Minimum Viable Products, Lead Times, Technische Schulden, (die Vermeidung von) Waste und viele andere Themen sind zutiefst betriebswirtschaftlich und gleichzeitig von zentraler Bedeutung für agile Produktentwicklung. Wer sie nicht kennt wird sich oft schwer damit tun, einem Stakeholder die Sinnhaftigkeit agilen Arbeitens zu erklären.


Fehlendes Systemverständnis

Gemeint ist hier das organisatorische Gesamtsystem. Ausserhalb der eigentlichen Produktentwicklung gibt es verschiedene Prozesse und Einheiten, die starke Einflüsse auf den Grad der möglichen Agilität haben: von Budgeting und Compliance über HR und Betriebsrat bis hin zum Facility Management. Ähnlich wie im Fall der technischen Expertise ist es ohne Systemverständnis an vielen Stellen nicht möglich, Impediments zu erkennen (und damit auch nicht, sie zu lösen).


Um es noch ein weiteres mal zu wiederholen: es gibt viele Firmen in denen sich andere Konstellationen finden lassen, die gerade genannten Qualifikationslücken sind also keineswegs typisch für die agilen Methoden-Berufe. Es gibt aber eine signifikante Menge in dieser Gruppe, die diese Aspekte (bewusst oder unbewusst) wenig beachtet hat, um sich stattdessen mit Themen wie Coaching, Achtsamkeit und kreativer Meeting-Moderation zu beschäftigen. Nicht dass die keine Berechtigung hätten, aus einer unternehmerischen Sicht sind sie aber deutlich weniger wichtig als die zuvor genannten.


Was man für ein vollständiges Bild aber auch sagen muss: aus einer unternehmerischen Sicht ist es ebenfalls sinnvoll und notwendig, die oben genannten Themengebiete in die Ausbildung und Weiterentwicklung der eigenen Scrum Master und Agile Coaches zu integrieren. Dort wo das geschehen ist, dürften diese Jobs wertstiftend (und damit sicher) sein. Dort wo es nicht geschehen ist sollte man sich fragen, ob die aktuellen Entlassungen nicht auch ein Zeugnis einer verfehlten Personalpolitik sind.



1Alleine im Grossraum Köln/Bonn weiss ich von einer dreistelligen Zahl an Scrum Master-, Agile Coach- und Release Train Engineer-Stellen, die gestrichen oder zu Teilzeit-Tätigkeiten reduziert wurden
2Klassische Missverständnisse sind das Weglassen zentraler Elemente, wie z.B. den Sprint Zielen, bei gleichzeitigem dogmatischem Beharren auf optionalen Elementen wie den Story Points oder der Definition of Ready

Donnerstag, 22. Februar 2024

Scaled Agile: Hubs

Wir alle kennen den für agile Teams anzustrebenden Idealzustand: crossfunktional, d.h. in der Lage, alle notwendigen Tätigkeiten selbst auszuüben, und selbstorganisiert, d.h. in der Lage, selbst darüber entscheiden zu können, welche dieser Tätigkeiten wann durchgeführt wird. In der Realität gibt es aber immer wieder Sachzwänge wirtschaftlicher oder regulatorischer Art, die diesen Idealzustand einschränken. Das macht Kommunikation und Koordination mit anderen Teams nötig.


Je nachdem wie (un)hierarchisch eine Organisation aufgestellt ist, kann die Gestaltung dieser Kommunikationsströme unterschiedliche Formen annehmen. Der klassische Weg ist dabei der durch das Management. Ein Team-, Abteilungs- oder Projektleiter sammelt die zu besprechenden Themen in seiner Einheit ein, trifft sich mit seinem Gegenpart aus der anderen Einheit, der dort vorher das Gleiche gemacht hat, bespricht alles mit ihm und bringt die Ergebnisse zurück zu seinen Leuten.


Eine solche Lösung ist zwar naheliegend, allerdings aus verschiedenen Gründen problematisch. Entscheidungskompetenz und Umsetzungsexpertise werden entkoppelt, diese Art der Informationsübermittlung dauert relativ lange, durch die verschiedenen Kommunikations-Stationen entsteht das Risiko von Stille Post-Effekten und es kann sich (ggf. unbeabsichtigt) beim Management Herrschaftswissen herausbilden.


Der häufig propagierte "agile Gegenentwurf" ist die Netzwerk-Organisation. Hierarchien kann es zwar auch hier noch geben, die Kommunikationsströme richten sich aber nicht mehr an ihnen aus. Stattdessen kann jeder Einzelne mit jedem Anderen (sowohl Personen als auch Gruppen) Kontakt aufnehmen und anstehende Themen besprechen und Klären. Gegebenenfalls können dabei auch direkte Kommunikationen zwischen unterschiedlichen Hierarchie-Ebenen zustande kommen.


Auch diese Lösung ist aber nicht unproblematisch. Es besteht das Risiko, dass die Kommunikation zerfasert und unübersichtlich wird, mit der Folge, dass entweder Redundanzen entstehen (die im schlimmsten Fall zu verschiedenen, ggf. inkompatiblen Lösungen für das selbe Problem führen), oder dass ein unverhältnismässig hoher Aufwand investiert werden muss, um für jeden nachvollziebar zu machen, wer gerade mit wem über welches Thema spricht.


Ein Versuch, einen Mittelweg zwischen diesen beiden Extremen zu finden, kommt von James Coplien, einem der unbekannteren Pioniere der agilen Software-Entwicklung (unter anderem hat er das Daily Scrum/Daily Standup erfunden). In seinem Ansatz der Scale Free Organisation ergänzt er die Netzwerk-Organisation um Personen, die Informationsknotenpunkte, die so genannten Hubs, bilden, welche die zu kommunizierenden Informationen konsolidieren, bzw. verteilen.


Der Unterschied zu dem Management-zentrierten Ansatz ist, dass es sich bei diesen die Informationen konsolidierenden, bzw. verteilenden Personen nicht um Manager oder sonstige Funktionsträger handelt, sondern lediglich um Menschen, die aufgrund ihrer Kommunikativität, ihrer Versetzungshistorie, ihrer Bereitschaft Wissen zu teilen oder sonstiger Faktoren (z.B. der Mitgliedschaft im Betriebssportverein) überdurchschnittlich viele andere Menschen kennen und bei Bedarf Kontakt zu ihnen herstellen können.


Ebenfalls im Unterschied zum Management-zentrierten Ansatz erfolgt die Herausbildung von Hubs selbstorganisiert, emergent und ggf. temporär. Mit anderen Worten: da kommunikative und/oder gut vernetzte Personen mit höherer Wahrscheinlichkeit angesprochen werden oder an Abstimmungs-Meetings (z.B. einem Scrum of Scrums) teilnehmen werden als andere, verstärkt sich ihr Hub-Status selbst. Fallen Hubs aus (z.B. durch Versetzung) entsteht durch die gleichen Mechanismen ein Ersatz.


Bedingt durch diese Selbstorganisations- und Kompensationsmechanismen (die Coplien in 200 von ihm untersuchten Unternehmen identifizieren konnte) sind Organisationen, deren Kommunikation über derartige Hubs läuft, mit einer hohen Effektivität, Flexibilität und Resilienz ausgestattet, da in ihnen direkte Verbindungen immer da entstehen wo sie gerade gebraucht werden, ohne dass sie sich durch Regulierung oder Normierung verfestigen.


Ein interessanter Aspekt, auf den Coplien aber nicht eingeht, ist die Frage, ob sich in formal Management-zentrierten Organisationen informelle Strukturen in Form von Hubs herausbilden können. Die Erfahrung spricht dafür, ob es wirklich in nennenswertem Ausmass der Fall ist, wäre aber ein interessantes Forschungsfeld für die Organisationssoziologie.