Kommentierte Links (LXXXVI)

Bild: Pixabay / Buffik - Lizenz

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

Jeff Gothelf: Horizontal IT is Why You Can’t Be Agile

Es ist ein immer wiederkehrendes Muster. Ein Kozern beschliesst agil zu werden, organisiert seine IT nach Scrum, SAFe oder "Spotify", schaut sich nach einiger Zeit das Ergebnis an und stellt fest, dass alles genauso langsam und unflexibel ist wie früher. Jeff Gothelf zeigt einen der häufigsten Gründe dafür auf: eine IT-Organisation in der verschiedene Business-Einheiten jeweils eine einzige gemeinsame IT-Einheit beauftragen. Die Folge sind Customer-Vendor-Antipattern, Flaschenhälse, Priorisierungskonflikte und ähnliche Misstände, die in Summe alles so stark verlangsamen, dass ein effektiverer Arbeitsmodus der Entwicklungsteams das nicht kompensieren kann.

John Cutler: The Basics

"Ich bin ja kein Prozess-Fanatiker, aber ein paar Grundlagen sollten schon da sein". Was bei anderen Menschen Overprocessing-Alarmglocken auslösen sollte hat bei John Cutler Hand und Fuss. Die folgenden Basics braucht es seiner Meinung nach für zielgerichtetes Arbeiten:

An Agile Rap

Wenn Du etwas zu sagen hast, sag es mit Musik! Das haben sich anscheinend auch Maria Matarelli, Alistair Cockburn und Mark Lombardi-Nelson gesagt. Das Ergebnis ist dieses Musikvideo, dank dem wir jetzt einen weiteren Punkt auf unserer grossen To Do-Liste der agilen Kuriositäten abhaken können: wir haben einem der Autoren des Agilen Manifests beim Rappen zugehört.

Wie bei einem derartigen Spassprojekt nicht anders zu erwarten wird es vermutlich nicht ganz für einen Musikpreis oder eine Chartplatzierung reichen, der Aufnahme- und Video-Qualität merkt man aber an, dass sich hier jemand mit der Technik auskannte. Vermutlich ist es Maria Matarelli, die eine bemerkenswerte Doppelkarriere als Scrum Trainer und professioneller DJ verfolgt.

Scaled Agile: Large Scale Scrum (LeSS)

Grafik: Less.works - CC BY-NC-ND 2.0

Wenn es um die Skalierungsframeworks für Scrum geht sind es in den letzten Jahren vor allem drei die immer wieder genannt werden. SAFe, das vor allem in Konzernen immer populärer wird, sowie Nexus und Scrum@Scale, die den Vorteil haben, dass jeweils einer der beiden Urheber von Scrum hinter ihnen steht. Tatsächlich gibt es aber noch ein weiteres: Large Scale Scrum (abgekürzt LeSS), das 2005 entwickelt wurde und damit sogar deutlich älter ist als die drei anderen.¹

Diese Kombination aus relativ geringer Bekanntheit und relativ weit zurückliegender Entstehung hat dazu geführt, dass selbst unter den Skalierungs-erfahrenen Scrum Mastern und Agile Coaches viele sind die eine bestenfalls wolkige Vorstellung von diesem Framework haben. Je nachdem wen man fragt kann es als z.B. sehr schlank oder sehr umfangreich, als Teil des eigentlichen Scrum-Frameworks oder als separate und inhaltlich erkennbar abweichende Variante beschrieben werden.

Am schnellsten lässt sich die zuletzt genannte Unklarheit aufklären. LeSS war mal de facto ein Teil des offiziellen Scrum, hat sich aber mit dessen Versionen von 2017 und spätestens 2020 von ihm gelöst. Wesentliche neue Teile wie das Produkt-Ziel wurden nicht übernommen, gestrichene Teile wie die verpflichtenden drei Fragen im Daily wurden dagegen beibehalten. LeSS ist damit auch nach eigener Auffassung zu einer weiteren Variante geworden, die inhaltlich erkennbar eigenständig ist.

Komplizierter ist es bei der Frage wie schlank das LeSS-Framework ist. Von der Grund-Idee ist es sehr schlank, es basiert auf den Skalierungs-Aspekten die ohnehin im offiziellen Scrum-Guide stehen: wenn mehrere Teams an einem gemeinsamen Produkt arbeiten haben sie ein gemeinsames Product Backlog, einen gemeinsamen Product Owner und eine gemeinsame Definition of Done. Plannings und Reviews sind jeweils Team-übergreifend, neue Rollen und Termine werden vermieden.²

In den Büchern und auf der Website finden sich allerdings noch umfangreiche weitere Inhalte. Zugrundeliegende Prinzipien, notwendige Vorbedingungen in der Aufbau- und Ablauforganisation, Ausführungen zur Rolle des Managements, notwendige agile Praktiken der Software-Entwicklung und Anleitungen für die initiale Methodeneinführung werden hier beschrieben, in Summe kommen so mehrere hundert Seiten Text zusammen.

Die Frage ist jetzt ob diese erweiterten Inhalte als Teil von LeSS gesehen werden oder nicht. Wenn nicht ist es tatsächlich ein sehr schlankes Framework, dessen Regeln ähnlich wie die von Scrum selbst auf wenigen Seiten zusammenfassbar sind. Sind sie dagegen Teil von ihm kommt ein Gesamt-Umfang zu Stande der vermutlich zur Zeit nur noch von SAFe übertroffen wird. Entscheidend ist die eigene Interpretation, eine klare Trennung zwischen einem "LeSS-Guide" und Good Practices gibt es nicht.

Aus diesen Klärungen ergeben sich auch Implikationen für die Umsetzung. Firmen in denen für bereits nach Scrum arbeitende Teams nach einem Skalierungsframework gesucht wird sollten sich die Eigenständigkeit von LeSS bewusst machen und sich fragen wie wohl sie sich mit dem parallelen Einsatz von zwei verschiedenen Scrum-Varianten fühlen würden.³ Ist das unbedenklich kann LeSS eine interessante Option sein, da es keine zusätzlichen Rollen und Meetings erfordert.

Auch neu mit Scrum startenden Unternehmen sollte der Unterschied zum offiziellen Scrum bewusst sein, allerdings gibt es für sie ein weiteres klares Argument für LeSS: mit seinen umfangreichen Beschreibungen der notwendigen Vor- und Rahmenbedingungen geht LeSS weit über den Scrum Guide hinaus und macht die notwendigen Umstellungen in der Gesamt-Organisation besser erkennbar. Das erfordert grössere Anstrengungen, verhindert aber Optimierungen die nur lokale Effekte haben.

Für alle denen diese Vorgaben zu weit ins Detail geht und die gleichzeitig mit dem offiziellen Scrum kompatibel bleiben wollen gibt es übrigens mit Nexus eine Alternative die LeSS sehr ähnlich ist aber einen geringeren Umfang hat⁴ und auf dem aktuellen Scrum Guide aufbaut. Letztendlich gilt aber auch für beide das Urteil des Dodo: wenn sie auf den gleichen Absichten und Erkenntnissen aufbauen werden sie auch ähnliche Ergebnisse mit sich bringen.

Die Diktatoren-Falle

Bild: Wikimedia Commons / Museo del Templo de Santo Domingo de Guzmán - Public Domain

Ein Blick über den Telerrand kann interessante Inspirationen bringen. Auf The Atlantic schreibt Brian Klaas über die Dictator Trap, hinter der sich verbirgt, dass die Inhaber bedeutender Machtpositionen gefährdet sind die Realität nur noch gefiltert wahrnehmen zu können, mit schlechten Entscheidungen als Folge. Was beim Lesen ins Auge fällt: vieles von dem was Klaas hier beschreibt trifft auch auf Manager in grossen Firmen zu.

Um mit einem Disclaimer anzufangen: natürlich ist nicht jeder Manager ein Autokrat, es gibt auch solche die einen jener Führungsstile pflegen die als "lateral", "partizipativ" oder "auf Augenhöhe" bezeichnet werden. Sehr viele setzen aber in ihrer Berufsausübung stark auf einsame Entscheidungen, Einweg-Kommunikation, direktive Führung und Absonderung von der "Ausführungs-Ebene".¹ Um diese zweite Gruppe soll es hier gehen.

Wie so häufig steht auch hier am Anfang eine rationale Entscheidung: wer neu in eine zentrale Position aufgerückt ist will sich meistens mit Mitstreitern umgeben die die eigenen Ziele und Überzeugungen teilen, umgekehrt macht es Sinn sich von Menschen mit gegenläufigen Zielen und Ansichten zu trennen.² Das sorgt zu Beginn für grössere Handlungsfähigkeit, steigert aber das Risiko, dass Group Think entsteht und auch relevante abweichende Einwände unter den Tisch fallen.

Selbst dort wo sogar die ähnlich denkenden Unterstützer der Meinung sind, dass eine getroffene Entscheidung falsch ist, wird Widerspruch mit der Zeit immer weniger stattfinden. Wenn die eigene Karriere auf das Wohlwollen des Chefs angewiesen ist, ist es naheliegend von jetzt an dessen Ansichten zu den eigenen zu machen. Und für den der das irgendwann mit seinen Überzeugungen nicht mehr vereinbaren kann ist es naheliegend zu gehen und bei einem anderen Förderer Karriere zu machen.

Auch das lässt sich aber noch steigern. Wenn falsche Entscheidungen an der Spitze zu Misserfolgen geführt haben kann es sein, dass diese aus Angst um die eigene Karriere oder als Loyalitätsbeweis verschwiegen oder umgedeutet werden - die fehlgeschlagene System- oder Methodenumstellung wird dann nach oben als Erfolg reportet, im Zweifel durch kreative Auslegung und selektive Nutzung von Daten oder Ergebnissen.³ Ein Phänomen das häufiger ist als man denken sollte.

Die Diktatoren-Falle ist damit zugeschnappt. Der Manager an der Spitze hat aus seiner Sicht alles richtig gemacht - sich mit Unterstützern umgeben und diejenigen unter ihnen gefördert die Erfolgsmeldungen statt ständiger Bedenken vorgetragen haben. Das Ergebnis ist aber eine Abkoppelung von der Realität. Probleme und Fehlschläge werden verschwiegen, Erfolge aufgebauscht oder künstlich konstruiert. Und wenn dieses Konstrukt irgendwann zusammenbricht ist es für ihn überraschend.

Um dieser Situation zu entgehen gibt es verschiedene Wege. Einer besteht darin, sich bewusst mit einigen kritischen Geistern zu umgeben, die auch dezidiert abweichende Meinungen vertreten. Das kann zwar die Tendenz zum Groupthink aufbrechen, führt aber häufig dazu, dass nur wenige "Hofnarren" das Recht haben unsanktioniert zu widersprechen, während die Dysfunktionen in der umgebenden Organisation erhalten bleiben.

The agile Bookshelf: Team Topologies

Bild: Pexels / Huy Chien Tran - Lizenz

Bevor es zu seinem Inhalt geht eine Vorbemerkung: das Schöne an diesem Buch ist, dass es selbst so entstanden ist wie agile Produktentwicklung idealerweise ablaufen sollte - iterativ-incrementell. Angefangen hat alles mit einem Blog-Post, weiter ging es mit einer Website, mehr und mehr Inhalte kamen über die Zeit dazu und irgendwann waren es so viele, dass sich der Buchdruck gelohnt hat. Um das so entstandene Werk soll es hier gehen, Team Topologies von Matthew Skelton und Manuel Pais.

Aufgeteilt ist es in drei grosse Abschnitte. Im ersten gehen die beiden Autoren auf die Faktoren ein die die Arbeit von Teams in grösseren Firmen typischerweise beeinflussen. Dazu gehört ganz zentral die Aufbau-Organisation mit ihren Ressorts, Bereichen, Abteilungen und ähnlichen Untereinheiten. Diese sind in der Regel anhand von beruflichen Spezialisierungen geschnitten (z.B. Konzeption, Entwicklung, Test) und behindern so eine ganzheitliche Sicht der Wertschöpfung.¹

Als zusätzliche Dimension dieser Aufbau-Organisation kommt dazu, dass sich üblicherweise auch die Kommunikationsströme an diesen Stukturen ausrichten, und zwar auch dann wenn direkte Kommunikation effektiver und schneller wäre. Da diese Kommunikationsströme meistens auch die Strukturierung der internen IT-Systeme vorgeben (das so genannte Conway's Law) tendieren auch diese dazu eher lokal optimiert zu sein, schlimmstenfalls auf Kosten des Gesamtsystems.

Zu den häufigen Folgen eines derartigen Organisations- uns Systemdesigns gehören zwei folgenschwere Missstände: erstens eine hohe kognitive Belastung der Teams, die dadurch entsteht, dass sie sich gleichzeitig mit (zu) vielen Aufgaben, Abhängigkeiten und Informationen beschäftigen müssen, zweitens die Verlangsamung vieler Vorgänge durch die zahlreichen Abhängigkeiten, durch die fast jedes der (zu) spezialisierten Teams früher oder später zu einem Flaschenhals für die anderen wird.

Als Gegenentwurf definieren Skelton und Pais im zweiten Abschnitt ihres Buchs vier grundlegende Team-Typen, die je nach Kontext gewählt (und später wieder verändert) werden können um eine optimale Balance zwischen möglichst wenigen Abhängigkeiten auf der einen Seite und möglichst geringer kognitiver Belastung auf der anderen Seite zu ermöglichen. Die vier Typen sind Stream-aligned Team, Enabling Team, Complicated Subsystem Team und Platform Team.

Die für die Wertschöpfung beste Variante ist die erste der vier, das Stream-aligned Team, das alle Tätigkeiten entlang der gesamten Wertschöpfungskette selbst ausüben kann, inclusive der Bereitstellung der Infrastruktur und des Betriebs auf Produktion. Die anderen drei Team-Varianten machen vor allem dort Sinn wo Stream-aligned Teams von besonders aufwändigen Teilaufgaben entlastet werden können, sie arbeiten diesen also zu und richten sich an ihnen aus.

Enabling Teams bestehen dabei aus Spezialisten für ein bestimmtes Thema, die dieses aber nicht monopolisieren oder regulieren sondern stattdessen anderen helfen in ihm besser zu werden. Complicated Subsystem Teams übernehmen Entwicklung und/oder Betrieb besonders spezialisierter oder komplizierter Software-Komponenten, die sie anderen zur Verfügung stellen, Platform Teams machen Werkzeuge und Infrastrukturen so verfügbar, dass andere sie einfach nutzen und konfigurieren können.

@tom_geraghty puts together a summary of the main points from the 2021 State of DevOps Report highlighting top take aways including how #TeamTopologies can help to improve flow.#DevOps #SODOR2021
https://t.co/IWnUYSEbe1 pic.twitter.com/qq8FW1pFra

— Team Topologies (@TeamTopologies) August 25, 2021

Im dritten Abschnitt des Buchs werden schliesslich drei möglichst effektive Kooperationsformen zwischen den Teams beschrieben. Es sind Collaboration Mode, in dem vonenander unabhängige Teams auf ein gemeinsames Zeil hinarbeiten, X-as-a-Service Mode, in dem ein Team dem anderen Komponenten, Werkzeuge und Infrastrukturen bereitstellt und Facilitation Mode, in dem ein Team dem anderen hilft Expertise und Erfahrung in einem Wissensgebiet zu entwickeln.

Natürlich gehen Matthew Skelton und Manuel Pais an vielen Stellen noch deutlich tiefer in die Details, zeigen Zusammenhänge, Kontextinformationen und Risiken auf und weisen auf Good Practices und Fallstudien hin. Auch die Informationsgrafiken sind so gut, dass sie es viedient haben hier gesondert erwähnt zu werden. Im grossen und Ganzen ist der Inhalt des Buches aber der hier beschriebene (es zu kaufen lohnt natürlich trotzdem).

Für die Umsetzung der in ihm stehenden Team- und Zusammenarbeitstypen geben die beiden schliesslich noch einen entscheidenden Ratschlag mit. Das Ganze ist nicht gedacht als Analyse-Werkzeug, mit dem man die "historisch gewachsene" Ist-Situation beschreibt sondern als Baukasten für bewusstes und regelmässiges Organisations-(Re)Design, mit dessen Hilfe die eigene Firma immer wieder optimiert und auf neue Rahmenbedingungen angepasst werden kann. Ganz im Sinn eines kontinuierlichen Verbesserungsprozesses.

Teamübergreifende Dailies

Bild: Unsplash / Parabol - Lizenz

Wenn mehrere agil arbeitende Teams merken, dass sie häufigen Austauschbedarf haben, ist in den meisten Fällen die Einrichtung eines gemeinsamen Daily Meeting die Folge, in dem ein tagesaktueller Austausch zu Neuigkeiten, Abhängigkeiten und gemeinsamem Vorgehen möglich ist. Derartige teamübergreifende Dailies sind die früheste und einfachste Form der agilen Skalierung, aber bereits eine die in verschiedenen Varianten durchgeführt werden kann. Da diese jeweils verschiedene Vor- und Nachteile haben lohnt es sich kurz zurückzutreten und sie nebeneinander zu betrachten.

I. Sequentielle Team-Dailies mit "Scouting"

Die einfachste Variante. Alle Team-Dailies finden nacheinander statt (idealerweise in einem Raum oder in einem gemeinsamen Call), so dass jedes Team einen Vertreter (oft "Scout" genannt) bestimmen kann, der bei den jeweils anderen teilnimmt. Der Vorteil dieses Vorgehens ist, dass so keine neuen Meetings entstehen, der Nachteil, dass sich das Scouting bei mehreren Teams sehr in die Länge ziehen kann. Scouting wird u.a. im Skalierungs-Framework LeSS empfohlen.

II. Ein übergreifendes Daily vor den Team-Dailies

Ein eher seltener Ansatz. Die Grundidee hier ist es, Informationen zusammenzutragen die für die danach folgenden Team-Dailies wichtig sind, wie z.B. die Ergebnisse nachts durchlaufender Regressionstests. Das kann Sinn machen, die Schwierigkeit dabei ist aber, dass neue Inputs aus den Team-Dailies erst mit einem Tag Verspätung in die grosse Runde kommen. Ein typisches Umfeld für diese früh stattfindenden übergreifenden Dailies ist das Skalierungs-Framework Nexus.

III. Ein übergreifendes Daily nach den Team-Dailies

Der Klassiker. Der Austausch über das was in den Teams kurz vorher als übergreifend wichtig erkannt wurde ist unter dem Namen "Scrum of Scrums" in vielen Firmen anzutreffen und gehörte zu den ersten Skalierungselementen von Scrum die erfunden wurden, noch vor den Skalierungs-Frameworks. Der Vorteil ist, dass Erkenntnisse aus den Team-Dailies schnell verbreitet werden, es besteht aber das Risiko, dass auch vieles aus den Teams berichtet wird, was keine übergreifende Relevanz hat.

IV. Mehrere Spezialisten-Dailies

Ein Vorgehen das z.B. im Skalierungsframework Scrum@Scale zu finden ist. Nach den Daily Scrums der Teams folgen hier die der Product Owner und der Scrum Master, möglich sind auch die der Frontend-Entwickler, der Tester, etc., etc. Der Überblick der in solchen Runden entsteht ist sehr spezifisch, zur Verbreitung eigentlich irrelevanter Informationen kommt es seltener. Dafür besteht das Risiko, dass es an keiner Stelle zu einem Gesamtbild kommt sondern überall nur Ausschnitte sichtbar sind.¹

Welche dieser Varianten die am besten passende ist dürfte von Fall zu Fall unterschiedlich sein und sich möglicherweise sogar über die Zeit ändern. Um die passende zu finden bieten sich zwei Vorgehensweisen an: initial kann man sich fragen welchen Zweck das teamübergreifende Daily überhaupt haben soll, oft ergibt sich daraus schon ein Hinweis auf den passenden Modus. Sobald die Termine stattfinden kann man in den Inspect & Adapt-Modus übergehen, überprüfen ob sie den erhofften Mehrwert bringen und ggf. neues ausprobieren.

Nur von einem ist abzuraten: dem "Reporting-Daily" für das Management. Die gehen soweit an der Idee selbstorganisierter Teams vorbei und laden so stark zum Micro-Management ein, dass man sie gar nicht erst einführen sollte.

Don't Scale, Descale

Ich bin begeistert. Darren Yeates hat es geschafft in diesem Vortrag genau das zu sagen was auch ich allen Menschen mitzugeben versuche, die mich danach fragen wie sie Agilität bei sich im Unternehmen skalieren sollten. Verkürzt gesagt: frage Dich zuerst ob Du es nicht auch ohne Skalierung erreichen könntest, sei Dir bewusst, dass es auch ein kulturelles Thema ist, pass gut auf ob Du nicht versehentlich Missverständnisse skalierst.

Was sich mir nicht völlig erschliesst ist lediglich der Untertitel "Electile Dysfunction". Offensichtlich ist es eine Anspielung auf "Erectile Dysfunction", mein Englisch reicht aber nicht aus um zu erkennen was damit gemeint ist.

Psychologische Sicherheit (II)

Bild: Pexels / Monstera - Lizenz

In der agilen Community (und weit darüber hinaus) ist die psychologische Sicherheit mittlerweile eines der am häufigsten genannten Konzepte die zur Förderung von Feedback- und Fehlerkultur grundlegend sind. In den allermeisten Fällen wird sie auch auf einer abstrakten Ebene richtig beschrieben, es ist die Gewissheit aller Mitglieder einer Gruppe ihre Meinung zu kritischen Themen äussern zu können ohne Angst haben zu müssen persönlich angegriffen oder an den Pranger gestellt zu werden.

Durch welche Faktoren dieser Zustand zustande kommen oder verhindert werden kann wird dagegen bereits seltener thematisiert, und wenn doch dann sehr häufig reduziert auf Verhaltensempfehlungen, sowohl für Mitglieder von Teams als auch für Manager. Um nicht falsch verstanden zu werden, diese meisten dieser Empfehlungen sind gut, sie lassen aber einen wichtigen vorgelagerten Schritt aus - verfügt die Gruppe überhaupt einen Raum in dem sie sich psychologisch sicher austauschen kann?¹

Bereits für den Psychologen William A. Kahn, der 1990 in einem seiner Artikel den Begriff zum ersten mal verwendete,² war dieser Aspekt einer der entscheidenden. Die Möglichkeit sich dorthin zurückzuziehen wo nur diejenigen zuhören und zusehen konnten in deren Anwesenheit die psychologische Sicherheit gegeben ist war für ihn ein zentraler Faktor. Dort wo das nicht möglich war fühlten die Beteiligten seiner Studien sich unsicher und überwacht.

The physical office space starkly symbolized the ways that overstepping the boundaries of expected behavior felt unsafe. Wide open and without walls except for four-foot partitions, the office resembled an open-air maze of public work spaces. There was also a loft that looked like a balcony. The space suggested that people were at once actors and audience. Its openness symbolically placed them on a stage in which they were constantly exposed to the scrutiny of others. There was no backstage, no place in which they could doff all vestiges of role and use their own voices.

William A. Kahn, Psychological Conditions of Personal Engagement and Disengagement at Work, S.713

Auf die meisten modernen Arbeitsplätze bezogen bedeutet das, dass sie für die Herstellung psychologischer Sicherheit nicht gut geeignet sind. Die von Kahn beschriebenen Grossraumbüros sind heute in grösseren Firmen der Standard, häufig sogar verbunden mit einer Aufhebung fester Arbeitsplätze und mit Meetingräumen die lediglich von Glaswänden umgeben sind.³ Geschützte Teamräume findet man nur in sehr wenigen Unternehmen.

In dieser Hinsicht hat die Verlagerung ins Homeoffice für Verbesserung sorgen können, allerdings sind auch in der Remote-Arbeit unsichere Kommunikations-Situationen häufig. Vor allem Unterhaltungen die in zu grossen oder öffentlich zugänglichen Chatgruppen stattfinden sind anfällig für psychologische Unsicherheit, das Gleiche kann zutreffen für Video-Calls die jederzeit ohne Einladung oder "Anklopfen" betreten werden können, da sich der Link zu ihnen auf öffentlichen Seiten befindet.

Dass die Bekenntnisse zu psychologischer Sicherheit ernst gemeint sind kann man also (unter anderem) daran erkennen, dass es für Teams sowohl physisch als auch digital die Möglichkeit gibt sich in geschützte Räume zurückzuziehen. Umgekehrt ist dort wo es lediglich Grossräum-Büros, gläserne Meetingräume und öffentliche Chats gibt das Konzept entweder noch nicht völlig verstanden worden oder die Bekenntnisse sind nicht so ernst gemeint wie behauptet.

Für die Einführung psychologischer Sicherheit ergibt sich schliesslich, dass die ersten Menschen die sich damit beschäftigen sollten oft nicht die sind von dem man es als erstes annehmen würde. Es sind nicht Manager, HR-Referenten, Agile Coaches oder Chief Culture Officer sondern - der Innenarchitekt und der Tool-Administrator.

Agile Overprocessing

Bild: Piqsels - Lizenz

Es mag wie ein Oxymoron erscheinen, trotzdem ist es ein in der Realität immer wieder zu betrachtendes Phänomen - das Agile Overprocessing. Gemeint ist damit die Überladung eines eigentlich für agiles Arbeiten konziperten Prozesses durch unnötige oder unnötig komplizierte Elemente, so dass am Ende das Gegenteil von Agilität erreicht wird: ein Erstarren in Formalismen, mit einer mehrheitlichen Ablehnung des Vorgehens als Folge.

Wichtig zum Verständnis ist, dass es sich bei den unnötigen Elementen nicht um solche handelt die genuin un- oder anti-agil sind (das wäre ein Hybrid-Vorgehen, nochmal ein eigenes Thema) sondern um solche die in anderen Kontexten durchaus agilitätsfördernd sein können. Dort wo sie durch nicht gegebene Voraussetzungen wirkungslos sind oder wo es den Missstand den sie beheben könnten gar nicht gibt werden fehlen ihnen aber Sinn, Mehrwert und als Folge auch Akzeptanz.

Um das an Beispielen festzumachen: ein häufiger Fall von agile Overprocessing ist die Einführung von WIP-Limits in Kanban-Systemen in denen zu viele parallele Arbeit kaum oder gar nicht vorkommt. Wärend sie dort wo vorher zu viel Multitasking vorherrschte befreiend wirken können verkommen sie ohne eine solche Problemlage zu einem blossen Formalismus, der darüber hinaus den Lean Management-Ursprüngen von Kanban diametral zuwiderläuft.

Ein weiterer Fall ist das in vielen Scrum Teams übliche Verwenden des klassischen User Story-Formats ("Als ... möchte ich ... um ...") für wirklich alle Anforderungen an deren Umsetzung gearbeitet wird, selbst dann wenn die so entstehenden Funktionen gar nicht für den Endnutzer gedacht sind ("Als Bank-Kunde möchte ich die Erstellung synthetischer Testdaten automatisiert haben, damit defekte Staging-Umgebungen schneller wiederhergestellt werden können").

Der Klassiker unter den unnötig komplizierten agilen Prozesse dürften die SAFe-Implementierungen sein bei denen versucht wird möglichst viele Teile des Startseiten-Wimmelbildes zu implementieren, obwohl im jeweiligen Anwendungsfall auch die minimalistische Version völlig ausreichend gewesen wäre. Dass SAFe durch seine vielen optionalen Teile versehentliches Overprocessiong so einfach macht ist ein Hauptgrund für seinen verheerenden Ruf in der Agile Community.

Selbst bei Ansätzen die als kaum anfällig für übertriebene Regulierung gelten kann sie auftreten. Ein Beispiele dafür wären Extreme Programming-Teams die eine Anwesenheit eines Onsite Customers auch in Iterationen fordern in denen nur Spikes zum besseren Verständnis des Legacy Code stattfinden oder Modern Agile-Teams die trotz grosser Vertrautheit und guter Feedback-Kultur vor jedem einzelnen Meeting die psychologische Sicherheit abfragen.

Alle derartigen Fälle (von denen es noch viel mehr gibt als hier beschrieben) haben das Risiko zur Folge, dass ihre offensichtliche Sinnlosigkeit und Unnötigkeit in der Aussenwahrnehmung auf das gesamte Vorgehen übertragen werden, das aufgrunddessen vollständig abgelehnt wird. Verstärkt wird das häufig durch unerfahrene aber dogmatische Scrum Master oder Agile Coaches, die WIP-Limits, User Stories o.Ä. für verpflichtend erklären und so auch noch ihr eigenes Amts-Charisma untergraben.

Die Lösung ist wie so oft das in Frage stellen dessen was scheinbar nicht in Frage gestellt werden kann. Frei nach dem Sprichtwort "Ist das noch Scrum oder kann das weg?" (oder "Ist das noch Kanban ...", "Ist das noch XP ...", etc) lässt sich bei allem was keinen Mehrwert bietet die Frage stellen ob das jeweilige Framework es wirklich zwingend erfordert. Bei einem genauen Blick auf das Regelwerk ist die Antwort darauf in den allermeisten Fällen ein klares Nein.

Ein Sonderfall liegt vor wenn  ein Prozess-Element zwar im jeweiligen Kontext offensich unnötig ist, im verwendeten Framework aber zwingend vorgeschrieben. In den Fällen liegt kein agile Overprocessing im Sinn einer unnötigen Verkomplizierung vor sondern lediglich eine unpassende Methodenauswahl. Aber auch die lässt sich natürlich korrigieren.

Siehe auch: Deine Muda - Overprocessing