Kommentierte Links (CI)

Bild: Unsplash / Fabio Bracht - 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.

Barry Overeem: How Poor Facilitation Of The Scrum Events Can Cause Zombie Scrum

Zusammen mit Johannes Schartau und Christiaan Verwijs hat Barry Overeem den Begriff "Zombie Scrum" geprägt, womit ein Vorgehen gemeint ist, dass oberflächliche Ähnlichkeiten mit dem echten Scrum hat, aufgrund einer nicht sinngemässen Umsetzung aber dysfunktional ist. Zu den stärksten Indikatoren für derartige Missstände gehören Meetings, die lediglich formelhaft durchgeführt werden, ohne ihren eigentlich Zweck zu erfüllen (und ihn ggf. sogar unterlaufen). Wie das aussieht erfährt man in diesem Artikel.

Bruno Baketarić: You should not track flow efficiency!

Die Flusseffizienz zu messen ist eine Idee der ich bei verschiedenen Kunden immer wieder begegnet bin, und grundsätzlich ist sie auch gut. Was Bruno Baketarić hier anmerkt ist aber ebenfalls Teil der Wahrheit: eine Erhebung ist sehr, sehr schwierig. Das liegt unter anderem daran, dass es dafür nötig ist die Daten mindestens auf Tagesbasis aktuell zu halten, was spätestens im Fall mehrerer paralleler Tätigkeiten und verschiedener beteiligter Teams aufwändig und kleinteilig wird. Nicht, dass es gar nicht ginge, man sollte sich aber bewusst machen, worauf man sich einlässt.

Jim Highsmith: Micromanaging the Right Way

Einige der besten Denkanstösse sind die, die auf den ersten Blick widersinnig wirken. Und da es sich bei Jim Highsmith um einen der Verfasser des legendären Agilen Manifests handelt konnte man direkt davon ausgehen, dass seine Verteidigung des Micromanagements in diese Richtung geht. Die wichtige Zusatz-Information ist, dass er zwischen dem Mircomanagement der Mitarbeiter und dem Micromanagement des Produkts unterscheidet. Das zweite sinnvoll zu finden ist immer noch kontrovers, aber schon eher mit agilem Arbeiten kompatibel.

Fagner Brack: Finding the Sweet Spot: Pros and Cons of Mob Programming, Pair Programming, and Solo Work in Software Development

Kategorische Aussagen sind bekanntlich immer falsch, so auch die, dass Entwicklungsteams am Besten alles im Pair Programming machen sollten. Wann das Sinn macht, was die Alternativen sind und wann diese Sinn machen arbeitet Fagner Brack in dieser Gegenüberstellung sehr schön heraus. Auch er liefert natürlich keine allgemeingültige Anleitung, nach dem Lesen seiner Ausführungen kann es aber einfacher sein sich auf ein Vorgehen zu einigen, dass dann eine Zeit lang ausprobiert werden kann.

Jeff Gothelf: The Product is the Variable

Je nachdem in welchem Kontext man arbeitet gelten verschiedene Parameter als fix und variabel, meistens Kosten, Zeit und Umfang. Jeff Gothelf versucht sich daran das Ganze neu zu denken: da im Rahmen von Continuous Delivery die Teams relativ stabil sind fällt das Budget als potentiell variabler Parameter weg (in der Wissensarbeit sind Gehälter der wesentliche Kostenfaktor), genau wie Zeit (es gibt kein Ende) und Umfang (verändert sich permanent). Als alternativen Fix-Parameter schlägt er ein anzustrebendes Kundenverhalten oder Geschäftsziel vor, als Variablen Parameter das Produkt, bzw. dessen Entwicklung - in der die bisherigen Parameter enthalten sind. Spannend.

Loyale Opposition

Bild: Encyclopædia Britannica - OGL 3.0

Dass es in den Politikwissenschaften nennenswerte Impulse für die Agile Produktentwicklung zu holen gibt, überrascht immer wieder, bei genauerer Bertrachtung ist es aber naheliegend. Die Aufteilung und Neuverteilung von Macht (Weisungsbefugnis, Budgets, Vetorecht, etc.) ist ein politischer Prozess, sowohl in einem Land als auch in einem Unternehmen. Und damit das während einer agilen Transition nicht in Konflikten endet, bedarf es einer besonderen Einrichtung: der loyalen Opposition.

Die Idee der loyalen Opposition stammt aus Grossbritannien, genauer gesagt aus dem britischen Parlament. Ursprünglich hatten hier alle Abgeordneten, die nicht die Regierung unterstützten, unter dem Verdacht gestanden, die vorhandene Ordnung komplett abzulehnen. Dadurch, dass die Opposition sich loyal zu dieser Ordnung erklärte und nur in ihrem Rahmen anders handeln wollte, wurden potentielle Konflikte entschärft und Regierungswechsel unproblematisch.

Übertragen auf Unternehmen und agile Transitionen bedeutet das, dass bestimmte grundlegende Rahmenbedingungen und eingegangene Verpflichtungen nicht ohne weiteres abgeschafft werden dürfen, wenn Macht (Weisungsbefugnis, Budgets, Vetorecht, etc.) an andere Gruppen übergeht. Welche das sind kann von Fall zu Fall anders sein, gegebenenfalls kann es sinn machen sie explizit zu machen, so dass alle Beteiligten das gleiche Verständnis haben.

Die sich daraus ergebende erste Funktion einer solchen loyalen Opposition ist es, die Vorbehalte gegen eine neue Machtverteilung abzuschwächen. Wenn beispielsweise klar ist, dass die Gewinnerzielungs-Absicht nicht in Frage gestellt werden wird, werden Widerstände von Besitzern und Aktionärsvertretern geringer werden, und wenn klar ist, dass Qualitätsstandards und Rechtssicherheit auch weiter für wichtig gehalten werden, werden sich Rechts- und Testabteilungen leichter mit Veränderungen abfinden.¹

Die zweite, häufig unterschätzte Funktion einer Loyalen Opposition ist die Bereitschaft, die nicht ohne weiteres abschaffbaren Teile der vorhandenen Ordnung nicht nur zu tolerieren, sondern aktiv an ihrer Aufrechthaltung mitzuwirken. Um bei den gerade genannten Beispielen zu bleiben: eine Entwicklungseinheit, die nicht von aussen bestimmt werden will muss im Gegenzug selbst bereit sein Profitabilität, Qualitätsstandards und Rechtssicherheit zu gewährleisten.

Natürlich ist der Begriff der loyalen Opposition in den meisten Unternehmens-Kontexten nur eingeschränkt benutzbar, da er zu erklärbedürftig oder wunderlich wirken dürfte, die dahinterstehenden Ideen sind aber einfach zu erklären und sollten dafür sorgen, dass Machtverschiebungen wesentlich konfliktfreier ablaufen als in nicht derartig fundierten Veränderungen.

¹Dass es tatsächlich immer wieder Bestrebungen zur Unterlaufung solcher Standards gibt, hat natürlich wenig mit der eigentlichen Agilität zu tun, ist aber durch den Sog der Addition erklärbar.

Chapter Leads & Group Leads

Bild: Pexels / Yan Krukau - Lizenz

Noch einmal zum Thema der neuen Führungsrollen in einem agiler werdenden Umfeld. Dass bei ihrer Ausgestaltung verhindert werden sollte, dass der disziplinarische Vorgesetzte eines Teams auch dessen fachliche oder methodische Leitung innehat, ist eine Einsicht, die sich immer mehr durchsetzt. Alles andere würde zwangsläufig zu einer (Teil-)Entmachtung des Product Owners oder Product Managers führen, da dieser dann nicht mehr der Einzige wäre, der seinem Team Ziele vorgibt.

Die sich zur Zeit etablierende Rolle des People Managers wird dieser Anforderung gerecht, indem sie in den meisten Fällen völlig aus dem operativen Geschäft herausgelöst wird. Das verhindert zwar Zielkonflikte, die Entkoppelung von der täglichen Arbeit macht es aber für viele People Manager sehr schwer zu erkennen, welche Mitarbeiter sich Versetzungen, Beförderungen oder Gehaltserhöhungen verdient haben und welche nicht (mehr dazu hier).

Manche Unternehmen versuchen daher einen dritten Weg zu gehen. In ihm wird die disziplinarische Führung nur in Teilzeit ausgeübt (zumindest auf den unteren Hierarchie-Ebenen), wodurch weiter ein unmittelbarer Bezug zur eigentlichen Arbeit gewahrt wird. Ausserdem bleibt ein Teil der fachlichen Führung erhalten, aber nicht in Bezug darauf was gemacht wird, sondern wie es gemacht wird (eine wichtige Unterscheidung).

In diesem Modell bleibt auf diese Weise die Entscheidung darüber welche Kundenprobleme gelöst werden oder welche Features gebaut werden (→ die Product Ownership) ausschliesslich beim Product Owner oder Product Manager, die Grundlage auf der die die disziplinarische Führungsrolle über Versetzungen, Beförderungen oder Gehaltserhöhungen entscheidet ist dagegen die Qualität der Arbeit - idealerweise anhand transparenter und im voraus feststehender Kriterien.

In diesem Modell gibt es dann nochmal zwei verschiedene Arten der Ausgestaltung. Eine allgemein übliche Bezeichnung hat sich für sie noch nicht durchgesetzt, um sie hier beschreiben zu können möchte ich aber die Titel aus den vermutlich jeweils bekanntesten Anwendungsfällen benutzen: den Chapter Lead aus dem Spotify Model (ja, ich weiss) und den Group Lead (japanisch Hanchô / 班長) aus dem Toyota Production System.

Chapter Lead

Das entscheidende Erkennungsmerkmal des Chapter Leads ist seine Einordnung in eine Matrix-Organisation. Seine Einheit (das Chapter) arbeitet nicht selbst an einem Produkt oder Feature, sondern besteht aus gleichartigen Spezialisten (z.B. UX, QA oder Kundenservice) die über mehrere produktorientierte Teams verteilt sind. Dieser sehr ähnliche Arbeitsgegenstand aller Chapter-Mitglieder ermöglicht es dem Chapter Lead, gemeinsame Qualitätskriterien zu erstellen (auch teamübergreifend).

Group Lead

Im Umfeld der Group Lead-Rolle sind Ablauf- und Aufbauorganisation identisch, es gibt also keine Matrix-Organisation. Eine Gruppe verantwortet in Gänze ein (Teil-)Produkt, ein Feature oder eine Fertigungsstation, und umfasst alle dafür notwendigen beruflichen Spezialisten. Für den Group Lead bedeutet das, dass er einen besseren Einblick in die Zusammenarbeit der Spezialisten hat als der Chapter Lead, dafür aber schlechter die jeweiligen Einzelleistungen beurteilen kann.

Um es vereinfacht zusammenzufassen: sowohl Chapter Leads als auch Group Leads überlassen die Product Ownership dem Product Owner, bzw. Produktmanager und haben stattdessen die Qualität als ihr Führungsgebiet. Während das bei dem stark spezialisierten Chapter Lead vor allem die Qualität der Arbeitsvorgänge ist, ist es bei dem eher generalistischen Group Lead vor allem die Qualität des jeweiligen (Teil-)Produkts. Beide Ausprägungen haben Vor- und Nachteile, keine ist besser als die andere.

Zur Sicherheit noch ein zweites Mal zur Klarstellung: die beiden hier genutzten Begriffe sind nicht offiziell oder allgemein anerkannt, dass ich sie hier benutzt habe, hat nur den Zweck, zwei Rollen, für die es noch keinen feststehenden Namen gibt, beschreiben zu können. Im Einzelfall können die Benennungen ganz anders sein. Das ist auch unproblematisch, wichtiger als die Bezeichnung ist das Verständnis der dahinterstehenden Ausgestaltungen.

Das ist auch der finale Ratschlag, bzw. das Fazit dieses Artikels: wichtiger als die schönen englischen oder japanischen Namen sind die Gestaltungsparameter: wie kann eine disziplinarische Führungsrolle so gestaltet werden, dass sie die Product Ownership des Product Owner/Produktmanager nicht untergräbt, trotzdem in der Lage ist auf sachlicher Ebene über über Versetzungen, Beförderungen oder Gehaltserhöhungen zu entscheiden und einen für alle klar erkennbaren Verantwortungsbereich hat?

Am Ende muss es nicht zwangsläufig auf eine der beiden hier genannten Varianten herauslaufen, zumindest sind sie aber ein guter Ausgangspunkt für die Neu-Konzeption sinnvoll ausgestalteter Führungsrollen in einem agiler werdenden Umfeld. In vielen Fällen die ich gesehen habe, hätten sich Firmen damit grosse Missverständnisse und Schmerzen ersparen können.

Scrum goes Pop Music (III)

Nachdem ich in der Vergangenheits bereits mehrfach Videos von Chad Beier hier eingebunden habe, habe ich seinen Youtube-Kanal irgendwie aus den Augen verloren. Nachdem er mir jetzt wieder in den Sinn gekommen ist, habe ich dort tatsächlich einige neue "agilisierte" Coverversionen bekannter Popsongs gefunden. Wie immer ein großer Spass.

Virtue Signaling

Bild: Pexels / Polina Tankilevitch - Lizenz

Eines der kurioseren soziologischen Phänomene der letzten Jahre ist das so genannte Virtue Signaling. Hinter diesem Begriff verbirgt sich das demonstrative öffentliche Kommunizieren von Standpunkten die als moralisch gut oder sogar überlegen wahrgenommen werden. Zweck dieser Handlung ist neben der Selbstvergewisserung die Symbolisierung einer Gruppenzugehörigkeit, die Abgrenzung zu anderen, als unmoralisch empfundenen Gruppen und die Beanspruchung einer Diskurs-Dominanz.

Virtue Signaling tritt vor allem im politischen Kontext auf, greift aber auch in der agilen Community um sich, etwa auf Meetups und Konferenzen, in Social Media oder Fachpublikationen. Verbunden ist es hier fast immer mit dem Kampf gegen eine (vermeintliche) Verfälschung und übermässige Kommerzialisierung der Idee der agilen Produktentwicklung, bzw. mit der Positionierung als Bewahrer der (idealisierten) ursprünglichen Absichten und Überzeugungen.

Mit der Zeit haben sich in diesem Zusammenhang einige populäre, stetig wiederholte Standard-Botschaften herausgebildet. Sie alle haben einen realen Kern, sprechen also tatsächliche Good Practices und Antipattern an, definieren sich aber sehr stark durch die Ablehnung bestimmter Missstände, wodurch sie oft von einem eher kritischen oder anprangernden Grundton durchzogen werden und in ihrem Dogmatismus mitunter über das Ziel hinausschiessen können.

Mit dieser Vorrede im Hintergrund - hier sind einige der am häufigsten vorgetragenen "agilen Virtue Signals", samt einer kleinen Einordnung:

Wir haben keinen Prozess, wir verhalten uns einfach vernünftig

Was steckt dahinter? Die Ablehnung der sehr stark ausufernden Prozessbeschreibungen, die SAFe, Disciplined Agile, Scrumstudy und weitere kommerzialisierte Anbieter verfasst haben. Diese werden als im Widerspruch stehend zu Selbstorganisation und Inspect & Adapt wahrgenommen.

Was ist davon zu halten? Die Grundidee mag vernünftig sein, in der Umsetzung stösst sie aber schnell an Grenzen. In jeder Situation neu zu erforschen und zu verhandeln was gerade die beste Lösung ist, selbst wenn es bereits passende Lösungen gibt, wäre verlangsamend und unwirtschaftlich.

Agile ist ein Mindset

Was steckt dahinter? Die Ablehnung der Reduktion von agilem Arbeiten auf spezifische Meetings, Rollen und Anforderungsformate, ohne das nötige Hinterfragen klassischer Welt- und Menschenbilder, die ohne Veränderung auch gutgemeinte Prozesse hierarchisch und kontrollierend umformen können.

Was ist davon zu halten? Ein kontroverses Thema. Für viele Agilisten ist dieser Spruch eine unverrückbare Wahrheit, die sie ständig rezitieren, für andere eine nicht zielführende Verlagerung systemischer Probleme auf die persönliche Ebene. Auf jeden Fall gut für lebhafte Diskussionen.

Kanban ist agiler als Scrum

Was steckt dahinter? Schlechte Erfahrungen mit rigide durchgesetztem und dogmatisch befolgtem Scrum, vor allem in Kontexten in denen Sprints und Sprintziele nur schlecht funktionieren können. Umgekehrt kommen gute Erfahrungen mit den schlanken und flexiblen Kanban-Prozessen dazu.

Was ist davon zu halten? In den meisten Fällen dürften derartige Äusserungen darauf beruhen, dass Scrum falsch (oder an einer nicht passenden Stelle) umgesetzt wurde. Grundsätzlich ist Kanban völlig in Ordnung, es ist aber nicht "Scrum ohne komische Vorschriften" (und beide sind ähnlich agil).

Extreme Programming ist das beste agile Framework

Was steckt dahinter? Zum einen Vergangenheitsverklärung - vor der Kommerzialisierungswelle der 2000er Jahre war XP das dominante Framework. Zum anderen der Ursprung vieler technischer agiler Praktiken in XP, ohne die Agilität (in der IT) nicht funktionieren kann.

Was ist davon zu halten? Wenn wirklich die technische Dimension im Vordergrund steht ist XP tatsächlich eines der besten agilen Frameworks (zumindest in der IT). Man muss sich nur bewusst machen, dass es seit ca. 20 Jahren nicht weiterentwickelt wurde und keinen Skalierungsansatz hat.

Story Points und Velocity gehören nicht zur Agilität

Was steckt dahinter? Die Ablehnung von Cargo Cult-Praktiken. Story Points und Velocity können bei falschem Verständnis die Illusion erzeugen, dass auch in volatilen und komplexen Umgebungen klassische Zeit- und Aufwandsplanung möglich ist. Dieses Missbrauchspotential führt zu einer Komplett-Ablehnung.

Was ist davon zu halten? Zum einen ist es richtig, dass Story Points und Velocity in keinem agilen Framework verpflichtend sind, man sollte aber zwischen Symptom und Root Cause differenzieren. Nicht diese Praktiken sind das Problem, sondern eher die Motive für ihren falschen Einsatz.

SAFe ist nicht agil

Was steckt dahinter? Die Ablehnung von zu umfangreichen oder falsch eingesetzten Regelwerken und Praktiken (siehe oben) und die Ablehnung zu starker Kommerzialisierung, für die SAFe mit seinen jährlich zu erneuernden, teuren Zertifizierungen das bekannteste Beispiel ist (siehe unten).

Was ist davon zu halten? Auch hier wieder: Ein kontroverses Thema. Für viele Agilisten ist die vehemente Ablehnung von SAFe Teil ihres Selbstverständnisses, andere bestehen darauf, auch mit SAFe agil arbeiten zu können (was z.T. sogar stimmen kann). Wie so oft - es kommt darauf an.

Wir machen Wir machen #NoBacklogs / #NoEstimates

Was steckt dahinter? Schlechte Erfahrungen mit zu detaillierten Planungen und dem Schätz-Zwang unschätzbarer Tasks. Aus Sorge, dass selbst gutgemeinte Ansätze zu diesem Zweck missbraucht werden können, kommt es auch hier zu kategorischen Ablehnungen von Planung und Aufwandsschätzung.

Was ist davon zu halten? Wenig, hier wird über das Ziel hinausgeschossen. Backlogs entstehen automatisch sobald unerledigte Arbeit da ist und Aufwandsschätzungen sind selbst dann gegeben wenn man sich fragt ob etwas im nächsten Monat machbar ist. Das zu vermeiden ist unmöglich.

Jira und andere Ticket-Tools sind nicht agil

Was steckt dahinter? Zum einen schlechte Benutzungserfahrungen, wie z.B. die, dass manche agilen Praktiken und Workflows in ihnen nicht abbildbar sind, zum Anderen schlechte Erfahrungen mit zu restiktiver Administration und Berechtigungsvergabe.

Was ist davon zu halten? Wie bei Story Points und Velocity sollte man auch hier zwischen Symptom und Root Cause differenzieren. Jira & Co haben ihre Schwächen (welches Tool hat die nicht?), meistens ist aber der nicht zielführende Einsatz das Problem, nicht das Tool selbst.

Selbst Spotify benutzt das Spotify Model nicht

Was steckt dahinter? Die Erzählung, dass das Spotify Model mit seinen Tribes, Squads, Gilden und Chaptern nur eine temporäre Momentaufnahme aus einer längeren Entwicklung war und nie als Blaupause für andere Organisationen gedacht gewesen ist (obwohl genau das passiert ist).

Was ist davon zu halten? Es kommt darauf an. Wenn man unter dem Spotify Model nur die Matrix-Organisation aus Tribes, Squads und Chaptern versteht, ist sie dort jahrelang im Einsatz gewesen (siehe hier ab Minute 28). Als Blaupause gedacht war sie nie, funktionieren kann sie trotzdem.

LeSS ist das beste agile Skalierungs-Framework

Was steckt dahinter? Erneut die Ablehnung übermässiger Prozesslastigkeit, die in den meisten Skalierungen anzutreffen ist. Das Versprechen von LeSS, Scrum ohne zusätzliche Meetings skalieren zu können, wirkt im Vergleich sehr verlockend.

Was ist davon zu halten? Erneut: es kommt darauf an. Wenn die beteiligten Teams mit einem gemeinsamen Ziel an einem gemeinsamen Produkt in einem gemeinsamen System arbeiten sind LeSS (oder Nexus) sehr zu empfehlen, bei anderen Konstellationen können andere Ansätze besser passen.

Es gibt einen agil-industriellen Komplex

Was steckt dahinter? Die Erkenntnis, dass es einem Grossteil der Schulungs- und Zertifizierungs-Anbieter vor allem um ein sicheres Business Model geht und weniger um bessere Produkte und flexiblere Prozesse, weshalb mitunter auch unnötige Kurse und Zertifikate verkauft werden.

Was ist davon zu halten? Über das Wording kann man streiten, aber das Phänomen ist real. Es gibt eine Schulungs- und Zertifizierungs-Industrie in der aufgrund systemischer Zusammenhänge teure Prüfungs- und Teilnahmebescheinigungen zum Selbstzweck geworden sind.

Die Liste liesse sich sicher noch erweitern, die grundlegende Stossrichtung dürfte aber klar sein, genau wie die sich daraus ergebende Problematik. (Agiles) Virtue Signaling wirkt bewusst polarisierend und z.T. ausgrenzend, zudem beansprucht es die Deutungshoheit über richtig und falsch. Das Führen differenzierter und konstruktiver Diskussionen ist auf dieser Basis sehr schwierig, mit grosser Wahrscheinlichkeit wird diese Art der Gesprächsführung in Konflikten enden (oder in Group Think).

Um die (ja grundlegend richten) Ausgangsüberlegungen besser zu vertreten bieten sich daher andere Vorgehensweisen eher an. Kritischer Rationalismus, Prime Directive und Datengetriebene Validierung lassen sich zwar nicht mit vergleichbarer Emotionalität vertreten, aber genau das ist am Ende auch der Punkt: wer in einer ungewissen und wechselhaften Umgebung versucht bestimmte Ideen als richtig und falsch zu kategorisieren, mag sich zwar moralisch überlegen fühlen, der Realität gerecht werden wird er aber eher nicht.

Fachkräftemangel und Selbstorganisation

Bild: Pexels / Fauxels - Lizenz

Zu den spannenden Fragen im Umfeld der stark auf selbstorganisierte Teams setzenden agilen Frameworks gehört diese: warum ist es vor allem in der Software-Entwicklung zu ihrer starken Verbreitung gekommen, während sie in anderen Branchen bisher eher Ausnahmeerscheinungen sind? Natürlich gibt es Erklärungsansätze, die aber meistens von der selben Prämisse ausgehen - der Komplexität des Arbeitsgegenstandes. Möglicherweise ist der Grund aber ein ganz anderer.

Zum besseren Verständnis kurz eine Erklärung der Arbeitsgegenstand-Hypothese. Sie beruht darauf, dass es sich bei der Softwareentwicklung um eine komplexe Tätigkeit handelt, also um eine, bei der Kleinteiligkeit, Vernetztheit und Volatilität dafür sorgen, dass ständig Neu- und Umgeplant werden muss. Da zentrale Befehls- oder Koordinations-Instanzen dabei zu verlangsamenden Flaschenhälsen werden können, wird angenommen, dass Selbstorganisation die logische Folge ist.

Was diese Annahme in Frage stellt ist ein Blick auf andere komplexe Arbeitskonstellationen. Z.B. unterliegen auch Filmproduktionen, Nachrichtenredaktionen und Spitzengastronomie den Faktoren Kleinteiligkeit, Vernetztheit und Volatilität, trotzdem ist Selbstorganisation in ihnen eher selten. Regelmässig aufkommende Skandale zeugen sogar vom Gegenteil: Macht-Zentralisierung (und Machtmissbrauch) sind weit verbreitet und werden stillschweigend geduldet.

Der zentrale Unterschied, der die IT-Branche von den gerade genannten (und vielen anderen) Branchen unterscheidet, ist der Fachkräftemangel. Während es auf dem Arbeitsmarkt ein deutliches Überangebot an Schauspielern, Kameraleuten, Journalisten und Köchen gibt, sind Softwareentwickler selten und schwer zu kriegen. Und selbst dort, wo es gelingt die freien Stellen zu besetzen, geschieht das häufig nur durch externe Dienstleister und Freiberufler.

Die sich daraus ergebenden Folgen kann sich jeder vorstellen: wer froh sein muss, einen von wenigen gut bezahlten Jobs ergattert zu haben, wird gegenüber seinem Vorgesetzten ein eher unterwürfiges Verhalten an den Tag legen, um ihn möglichst lange ausüben zu können. Und das sogar dann, wenn die Behandlung die man erfährt bestimmend, micro-managend oder sogar missbrauchend ist (in den oben verlinkten Artikeln sind z.T. verstörende Details zu lesen).

Umgekehrt wird jemand der nicht nur in kurzer Zeit sondern auch in der näheren Umgebung jederzeit eine neue, gleich gut bezahlte Anstellung finden kann, sich wenig gefallen lassen und im Zweifel durch eine Abstimmung mit den Füssen dafür sorgen, dass dominante Vorgesetzte bald niemanden mehr haben, den sie im Detail managen können. Und da jeder Manager das weiss wird er seinen Untergebenen bereits vorauseilend möglichst grosse Freiheiten gewähren.

Auch im Rahmen grosszügig gewährter Freiheiten muss aber sichergestellt sein, dass Kunden- und Unternehmens-Interessen und Gesetze gewahrt werden. Und da eine Erzwingung von oben die kostbaren Fachkräfte verschrecken könnte, ist die Gewährung von Selbstorganisation oft der beste Weg um zur Einhaltung dieser Vorgaben zu kommen - ihre Umsetzung wird einfach in die Verantwortung von selbstorganisierten Teams übergeben.

Um Missverständnisse zu vermeiden: damit soll nicht gesagt sein, dass die Annahme falsch ist, dass komplexe Herausforderungen am besten durch selbstorganisierte Teams gemeistert werden können. Vieles spricht dafür, dass das tatsächlich der Fall ist. Der tatsächliche Grund für die Zulassung und Förderung von selbstorganisiertem Arbeiten ist aber sehr oft eher darin zu finden, dass Jobs in den Mangelberufen der IT attraktiv ausgestaltet werden sollen.

Dass agile Frameworks wie Scrum & Co in der Softwareentwicklung derartig stark verbreitet sind, dürfte daher ganz wesentlich mit dem dort vorherrschenden Fachkräftemangel zu tun haben, und nicht nur mit dem Arbeitsgegenstand. Und jeder Versuch, derartige Arbeitsweisen in Bereichen mit Arbeitskräfte-Überschuss einzuführen, wird nur dann erfolgreich sein, wenn dort der Missbrauch von Abhängigkeitsverältnissen konsequent und frühzeitig verhindert wird.

Lean-Metriken (III)

Grafik: Wikimedia Commons / Daniel Penfield - Public Domain

Dritter Teil der Übersicht über die Lean-Metriken. Nach einer allgmeinen Übersicht über die Typen von Durchlaufzeiten im ersten Teil (zu finden hier) und die einer Einführung in die Flusseffektivität im zweiten Teil (zu finden hier) soll es heute um die Flusseffizienz gehen. Um diese ähnlich klingenden Begriffe zu unterscheiden: während es bei der Effektivität darum geht die eigenen Tätigkeiten auf Sinnhaftigkeit zu optimieren (→ wenig Waste) hat Effizienz die Leistungsfähigkeit als Ziel (→ hoher Ausstoß). Zu beachten ist dabei natürlich, dass beides angestrebt werden sollte, hier soll es aber jetzt nur um Metriken für die Flusseffizienz gehen.

Takt Time

Die Takt Time bezeichnet die (anzustrebenderweise) immer gleich bleibende Zeit die zur Fertigstellung eines Liefergegenstandes benötigt wird, beispielsweise die 30 Sekunden die für einen Stanz- oder Fräs-Vorgang nötig sind. Eine der Lean-Metriken die nur schwer in die Software-Entwicklung übertragbar sind, wenn überhaupt eher auf automatisierte Prozesse als auf Programmiertätigkeiten.

Throughput Time

Auf Deutsch der Durchsatz. Bei ihm wird nicht mehr die Dauer einzelner Arbeitsvorgänge gemessen, sondern die Anzahl der erzeugten Ergebnisse (Produkte, Features, etc.) pro Zeiteinheit. Ein Beispiel wären 500 Autos die pro Tag in einer Fabrik gebaut werden. Aus dem Versuch die Throughput-Messung in die Software-Enwicklung zu übertragen ist das Konzept der Velocity entstanden.

Maintenance Time

Eine Metrik die leicht für einen Teil der Blocked Time gehalten werden kann, da Maintenance (Wartung) ähnlich wie diese dafür sorgt, dass die eigentliche Arbeit nicht stattfinden kann. Die Differenzierung: statt die Gesamtzeit der Nichtverfügbarkeit zu messen geht ist hier um die Durchschnittsdauer eines Wartungsintervalls, die idealerweise möglichst kurz sein sollte.

Recovery Time

Dieser Metriken-Typ ist von Bedeutung wenn es trotz Wartungen zu unfallbedingten Ausfällen kommt und misst die Durchschnittsdauer der Reparaturen und und der anschliessenden Wiederinbetriebnahme. Diese Dauer möglichst kurz zu halten ist nochmal wichtiger als bei der Maintenance Time, da das Eintreten von Zwischenfällen und Recovery-Phasen meistens unvorhersehbar und nicht planbar ist.

Flusseffizienz

Sowohl in Bezug auf die Produktion von Ergebnissen (Produkte, Features, etc.) als auch in Bezug auf Wartungen und Wiederinbetriebnahmen ist es das Ziel, die durchschnittliche Erstellungs- oder Bearbeitungszeiten so kurz wie möglich zu halten. Mit Hilfe der hier genannten Metriken darauf zu optimieren ermöglicht eine höhere Effizienz im Arbeitsfluss, die aber nicht ohne Risiko ist.

Eine ausschliessliche Fixierung auf Flusseffizienz macht vor allem in der Serienfertigung Sinn, in der Produktentwicklung besteht das Risiko, dass man in der Build Trap landet, also versehentlich das Falsche produziert, davon aber sehr schnell sehr viel. Hier solte also regelmässig überprüft werden, ob man noch immer in der richtigen Richtung unterwegs ist.

Der Scrum Master als Impediment (II)

Bild: Pixabay / Robin Higgins - Lizenz

Um es vorwegzunehmen: ich bin grosser Fan von Scrum im Allgemeinen und von der Rolle des Scrum Masters im Besonderen. Wie aber bei allen guten Ideen gibt es aber leider auch hier die Möglichkeit, sie so umzusetzen, dass sie eher schadet als nützt. Das kann schon bei der Ausgestaltung und Besetzung der Rolle beginnen (siehe hier), es kann aber auch sein, dass der Rollen-Inhaber sich (ggf. unbewusst) kontraproduktiv verhält. Um einen solchen Fall soll es hier gehen.

Ein Verhaltensmuster, das immer wieder zu beobachten ist, ist dass der Scrum Master bestimmte Tätigkeiten auf sich monopolisiert. Das kann auf den ersten Blick sinnvoll erscheinen, da die Absicht dahintersteckt das Team zu entlasten oder zu beschützen, im Ergebnis führt ein solches Verhalten aber meistens zu Flaschenhälsen in der Kommunikation, zu Unselbstständigkeit des Teams und zur Errichtung von Barrieren zwischen Menschen die eigentlich zusammenarbeiten sollten.

Der Klassiker unter diesen Monopolisierungen betrifft die Moderation der Meetings. Obwohl im Scrum Guide nicht vorgegeben ist, wer die Moderatoren-Rolle einzunehmen hat, wird sie in gefühlt 99 Prozent der Fälle vom Scrum Master übernommen. Dafür gibt es auch Gründe (der einfachste ist der, dass er es am besten kann), die Konsequenz ist aber häufig, dass in seiner Abwesenheit die Termine ausfallen, unstrukturiert ablaufen oder einen externen Moderator brauchen. Alles nicht im Sinn der Idee.

Ebenfalls problematisch ist die Monopolisierung des Impediment-Lösens. Auch hier ist die Absicht meistens eine gute: die anderen Teammitglieder sollen sich auf ihre Arbeit konzentrieren können und für die Stakeholder soll ein durchgehender Ansprechpartner da sein. Das Ergebnis sind aber häufig stille Post-Effekte und verlangsame Kommunikation, da die von Problemen betroffenen Personen und die, die es lösen können nicht mehr in direktem Kontakt sind.

Ein dritter Problemfall tritt auf, wenn die Koordination zwischen den Teams vor allem über deren Scrum Master läuft, z.B. wenn nur sie an einem Scrum of Scrums teilnehmen, neben dem es keine anderen gemeinsamen Kommunikations-Gelegenheiten gibt. Stille Post-Effekte und verlangsame Kommunikation sind auch in diesem Fall wahrscheinlich und werden oft dadurch verstärkt, dass die Scrum Master keinen technischen Hintergrund haben.

Die Lösung für diese (und viele weitere) Probleme ist es, gezielt nach den Themen zu suchen, die bisher ausschliesslich beim Scrum Master liegen und dafür zu sorgen, dass auch andere Mitglieder des Scrumteams Übung darin bekommen, sie zu übernehmen. Das ist am Einfachsten möglich bei der Meeting-Moderation, relativ einfach bei den teamübergreifenden Abstimmungen und am schwierigsten bei der Impediment-Lösung. Möglich ist es aber in allen Fällen.

Zuletzt noch zu möglichen Gegenargumenten. Anders als häufig angenommen wird gibt der Scrum Guide nicht vor, dass bestimmte Themen ausschliesslich dem Scrum Master zugeordnet sind. Um die häufigsten Missverständnisse zu nennen - "ensuring that all Scrum events take place" bedeutet eben nicht, dass er sie alle moderiert (im Daily ist nichtmal seine Anwesenheit nötig), und "causing the removal of impediments" bedeutet eben nicht, dass er sie alle selbst beseitigt.

Auch das Argument, dass die Übernahme von Meeting-Moderation, Impediment-Lösungen und übergreifender Kommunikation die Team-Mitglieder von ihrer "eigentlichen Arbeit" abhält, ist mindestens fragwürdig. In Scrum sind "self-management and cross-functionality" explizit für das gesamte Team vorgesehen, eben um zu verhindern, von einzelnen Personen abhängig zu sein. Die (scheinbaren) Scrum Master-Aufgaben zu übernehmen gehört also explizit zur Arbeit dazu.

Natürlich muss man diese Ansichten nicht teilen, man kann auch der Meinung sein, dass es effizienter oder effektiver ist, derartige Aufgaben vom Team fernzuhalten. Der Punkt ist aber: selbst wenn man das aus dem besten Willen heraus tut, wird man sehr schnell in einen Widerspruch zu den Regeln von Scrum geraten. Und jemand, der die Regeln von Scrum unterläuft oder aufhebt, ist per Definiton ein Impediment, selbst dann wenn diese Person der Scrum Master ist.

Practical Project Aristotle

Ich bin mir ziemlich sicher, dass ich irgendwann mal etwas über das Arisoteles-Projekt von Google geschrieben habe, eine Studie mit 180 teilnehmenden Teams, deren Ergebnis war, dass Hochleistung vor allem dann möglich ist, wenn die folgenden Dinge gegeben sind: Psychologische Sicherheit, Verlässlichkeit der Kollegen, Struktur und Klarheit der Ziele, Sinnhaftigkeit der Arbeit und Selbstwirksamkeitserwartung. Ich finde meinen Text gerade nicht, daher ist es um so besser, dass Talia Lancaster einen Vortrag zu dem Thema gehalten hat, den man sich ansehen kann.

Der Vortrag fasst dabei nicht nur die Ergebnisse des Aristoteles-Projekts zusammen, sondern zeigt auch auf wie im eigenen Unternehmen überprüft werden kann ob die verschiedenen Faktoren gegeben sind. Man kann sich also direkt für eine eigene Anwendung inspirieren lassen.

Der Endspurt

Bild: Pexels / Fauxels - Lizenz

Team, der Sprint ist fast zu Ende
Seht den Burndown, wie er brennt
Bald schon woll’n wir fertig werden
Stellt es her, das Inkrement

Integriert den Code auf PreProd
Bringt die Build Pipeline zum Glüh’n
Führt die letzten Code Reviews durch
Haltet mir den Master grün

Bringt die Features auf Production
Testet schnell in Regression
Aktiviert das Feature Toggle
Uns’re Nutzer warten schon

Baut ein Dashboard! Ein A/B-Test
Wird uns helfen, klar zu seh’n
Ob die Menschen uns’re Features
Finden, mögen und versteh’n

Und mit diesem bess‘ren Wissen
Was der Nutzer Wünsche sind
Soll ein neuer Plan entstehen
Für den neuen, nächsten Sprint

***

Wer erkennt, von welchem klassischen Gedicht dieses kleine Werk inspiriert ist, darf sich melden, ich gebe dann einen aus