Seit einiger Zeit gibt es in der agilen Szene etwas Katzenjammer. Aufträge gehen zurück, agile Transformationen werden laut den Informationen eigener Kontakte wieder zurückgerollt, das Geschäft boomt nicht mehr. Bashing agiler Arbeitsweisen scheint gerade en vogue. Ist das nicht (mal wieder) zu kurzsichtig?
Mir kam die Idee, einen Artikel darüber zu schreiben, denn mir fiel auf, dass inzwischen offenbar viele auf den oben genannten Zug aufgesprungen sind - sogar bekanntere Leute, die regelmäßig eigene Blogbeiträge an Abonent:innen versenden und bis dato agile Hilfestellung gegeben haben. Selbst die reden teilweise nun davon, dass "Agile" in Zukunft wahrscheinlich ein Nischendasein führen werde /1/.
Verbrannte Erde
Zu Beginn recherchierte ich zum als Überschrift geplanten Slogan. Ziemlich weit oben in der Ergebnisliste erschien eine Quelle, die aus Sicht von Betroffenen argumentiert /2/, und das ist ja immer sehr interessant.
Über den in der Quellenangabe genannten Artikel auf "Entwickler.de" kann man beobachten, was offenbar häufig bei den vielen Einführungen von Agil als schaler Beigeschack übrigbleibt: allein Begriffe sind schon „verbrannte Erde“. Man sagt jetzt nicht mehr „agile“, sondern „modern agile“, weil man etwas anderes meint als das, was inzwischen mit dem erstgenannten Begriff verbunden wird. Ich kenne Kolleg:innen, die darüber gesprochen haben, dass man Scrum-Events in manchen Kontexten eigentlich nicht mehr guten Gewissens bei ihrem Namen nennen kann (was ja auch irgendwie schlecht ist für die Völkerverständigung unter Agilist:innen), weil allein beim Begriff bei vielen Teammitgliedern schon der Rolladen der Negativ-Assoziation herunterrasselt. Klischee-Beispiel: „Lasst uns mal 'ne Retrospektive machen“, und alle denken an Glitzer, Einhörner, Gelaber ohne Substanz oder noch schlimmer: Psycho-Gelaber ohne Substanz und Konsequenz, Teammitglieder ohne Commitment, den Stress, den sie haben, wenn sie die durch diesen Termin „verlorene“ Zeit durch Hardcore-Programmierung wieder aufholen zu müssen meinen, und so weiter, und so fort.
(Bild generiert von Bing Copilot)
Wir setzen sehr oft gar kein Agile um
"(...) Ron Jeffries beispielsweise schreibt, dass Entwickler „Agile“ aufgeben sollten (...). Genauer: Entwickler sollten aufhören, das zu tun, was heutzutage „Agile“ genannt wird. Wir sollen uns von dem Begriff lösen. (...) die Werte und Prinzipien des Agilen Manifests sind immer noch richtig, nur die Umsetzung ist oft toxisch für alle Beteiligten. (...)"
Das kann ich in Teilen bestätigen, denn ich arbeite seit 2020 im agilen Kosmos. Damals habe ich mir beim Lesen über Scrum und das Agile Manifest eindringlich vorzustellen versucht, was jeweils der dahinterliegende Sinn, die Essenz ist. Wenn man sich gedanklich damit beschäftigt, weiß man irgendwann auch, was gemeint ist, man erkennt, wie sich die gemeinsame Arbeit anfühlen muss. In nicht-erwerbsmäßigen Kontexten hatte ich schon das Glück, „echt“ agil arbeiten zu dürfen, und es hat immer sehr viel Spaß gemacht (gell, Pierre Smits?).
Von Baumhäusern, Selbstorganisation und gemeinsamer Identifikation
Apropos Pierre: Er war es, der einmal das Beispiel von einigen Jungen brachte, die sich gemeinsam im Wald ein Baumhaus bauen wollten. Da gab es keinen Chef, der alles vorkaute, sondern alle fühlten sich gemeinsam verantwortlich für die Entstehung und den Unterhalt des Baumhauses. Man nennt es wohl "Identifikation": Alle sahen das Zielobjekt als lohnenswertes gemeinsames Projekt, freuten sich, daran mitzuarbeiten, und es war fast egal, wer was machte - hier auch gleich der kleine Nebenverweis auf Konzepte wie "t-shape", "pair working" (in Abwandlung...), Selbstverpflichtung und Know-how-Transfer. Jeder machte alles, und man half sich gegenseitig, ohne darüber ein Wort zu verlieren. War ein Loch im Dach, überlegte man gemeinschaftlich, wie es zu stopfen sei, und niemand wartete einfach, bis die anderen alles gemacht hatten.
Ziellos ins Nirgendwo
Ein nicht zu unterschätzendes Problem scheint zu sein, dass die Ziele, die an Teams herangetragen werden, ja sehr häufig "von außen" kommen, dass niemand fragt, ob sich die Umsetzenden damit identifizieren können. Sie dürfen dann ggf. gemeinsam mit einem schwitzenden Scrum Master oder Teamcoach versuchen, sich ihre eigene Arbeit, ihre möglichen Freiräume dabei und die Erfüllung der Unternehmensziele irgendwie zurechtzudengeln. Schwierig ist auch, dass sich diejenigen, die die Ziele formuliert haben, gegebenenfalls nicht die Mühe mit deren Findung gegeben haben, die es benötigt hätte. Dazu kommen dann noch Zutaten wie: jemand "von oben" stellt die Teams zusammen, d. h. schließt einfach diejenigen, die gerade etwas mehr Zeit haben als die anderen und deren Profil halbwegs zu den zu erledigenden Aufgaben passt, gemeinsam in einen Raum.
Wir brauchen (die richtigen) Kennzahlen
Eine Reihe von Scrum Mastern, so bekommt man derzeit häufiger als früher mit, seien in ihren jeweiligen Kontexten zu "Feel Good Managern" geworden, und die Erkenntnis dringt bei Unternehmen erst mit Verspätung durch, dass sie selten oder nie nach Kennzahlen gefragt haben, mit denen der Scrum Master zeigen kann, wie er/sie zu Verbesserungen beiträgt und sein/ihr Gehalt wert ist. KPIs für „Verbesserung“ in verschiedenen Bereichen stehen vielfältig zur Auswahl.
KPI-Beispiele aus unserem letzten Lean Coffee
Im Lean Coffee Karlsruhe/Frankfurt Ende Januar kamen zu diesem Thema einige gute Beiträge (wir sind ja auch die Guten 😉). Jemand trug bei, dass, wenn ein Backlog zu lang sei, man die Gesamtdurchlaufzeit für die Summe der Einträge berechnen könne. Wenn dann die Umsetzung des Backlogs „1,5 Jahre“ brauche, „dann werden Stakeholder sich verhalten wie auf dem Schulhof“. Prozesse, so ein weiterer Punkt, würden außerdem verlangsamt, wenn kein Abbruchkriterium definiert wurde. Praxisbeispiel sind Teams, in denen keine „definition of done“ ausgearbeitet wurde. Manche nervt das Herumreiten auf solchen Konzepten, aber sie haben alle ihre Berechtigung. Definiert man nämlich nicht, was alles passieren muss, um ein Stück Arbeit als „fertig“ betrachten zu können und zur Abnahme zu schieben, wird womöglich nie etwas fertig. Kreative Entwickler sind dann in Gefahr, goldene Wasserhähne anzuprogrammieren – und regelmäßig zu „vergessen“, ihre Entwicklertests durchzuführen etc. pp. Es gilt: „Je kürzer die timebox für eine Fertigstellung, desto besser“, man nehme z. b. einen Sprint…
Kanban? Kann man!
Empfehlungen anderer Lean-Coffee-Gäste der o. g. Sitzung lauten, sich bei Kanban zu bedienen, um etwa die Prognostizierbarkeit von Lieferungen aus dem Team zu erhöhen. Hier wird zwischen reproduzierbaren Aufgaben (Kennzahlen z. B. Durchsatz, Durchlaufzeit, Liegezeiten, Feedbackzeiten) und nicht-reproduzierbaren Aufgaben (für die die genannten Kennzahlen zwar ebenfalls genutzt werden können, die aber schwerer zu standardisieren und zu analysieren sind) unterschieden.
Wann lernen wir es endlich?
Experten in der agilen Szene, die sogar schlaue (?) Bücher geschrieben haben, empfehlen schon seit 2017, auf die „time to learn“ zu sehen /3/, um nicht nur die Messung der stumpfen Erstellung eines Produktes vorzunehmen, sondern auch den feinen Glanz der Lernkurve zu berücksichtigen, der das Unternehmen verändert, „schlauer“ für die Zukunft macht.
Aus der Teamzentrierung herauskommen
Wertvolle Hinweise, die uns aus unserer eigenen kleinen Suppenteller-Welt hieven, sind außerdem die Betrachtung von "non-functional requirements" oder nicht-funktionalen Anforderungen, die eng mit der unterliegenden Systemarchitektur zusammenhängen. Anwendungsbeispiel: "Funktioniert mein in Team X entwickelter Login auch noch, wenn sich da draußen 10.000 User:innen gleichzeitig einzuloggen versuchen?". Auch ein Blick, der über das eigene kleine Atom „Team“ hinausgeht, hilft, z. B. auf „Capabilities“. Über diese kann der früheste Zeitpunkt, an dem jemand im Unternehmen eine Idee hatte, aufgezeichnet werden, anstatt dass der Startpunkt einer neuen Entwicklung mit der Erstellung der ersten UserStory in Team Y (sichtbares im System angelegtes Arbeitspaket) gleichgesetzt wird. Hilfreich kann weiterhin sein, Ablaufprozesse im Unternehmen näher zu betrachten, etwa Genehmigungsprozesse, da diese häufig von der grundsätzlichen Art geprägt sind, wie das Unternehmen „funktioniert“.
Prozesse und "Gesundheit"
An dieser Stelle reiche ich auch den im Lean Coffee gegebenen Hinweis weiter, dass Verbesserungsmetriken natürlich immer temporär angewendet werden und regelmäßig zu überprüfen sind. Zur Verfügung stehen außerdem Gesundheitsmetriken /4/ sowie Prozessmetriken. Letztere bewerten die „Effizienz“ von internen Prozessen. Die Ergebnisse aus Prozessmessungen können wiederum als Grundlage für die Bildung von Verbesserungsmetriken verwendet werden (ChatGPT über den Zusammenhang von Prozess- und Verbesserungsmetriken, natürlich ohne eigene Quellenangabe).
Elementar ist dabei die Analyse des eigenen Tuns über beispielsweise die Kennzahl „fit for purpose“/F4P /5/. Der Teilnehmer des Lean Coffee ergänzt: „Treffe ich den unteren Wert nicht, kann ich den Laden zumachen…“ Klar: Wenn ich als Unternehmen nicht das liefere, was meine Kundschaft möchte, bin ich irgendwann nicht mehr im Markt.
Welches Umfeld erleben wir bei unserer Arbeit?
Verweisen möchte ich an dieser Stelle auch auf einen Artikel eines meiner Mit-Blogger, Egdar, der eine prägnante Beschreibung dessen liefert, wie sich der Inhalt von "Arbeit" für uns im Laufe der Zeit verändert und erweitert hat /6/.
Arbeit ist für uns heute wertiger als früher, erhält von uns viel mehr Bedeutung, ungeachtet der Bemühungen um „work life balance“, die ich als Gegenbewegung zu dem sehe, was Edgar in seinem Artikel als ungesunde Entwicklung beschreibt. Inhalte aus Edgars Artikel passen zu dem Buch "Die angstfreie Organisation" /7/. Die Mehrheit der Unternehmen, in denen ich gearbeitet habe, ist von der angstfreien Organisation recht weit entfernt, wenn auch die Methoden, die dort praktiziert wurden, deutlich harmloser sind als das, was im Buch explizit als extremes Praxisbeispiel beschrieben wird. Dort wird u. a. der Diesel-Skandal von Volkswagen seziert und die dahinterstehende "Kultur", die diesen Skandal erst möglich gemacht hat, ans Licht gebracht. Edmondson kristallisiert für Unternehmen, in denen psychologische Sicherheit fehlt, folgende (O-Ton) „Vorlage“ heraus: „(…) unerreichbare Zielvorgaben, eine Hierarchie mit Befehl und Kontrolle, die durch Angst motiviert, und Menschen, die beim Scheitern um ihren Job bangen (…)“. Das sind alles Zutaten, die, metaphorisch gesprochen, in unserem agilen Gericht nichts zu suchen haben. Edmondsons Forschung hat gezeigt, dass man Lernen, Kreativität und Innovation, wenn psychologische Sicherheit im entsprechenden Unternehmen(sbereich) fehlt, sofort in die Tonne treten kann.
Bashing und Mimese
Als ich über die aktuelle Situation nachdachte - wie die Menschheit im Laufe der Geschichte "agil" mal wieder einzuführen versucht, weithin nicht richtig umsetzt, es dann aber "agil" anlastet (die "Methode“ ist schlecht etc.) - kam mir die Idee, einmal ChatGPT danach zu fragen. Wieso springen Menschen nicht selten in Massen auf Trends auf, und woher kommt das? Dass wir alle zur "Herde" dazugehören wollen, weil das in der Urzeit das Überleben sicherte, weiß ich natürlich, ich wollte es aber etwas genauer wissen. In der ersten Antwort tauchte das von mir nie gehörte Wort "Mimese" auf. Auf Nachfrage erfuhr ich: "(...) In der Psychologie und Soziologie beschreibt Mimese das menschliche Verhalten, sich an andere anzupassen. Das geschieht oft unbewusst, um sozial akzeptiert zu werden.(...)" (Quellen wurden leider mal wieder nicht angegeben, und ich habe zugegebenermaßen nicht mehr weiter recherchiert.) Offenbar ist es in bestimmten Kreisen jetzt gerade angesagt, der agilen Welt den Rücken zu kehren.
Agil: Unsere eigentliche Natur (?) (!)
Ich glaube, wie wahrscheinlich viele andere, dass agiles Arbeiten eigentlich die für uns natürliche Form der Zusammenarbeit ist, die die besten Ergebnisse bringt und die Beteiligten am zufriedensten macht. Jeder erhält hier die Gelegenheit, den eigenen Beitrag zu leisten, und es finden sich automatisch diejenigen, die an einer gemeinsamen Sache arbeiten wollen. "Die Arbeit findet die richtigen Leute", wie manchmal gesagt wird. Für uns geht es in meinen Augen nach wie vor darum, wie wir "entlernen", was wir über Jahrzehnte hinweg im Arbeitskontext gemacht haben, um uns anschließend (wieder) mit dem zu füllen, was in uns schon vorhanden war, als wir noch Kinder waren. An diese Stelle passt, wie ich finde, wieder eines meiner Lieblingszitate in diesem Kontext. Es stammt aus dem Film Avatar I: „Es ist nicht leicht, ein Gefäß zu füllen, das bereits voll ist.“ /8/ Auf der Suche nach dem genauen Zitat stieß ich übrigens auf ein schönes anderes, das einer der Schlüssel für unser aller Umlernen sein könnte: „Der Geist ist nicht wie ein Gefäß, das gefüllt werden soll, sondern wie Holz, das lediglich entzündet werden will.“ /9/ Da denke ich sofort an den Spaß beim Spiel, der auch bei vielen Erwachsenen schnell entfacht werden kann, und an das eindrückliche Erfahrungslernen durch Simulationen…
Steter Tropfen höhlt den Stein – auch Umlernen braucht Iterationen
Als Verkäufer:in, so las ich vor Jahren, muss man bis zu ca. 13 Mal (!) ein Produkt platzieren, bevor der potenzielle Kunde dann endlich die Inhalte der Ansprache "verarbeitet" hat und es als mögliches erstrebenswertes Produkt betrachtet (Quelle nicht mehr abrufbar durch Quellenamnesie des Schreiberlings, lt.
der Seite "rep.ai" sind heute durchschnittlich 8 Kontakte erforderlich) /10/. Die notwendigen Wiederholungen für ein Einprägen passen wiederum auch zu den Erkenntnissen von Ebbinghaus, die er mit seiner „Vergessenskurve" beschreibt /11/, /12/. Unsere Köpfe – und Herzen - sind noch voll vom Berufsleben der letzten Jahrzehnte, und sobald wir beim Versuch, agile Arbeitsweisen anzuwenden, auf den feinsten Widerstand stoßen, fallen wir sofort zurück in die alten Reflexe, und ein Schuldiger – meist die „Methode“ – ist auch schnell zur Hand. Meine weitere Vermutung ist, dass Führungskräfte bis heute keine Ahnung davon haben, welchen Einfluss sie auf Erfolg oder Scheitern agilen Arbeitens in ihren Wirkungsbereichen haben.
Das oben genannte "Umlernen" haben wir bis heute nicht geschafft. Sehr wahrscheinlich müssen wir auch mehr Mühe investieren, um zu lernen, wie wir es z. B. in einem großen Konzern schaffen, dass gemeinsame – sinnvolle und erfassbare - Ziele von gemeinsam im Team arbeitenden Menschen erfüllt werden können, ohne dass wichtige Arbeit "liegenbleibt" und ohne dass die nötige Identifikation mit den Arbeitsinhalten auf der Strecke bleibt. Verzweifelte Versuche, das hinzukriegen, werden ja gerne mit dem Etikett "OKR" versehen, aber auch hier erlebt man, direkt oder indirekt über Berichte, in der eigenen Berufspraxis häufig mechanistische Strukturen, die zum Scheitern verurteilt sind. /13/
Kathedralenbaumeister:innen der Gegenwart
Um nochmals Jan Fischbach sinngemäß zu zitieren (auch das passt einfach zu gut, und ich habe natürlich auch die Vergessenskurve der Leserschaft des Teamworkblogs im Hinterkopf 😉): Wir befinden uns metaphorisch in einem Kontext des Kathedralenbaus. Wahrscheinlich sind wir bei der Verbreitung agiler Arbeitsweisen noch dabei, das Fundament zu erstellen und zu glätten, damit später weitere Schichten darauf aufbauen können. Die Vollendung der Kirchtürme aber ist von uns zeitlich noch so weit weg, für nachfolgende Generationen reserviert, dass wir sie nicht mehr erleben werden.
Wir sollten trotzdem weitermachen, damit es diese Kathedrale eines Tages gibt.
Quellen:
/1/ Maarten Dalmijn from Maarten’s Newsletter <mdalmijn@substack.com> am 11.11.2024: "Sayonara to the Golden Age of Scrum - Scrum Will Become Niche Like XP"
/2/ https://entwickler.de/java/agile-ist-tot-lang-lebe-modern-agile
/3/ https://www.scrum.org/resources/blog/its-time-learn-missing-metric
/4/ z. B. https://www.scrum.org/resources/blog/health-checks-fur-agile-teams
/5/ Die Limited WIP Society in Köln verlinkt auf ihrer Seite auf die Quelle https://www.fitterforpurpose.com/
/6/ https://www.teamworkblog.de/2025/01/leisten-leisten-leisten.html
/7/ Amy C. Edmondson: "Die angstfreie Organisation - Wie Sie psychologische Sicherheit am Arbeitsplatz für mehr Entwicklung, Lernen und Innovation schaffen" (Vahlen, 2020)
/8/ https://james-camerons-avatar.fandom.com/de/wiki/Zitatesammlung#Mo'at
/9/ https://www.aphorismen.de/zitat/14995
/10/ https://rep-ai.translate.goog/blog/cold-calling-statistics?_x_tr_sl=en&_x_tr_tl=de&_x_tr_hl=de&_x_tr_pto=rq
/11/ https://de.wikipedia.org/wiki/Vergessenskurve
/12/ siehe z. B. https://www.vertriebslexikon.de/vergessenskurve.html; mit Grafik
/13/ Eine m. E. griffige Abhandlung der Schwierigkeiten in Zusammenhang mit OKR-Einführungen findet sich z. B. hier: https://www.haufe.de/controlling/controllerpraxis/objectives-key-results-okr-fehler-bei-der-einfuehrung_112_562674.html
Kommentare
Kommentar veröffentlichen