On Lean and Agility

Witzig ist das auf gleich zwei Ebenen: zum einen, weil es die durch die DevOps-Community wabernden Buzzword-Wolken treffend persifliert, zum anderen weil in dem ganzen Wortsalat einige sehr scharfe Abrechnungen mit häufigen Umsetzungs-Fehlern versteckt sind. "DevOps is a mindset - you build it, you run it. Now you're bad at building and running it." Soll tatsächlich so vorkommen.

Und für alle die jetzt in der entsprechenden Stimmung sind - hier sind fünf weitere, die ich in den vergangenen Jahren bereits geteilt habe:

• Agile Night Xmas
• An Agile Little Christmas
• Agile Christmas Eve in Lockdown
  
• Agile Xmas Song
• Do they know this Agile Thing?

Für die Playlist nach dem einen Eggnogg zu viel.

Eine kleine Anekdote: in einem meiner längeren Einsätze war ich mit der Begleitung einer agilen Konzern-Transformation beauftragt, in deren Rahmen ich über mehrere Monate Product Owner und Scrum Master ausbildete, Schulungen durchführte und bei der Erstellung einer neuen Aufbau und Ablauforganisation beriet. Im Großen und Ganzen ein Auftrag, auf den ich gerne zurückblicke - mit einer Ausnahme, bei der ich mich etwas fahrlässig verhalten habe.

In einem Workshop mit mehreren angehenden Scrum Mastern stellte irgendjemand einen der Klassiker unter den Einsteiger-Fragen: für was Scrum eigentlich die Abkürzung wäre.¹ Ich war gleichermassen amüsiert und leicht genervt, da ich den Ursprung dieses Namens bereits mehrfach erklärt hatte. Und aus einem Affekt heraus antwortete ich mit einem Witz: "Scrum steht für Scaled Corporate Rational Unified Model". Alle lachten kurz, ich dachte mir nichts dabei und der Workshop ging weiter.

Man kann sich vermutlich denken, was als nächstes passiert ist: Zu den Aufgaben der anwesenden neuen Scrum Master gehörte auch die Erstellung von Schulungsunterlagen, und als ich die zwei Wochen später zu Gesicht bekam, musste ich kurz nach Luft schnappen. SCRUM wäre eine Abkürzung, hiess es da, und sie würde stehen für Scaled Corporate Rational Unified Model. Mir war sofort klar, wo diese Fehldeutung ihren Ursprung hatte - bei mir.

Sensibilisiert durch dieses Erlebnis achte ich seitdem darauf, dass humorige oder sarkastische Bemerkungen von mir klar als solche zu erkennen sind, um nicht wieder zur Quelle für eine fehlerhafte Information zu werden. Und ich achte darauf, wo andere Agile Coaches versehentlich mit flapsigen Bemerkungen Falsch-Informationen verbritet haben. Und was soll ich sagen - selbst wenn es zum Glück nicht häufig ist, es kommt immer wieder vor.

Bei einem Kunden stand in der Dokumentation, dass die Kanban-Methode nach ihrem Erfinder Kenji Kanban benannt worden wäre. Bei einem anderen, dass SAD MF ein vielversprechendes Skalierungs-Framework wäre, dass man näher evaluieren sollte. Mehrfach habe ich erlebt, dass Jira erkennbar ironisch als agiles Framework bezeichnet wurde, einmal mit der Anmerkung, dass Entwickler die es benutzen nicht mehr selbst denken müssten. Offensichtlicher Sarkasmus, der aber nicht erkannt wurde.

Wie es zu derartigen Transfer-Missverständnissen kommt ist dabei einfach erklärbar: Für den Agile Coach ist sene Arbeit entweder Routine, die er durch Scherze aufzulockern versucht, oder eine Frustrationserfahrung, die in zu Sarkasmus verleitet. Die ihn umgebenden Menschen befinden sich dagegen in einer Sondersituation, sind noch unsicher was von dem neuen Wissen relevavant ist und verinnerlichen vorsichtshalber alles. Was daraus folgt ist offensichtlich.

Gerade aufgrund dieser Wissens-Asymetrie befindet sich der jeweilige Agile Coach in einer Position, in der er sich verantwortungsvoll verhalten muss. Wie oben gesagt, Humor und Sarkasmus sind in Ordnung, sie müssen aber als solche erkennbar sein, im Zweifel durch die Anmerkung, dass die letzte Aussage bitte nicht ernst zu nehmen ist. Das hilft allen anderen, hilft aber auch dem Agile Coach selbst, der sich weniger Sorgen machen muss, dass von ihm versehentlich das Falsche gelernt wird.

Bereits seit einiger Zeit taucht dieses Video von Dorota Mleczko immer wieder in meinen Social Media-Feeds auf. Mittlerweile ist es auch in Youtube verfügbar, so dass man auch  sich dort (und hier) anschauen kann, wie eine Unterhaltung zwischen Scrum, Kanban, Extreme Programming und SAFe aussehen würde.

Ich halte die vier Frameworks trotz aller absichtlichen Überzeichnung für gut getroffen. Wer sich beruflich mit ihnen (und ihrer Wahrnehmung durch ihre Anwender) beschäftigt, wird einiges davon im Video wiedererkennen. Ich sage nur: Fishbone.Diagramm.

Kaum schaut man zwei Jahre nicht hin, schon veröffentlicht jemand neue Musik. Chad Beier ist seinem Hobby treu geblieben und hat weitere, auf das Thema der agilen Produktentwicklung umgetextete, Coverversionen bekannter Pop- und Rockhits aufgenommen (siehe hier, hier, hier und hier). Wunderbar geeignet für die Party nach dem nächsten erfolgreichen Release.

Die Weihnachtsfeiertage sind viel zu beschaulich für steile Thesen, tiefschürfende Analysen oder methodische Meta-Betrachtungen. Daher gibt es heute etwas ganz anderes: Musik. Adam Janosch setzt sich für die agile Festtagsstimmung ans Klavier.

Je nach persönlicher Vorliebe empfehle ich übrigens, zu seinem Lied mit Glühwein, Eggnogg oder Weihnachtsbock anzustossen. Der stimmungshebende Effekt wird dadurch nochmal verstärkt.

Ein wirklich schön gemachtes Video, das eine weit verbreitete Meinung gut zusammenfasst: die, dass das agile Arbeiten sich von seinen Ursprüngen entfernt hat und zunehmend in Ritualen erstarrt. Leicht überspitzt, aber mit einem wahren Kern.

Etwas verwirrend ist der Titel, ein "Agile Paradoxon" wäre ein (wie auch immer gearteter) Widerspruch in sich, nicht eine Entwicklung in eine merkwürdige Richtung. Aber das nur am Rand.

Bild: Pexels / DS Stories - Lizenz

Man hört ja in letzter Zeit immer wieder, dass es so toll wäre, ein agiles Mindset zu haben. Ist es aber nicht. Wir haben es ausprobiert und es hat überhaupt nicht geklappt!

Dabei waren wir echt offen. Unmittelbar nachdem unser Personalvorstand auf seinem Yoga-Retreat gelernt hat, dass man nur die richtige geistige Haltung braucht, damit sofort alles besser läuft, haben wir die Tat ergriffen und alle unsere HR-Führungskräfte in Weiterbildungen zu Achtsamkeit, Spiral Dynamics und Emotionscoaching geschickt. Das lief auch wirklich total super, einige haben sich sogar ein Enneagram tätowieren lassen.

Wir haben es auch geschafft Fehlentwicklungen einzufangen. Statt sich auf Meditation und NLP einzulassen wollte unsere IT alles auf ihre technische Ebene herunterziehen und uns erzählen, dass Implementierungsdetails wie Clean Code, Build Pipelines und Testpyramiden etwas mit Agilität zu tun hätten (was soll das mit geistiger Haltung zu tun haben?). Zum Glück konnten wir klarmachen, dass wir es sind, die entscheiden was agil ist und was nicht, schliesslich sind wir zertifizierte Agile Mindsetter.

Auch weitere gefährliche Missverständnisse haben wir in dem Zusammenhang korrigieren können. Stellen Sie sich vor, die wollten unser agiles Budget nehmen um ihre Leute in Mob-Programming zu trainieren. Mobbing, das geht doch gar nicht. Wir haben das sofort untersagt und stattdessen alle auf verpflichtende Kurse zu gewaltfreier Kommunikation geschickt. War auch höchste Zeit, denn einige Entwickler sind ausfällig geworden als sie das gehört haben. Die mussten direkt nochmal teilnehmen.

Einen Volltreffer gelandet haben wir bei der Besetzung der Stelle des Agile Coach. Den alten, den die IT irgendwoher besorgt hatte, haben wir weggeschickt, der hatte nur ganz merkwürdige Ideen. Beyond Budgeting und Lean Governance zum Beispiel, wir glauben, der hat nur mit dem Zufallsgenerator Wörter zusammengewürfelt. Sein Nachfolger dagegen hat verstanden worum es geht: er hat allen Mitarbeitern eine Spiral Dynamics-Farbe zugeordnet. Endlich Klarheit, wer das richtige Mindset hat und wer nicht!

Basierend darauf haben wir dann die agile Transition in der Belegschaft durchgeführt, mit dem Ziel ein einheitliches agiles Mindset zu bekommen. Allen Kollegen bei denen die Farben Beige, Purpur, Rot, Blau und Orange diagnostiziert wurden, haben wir Tetralemma-Aufstellungen und AQAL-Coachings als Entwicklungsziele gesetzt, damit sie sich aus ihren eigenen geistigen Beschränkungen befreien können. Und glauben Sie uns, die Coaches die wir dafür geholt haben waren nicht billig.

Das Ergebnis war dann auch erstmal überragend. Jedem Mitarbeiter konnte man die Worte "agil ist ..." zurufen und sie wurden wie aus der Pistole geschossen mit "... ein Mindset" beantwortet. Bei Problemen jeglicher Art wurde immer zuerst über die Einstellung der Beteiligten geredet. Und die Querulanten, die das alles bis zum Schluss nicht mitmachen wollten, haben dann irgendwann gekündigt und machen jetzt ihr DevOps, CI, TDD, XP oder was die sonst noch fälschlicherweise für agil halten woanders.

Sie sehen also, wir haben nicht nur alles dafür getan um ein agiles Mindset zu bekommen, wir haben es sogar erfolgreich geschafft, die Agile Mindsetter-Zertifikate sind der Beweis. Aber jetzt kommts: trotzdem sind Arbeitsgeschwindigkeit, Produktqualität, Reaktionsfähigkeit oder Kundenzufriedenheit nicht nach oben gegangen sondern nach unten. Wir müssen deshalb die unbequeme Wahrheit aussprechen: Wir haben es mit dem agilen Mindset versucht, aber es funktioniert nicht. Untertanenkultur war doch besser.

[/ironie off]

Bevor sich jemand aufregt - natürlich ist alles was weiter oben steht populistisch, polemisch und überspitzt. Aber: alles was ich dort aufgeschrieben habe, habe ich irgendwann mal im Rahmen verschiedener agiler Transition erlebt, sogar die Enneagram-Tätowierung und den zertifizierten Agile Mindsetter. Ein Grossteil des angeblichen Veränderungswiderstands in Belegschaften lässt sich damit erklären, dass ihnen derartige Esoterik als Bestandteil von Agilität verkauft wird.

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

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.

Bild: Wikimedia Commons / Popo le Chien - CC0 1.0

Bei der Vermittlung komplexer oder komplizierter Inhalte geht nichts über eine bildhafte Sprache. Dinge die man sonst nur schwer im Gedächtnis behalten könnte werden auf diese Weise gleich doppelt in den Erinnerungen verankert, sowohl in Wort- als auch in Bildform. Wenn es dann noch gelingt Metaphern zu finden die ungewöhnlich oder kreativ sind werden diese im Zweifel sogar bereitwillig weitererzählt und gelangen so dauerhaft in ein kollektives Gedächtnis.

Eines der bekanntesten Beispiele dafür ist The evolution of software architecture - Italian food perspective (siehe hier). In ihm werden verschiedene Paradigmen der Software-Architektur dadurch nachvollziehbar gemacht, dass sie mit italienischen Nudelgerichten verglichen werden. Schon lange trage ich den Gedanken mit mir herum, dass sich diese Bildsprache auch auf die Typologie von Entwicklungsteams anwenden lässt. Gedacht, gemacht! Hier kommen sie, die Pasta-shaped Teams.

Bild: Pixabay / Salahgraphic - Lizenz

Der erste Team-Typ sind die Spaghetti-Teams. Charakterisiert sind sie dadurch, dass ihre einzelnen Mitglieder sehr lange an sehr schmal geschnittenen Aufgaben sitzen, wodurch es ihnen schwerfällt ihren gemeinsamen Inhalt (symbolisiert durch das Ragù Bolognese) zusammenzuhalten. Spricht man mit den Mitgliedern findet man immer wieder lange Enden die irgendwohin führen, im Zweifel in Legacy-Tätigkeiten wo noch "Restaufwände" zu erledigen sind. Alles wirkt irgendwie unordentlich.

Bild: Wikimedia Commons / PoiseWinsTitles - CC BY 2.0

Lasagne-Teams bringen schon etwas mehr Ordnung zusammen, indem sie sich in Schichten organisieren (z.B. Frontend, Middleware, Backend). Das beseitigt zwar das gröbste Durcheinander, allerdings besteht das Risiko, dass die Schichten aufeinander verrutschen und nicht mehr genau aufeinanderpassen wenn man versucht handhabbare Teile abzutrennen. Und in alle seitlichen Richtungen laufen die Inhalte in die Breite um sich mit allem zu vermischen was daneben liegt.

Bild: Wikimedia Commons / Alpha - CC BY-SA 2.0

Cannelloni-Teams gehen noch einen Schritt weiter. Der Inhalt ist bereits von überschaubarer Grösse und wird ausserdem durch eine feste Hülle zusammengehalten, die es einfacher macht einzelne Einheiten unabhängig von den anderen zu bewegen. Es besteht auch nicht mehr die Gefahr, dass die Inhalte an den Seiten mit anderen ineinanderfliessen - zumindest nicht an allen. Vorne und hinten gibt es noch offene Stellen, z.B. bei Konzeption oder Betrieb. Hier können sich noch wertvolle Teile der Kontrolle entziehen.

Bild: Wikimedia Commons / Cyclone Bill - CC BY-SA 2.0

Diesen Kontrollverlust haben Ravioli-Teams nicht mehr. Die Inhalte werden auf allen Seiten zusammengehalten, jedes einzelne Objekt ist damit für sich genommen vollständig und servierbereit. Die entsprechende Organisationsform wäre das crossfunktionale Team, das keine Abhängigkeiten nach Aussen mehr hat. Allerdings: das Ganze ist dadurch so gross und unhandlich, dass es am Ende zerteilt werden muss und dann doch wieder offene Seiten hat, die kaum zusammenzuhalten sind.

Bild: CCNull / Marco Verch - CC BY 2.0

Gelöst wird auch diese letzte Herausforderung schliesslich durch die Tortellini-Teams. Alles was auf die Ravioli-Teams zutrifft, trifft auch auf sie zu - mit einer weiteren Verbesserung: es ist gelungen sie auf eine so kleine Grösse zu bringen, dass sie bis zum Schluss nicht aufgeteilt werden müssen. Das Äquivalent wäre z.B. ein mit Microservices arbeitendes Feature-Team. Die Kontrolle über die Inhalte ist hier am grössten, die potentielle Unordnung am geringsten.

Und das sind sie, die Pasta-shaped Teams in ihrer ganzen Vielfalt. Dass aus einer "agilen Perspektive" die Ravioli- und Tortellini-Teams den anderen zu bevorzugen sind dürfte klar sein, in der Realität dürften die meisten agil arbeitenden Teams allerdings eher Cannelloni-artig sein. Letztendlich gilt aber, dass jede Variante besser ist als die jeweils vor ihr genannten. Auch ein Lasagne-Team kann im Vergleich zu einem Spaghetti-Team ein Fortschritt sein.

Lieder von Chad Beier habe ich schon zwei mal hier eingebunden, jeweils mit "agilen Coverversionen" von zeitlosen Pop/Rock-Klassikern. Auch dieses hier ist im Original zeitlos (Have Yourself a Merry Little Christmas von Judy Garland, bzw. von Frank Sinatra) in dieser Version aber wieder so umgedichtet, dass ein Bezug zur agilen Softwareentwicklung besteht.

Selbst wenn die Eingängigkeit ein bisschen dadurch verloren geht, dass die Ursprungsversion in Deutschland bei weitem nicht so bekannt ist wie in den USA, kann man sich das Ergebnis gut anhören. Und mit seinem Rauschebart wirkt Beier im Video auch sehr wie ein Weihnachtsmann.

Heute mal wieder etwas Unfug zwischen all den ernsten Themen. Irgendjemand ist auf die grossartige Idee gekommen den Beitrag eines fiktiven Software-Entwicklers in seinem Daily Scrum zu einem Lied zu verarbeiten. Erkennbar einige typische Antipattern parodiend natürlich.

Bemerkenswert ist übrigens auch die erstaunlich gute Aufnahmequalität, die ja bei den von privaten Liebhabern eingesungenen Agile-Songs nicht immer gegeben ist. Dieses Lied ist gut genug um in eine Team-Playlist aufgenommen zu werden ohne zwischen den anderen durch schiefe Stimme oder rauschenden Ton aufzufallen.

Grafik: Pixabay / Revzack - Lizenz

Du kommst aus dem (IT-)Produkt- oder Projektmanagement? Du möchtest Deinen Bekanntheitsgrad erhöhen? Du möchtest als Sprecher auf Konferenzen eingeladen werden und Artikel in Fachpublikationen veröffentlichen? Dann ist das hier die Möglichkeit für Dich - Du musst nichts weiter tun als zu verkünden dass "Agile", der zur Zeit dominierende Denkansatz, tot ist. Das ist mittlerweile ein bewährtes Vorgehen, so bewährt sogar, dass es eine Blaupause dafür gibt. Hier ist sie:

I. Bau Deine Reputation auf

Zu Beginn Deines Vortrages oder Artikels solltest Du hervorheben wie relevant Deine Meinung ist. Praktischerweise kannst Du dafür alles als Beleg nennen - wenn Du schon lange mit agilen Frameworks arbeitest bist Du die weise Koryphäe, mit wenig Erfahrungen bist Du einer der jungen Wilden, wenn Du gar keine hast bist Du der unbefangene und sachliche Beobachter ausserhalb des Systems. Egal was es ist, Du kannst es als Grund dafür nennen, dass gerade Du zu originellen Gedanken in der Lage bist.

II. Verteile vergiftetes Lob

Auf gar keinen Fall solltest Du sagen, dass Agile schon immer Mist war, damit erzeugst Du zu frühen Wiederspruch. Streiche heraus, dass die Verfasser des Agilen Manifests bahnbrechende Pioniere waren, denen nur Hochachtung gebührt. Lass aber auch Relativierungen einfliessen, etwa, dass das Manifest "zur damaligen Zeit" genau das Richtige war, oder dass es die Arbeit "auf der Team-Ebene" revolutioniert hat. Selbst wenn Du es nicht aussprichst, jeder wird spüren, dass gleich ein "aber" folgen wird.

III. Prangere vermeintliche Unzulänglichkeiten an

Hier kannst Du kreativ sein. Egal ob "Agile funktioniert nicht in grösseren Organisationen", Agile funktioniert nicht mit Product Discovery" oder "Agile funktionier nicht in bestimmten Ländern" - je steiler die These desto besser. Empirische Belege dafür brauchst Du keine, es reicht anekdotische Evidenz, also eigene Erfahrungen (die keiner überprüfen kann). Ein schöner Seiteneffekt: Gegenbeispiele kannst Du als "verkopft" und theoretisch" abtun wenn Du sie nicht selbst erlebt hast.

IV. Hebe einzelne bekannte Negativ-Beispiele hervor

Zum Glück kannst Du hier aus dem vollen Schöpfen. Nimm irgendein Beispiel eines (angeblich) agil organisierten Vorhabens das schiefgelaufen ist und erhebe es zum Beweis, dass Deine persönlichen Erfahrungen universell richtig sind. Wenn Du weisst welcher methodische Ansatz dort verwendet wurde kannst Du zur Verstärkung Elemente aus dem Kontext reissen und Dich über sie lustig machen, etwa über das Wimmelbild auf der SAFe-Startseite oder über Begriffe wie Tribe und Gilde.

V. Immunisiere Dich

Irgendwann wirst Du es nicht mehr vermeiden können Dich mit Beispielen geglückter Umsetzung der agilen Frameworks auseinanderzusetzen. Dem kannst Du zuvorkommen indem Du selbst einige davon aufführst, aber mit einem überraschenden Dreh: behaupte, dass diese Organisationen nur deshalb erfolgreich sind weil sie das Vorgehen an ihre Bedürfnisse angepasst haben. Je nach der Agenda die Du verfolgst kannst Du sie dann als "nur noch eingeschränkt agil" oder sogar "post-agil" bezeichnen.

VI. Begeistere alle mit einer alternativen, besseren Lösung

Auf zum grossen Finale. Nachdem Du alle davon überzeugt hast, dass Agile wirklich tot ist bleibt nur noch Eines zu tun - die Alternative zu benennen. Je nach Deinen persönlichen Vorlieben (oder Deinen politischen Absichten) kann die darin bestehen alles wieder stärker zu steuern und zu kontrollieren, es kann aber auch Dein neuer, "post-agiler" Ansatz sein, mit dessen Vermarktung Du vorhast Geld als Berater oder Vortragsredner zu verdienen. Du machst das alles ja schliesslich nicht umsonst.

Und das war es auch schon. Nur sechs einfache Schritte und schon ist Agile tot und Du als neuer Thought Leader etabliert. Angesichts der Tatsache, dass das Ganze mit dieser Blaupause zu einer wirklich einfachen Übung wird ist es kein Wunder, dass das bereits seit Jahrzehnten von zig verschiedenen Leuten nach genau diesem Muster gemacht wird. Nur gut, dass die Agilität in all der Zeit noch nicht gestorben ist, so dass man sie immer wieder erneut für tot erklären kann.

[Ironie off] Inspiriert ist dieser Text von Jahn Meckes Artikel Agile is Dead (So is COBOL, XP, RAD, UML, SAFe, etc) und von zu vielen "Agile is Dead"-Meinungsbeiträgen in den letzten 10 Jahren. Meine persönliche Meinung: Agile wird zwar irgendwann in Vergessenheit geraten, aber nicht so wie in diesen Beiträgen beschrieben sondern aus banaleren Gründen. Mehr dazu hier.

Als ich vor ein paar Monaten entdeckt habe, dass Chad Beier angefangen hat auf Scrum umgetextete Lieder neu aufzunehmen hatte ich direkt gehofft, dass noch weitere nachkommen. Tatsächlich wurde ich nicht enttäuscht, mittlerweile gibt es drei weitere. Mein persönliches Highlight ist die neue Version von Nirvanas Smells like teen spirit, aber auch die beiden anderen kann man sich gut anhören. Ich bin gespannt wieviele noch kommen werden.

 Ich muss mich im voraus entschuldigen, an der einen oder anderen Stelle klingt dieses Lied ein kleines bisschen schief. Aber da müssen wir jetzt durch, denn was diese Damen und Herren aufgenommen haben ist eine Coverversion von Queens Bohemian Rhapsody, mit auf Scrum und Kanban umgedichteten Texten. Und diese Kombination kann nicht unbeachtet bleiben.

Ganz nebenbei: gefühlt gibt es auf dieser Seite mittlerweile schon so viele "Agile Lieder", dass ich fast über eine eigene Kategorie nachdenken könnte.

Ein weiterer Beleg für die Soft Power of Scrum: Chad Beider, ein amerikanischer Agile Coach, hat begonnen bekannte Musikstücke mit einem neuen, auf Scrum bezogenen Text zu versehen und neu aufzunehmen. Im Moment sind das drei (neben den beiden die hier eingebunden werden noch ein drittes, dessen Weihnachts-Thema aber nicht mehr zur Jahreszeit passt). Hoffen wir dass bald noch weitere dazukommen.

Passend zu diesem tragischen und verrückten Jahr ist dieses Weihnachtslied ein schwermütiges, das den Geist der erzwungenen Remote-Arbeit einfängt, dabei aber gleichzeitig auch einen trotzigen Optimismus verströmt. Vermutlich die Haltung die wir jetzt alle brauchen können.

Übrigens: wer möchte findet auf der Youtube-Seite des Videos eine Möglichkeit für einen guten Zweck zu spenden. Auch das passt ja zu Weihnachten.

Auf die Gefahr hin in diesem Monat eine leichte Schlagseite in Richtung "agile Netzfundstücke" zu bekommen - das hier ist dann doch zu bemerkenswert um es hier nicht einzubetten. Der "Agile Song"  von Adam Janosch wurde gestern auf dem kölner Scrumtisch zwischen den Sessions gespielt und zumindest bei mir ist er direkt im Ohr hängen geblieben.

Um es auf eine Meta-Ebene zu hieven: dass es Werke wie dieses Lied gibt würde ich in ein Phänomen einordnen, dass ich einmal The Soft Power of Scrum genannt habe. Viele Umsetzungen dieses und anderer Frameworks sind bewusst verspielt, bunt und geekig gehalten, und das nicht etwa als von oben verordnetes Image-Programm sondern weil die an der Umsetzung Beteiligten sich über das rein Berufliche hinaus mit dem Vorgehen identifizieren und ihre Energie und Kreativität einfliessen lassen. Das ist etwas was nur sehr wenige andere Projekt-, Produkt- oder Prozessmanagement-Ansätze über sich sagen können.

Nachtrag 12.12.2020:

Jetzt auch in einer Weihnachts-Version.