The Law of unintended Consequences

Bild: Flickr / McKinney75402 - CC BY 2.0

Unter den verschiedenen "Gesetzmässigkeiten", die in Projektmanagement-Kreisen gerne zitiert werden, nimmt das Gesetz der unbeabsichtigten Konsequenzen eine Sonderstellung ein. Anders als fast alle anderen (Conway's Law, Gall's Law, Goodhart's Law, etc) ist es nicht nach einer Person benannt, die es erfunden und popularisiert hat, sondern ist nach und nach in den Wirtschafts- und Sozialwissenschaften entwickelt worden, u.a. von John Locke, Adam Smith und Friedrich Hayek.

Sie alle hatten unabhängig voneinander die folgende Einsicht: wer in komplexen, vernetzten oder volatilen Systemen Veränderungen vornimmt, der wird nicht nur den Effekt erzielen den er beabsichtigt,¹ sondern auch andere, unbeabsichtigte. Zu einem "Gesetz" wird es dadurch, dass diese ungewollt eintretenden Konsequenzen praktisch unvermeidbar sind, einzig ihre Art und Intensität kann von Fall zu Fall anders sein. Vereinfacht gesagt sind mindestens sechs verschiedene Varianten möglich:

Unerwartete positive Konsequenzen

Der beste Fall der eintreten kann, in ihm treten positive Effekte auf, mit denen man gar nicht gerechnet hatte. Ein Beispiel wäre ein Sparkurs, durch den ein Grossprojekt auf nur noch wenige Teams zusammenschrumpft. Da diese jetzt jeweils mehr Themengebiete abdecken müssen, werden sie crossfunktionaler und weniger arbeitsteilig, wodurch nicht nur die Personalkosten sinken, sondern auch der bisherige Koordinationsaufwand und mit ihm weitere Kosten.

Unerwartete negative Konsequenzen

Das Gegenteil des ersten Falls. Ein Beispiel dafür wäre die Neueinführung gehaltsrelevanter Ziele für einzelne Mitarbeiter. Die arbeiten dann zwar mit gesteigerter Motivation an diesen Zielen, aber das im Zweifel auch auf Kosten der gemeinsamen Team- oder Unternehmensziele. Ein Sicherheitsbeauftragter, der für jeden gefundenen Regelverstoss belohnt wird, hat etwa einen starken Anreiz, seine Kollegen mit einer lähmenden und demotivierenden Kontroll-Bürokratie zu überziehen.

Unerwartete perverse Konsequenzen

Eine derartige Übersteigerung der negativen Konsequenzen, dass es sogar zu einer Verschlechterung in dem Bereich kommt, der eigentlich verbessert werden sollte. Ein bekannter Fall der Versuch, durch die Einführung von gemeinsamen Grossraumbüros die Kommunikationsbarrieren zwischen Mitatarbeitern abzubauen. Forschungsergebnisse zeigen, dass das Gegenteil der Fall ist - um den Geräuschpegel auszublenden werden Headsets aufgesetzt, wodurch die Kommunikation sogar zurückgeht.

Unerwartete positive Seitenauswirkungen

In diesem Fall treten unbeabsichtigte positive Effekte auf, die ihre Auswirkungen in einem anderen Bereich entfalten als dem, in dem die Veränderungen stattgefunden haben. So können Programme zur Förderung von Achtsamkeit und Sorgfalt nicht nur zu geringeren Fehlerquoten bei der Arbeit führen, sondern auch zu einem generell bewussteren und verantwortungsvolleren Konsumverhalten, wodurch im Privatleben der Beteiligten weniger Haushaltsmüll erzeugt wird.

Unerwartete negative Seitenauswirkungen

Wieder das Gegenteil des letzten Falls, hier tretennegative Effekte in einem anderen Bereich auf als dem, in dem die Veränderungen stattgefunden haben. Wenn eine Firma beispielsweise Kosten senken will indem sie von externen Mitarbeitern Gebühren für die Nutzung des eigenen Parkhauses verlangt, wird sie dadurch die Verkehrs- und Parkplatz-Situation in der Nachbarschaft verschlechtern, da auf die hier befindlichen Pakkplätze ausgewichen wird.

Sonstige unerwartete Seitenauswirkungen

Auch das gibt es - unbeabsichtigte Auswirkungen auf andere Bereiche als den, in dem die Veränderungen stattgefunden haben, die weder positiv noch negativ sind. Ein anschaulicher Fall dafür wäre eine Firma, die im Rahmen eines Corporate Design-Relaunch die Farbe ihrer Dienstwagen von Gelb zu Grün ändert. Das Strassenbild der Umgebung wird das zwar verändern, allerdings nicht zum Besseren oder Schlechteren, es sieht einfach nur anders aus.

Welche auch immer es sind, die Gemeinsamkeit der verschiedenen unbeabsichtigten Konsequenzen ist, dass sich weder ihre Art noch die Schwere ihrer Auswirkungen vorhersagen lassen. Dort wo in komplexen, vernetzten oder volatilen Systemen Veränderungen vorgenommen werden, ist es daher eine gute Idee, regelmässig zu überprüfen, ob derartige Effekte auftreten. Nur dann ist es möglich ggf. schnell Gegenmassnahmen zu ergreifen. Auch hier gilt also wieder: Inspect & Adapt.

¹Falls der überhaupt eintritt

Agile Success Stories: Agile by Accident

Bild: Pexels / Moe Magners - Lizenz

Dass viele "agile Methodiker" (Agile Coaches, Scrum Master, etc.) mit der Zeit eine eher negative Weltsicht entwickeln ist schade, aber erklärbar. Wer sich ständig mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue, Overcompliance und Konzern-Trolle beschäftigen muss, kann leicht in Frustration und Fatalismus abrutschen. Um nicht selbst in dieses Muster verfallen, möchte ich dagegenhalten, indem ich ab und zu selbst erlebte "agile Erfolgsgeschichten" veröffentliche.

Diese hier habe ich mehrfach in ähnlicher Form erlebt, aber die an die ich gerade denke, begann damit, dass ich als externer Scrum Master oder Agile Coach in eine Firma gekommen bin und dort Teams vorgefunden habe, die mir gleich zu Beginn Eines unmissverständlich klar machen wollten: dass es agiles Arbeiten bei ihnen nicht geben würde. Sie hätten das bereits versucht gehabt, es sei furchtbar gewesen und sie wären heilfroh, es zugunsten eines besseren Vorgehens  hinter sich gelassen zu haben.

Bedingt dadurch, dass ich diese Erfahrung wie gesagt bereits mehrfach gemacht habe, lasse ich mich in derartigen Situationen zunächst noch auf keine Diskussion über das zukünftige Vorgehen ein, sondern lasse mir zuerst erklären, warum der agile Arbeitsmodus als so furchtbar empfunden wurde und was den stattdessen gewählten so viel besser macht. Und es stellte sich dabei heraus, dass hier zwei aufeinander aufbauende Missverständnisse vorlagen.¹

Das erste dieser Missverständnisse betraf das, was dort irgendwann mal unter dem Namen "Agile" eingeführt worden war. Mit der zugrundeliegenden Idee hatte das eher wenig zu tun, stattdessen wurden lediglich zusätzlich zu den bereits bestehenden (und z.T. unverändert gültigen) Prozessen einzelne aus Scrum oder SAFe entlehnte Meetings, Titel und Begriffe eingeführt, die aber ohne geänderte Rahmenbedingungen nichts verbessert sondern nur alles verkompliziert hatten. Cargo Cult also.

Aufbauend darauf war das zweite Missverständnis entstanden. Da "Agile" als komplizierter, unverständlicher und bürokratischer Prozess wahrgenommen wurde, hatten die Teams stattdessen ein Alternativvorgehen entwickelt, dass auf direkter Kommunikation, crossfunktionaler Zusammenarbeit, wenigen Regeln, kurzen Lieferzyklen und regelmässigen Prozessverbesserungen beruhte.² Folgerichtig hielten sie dieses Vorgehen für nicht-agil und dem agilen Arbeiten überlegen.

Als ich auf diese beiden Missverständnisse hinwies, und darauf, dass der "nicht-agile Arbeitsmodus" in Wirklichkeit sehr agil war, waren zunächst Überraschung und Unglaube gross. Erst nachdem sich einige Teammitglieder bereiterklärten, einige der Originalquellen (Scrum Guide und Agiles Manifest) zu lesen, setzte sich langsam die Erkenntnis durch, dass sie die Idee falsch verstanden hatten, und durch die Abwehr der Cargo Cult-Methode "versehentlich" agil geworden waren.

Wirklich warm geworden sind sie mit dem Begriff zwar nicht mehr, dafür hatten sie sich bereits zu sehr auf ihn eingeschossen. Aber ganz ehrlich - sie waren nah am Kunden, lieferten regelmässig Mehrwert aus, passten das eigene Vorgehen regelmässig an und arbeiteten gut zusammen. Angesichts dessen war die Ablehnung des Wortes "Agil" ein Thema, das man mit gutem Gewissen vernachlässigen konnte. Wenn das Ergebnis stimmt, ist der Name des Prozesses nicht so wichtig.

¹Es gab natürlich auch Fälle in denen agiles Arbeiten verstanden und trotzdem abgelehnt wurde. Das ist nochmal ein eigenenes Thema.
²Dieses selbstentwickelte Vorgehen war auch deutlich schlanker und effektiver als der ursprüngliche, "vor-agile" Prozess

The Philosophy of Architecture

Das hier gefällt mir wirklich: Barry O'Reilly versucht sich an einem philosophischen Blick auf das Konzept der Software-Architektur. Verkürzt gesagt - während sie häufig als ein logischer und konsistenter Ansatz zur Strukturierung von Software gesehen wird, ist sie in Wirklichkeit eine soziale Technik, mit der versucht wird, Ordnung in eine Welt zu bringen, die sich in einem Prozess der permanenten Unordnung befindet.

Alleine die oben genennten Gedanken hätten vermutlich schon für einen eigenen Vortrag gereicht, aber dieser geht deutlich weiter, und berührt unter anderem Essentialismus, Strukturalismus, Determinismus (und dessen Negierung), die Diskrepanz zwischen Sein und Werden, Positivismus, Interpretivismus, naive Kybernetik, Kausalität, Dekonstruktion und die philosophischen Grundlagen der Matrix-Filmreihe. Definitiv sehens- und hörenswert.

Warum deutsche Unternehmen keine Silicon Valley-Startups kaufen sollten

Bild: Pexels / Yan Krukau - Lizenz

Das Silicon Valley - Speerspitze des Fortschritts, Verkörperung technischer Disruptionen, Geburtsstätte bahnbrechender Innovationen und immerwährender Kreativität. Sich durch die Übernahme eines dort angesiedelten Startups in diese Wunderwelt einzukaufen erscheint den Managern vieler deutscher Konzerne und Mittelständler eine gute Idee zu sein, in der Realität enden diese Zukäufe allerdings meistens in Enttäuschungen. Und dass es immer wieder so kommt ist kein Zufall.

Um es vorwegzunehmen: was jetzt folgt ist anekdotische Evidenz. Ich habe einige dieser gescheiterten Silicon Valley-Expansionen selbst miterlebt, bei einigen weiteren kenne ich Menschen die dabei waren. In Summe lediglich eine niedrige zweistellige Zahl von Fällen, also Nichts was wissenschaftliche oder statistische Validität hätte. Da aber bestimmte Probleme immer wieder aufgetreten sind, glaube ich, dass es hier erkennbare (und prognostizierbare) Muster gibt.

Um mit dem Folgenschwersten (und auf den ersten Blick unglaublichsten) zu beginnen - die meisten deutschen Unternehmen sind sehr schlecht im Gestalten und Befolgen von Prozessen. Das kann bedeuten, dass es selbst für zentrale Geschäftsvorgänge keine offizielle Definition gibt (v.a. im Mittelstand anzutreffen), oder dass in Konzernen alles so überreguliert ist, dass die Mitarbeiter gezwungen sind, sich auf informelle Prozesse zurückzuziehen, um überhaupt arbeitsfähig zu sein (→ brauchbare Illegalität).¹

In beiden Fällen ist das Ergebnis, dass neue Mitarbeiter die inoffiziellen, aber für das Funktionieren der Firma elementaren Prozesse erst nach und nach herausfinden müssen, da diese lediglich im kollektiven Gedächtnis festgehalten sind. In Folge dessen dauert es entsprechend lange bis sie wirklich arbeitsfähig sind - sechs bis zwölf Monate sind in grossen Unternehmen nicht ungewöhnlich. Da in Deutschland viele Angestellte jahrzehntelang in ihrer Firma bleiben, ist das aber ein eher geringes Problem.

Im Silicon Valley findet man gleichzeitig ein Muster, das mit dem zuvor genannten komplett inkompatibel ist - die meisten Angestellten bleiben weniger als zwei Jahre bei einem Arbeitgeber, viele wechseln sogar mehrmals im Jahr. Das langsame Aufbauen von Wissen über die inoffiziellen Prozesse ist daher nicht möglich, weshalb die offiziellen möglichst minimalistisch gehalten, dafür aber strikt durchgesetzt und neuen Mitarbeitern durch starke und umsetzungsnah agierende Manager vermittelt werden.

Übernimmt jetzt ein deutsches Unternehmen ein Silicon Valley-Startup, kommt es mit hoher Wahrscheinlichkeit zu einem Culture Clash: in der (unbewussten) Erwartung, dass sich die Mitarbeiter die (inoffiziellen) Prozesse mit der Zeit selbst aneignen werden, wird von den deutschen Managern ein weniger strikter Führungsstil eingeführt. Der ständig wechselnden Belegschaft fehlen damit sowohl die schnelle Einweisung in die offiziellen, als auch das langsame Erlernen der inoffiziellen Prozesse.

Die unvermeidbare Folge eines derartigen Zusammenpralls so unterschiedlicher und inkompatibler Unternehmenskulturen ist ein erstaunlich schnelles Zusammenbrechen von Abläufen und Strukturen. Innerhalb von ein bis zwei Jahren sind kaum noch Kollegen da, die Erfahrung damit haben, die Prozesse am Laufen zu halten, stattdessen sind die meisten erst seit einigen Monaten an Bord, wurden nie richtig eingearbeitet und sind dadurch nur eingeschränkt zu effektivem Arbeiten in der Lage.

Diesem rapiden Verfall des intellektuellen Kapitals folgt meistens ein genauso schneller Einbruch der Produktqualität. Marktforschung, Product Discovery, technische Exzellenz und Qualitätssicherungs-Routinen sind mit den sich auflösenden Strukturen und Prozessen nur noch eingeschränkt durchführbar, Bugs und technische Schulden häufen sich an, die Umsetzungsgeschwindigkeit sinkt und mit ihr die Wettbewerbsfähigkeit und die Marktanteile. Irgendwann kann man alles nur noch abwickeln.

Selbst wenn diese Abläufe immer wieder zu beobachten sind, sind sie natürlich kein Naturgesetz. Sind die zugrundeliegenden Muster einmal erkannt, kann man gegensteuern und eine Silicon Valley-Tochtergesellschaft auch von Deutschland aus gut führen. Voraussetzung dafür ist allerdings, sich die Unzulänglichkeit oder Lückenhaftigkeit der meisten offiziellen Prozesse einzugestehen und ihre Unbrauchbarkeit in einer Umgebung mit hoher Personalfluktuation zu erkennen. Eine hohe Hürde.

¹Natürlich ist in der Regel ein Grossteil der Prozesse gut beschrieben und wird auch befolgt, bei einem signifikanter Teil ist es aber umgekehrt.

Wie man ein Spezialistenteam reibungslos auflöst

Bild: Unsplash / Annie Spratt - Lizenz

Zu den Grundüberzeugungen aller agilen Frameworks gehört, dass Entwicklungsteams nach Möglichkeit Crossfunktional sein sollten, also in der Lage, alle im Rahmen der Produktentwicklung nötigen Tätigkeiten selbst durchzuführen, ohne dabei von anderen Abhängig zu sein. In traditionell arbeitenden Unternehmen dominieren dagegen die Spezialistenteams, die nur eine bestimmte Spezialtätigkeit beherrschen, die aber besonders effizient.

Am Anfang von agilen Transitionen stehen daher häufig Reorganisationen, in denen die Spezialistenteams aufgelöst und ihre Mitglieder auf die neuen, crossfunktionalen Teams verteilt werden. Wenn es in solchen Situationen aber mehr dieser neuen Teams gibt als bisher Spezialisten, treten Probleme auf. In den einen Teams feht das Spezialistenwissen, sie sind also doch wieder von anderen abhängig. Die anderen Teams müssen wiederum die erste Gruppe unterstützen, was zu Defocussierung und Prioritätskonflikten führt.

Um das zu vermeiden ist es sinnvoll, die Auflösung der Spezialistenteams nicht von jetzt auf gleich durchzuführen, sondern im Rahmen eines langsamen Prozesses, während dem immer mehr Wissen und Zuständigkeiten in die Breite verlagert werden. Wie das im Einzelnen geschehen kann wird natürlich von Fall zu Fall unterschiedlich sein, es gibt allerdings einen Denkansatz, mit dessen Hilfe sich der Übergang strukturiert durchführen lässt: Team Topologies.

Team Topologies geht von vier grundlegenden Team-Typen aus: Stream-aligned Teams (crossfunktional, können alles selbst), Enabling Teams (befähigen andere Teams), Complicated Subsystem Teams (besondere Spezialistenteams, deren Tätigkeit sich nicht so einfach aufteilen lässt) und Platform Teams (stellen anderen Teams Produkte oder Dienstleistungen zur Verfügung, die diese ohne externe Unterstützung sich selbst beschaffen und benutzen können). Mehr dazu hier.

Da spezialisierte Teams in Team Topologies den Complicated Subsystem Teams entsprechen sind diese der Ausgangspunkt, von dem aus zwei Weiterentwicklungen möglich sind: entweder sie können ihr Spezialgebiet zu einer Plattformdienstleistung umwandeln, die von den anderen Teams in einem Selbstbedienungs-Modus genutzt werden kann, oder sie wandeln sich zu enabling Teams indem sie das, was sie bisher selbst gemacht haben, anderen beibringen.

Häufige Anwendungsfälle für die Weiterentwicklung in Richtung Platform Team sind Spezialisten-Einheiten, von denen bisher Werkzeuge, Daten oder Infrastruktur verantwortet wurden. Die können in Selbstbedienungs-Portale überführt werden, in denen man sich Entwicklungsumgebungen, Testdaten, Anleitungen, Nutzungs-Simulationen o.ä. konfigurieren kann, die dann automatisiert erstellt und zur Verfügung gestellt werden.

Alternativ kann das bisherige Spezialisten-Team seine bisher verantworteten Themen direkt an die neuen, crossfunktionalen Teams weitergeben, allerdings mit einer wichtigen Ergänzung - statt diese mit ihrer neuen Aufgabe alleinzulassen, stehen die bisherigen Spezialisten als Trainer, Ratgeber, Erklärer und Notfallhelfer zur Verfügung, und das so lange bis sichergesetellt ist, dass ihre Unterstützung nicht mehr benötigt wird und sie sich neue Aufgaben suchen können.

In beiden Fällen (Umwandlung in ein Platform Team und Umwandlung in ein Enabling Team) kann es schliesslich zu einer finalen Entwicklungsstufe kommen, in der sich die ursprüngliche Spezialisteneinheit zwar auflöst, als "virtuelles Team" aber erhalten bleibt. Das kann z.B. in Form einer Community of Practice stattfinden, in der (ggf wechselnde) Vertreter aller crossfunktionalen Teams gemeinsam eine Platform-Dienstleistung oder einen Wissenstransfer am Leben halten.

In der Realität findet man derartige kontrollierte Auflösungsprozesse von Spezialistenteams übrigens in den meisten Fällen ohne die Nutzung der Teams Topologies-Begriffe. Das ist auch vollständig in Ordnung, es handelt sich bei ihnen nicht um eine Prozessvorgabe, sondern um nur ein Denkwerkzeug, mit dem man abstrakte Konzepte in Worte fassen kann.

Overcompliance

Wer versucht in grossen Organisationen Bürokratie zu bekämpfen, der wird möglicherweise an der folgenden paradoxen Situation vorbeigekommen sein: während die Ausführungs-Ebene unter der Last der Prozesse und Vorschriften ächzt, ist sich die Führungsebene keiner Schuld bewusst, und kann sogar darauf verweisen, dass das offizielle Regelwerk sogar relativ schlank ist. Für diesen scheinbar widersinnigen Zustand gibt es einen häufigen Grund: Overcompliance.

Um das besser begreifen zu können schauen wir uns zunächst den zugrundeliegenden Begriff an: die Compliance. Hinter ihm verbirgt sich die anzustrebende Regelkonformität von Unternehmen, Behörden und sonstigen Organisationen, also die Einhaltung von Gesetzen, Richtlinien und internen Vorschriften. Compliance zu haben (bzw. Compliant zu sein) ist als Folge dessen das Ziel zahlreicher Prozesse, Tätigkeiten und Organisationseinheiten, die nur zu diesem einen Zweck existieren.

Das Problem bei der Herstellung von Compliance ist allerdings, dass es an ihren Rändern eine Grauzone gibt. Ab wann wird aus einer Routine ein zu dokumentierender Prozess? Gibt es Bagatellgrenzen für Zeit-, Qualitäts- und Budgetabweichungen? Wann können Anweisungen mündlich erfolgen, wann ist die Text-Form ausreichend und wann ist die Schriftform nötig? Alle diese Fragen sind in den Einzelfällen nicht immer eindeutig zu beantworten und lassen einen Interpretationsspielraum offen.

So lange dieses freie Interpretieren innerhalb der Grauzone keine negativen Folgen hat, ist das auch meistens unproblematisch, schwierig kann es aber werden, wenn das zu Unfällen, Qualitätsmängeln oder versehentlichen Regelverstössen führt. Viele Organisationen kehren in derartigen Situationen den Interpretationsspielraum um - alles woraus sich eine wie auch immer geartete Verantwortlichkeit ableiten lässt, wird rückwirkend zur Norm erklärt - oft mit disziplinarischen Folgen für die Betroffenen.

Und an dieser Stelle kommt es zur Overcompliance: um nicht ebenfalls oder erneut für etwas zur Verantwortung gezogen zu werden, was sich innerhalb einer Grauzone abspielt, beginnen die Mitarbeiter jetzt die jeweils strengste (und für sie sicherste) Auslegung der Gesetze, Richtlinien und internen Vorschriften anzuwenden. Im Zweifel also alles dokumentieren und schriftlich genehmigen zu lassen, und bereits kleinste Abweichungen zu verfolgen und zu eskalieren.

Bereits das kann lähmende Auswirkungen auf nahezu alle Abläufe haben, im schlimmsten Fall kann es aber sogar noch schlimmer werden - wenn es als Reaktion auf eine kontrollierende und überwachende Variante der Overcompliance dazu kommt, dass selbst für kleinste Aufwände explizite und schriftliche Anweisungen und Abnahmen nötig sind (gewissermassen Gegen-Overcompliance), ist es nicht mehr weit bis zu gegenseitigen Blockaden und bis zum totalen und dauerhaften Stillstand.

Um sich aus einer derartigen Situation zu befreien (oder um es gar nicht erst soweit kommen zu lassen) sind zwei Dinge notwändig: zum einen muss man akzeptieren, dass sich nicht alle Eventualitäten vorhersehen und mit vertretbarem Aufwand regulieren lassen, und zum anderen muss man darauf verzichten, nach in Grauzonen stattgefundenen Unfällen, Qualitätsmängeln oder versehentlichen Regelverstössen immer nach einem Schuldigen zu suchen und ihn bestrafen zu wollen.¹

Was darüber hinaus ein sinnvolles Werkzeug für die Verhinderung von Overcompliance sein kann, ist eine Vereinbarung, bei allen Regel-Umsetzungen immer die am wenigsten restriktive Variante anzustreben und von anderen zu fordern. Idealerweise kann das sogar Teil eines "Gesellschaftsvertrages" werden, an dem sich die gemeinsame Zusammenarbeit ausrichtet und auf den man sich bei Prozessgestaltungen, in Konflikten und bei Meinungsverschiedenheiten berufen kann.

¹Das bedeutet natürlich nicht, dass man darauf verzichtet, daran zu arbeiten, dass sich derartige Vorfälle nicht wiederholen - das geht aber auch ohne Schuldzuweisungen

Ein Bild sagt mehr als 1000 Worte (XLVI)

Grafik: Forrest Brazeal - CC BY-NC-ND 4.0

Erinnert mich ein bisschen an den Klassiker I fucked up Git so bad it turned into Guitar Hero.

Thermal Teams

Bild: Pixabay / Ferafba - Lizenz

Fast immer wenn in grossen Organisationen der Handlungsdruck gross ist, Termine stark in Gefahr geraten oder irgendwie Nichts weitergeht, werden Task Forces gegründet - kleine, crossfunktionale und auf eine einzige Aufgabe focussierte Einheiten, die die anstehenden Aufgaben schnell erledigen können. Eine Frage die in solchen Situationen häufig gestellt wird ist die, ob sich dieser Arbeitsmodus nicht formalisieren lässt, um in Zukunft von Anfang an derartig lieferfähig sein zu können.

Die Antwort: natürlich geht das, und in verschiedenen Unternehmen gibt es auch Beispiele dafür. Ein prominentes sind die Thermal Teams oder Thermal Projects bei Twitter, bzw. X, deren Funktionsweise die beiden Manager Keith Coleman (VP of Product) und Jay Baxter (ML Lead) in Lenny's Podcast erklärt haben. In Anlehneng an die thermischen Aufwinde, die Vögeln das Fliegen erleichtern, handelt es sich bei ihnen um vom Top-Management geförderte Vorhaben mit besonders guten Rahmenbedingungen.¹

Wie immer in solchen Fällen gilt natürlich auch in diesem hier, dass es sich um eine Fallstudie aus einem sehr spezifischen, nicht in allen Asspekten nachvollziehbaren Kontext handelt, die darum nicht mit Copy & Paste in andere Unternehmen übertragbar ist. Allerdings handelt es sich auch um eine der bekanntesten und erfolgreichsten IT-Firmen der Welt, so dass es durchaus interessant und inspirierend sein kann, sich deren Vorgehensmodell anzuschauen.²

Die erste der oben genannten fördernden Rahmenbedingungen ist bei Twitter/X das Vorhandensein eines möglichst hochrangigen Sponsors (idealerweise in Person von Elon Musk selbst), der auch als Eskalations-Instanz dient, wenn es mit anderen Team zu Konflikten über Architektur, Ressourcen oder Sonstiges kommt. Das sorgt nicht nur für ein schnelles Lösen von Blockaden, es limitiert indirekt auch die Zahl der Thermal Teams, da die Anzahl möglicher Sponsoren nur klein ist.

Bei der nächsten fördernden Rahmenbedingung handelt es sich um die Selbst-Auswahl der Teammitglieder. Wenn der Start eines neuen derartigen Teams verkündet wird, sucht nicht das Management die aus seiner sicht passenden Entwickler aus, sondern diejenigen die Interesse haben melden sich selbst.³ Dadurch ist sichergestellt, dass alle Beteiligten intrinsisch motiviert sind und bereit sind, ihr gesamtes Leistungsvermögen einzubringen.

Als nächste Besonderheit sind die so entstehenden Einheiten möglichst klein, mit im besten Fall deutlich weniger als zehn Teammitgliedern, wodurch die interne Kommunikation einfacher und schneller wird. Ein begrenzender Faktor ist dabei, dass möglichst crossfunktionale Einheiten angestrebt werden, die alle in Frage kommenden Arbeiten selbst ausführen können. Dort wo hohe Spezialisierung nötig ist, führt das ggf. zu grösseren Gruppen.

Wichtig ist ausserdem, dass Thermal Teams soweit wie möglich von allen anderen Verpflichtungen und Vorschriften befreit sind. Das bedeutet vor allem, dass sie nicht parallel in anderen Projekten mitarbeiten dürfen und sich nicht mehr an anderen Meetings und Reportings beteiligen müssen, es bedeutet aber auch, dass sonst vorgehebene Tools und Standards nicht mehr benutzt werden müssen. Coleman und Baxter nennen als Beispiel Jira, von dessen Nutzung Thermal Teams befreit sind.

Als letztes ist von Bedeutung, dass diese Art von Teams bei Twitter/X nur jeweils für eine begrenzte Zeit bestehen sollen (daher auch die alternative Benennung Thermal Projects). Die Grümde dafür dürften offensichtlich sein: zum einen wird so ein Abrutschen in Routinen und ein Zurückgehen der besonderen Motivation verhindert, zum anderen können die Teammitglieder in ihre ursprünglichen Einheiten zurückkehren, in denen ihre Beteiligung schliesslich auch benötigt wird.

Wie oben gesagt, die Idee der Thermal Teams ist nichts was andere Unternehmen einfach kopieren sollten, dafür ist der Kontext in dem sie funktionieren zu spezifisch. Es kann aber eine gute Idee sein, einzelne Elemente davon zu übernehmen, bei sich zu testen, ggf. anzupassen und so sein eigenes Vorgehensmodell zu entwickeln, mit dem sich der eher unstrukturierte Taskforce-Modus ablösen lässt.

¹Anscheinend gehörte es zur Firmenkultur von Twitter, vor allem Namen mit Vogelbezug auszuwählen
²Auf einem völlig anderen Blatt stehen der Besitzer und die Community-Regeln von X, um die geht es hier nicht
³Bei zu vielen, zu wenigen oder ungeeigneten Bewerbungen wird es vermutlich doch zu Management-Entscheidungen kommen

Kommentierte Links (CXXIV)

Grafik: Pixabay / Brian Penny - 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.

Luxshan Ratnaravi: The Six Agile People Manager Stances

Über die Jahre hat es immer wieder Artikel gegeben, die die verschiedenen Ausprägungen verschiedener agiler Rollen beschrieben haben: für den Scrum Master, den Product Owner, den Agile Coach, den Agile Leader, den Tech Lead, etc. Luxshan Ratnaravi hat aber tatsächlich noch eine weitere Rolle gefunden, mit der das anscheinend noch nicht passiert ist - den Agile People Manager. Was in dieser Galerie aber bemerkenswerterweise immer noch fehlt, sind die Developer.

Jeff Sutherland: Mastering Agile Spikes for Smarter Resource Management

Anscheinend hat Jeff Sutherland, der Godfather of Scrum, eine neue Firma, JVS Management. Auf deren Seite findet sich diese Übersicht über den Einsatz von Spikes in Extreme Programming und Scrum, von ihrem Ursprung über ihre Einsatzmöglichkeiten bis hin zu einer Case Study. Wie in Sutherlands gesamtem Spätwerk finden sich auch kontroverse Passagen (z.B. "The PO assigns a fixed number of story points to a Spike"), insgesamt ist es aber ein guter Überblick.

Salvatore Sanfilippo: We are destroying software

Ich bin nicht sicher, ob das, was Salvatore Sanfilippo hier verfasst hat, eine blosse Aufzählung ist, eine nüchterne Analyse, eine Anklageschrift, ein Rant, ein Wutausbruch oder eine kopfschüttelnd vorgetragene Betrachtung der über die Zeit aufgekommenen Missstände und Missverständnisse der modernen Softwareentwicklung. Vermutlich ist es von allem etwas, vorallem ist es aber eines: sehr schön minimalistisch im Layout. Das ist doch schon mal etwas.

Doc Norton: Fixing Full-Stack Teams; Specialization Required

Was Doc Norton hier adressiert ist ein häufiges Missverständnis, dass das in agilen Unternehmen meistens angestrebte Full Stack-Prinzip umgibt - hinter diesem Konzept verbirgt sich nicht die Idee, dass jedes Mitglied eines solchen Teams in der Lage ist, alle für dieses Team anliegenden Aufgaben zu erledigen. Stattdesssen sind die Team-Mitglieder in Summe dazu in der Lage. Ist das einmal verstanden werden die Diskussionen um das Full Stack-Prinzip sofort weniger emotional.

Charity Majors: Corporate “DEI” is an imperfect vehicle for deeply meaningful ideals

Der Zeitgeist bewegt sich gerade nicht unbedingt in die Richtung von DEI (Diversity, Equity and Inclusion) - und das nicht nur zu Unrecht, sicher ist dieser Ansatz an einigen Stellen zu weit getrieben worden. Dass er aber grundsätzlich gut ist arbeitet Charity Majors hier sehr schön heraus, einschliesslich der Widerlegung einiger weit verbreiteter Missverständnisse.

Der andere Kanban Guide

Bild: Flickr / Rosenfeld Media - CC BY 2.0

Einer der grossen Unterschiede zwischen den beiden populärsten agilen Frameworks, Scrum und Kanban, war immer, dass Scrum mit dem Scrum Guide ein verbindliches Regelwerk hatte, während Kanban trotz weit verbreiteter und allgemein anerkannter Praktiken eher "Open Source" war, so dass jeder hineindefinieren und -interpretieren konnte was er wollte. Diese Unklarheit hat immer wieder den Wunsch nach einem "Kanban Guide" aufkommen lassen.

Die erste Organisation die versucht hat diese Lücke zu füllen (bzw. den damit verbundenen Zertifizierungs-Markt zu erschliessen) war die Lean Kanban University, die 2016 den trotz seines Namens etwas aufgeblähten Essential Kanban Condensed Guide veröffentlichte, der dann 2021 durch den schlankeren "Official" Kanban Guide abgelöst wurde. Aufgrund seines Namens wird der immer wieder für das einzige und verbindliche Kanban-Regelwerk gehalten.

Da der Begriff und die Idee von Kanan nicht geschützt sind, gibt es aber auch Alternativen, unter denen die vielleicht bekannteste schlicht The Kanban Guide heisst. Selbst wenn seine Verfasser Daniel Vacanti und John Coleman mit ProKanban (einer anderen Zertifizierungs-Organisation) verbunden sind, ist das Dokument bewusst nicht mit deren Brand verbunden oder auf deren Website gehostet, um so seinen universellen Anspruch und seinen nicht-kommerziellen Charakter hervorzuheben.

Von seiner Struktur her organisiert er sich sehr stark am Scrum Guide, bis hin zu dem Punkt, dass mehrere seiner Abschnitte fast identisch benannt sind (Purpose of the Kanban Guide statt Purpose of the Scrum Guide, Definition of Kanban statt Scrum Definition, Kanban Theory statt Scrum Theory, etc.).¹ Lediglich in seinem Mittelteil gibt es Abweichungen, gegen Ende entspricht der Aufbau mit End Note und Acknowledements wieder sehr stark dem des Scrum Guides.

Inhaltlich sind es auch vor allem diese mittleren Abschnitte, die Kanban Practices, das Improving the Workflow und die Kanban Measures die interessant sind.² Den grössten Teil nehmen dabei die Practices ein, es handelt sich bei ihnen um Defining and Visualizing the Workflow, Actively Managing Items in a Workflow, Controlling Work In Progress und  Service Level Expectation.³ Nach Ansicht der beiden Autoren handelt es sich dabei um die unverzichtbaren Kernbereiche der Kanban-Methode.

Hinter Defining and Visualizing the Workflow verbirgt sich das explizit machen des eigenen Arbeitsflusses, wodurch erkennbar wird wer im Rahmen seines Ablaufs was macht, in welcher Reihenfolge, mit welchen Schnittstellen-, bzw. Übergabe-Kriterien und welchen Kontrollmechanismen. Genannt wird das Ganze Definition of Workflow (DoW) - auch hier erkennt man wieder eine Parallele zum Scrum Guide und seiner Definition of Done (DoD).

Mit Actively Managing Items in a Workflow sind im Kanban Guide die Tätigkeiten gemeint, die den reibungslosen Durchfluss von Arbeit durch das System sicherstellen oder wiederherstellen sollen. Im Einzelnen sind das Controlling Work in Progress (d.h. dessen Menge), Avoiding work items piling up in any part of the workflow, Ensuring work items do not age unnecessarily (mit Hilfe von Service Level Agreements) und Unblocking blocked work.

Mit Controlling Work in Progress und Ensuring work items do not age unnecessarily bekommen die erste und letzte der zuletzt genannten Tätigkeiten noch einen eigenen Abschnitt, in dem tiefergehend erläutert wird, was sich dahinter verbirgt, bzw. welche weiteren Konzepte damit verbunden sind. Hier finden sich u.a. auch das Pull-Prinzip und das probabilistische Forecasting, die damit im Vergleich zu anderen Kanban-Auslegungen eine eher wenig prominente Plazierung haben.

Im Vergleich dazu ist das Improving the Workflow relativ knapp beschrieben. Hervorgehoben wird vor allem, dass es überhaupt stattfinden sollte, dass es auf der Grundlage von Zahlen und/oder Erfahrungen erfolgen sollte und dass es Verbesserungen der Effizienz, Effektivität und Vorhersagbarkeit zum Ziel haben sollte. Bemerkenswert ist, dass explizit nicht nur kleine sondern auch grosse Verbesserungen möglich sind, also nicht nur Kaizen sondern auch Kaikaku.

Die Kanban Measures sind schliesslich wieder die grossen Klassiker: Work in Progress-Menge, Throughput, Work Item Age und Cycle Time (Lead Time dagegen bemerkenswerterweise nicht). Neben ihrer kurzen Erklärung wird noch unterstrichen, dass sie nur zum Zweck der Prozessverbesserung erhoben und kein Selbstzweck sein sollen, und dass es möglich ist, sie um weitere Metriken zu ergänzen, wenn man darin einen Mehrwert sieht.

Was der Kanban Guide nicht (bzw. nur als Nennung optionaler Möglichkeiten) enthält, sind Meetings und Rollen. Es wird zwar erwähnt, dass es möglich ist, Dailies und Retrospektiven (die hier nur Reviewing the Definition of Workflow from Time to tTime heissen) abzuhalten, von einer zu starken Formalisierung wird aber abgeraten. Im Fall der Rollen ist nicht mal das gegeben, sie werden an keiner Stelle des Kanban Guide auch nur erwähnt, geschweige denn vorgegeben.

Zur Bewertung, bzw. Einordnung: das auf den ersten Blick Auffälligste am Kanban Guide dürfte die starke Anlehnung seiner Struktur an die des Scrum Guide sein. Die mag ihre Vorteile haben, da jemand der bisher nur Scrum kennt sich leichter zurechtfinden wird, andererseits wirkt sie etwas gezwungen und z.T. sogar un-originell, etwa in den End Note, die in einigen Passagen eine Eins-zu Eins-Kopie ist. Auch die Definition of Workflow wirkt etwas gezwungen.

In Abgrenzung zum "Official" Kanban Guide der Kanban University ist erkennbar, dass die jeweiligen Verfasser jeweils unterschiedliche Elemente für wichtig oder verzichtbar gehalten haben. Während z.B. im "Official" Kanban Guide Aufbau und Nutzung eines Kanban-Boards einen grossen Platz einnehmen, fehlen sie in The Kanban Guide völlig. Das macht einmal mehr die Gestaltungsoffenheit von Kanban deutlich (die dann allerdings mit den Mindestvorgaben der Verfasser kollidiert).

Genau die Offenheit an dieser Stelle, durch die klar wird, dass Kanban zwar in Form eines Boards mit Kartenoder Kacheln dargestellt werden kann, aber keinerswegs dargestellt werden muss, ist übrigens eine, die grossen Teilen der Kanban-Community fehlt (Alternativen sind Ampelfarben, Kontroll-Charts, Kummulative Flussdiagramme, etc.). Alleine in dieser Hinsicht ist Vacantis und Colemans Guide eine wertvolle Ergänzung.

Auffällig ist ausserdem, dass ihr Regelwerk nochmal kürzer und komprimierter ist als die von Scrum und der Kaban University. Einschliesslich Inhaltsverzeichnis umfasst er nur neun Seiten. Aufgrunddessen kann man ihn auch ohne grossen Aufwand als Ergänzung zum nur unwesentlich längeren Guide der Kanban University benutzen, alleine um verschiedene Blickwinkel auf das Thema Kanban zu bekommen, dass sich mit einem Dokument alleine kaum abbilden lässt.

¹Sogar die URL ist ähnlich: https://kanbanguides.org statt https://scrumguides.org
²Ähnlich wie im Scrum Guide ist der Theorieteil sehr kurz und besteht im Wesentlichen aus einer Aufzählung zugrundeliegender Methoden und Frameworks
³Es gibt zwar eine deutsche Übersetzung, da deren Wortwahl mitunter etwas sperrig ist bevorzuge ich das englische Original

Bürokratie

Bild: Flickr / Queensland State Archives - Public Domain

Die Klagen über zu viel Bürokratie kennt man aus nahezu jeder grösseren Organisation, egal ob in der freien Wirtschaft, in der staatlichen Verwaltung oder bei Nichtregierungsorganisationen. Erstaunlich ist dabei aber in fast allen Fällen, dass es sich um eher unspezifische Beschwerden handelt - meistens werden nur zu viele Prozesse und Vorschriften genannt, ohne die genauer zu beschreiben. Dabei ist es durchaus möglich, diese aufzuschlüsseln, um sie deutlich klarer erkennen und ggf. beseitigen zu können.

Wichtig ist dabei, dass die offiziellen Kategorien nur eingeschränkt hilfreich sind, da es sich bei ihnen oft um Sammelbegriffe für verschiedene vorgeschriebene Tätigkeiten handelt. So kann sich z.B. hinter einer Sorgfaltspflicht oder einer Nachweispflicht alles Mögliche verbergen, mit je nach Einzelfall deutlich unterschiedlichen Auswirkungen. Eine differenzierte Betrachtung macht daher Sinn, und mit ihr kommt man zu dieser (sicherlich unvollständigen) Liste bürokratiefördernder Vorgaben:

Durchführungspflichten

Hier geht es darum, wer was zu tun hat und in welcher Reihenfolge der Arbeitsschritte. Das kann abstrakt sein, wie bei der Vorgabe eines Vier-Augen-Prinzips, aber auch komplizierte vorgegebene Abläufe umfassen, z.B. bei der Wartung einer Maschine.

Informierungspflichten

Aufbauend auf den Durchführungspflichten geht es als nächstes darum, andere über das was man selbst getan hat (oder vorhat) in Kenntnis zu setzen. Detailgrad und Empfänger können dabei je nach Fall unterschiedlich sein, wichtig ist, dass irgendjemand informiert worden ist.

Begründungspflichten

Bereits etwas einengender. Es reicht nicht mehr, zu berichten, was man getan hat oder vorhat, es muss auch klar werden, aus welcher Motivation heraus das geschieht, mit welchem Ziel oder auf wessen Anweisung. Eine häufige Erweiterung ist die Begründung für den Durchführungszeitpunkt.

Dokumentationspflichten

Die Formalisierung der Informierungspflichten. Der Kommunikationskanal zur Übermittlung der Informationen ist nicht mehr frei wählbar sondern vorgegeben, am häufigsten ist dabei die Vorgabe der Schriftform (ggf. verstärkt durch die Pflicht zur persönlichen Identifikation durch Unterschreiben).

Formatierungspflichten

In gewisser Weise die Formalisierung der Formalisierung. Es reicht nicht mehr, in irgendeiner Form die Informationen über die eigenen Handlungen zu übermitteln, auch die Struktur dieser Information wird jetzt vorgegeben, z.B. in Form einer Tabelle oder eines Formulars.

Nutzungspflichten

Die Vorgabe von Arbeitswerkzeugen. Das können physische Werkzeuge sein, digitale Werkzeuge aber auch bestimmte Räumlichkeiten, in denen Arbeit verrichtet werden muss. Eine noch immer erstaunlich häufige Extremform ist die an den hierarchischen Rang gekoppelte Vorgabe der Tintenfarbe.

Unterlassungspflichten

Das Spiegelbild der Nutzungspflichten. In einer restriktiven Variante ist alles zu unterlassen, was nicht explizit zur Nutzung vorgegeben ist, in einer offeneren Variante sind nur solche Handlungen zu unterlassen, die explizit verboten werden. Beides kann aber ggf. zu Handlungsunfähigkeit führen.

Anhörungspflichten

Während die zuvor genannten Pflichten eine Person oder Organisationseinheit selbst betreffen, werden jetzt andere einbezogen, die ein Recht darauf haben, ihre Meinung zu den Sachverhalten abzugeben, über die sie informiert wurden (ggf. mit der Erweiterung, dass diese festzuhalten ist).

Beteiligungspflichten

Mit dieser Stufe ist das Mitwirken Anderer nicht mehr optional und auf die Meinungs- oder Bewertungsabgabe beschränkt, sondern verpflichtend und in die Arbeitsabläufe fest eingebunden, z.B. in Form einer Zulieferung oder Qualitätssicherung.

Kenntnisnahmepflichten

Das Gegenstück zu den Informierungspflichten. Wer auch immer Informiert wird darf das nicht einfach ignorieren, sondern ist verpflichtet, es selbstverantwortlich zur Kenntnis zu nehmen und von sich aus zu reagieren, wenn er angehört oder beteiligt werden will.

Überprüfungspflichten

Die Steigerung der Kenntnisnahmepflichten. Übermittelte Informationen müssen nicht nur zur Kenntnis genommen, sondern auf ihre Richtigkeit und ggf. Angemessenheit überprüft werden, einschliesslich einer Rückmeldung, wenn eines davon nicht gegeben sein sollte.

Genehmigungspflichten

Die Formalisierung und Generalisierung der Überprüfungspflichten. Übermittelte Informationen müssen nicht mehr nur zur Kenntnis genommen und ggf. überprüft werden, ohne eine auf dieser Überprüfung beruhende Freigabe darf der jeweilige Arbeitsvorgang nicht fortgesetzt werden.

Rechtfertigungspflichten

Spätestens an dieser Stelle wird es unangenehm. Wenn ein Überprüfungs- oder Genehmigungsprozess zu einem negativen Ergebnis führt, ist zu erklären, durch welche Fehler oder Nachlässigkeiten es überhaupt dazu kommen konnte.

Qualifizierungspflichten

Sowohl als Folge von Überprüfungs- oder Genehmigungsprozessen oder vorbeugend kann es sein, dass bestimmte Ausbildungen oder Schulungen verpflichtend vorgegeben werden, in der Regel vermunden mit der Pflicht zum Nachweis der Teilnahme oder des Bestehens einer Prüfung.

Weiterbildungspflichten

Die Verstetigung der Qualifizierungspflichten. Es reicht nicht mehr aus, Ausbildungen oder Schulungen einmal zu durchlaufen, es muss darüber hinaus in regelmässigen Abständen zu Wiederholungen, Auffrischungen, Erweiterungen oder Resensibilisierungen komen.

Stellenbesetzungspflichten

Eine Konsequenz aus den zuvor genannten Pflichten. Um ihre Erfüllung mit der nötigen Kapazität, Qualifikation und Aufgabenteilung durchführen zu können, sind Planstellen notwendig. Eigentlich nur ein Symptom der Bürokratisierung, selbst wenn es oft selbst für Bürokratie gehalten wird.

Wie oben gesagt, diese Auflistung ist sicher noch unvollständig, dass die Befolgung aller dieser Pflichten in erheblichem Ausmass zu Bürokratie im Sinn von formalisierter, nicht Mehrwert schöpfender Verwaltungsarbeit führen kann (und meistens auch führen muss), dürfte aber offensichtlich sein. Und trotzdem ist es so, dass sie alle in jeder grösseren Organisation anzutreffen sind (wenn auch in unterschiedlicher Ausprägung).

Dass das so ist, liegt daran, dass keine dieser Vorgaben komplett unsinnig ist, in jeder von ihnen wird man einen Kern von Sinnhaftgkeit finden können, schliesslich erfüllt Bürokratie durchaus einen Zweck. Es kann also kein Ziel sein, sie (oder die ihr zu Grunde liegenden Pflichten) komplett abzuschaffen. Stattdessen muss es darum gehen, die Bürokratie auf das sinnvolle Mindestmass zu beschränken - im Zweifel durch regelmässige Evaluierung und Justierung.

Und jetzt kommt es: um Evaluierung und Justierung durchführen zu können, sind wieder einige der oben genannten Pflichten notwendig, selbst wenn auch diese zwangsläufig bis zu einem gewissen Grad bürokratisch sein müssen Die finale Pointe lautet also - um Bürokratie zu bekämpfen, braucht man noch mehr Bürokratie.

From XP to TCR & Limbo

Zu den (wenigen) Kritikpunkten an Extreme Programming (XP) gehört, dass es seit ca. dem Jahr 2000 nicht mehr weiterentwickelt wurde. Diese Einschätzung ist allerdings falsch - wie XP-Erfinder Kent Beck in diesem Interview erklärt, gibt es mittlerweile mindestens einen neuen Bestandteil: TCR (mit dieser Abkürzung wurde der etwas sperrige ursprüngliche Name test && commit || revert ersetzt). Verkürzt gesagt: neu geschriebener Code wird in kleinsten Mengen sofort nach dem Schreiben durch einen vordefinierten Test geprüft - und bei fehlgeschlagenem Test automatisch gelöscht, so dass man neu beginnen muss. Extreme Programming, aber noch ein bisschen extremer als bisher.

Das Interview umfasst ausserdem noch verschiedene weitere Themen. Wer ein bisschen Zeit hat und sich auch zu denen informieren will, kann das auf der Website zum Interview tun, wo es nicht nur das Transkript gibt, sondern in ihm eingebettet weitere Videos, die das jeweilige Thema vertiefen.

Flooding the Zone

Wer die politischen Ereignisse in den Vereinigten Staaten von Amerika verfolgt, wird mit hoher Wahrscheinlichkeit früher oder später an einem merkwürdigen Slogan vorbeikommen: Flooding the Zone (with Shit). Dahinter verbirgt sich ein Vorgehen, das genauso obszön ist, wie es sich anhört, das man aber auch in vielen Veränderungsvorhaben beobachten kann. Sobald man es sich bewusst gemacht hat, erkennt man es an vielen Stellen wieder.

Popularisiert worden ist das Flooding the Zone von Steve Bannon, dem ehemaligen Chief Strategist (obersten Berater) von Donald Trump. Angelehnt an eine Taktik aus Mannschaftssportarten, in denen darunter Überzahlspiel verstanden wird, erklärte er es zum Ziel, eine Diskussion derartig mit Themen zu überladen, dass es der Gegenseite nicht mehr möglich ist, sich auf eines davon zu konzentrieren um es auszudiskutieren oder zu widerlegen.

Da das Change Management in grossen Organisationen wesentlich aus dem Erklären, Hinterfragen und Ausdiskutieren von Veränderungsmassnahmen besteht, sind die Einsatzmöglichkeiten des Flooding the Zone in diesem Bereich offensichtlich. Differenziert betrachtet treten dabei verschiedene Dimensionen auf. Zum einen ist es von Bedeutung, mit welchem Ziel die Flutung stattfindet, des Weiteren womit und zuletzt ob es sich dabei um eine taktische oder eine strategische Massnahme handelt.

Das Ziel des Floodings kann sowohl das Vorantreiben als auch das Behindern von Veränderungen sein. Im ersten Fall findet es statt indem immer neue Ideen und Initiativen angekündigt oder thematisiert werden, im zweiten indem immer neue Bedenken, Argumente und Fragen gegen laufende oder kommende Vorhaben aufgeworfen werden. Die Absicht in beiden Fällen: die andere Seite soll aus dem Konzept gebracht werden, ständig reagieren müssen und dadurch sprunghaft und konfus erscheinen.

Bei der Frage womit die Überflutung stattfindet gibt es erneut zwei Möglichkeiten. Entweder mit realen (ggf. aber kleinteiligen oder redundanten) Bedenken, beliebt sind dabei solche, die einen (angeblich) drohenden Verlust von Qualität, Verlässlichkeit oder Rechtssicherheit zum Gegenstand haben. Alternativ kann man das tun, was Bannon Flooding the Zone with Shit nannte - absurd überspitzte, unsinnige oder falsche Argumente vorbringen, nur mit dem Ziel, der anderen Seite die Lust an dem Thema zu nehmen.

Ob ein Flooding taktischer oder strategischer Natur ist, entscheidet sich schliesslich am jeweiligen Zeit-Horizont. Eine taktische Überflutung findet kurzfristig im Rahmen eines Gesprächs, Meetings oder Mail-Verkehrs statt und hat das Ziel, sie ohne Ergebnis enden zu lassen. Eine strategische Überflutung findet langfristig und kontinuierlich statt und meistens auch gleichzeitig auf verschiedenen Hierarchie- oder Granularitätsebenen und in verschiedenen Organisationseinheiten. Ziel ist eine allgemeine Konfusion.

Gegenmassnahmen gegen das Flooding the Zone sind anstrengend aber möglich. Naheliegend ist es, dieses Verhalten anzusprechen (und damit wahrnehmbar zu machen), auf seine Destruktivität hinzuweisen und darum bitten, es zu unterlassen. Findet es dann trotzdem weiter statt greift die alte Weisheit, dass die Kultur eines Unternehmens vom schlechtesten Verhalten definiert wird, das vom Management zugelassen wird. Mit anderen Worten - es wird zu einem Führungs- oder Disziplinar-Thema.

Soll das Thema Team- oder Gruppen-intern gelöst werden, sind gemeinsame Vereinbarungen der beste Weg. Die können zum Beispiel darin bestehen, für Bedenken oder Änderungs-Anträge eigene Termine oder Agenda-Punkte zu schaffen und die anderen davon freizuhalten, oder zu Beginn eines Meetings die Agenda gemeinsam zu priorisieren (z.B. durch Dot-Voting), wodurch destruktive Agendapunkte gar nicht erst diskutiert werden, oder erst dann wenn die konstruktiven bereits geklärt sind.

Bei all diesen Überlegungen sollte man aber eine weitere nicht vergessen - nicht jeder, der regelmässig eine andere Meinung hat, betreibt gerade Flooding the Zone. Es kann auch sein, dass sich mit der Zeit quer durch eine gesamte  Organisation so viel dysfunktionales Verhalten herausgebildet hat, dass alle anderen mittlerweile abgestumpft sind und es nicht mehr wahrnehmen. Herauszufinden zu können was davon gerade der Fall ist, ist dann die entscheidende Kunst, an deren Beherrschung man arbeiten sollte.

10 Jahre

Das hier ist das zweite sich surreal anfühlende Jubiläum, das ich in relativ kurzer Zeit feiern darf. Vor etwa einem halben Jahr habe ich auf lean-agility.de den tausendsten Eintrag veröffentlicht, und ich war leicht erschlagen von dieser Menge. Heute geht es weiter - vor genau zehn Jahren habe ich mit Hallo Welt den ersten dieser Einträge veröffentlicht, und wieder fühle ich mich erschlagen, diesesmal von der Länge der seitdem vergangenen Zeit - ein Jahrzehnt!

"Jedem Anfang wohnt ein Zauber inne, so auch diesem hier. Mal sehen wieviel Zeit ich für diese kleine Internetpräsenz hier aufbringen werde." waren meine ersten Worte die ich hier geschrieben habe, und tatsächlich hatte ich Zweifel daran, dass ich ein Jahr lang in der Lage sein würde, regelmässig etwas zu veröffentlichen. Jetzt sind zehn Jahre vorbei, und ich habe im Schnitt zwei mal pro Woche auf den Publish-Button gdrückt. Wie gesagt, insgesamt mehr als tausend mal.

Im tausedsten Artikel habe ich geschrieben, dass mich im Rückblick fast am meisten erstaunt, dass mir nicht irgendwann die Themen ausgegangen sind, mittlerweile kann ich sagen, wie ich das geschafft habe. Sobald ich ein Thema interessant oder amüsant finde (was oft genug vorkommt) speichere ich es bewusst oder unbewusst im Kopf ab und mache bei Gelegenheit einen ersten, stichpunktartigen Entwurf. Von denen fliegen im CMS dieser Seite erstaunlich viele herum - zur Zeit sind es ca. 80.

Und sobald ich irgendwann etwas Leerlauf habe, Zeit totschlagen oder mich ablenken will, habe ich etwas zu tun - ich schaue, was alles da ist, und wenn mir zu einem Thema etwas einfällt schreibe ich einige Sätze dazu. Aus diesen kurzen Kreativ-Phasen (die manchmal nur wenige Minuten lang sind) entsteht dann nach und nach mein Content (natürlich gibt es auch Momente, in denen ich spontan einen ganzen Text herunterschreibe, aber das ist im Vergleich seltener der Fall).

Es gibt in der Psychologie die Theorie, dass das Aufschreiben von Gedanken dazu führt, dass man diese besser strukturieren, einordnen, verarbeiten und verinnerlichen kann. Wenn das stimmen sollte, habe ich mir seit 2015 mit dieser Website ein Werkzeug geschaffen, dass mir zu einem differenzierten und reflektierten Blick auf meine Arbeitswelt verhilft. Nicht das schlechteste für jemaden, zu dessen beruflichem Alltag es gehört, in technischen und sozialen Systemen Muster und Dynamiken zu erkennen.

In gewisser Weise ist der Zauber des Anfangs geblieben. Mal sehen wie lange noch (zur Zeit ist aber noch kein Ende absehbar).

The Cult of the agile Amateur

Von Zeit zu Zeit lohnt es sich, Bücher heranzuziehen die zwar zu Zeiten des Aufschwungs der agilen Methoden verfasst wurden, sich aber nicht mit ihnen im engeren Sinn befassen, sondern breitere gesellschaftliche Trends zum Gegenstand haben. Da die agile Bewegung Teil der Gesellschaft ist, bietet diese Art der Betrachtung einen interessanten Blickwinkel: ist auch sie von diesen Trends beeinflusst worden, und wenn ja wie? Ein Buch mit dem man derartig vorgehen kann ist The Cult of the Amateur.

Verfasst wurde es im Jahr 2007 vom britisch-amerikanischen Unternehmer und Schriftsteller Andrew Keen. Vordergründig richtete es sich gegen das in dieser Zeit aufkommende partizipative Internet, damals Web 2.0 genannt (heute würde man von User generated Content sprechen). Auf einer grösseren Ebene handelte es sich aber gleichzeitig um eine harte Kritik an der zu dieser Zeit häufigen Verklärung unwissenschaftlicher und autodidaktischer, dafür aber meinungsstarker Diskussionsteilnehmer.

Zum Kontext: im ersten Jahrzehnt des dritten Jahrtausends ist es zu einer nie zuvor dagewesenen Demokratisierung des Zugangs einzelner Personen zur Öffentlichkeit gekommen. Services wie Wordpress, Youtube, Twitter, Facebook und Wikipedia erlaubten es jedem Menschen, Beiträge zu jedem beliebigen Thema zu veröffentlichen und damit potentiell den allgemeinen Diskurs zu diesem Thema mitzugestalten. Aus demokratietheoretischer Sicht eine grossartige Entwicklung.

Was Keen an dieser Entwicklung kritisierte, war, dass durch den Wegfall der bisherigen Verlags- und Sender-Oligopole nicht nur die Zugangsbarrieren wegfielen, sondern auch die mit ihnen verbundenen Qualitätssicherungs-Mechanismen. Während vorher vorwiegend Inhalte eine grosse Öffentlichkeit erreichten, die gut begründet, in sich konsistent und überprüfbar waren, verschob sich das plötzlich zu solchen, die auf starken Einzelmeinungen zu aktuellen Themen basierten.

Und an dieser Stelle kommen wir zurück zur agilen Bewegung. Selbst wenn viele der damals noch neuen agilen Frameworks basierend auf Praxiserfahrungen entstanden waren, waren die jeweiligen Entstehungsbedingungen so überschaubar und einzelfallspezifisch, dass sich nicht klar sagen liess, was Kausalität war und was Korrelation. Um ein bekanntes Beispiel zu nennen - Extreme Programming (XP) basierte ursprünglich auf den Erfahrungen eines einzigen Teams, das nur wenige Jahre lang bestand.¹

Dass dieser anfangs eher überschaubare Anwendungsfall es zeitweise schaffte, zum populärsten agilen Famework zu werden,² lag wesentlich an den zuvor erwähnten demokratisierten Zugängen zur Öffentlichkeit, im Fall von XP in Form von Wikis wie wiki.c2.com oder wiki.org, in denen Praktiker und Enthusiasten in selbst gewähltem Umfang und Detailgrad Inhalte veröffentlichen konnten, die weltweit von jedem Inhaber eines internetfähigen Computers gelesen werden konnten.³

In diesem Fall hat die Geschichte zwar ein Happy End, da sich XP mit der Zeit in der Praxis bewährte, in anderen Fällen war der Ausgang aber nicht ganz so gut - dass viele Versuche agile Arbeitsweisen einzuführen kläglich gescheitert sind, liegt ganz wesentlich daran, dass das dafür gewählte Vorgehen lediglich auf starken Meinungen und anekdotischer Evidenz beruhten, verfälscht durch Survivor Biases, Hindsight Biases und ähnliche Phänomene.

Zu den klassischen, immer wieder auftretenden Fehlern gehören dabei Über-Simplifizierung ("man muss nur alle Mitarbeiter schulen"), Personalisierung ("die Personen X, Y und Z wollen sich nicht ändern"), Blaupausen-Gläubigkeit ("Spotify hat das auch so gemacht"), Confirmation Bias ("ich habe schon immer gesagt: einfach machen! Endlich sehen das jetzt alle so.") und Ausblendung von Zusammenhängen ("warum reden wir hier über Budgetierung, wir wollten doch über die agile Transformation sprechen").

Dabei ist keiner dieser Fehler unvermeidbar, in der psychologischen und betriebswirtschaftlichen Forschung und Literatur werden sie seit über hundert Jahren behandelt, einschliesslich der Möglichkeiten sie zu erkennen und zu verhindern. Wer eine wissenschaftliche oder praktische Ausbildung im Produkt- oder Projektmanagement durchlaufen hat, wird sie mit grosser Wahrscheinlichkeit vermeiden oder abschwächen können.⁴

Dass eine Kenntnis dieser Forschungsergebnisse und Fachliteraturen in agilen Transitionenzu selten erwartet wird, liegt schliesslich an etwas, das man in Anlehnung an Keen als "Cult of the agile Amateur" bezeichnen könnte: der Verklärung unwissenschaftlicher und autodidaktischer, dafür aber meinungsstarker Scrum Master und Agile Coaches als "Organisationsrebellen" oder Inhaber eines "agilen Mindsets", deren Expertise keiner Valisierung bedarf.

Um Missverständnisse zu vermeiden: dieser Cult of the agile Amateur ist nicht in den verschiedenen agilen Frameworks selbst verankert, sondern ist eher aus den oben erwähnten Besonderheiten der Entstehungszeit zu erklären. Und überall dort wo agile Transitionen langfristig erfolgreich gewesen sind, ist er entweder von Anfang an vermieden worden oder er wurde mit der Zeit erkannt und nach und nach eingedämmt und beseitigt.

Wie eine solche Gegenbewegung vor sich gehen kann ist dann wieder von Einzelfall zu Einzelfall unterschiedlich, so dass es dafür kein Patentrezept gibt (ein empirisch-analytisches Vorgehen ist aber ein guter Startpunkt). Lediglich eines lässt sich mit Sicherheit sagen: was nur in den allerseltensten Fällen helfen wird sind agile Zertifizierungen.

¹Zur Klarstellung: XP ist grossartig, aber das wissen wir heute, damals liess sich das noch nicht absehen
²Um das Jahr 2000, es wurde erst später von Scrum überholt
³Wir können uns heute nicht mehr vorstellen, wie revolutionär das damals war
⁴Natürlich treten dafür andere Risiken auf, z.B. Methodismus

Larman's Law (V)

Bild: Pexels / Tara Winstead - Lizenz

Mit der Zeit haben sich viele Menschen Gedanken über die ungeschriebenen Gesetze der Organisationsentwicklung gemacht und versucht sie (auf manchmal seriöse, manchmal aber auch eher zynische Art) auf Papier zu bringen. Besonders produktiv war dabei Craig Larman, der Erfinder von LeSS, der insgesamt fünf Gesetze verfasst hat, die er Larman's Laws of Organizational Behavior genannt hat. Heute soll es hier um das Fünfte von ihnen gehen. Es lautet:

In large established orgs culture follows structure. And in tiny young orgs, structure follows culture.

Zum Hintergrund: Larman verfasste dieses Gesetz als Reaktion auf die in der agilen Community verbreitete Ansicht, dass Veränderungsvorhaben grundsätzlich  damit beginnen müssten, die Kultur zu verändern. Da diese bestimmend für alles weitere wäre, würden alle weiteren Veränderungen mehr oder weniger von selbst folgen. Diese Ansicht hält er (zumindest in grösseren Organisationen) für nicht zutreffend und realitätsfern.

Die von Larman (und vielen Anderen) beobachtete Realität ist eine andere. In ihr ist die Unternehmenskultur (also die Summe aller informellen Erwartungen, Glaubenssätze, Deutungsmuster, etc.) stark von der Formalstruktur beeinfusst, bzw. eine Reaktion auf sie (zur Formalstruktur gehören Regel, Hierarchien, Anweisungen, o.A.). Ein einfaches Beispiel: in einem Unternehmen in dem alles zentral und geheim entschieden wird, wird es kaum zu einer partizipativen Mitmach-Kultur kommen.

In einem derartigen Umfeld haben Veränderungsvorhaben daher eine höhere Erfolgswahrscheinlichkeit, wenn sie mit strukturellen Veränderungen beginnen, z.B. mit der Delegation von Entscheidungen auf untere Hierarchieebenen, wodurch eine passive Gehorsams-Kultur dort nicht mehr möglich ist. Ob die dadurch herbeigeführten Kulturveränderungen die erhofften sind oder ob und wie nachgesteuert werden muss, ist dann nochmal ein separates Thema, das weit in das Change Management hineinführt.

Nun zum umgekehrten Fall: es gibt einige Firmen in denen es doch so ist, dass die Unternehmenskultur die Unternehmensstruktur definiert. Wie kann das sein? Larman gibt die Antwort, indem er darauf verweist, dass das vor allem in kleinen und jungen Organisationen gegeben ist. In derartigen Umgebungen sind Strukturen meistens nur rudimentär vorhanden (da noch nicht nötig) und verfestigen sich erst mit der Zeit. Diese Verfestigung bildet dann in der Regel die Kultur ab.

Diese Unterscheidung lohnt es, im Hinterkopf behalten zu werden: in grossen und alten Unternehmen überschreibt die Struktur die Kultur, in kleinen und jungen Unternehmen überschreibt die Kultur die Struktur. Wie immer mit Abstufungen und Ausnahmen, aber eine brauchbare Fausregel, auf die man den Beginn eines Veränderungsvorhaben aufsetzten kann. Und umgekehrt gibt sie einem eine klare Idee mit, wie man es besser nicht versuchen sollte.

Kommentierte Links (CXXIII)

Grafik: Pixabay / Brian Penny - 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.

David Pereira: The Refactoring Guide for PMs Tired of Endless Tech Discussions

Eine der klassischen Herausforderungen, an denen (nicht nur agile) Entwicklungsteams scheitern, ist die Erklärung von Refactoring für Menschen ohne IT-Hintergrund. Wer mal wieder in dieser Situation ist, kann sich an diesen Artikel von David Pereira halten. In ihm wird nicht nur das Konzept erklärt, sondern auch warum es wichtig ist, wie mayn es falsch machen kann, wie man es richtig machen kann, wann man es machen sollte und was typische Formen von Refactoring sind.

Jeff Gothelf: OKRs for Organizational Agility

Auf die Gefahr hin, versehentlich in die Falle von Maslows Hammer zu laufen - man kann Objectives und Key Results (OKRs) eigentlich für so gut wie alles benutzen. Jeff Gothelf zeigt hier ein eher selten verwandtes Einsatzgebiet auf: die Verwendung von OKRs für agile Transitionen (oder wie er es nennt, organisatorische Agilität). Im Wesentlichen geht es dabei darum, Reaktions- und Durchlaufzeiten messbar zu verkürzen. Schlicht, aber wirkungsvoll.

Erik de Bos: Using the Flow Channel to Measure Team Effectiveness

Neben dem Durchfluss von zu erledigenden Aufgaben durch ein Verarbeitungssystem hat der Begriff Flow im Arbeitskontext eine zweite Bedeutung: den idealen Zustand, in dem eine Person oder ein Team werder überfordert noch unterfordert ist, und daher hochmotiviert und leistungsbereit. Erik de Bos differenziert das mit Hilfe des so genannten Flow Channel aus, in dem ein Team versuchen kann, dauerhaft zu bleiben, um optimale Ergebnisse erbringen zu können.

Marty Cagan: The Product Model and Agile

Dieser Blogpost hier ist durchaus erstaunlich, da sein Verfasser, Produktmanagement-Thought Leader Marty Cagan, über lange Zeit dafür bekannt war, öffentlich schlecht über agile Rollen und Frameworks zu sprechen. Irgendetwas scheint seine Meinung geändert zu haben, denn auf einmal findet er es nicht nur grundsätzlich ok wenn agil gearbeitet wird, er erkennt sogar an, dass Agile Coaches dazu einen wertvollen Beitrag leisten können - was er allerdings vor allem im Delivery-Bereich sieht.

Sebastian Sigl: High-Performing Teams Focus On These 4 Areas to Remain Successful

Zugegeben, Sebastian Sigls Überschrift klingt auf den ersten Blick so, als würde als nächstes eine Plattitüden-Sammlung folgen. Tatsächlich ist seine Übersicht aber durchaus sinnvoll, denn er zählt nicht nur die vier Bereiche auf (Anpassungsfähigkeit, Zielsetzung, Psychologische Sicherheit und Feedback), sondern er zeigt auch Fehler auf die man vermeiden sollte, wenn man hier besser werden möchte - darunter auch einige unerwartete, wie z.B. ein zu grosses Vertrauen in Expertenwissen.

Zwerge auf den Schultern von Riesen

Bild: Wikimedia Commons / Japanische Akademie der Wissenschaften - CC BY 4.0

Manchmal kommen die tragischen Entwicklungen schnell und unverhofft. Nur zwei Tage nachdem ich sein bahnbrechendes Paper The New New Product Development Game empfohlen habe ist Ikujirō Nonaka gestorben, einer der grossen Vordenker der Methoden, die wir heute ale Agil bezeichnen würden. Was dadurch in Erinnerung gerufen wird: leider müssen wir uns in den nächsten Jahren auf weitere derartige Trauer-Nachrichten einstellen - und die werden Folgen haben.

Zur Einordnung: grossteils aufbauend auf das oben erwähnte Paper sind die meisten agilen Vorgehensmodelle (Scrum, XP, IT-Kanban, Agile Testing, etc) zwischen den späten 80er und frühen 2000er Jahren entstanden. Da ihre Erfinder bereits damals über einige Jahre oder sogar Jahrzehnte Berufserfahrung verfügten, sind sie mittlerweile in ihren 60ern, 70ern oder 80ern angekommen. Und obwohl sie hoffentlich noch lange leben werden - nicht jeder dürfte 90 werden, so wie Nonaka.

Das ist deshalb von Bedeutung, weil diese Vordenker bisher durch ihre öffentlichen Meinungsäusserungen ein Korrektiv zu den verbreiteten esoterischen oder komerziell getriebenen Fehldeutungen ihrer Arbeit bilden konnten, legitimiert dadurch, dass sie schliesslich selbst am Besten sagen können, was sie mit ihren Ansätzen beabsichtigt haben und was nicht (das bekannteste Beispiel dafür dürfte ihre einhellige Ablehnung des Scaled Agile Framework / SAFe sein).

Mit dem absehbaren Verschwinden dieser Stimmen (das auch bereits durch einen altersbedingten Rückzug aus der Öffentlichkeit geschehen kann) dürfte es in der Zukunft immer weniger mit einer derartigen Autorität ausgestattete Widersprüche gegen absichtliche oder versehentliche Verfremdungen der agilen Ideen und Prinzipien geben. Und noch bedenklicher: kommerzielle Organisationen wie Scrum Alliance, SAFe, Kanban University und PMI werden diese Autorität vermutlich für sich beanspruchen.

Um so wichtiger wird es werden, die von den agilen Pionieren verfassen Originalquellen (von denen es aufgrund der Entstehung der Agilität in den Schatten ohnehin viel zu wenige gibt) in Erinnerung zu behalten und als Massstab für die Bewertung neuer Entwicklungen zu benutzen, von der Forschung Nonakas und Takeuchis über die frühen Vorträge auf den OOPSLA- und Agile-Konferenzen bis zu den Büchern und Artikeln der Verfasser des Manifests für agile Softwareentwicklung.

Die grosse Herausforderung dabei wird es sein, derartig auf den Schultern der Riesen zu stehen, dass deren Absichten gewahrt bleiben, ohne dass es zu einer rückwärtsgewandten Erstarrung der damit verbundenen Methoden kommt. Andererseits - verglichen mit dem, was zwischen den späten 80er und frühen 2000er Jahren geleistet wurde, ist das eine fast schon einfache Aufgabe. Und noch haben wir genug Zeit um uns von den agilen Vordenkern inspirieren zu lassen.

Ein Hoch auf die Wissenschaft

Wenn man Aussagen sucht, auf die die agile Bewegung sich einigen kann, dann wird man schnell auf die stossen, dass agiles Arbeiten Empirie- und Evidenz-getrieben sein sollte, oder mit anderen Worten: wissenschaftlich. Ernst genommen bedeutet das zum Einen, dass man im Kleinen selbst versuchen sollte, so vorzugehen, zum Anderen aber auch, dass man sich für wissenschaftliche Erkenntnisse interessieren sollte, die das eigene Arbeitsfeld betreffen - und wer danach sucht, findet Einiges.

Ich bin mit der Zeit auf eine ganzen Reihe wissenschaftlicher Papers gestossen und spiele gerade mit dem Gedanken, eine Beitragsreihe zu starten, in der ich jeweils einige von ihnen vorstelle. Ob es wirklich dazu kommt wird sich zeigen, für den Moment habe ich aber zumindest fünf, die mir erwähnenswert erscheinen. Sie gehen quer durch alle möglichen Themen durch und sind natürlich eine subjektive Auswahl, aber eine die ich empfehlen möchte. Hier sind sie:

Takeuchi, Hirotaka; Nonaka, Ikujiro: The New New Product Development Game

Eine der Initialzündungen dessen, was wir heute agile Produktentwicklung nennen. Vereinfacht gesagt haben Takeuchi und Nonaka Feldforschung betrieben um herauszufinden, warum manche Firmen effektiver Produkte entwickeln als andere. Ihre Forschungsergebnisse sind zwar schon 40 Jahre alt, haben aber nichts von ihrer Aktualität eingebüsst.

Verwijs, Christiaan; Overeem, Barry: The Double-Edged Sword Of Diversity In Teams

Manchmal tun Erkenntnisse weh. Verwijs und Overeem haben versucht, den in der agilen Bewegung verbreiteten Glaubenssatz zu validieren, dass Diversität in Entwicklungsteams etwas grundsätzlich Gutes ist. Ihre Erkenntnis - ganz so einfach ist es nicht. Zwar gibt es eindeutig positive Effekte, in einigen Dimensionen ist Diversität aber ohne Auswirkungen oder führt sogar zu Nachteilen.

Eilers, Karen; Peters, Christoph; Leimeister, Jan: Why the agile mindset matters

Diese Arbeit ist wirklich verdienstvoll. Zum ersten mal habe ich hier gesehen, wie versucht wird, den umstrittenen Begriff des "Agilen Mindset" neutral und sachlich einzuordnen und zu untersuchen. Ein wohltuender Kontrast zu dem eher esoterischen und zum Teil sogar übergriffigen Umgang, der sonst in der Beschäftigung mit diesem Begriff vorherrschend ist.

Flyvbjerg, Bent; Budzier, Alexander: Why Your IT Project May Be Riskier than You Think

Der bemerkenswerte Forschungsschwerpunkt von Bent Flyvbjerg sind (scheiternde) Grossprojekte. Dass die häufig ausser Kontrolle geraten ist zwar bekannt, er differenziert es aber entscheidend aus. Vereinfacht gesagt: es geht nicht immer schief, aber wenn es schiefgeht, dann richtig. Und: die Gründe dafür sind identifizierbar und es gibt erfolgsversprechende Gegenmassnahmen.

Kühl, Stefan: Das Scharlatanerieproblem – Zwischen Professionsbildung und Professionalisierung

Noch einmal Erkenntnisse, die weh tun. Über die Zeit hat sich Stefan Kühl die Rolle des Hofnarren der (agilen) Berater-Szene erarbeitet, der er ihre Unzulänglichkeiten aus soziologischer Perspektive und mit erkennbarer Freude vorhält. An dieser Stelle mit Fokus auf einem der grossen strukturellen Defizite: dem weitgehenden Fehlen verbindlicher professioneller Standards zur Qualitätssicherung ihrer Arbeit.