Der Wille, die Welt zu verbessern, wird den Willigen durch die Welt ausgetrieben.
Ulrich Erckenbrecht (*1947, dt. Schriftsteller und Philosoph)
Viele im sogenannten agilen Umfeld kennen es: Retrospektiven, von Scrum Mastern gern als Kernstück ihrer Arbeit gesehen, als wichtigstes aller Scrum Events, erfreuen sich in den Kreisen derer, die das Tagesgeschäft abwickeln, häufig nicht eben größter Beliebtheit.
In manchen Unternehmungen ist sogar der Begriff "Retrospektive" (wie auch andere Bezeichnungen aus Scrum) bereits verbrannte Erde, verbraucht und verschlissen durch Heerscharen von Beratern, Agile Coaches und Scrum Mastern, die sich beispielsweise als Scrum-Polizist betätigt oder anderweitig unbeliebt gemacht haben und deren Bild in den Gehirnen ihrer ehemaligen Teamkollegen in pawlovscher Manier untrennbar mit Begriffen wie "Retrospektive" verknüpft ist. Man spricht als in diesen Unternehmungen neu eingestiegener Scrum Master (oder Teamcoach) dann gern von "Rückblicken" oder bezeichnet Retrospektiven z. B. als "Workshops", um nicht sofort anzuecken.
Ein Vergleich mit der UNO
Vielleicht ist es den Menschen auch nicht zu verdenken, dass sie Retrospektiven nicht so gerne mögen. Vielleicht erfahren nicht wenige in ihren Retrospektiven das, was Carla del Ponte über die Vereinten Nationen gesagt haben soll. Diese wurden von ihr als "Schwatzbude" bezeichnet. Zitat aus der "Zeit": "(...) Die frühere UN-Chefanklägerin (...) hält die Vereinten Nationen für eine Organisation, in der viel geredet und nur wenig gearbeitet wird(...)." Ich kenne selbst völlig sinnlose Retrospektiven, in denen ein Scrum Master oder Agile Coach mit gedankenschwerer Stimme fragt, wie man sich bei diesem oder jenem gefühlt habe. "Ja, und? Was geht es dich an? Wie hilft mir das in meinem Alltag? Was machst du mit der Information?" Ganz abgesehen davon, dass vielleicht nicht jeder in großer Runde danach gefragt werden möchte, wie er oder sie sich "gerade fühlt", weil am Vortag das Haustier gestorben ist oder man einen saftigen Ehekrach hatte, von dem die anderen nicht unbedingt etwas erfahren sollen.
Ich weiß nicht, was soll es bedeuten...
Ganz groß auch die liebevoll und in endloser Kleinarbeit vorbereiteten Kollaborationsboards mit Weihnachtsbaumkugeln zur Weihnachtszeit oder Häschen zur Osterzeit oder Sternchen oder sonstiger Deko (werden auch mal von Kolleg:innen vorgezeigt, als Schulterklappen aus der Vergangenheit), während man als unbeteiligter Betrachter sich heimlich fragt, wie man über dieses Board eine für das Team und seine Arbeit sinnvolle Information extrahieren soll. Ja, auch im Leben eines Scrum Masters gibt es Kennzahlen. Leider bin ich hier nicht so begabt, und die Formel bzw. die Messpunkte für die Berechnung einer Prozesseffizienz kann ich immer noch nicht aus dem Ärmel schütteln (ja, okeh, Jan, jetzt isses raus...), aber auch unserseins sollte sich bemühen, greifbare Veränderungen, die sich am besten in barer Münze für das Unternehmen niederschlagen, einzuleiten.
Große Pläne - Der Prophet gilt nichts im eigenen Land
Gerade vor kurzem hatte ich neben der eigentlichen Veranstaltung, einer Art Bereichsretrospektive zum Thema Planung, einen "Nebenaustausch" über Teams.
Wenn es nach Arbeit riecht, will ich es nicht?
Die Person aus meinem Team, mit der ich mich austauschte und die zum wiederholten Male auch in der genannten Retrospektive Misstände sachlich ansprach, schrieb mir dazu, dass es vermutlich "wieder niemand hören" wolle. Ich war zum ersten Mal mit dabei, als Zaungast, und konnte beobachten, wie missliebige Themen "wegmoderiert" wurden, wie jeder seinen Dampf abließ und wie vor allem hauptsächlich Stille herrschte, als es um die Maßnahmen aus der letzten Retrospektive ging. Da hatte man den Eindruck, dass diejenigen, die bei der letzten Bereichsretrospektive dabeiwaren, just in dem Augenblick, da der nächste Termin stattfindet, erstmalig wieder auf die "damals" verabschiedeten Maßnahmen sehen. An diesen hatte, so der weitere Eindruck, bis zum aktuellen Zeitpunkt - natürlich - niemand gearbeitet (vielleicht, weil ihr impact schon von vorneherein erkennbar gering war).
Scrum Master als Verbesserungsamme
Es kommt sicherlich nicht selten vor, dass der Scrum Master, wenn er/sie es denn geschafft hat, die Gäste konkret umsetzbare Maßnahmen ableiten zu lassen, selbst vergisst, die Umsetzung dieser Maßnahmen zu unterstützen und zu begleiten (ja, das ist leider immer noch notwendig).
Es werden halberzig Maßnahmen verabschiedet, die man entweder gar nicht alleine umsetzen kann oder die man schon am nächsten Tag über dem eigenen Tagesgeschäft "vergessen" hat. Bestenfalls kümmert sich der Scrum Master darum, dass die Maßnahmen umgesetzt werden, wohingegen doch das Team eigentlich ein ureigenes Interesse daran haben müsste, weil die Maßnahmen ja Verbesserungen in senem eigenen Umfeld herbeiführen sollten.
Woran liegt die Unbeliebtheit?
Es kann verschiedenste Gründe dafür geben, warum es mit den Retrospektiven teils nicht klappen will.
Der Versuch, andere zu ändern/bewegen
Die verabschiedeten Maßnahmen sind "lauwarm", weil das Team verstrickt ist in Abhänigkeiten zu anderen Teams und die Maßnahmen, die einen wirklichen Hebel bedeuten würden, gar nicht alleine umsetzen kann. Ein anderer hätte die Macht dazu, der aber nur herumsitzt und anders priorisiert.
Das Team darf nicht alleine entscheiden
Das Team erhält nicht die volle Verantwortung und Kontrolle, Maßnahmen wie von ihm selbst gewünscht zu realisieren. Ich habe die unschöne Realität kennengelernt, dass in manchen Konzernen ein dafür zuständiges Team eine veraltete Technologie bzw. Anwendung abschalten möchte, ein End of Life aber immer wieder salamitaktik-artig in weitere Ferne rückt, weil doch noch irgendjemand "dringend" diese Technologie oder Anwendung benutzen muss, im Zweifel 2,5 Personen, und somit eine Reihe von "Altlasten" nur zu 80% abgeschaltet werden.
Der Scrum Master optimiert sich selbst (und seinen Auftrag)
Pech hat das Team auch, wenn der Scrum Master nur für seine "Events" arbeitet und lieber Tag und Nacht an seinen Remote-Boards herumfrickelt, anstatt seinen Teammitgliedern einmal in die Augen zu sehen und persönliche Gespräche mit ihnen zu führen. Möglicherweise versäumt er/sie es, seine/ihre Leute nach außen hin abzuschirmen, wenn z. B. ständig neue Anforderungen an das ohnehin schon unterbesetzte Team herangetragen werden, etwa die gefürchteten und von außen nahezu unkontrolierbaren Anforderungen über einen informellen "kurzen Dienstweg" ("Ich kenne den x, der hat das immer schon gemacht, den ruf' ich mal eben an"). Die Personen, die die beste Kontrolle haben könnten, sitzen am anderen Ende des kurzen Dienstwegs, im Team, aber leider sind sie Teil des Systems.
Was interessiert mich mein Geschätz von gestern?
Das Umfeld des Teams ändert sich häufig, weil immer neue "wichtige" Projekte und Initiativen wie Pilze aus dem Boden schießen und man in den Retrospektiven gar nicht weiß, ob es sich überhaupt noch lohnt, eine Maßnahme umzusetzen, weil die Welt morgen vielleicht schon ganz anders aussieht. Wann genau sich die Projekte dann aber mit ihrem Startschuss materialisieren, weiß natürlich auch niemand, und es kann dann wider Erwarten doch noch lange dauern, wodurch sich ein Zustand der fortwährenden Lähmung manifestiert.
Cargo Cult-Maßnahmen
Das Team verabschiedet Maßnahmen, an denen es selbst kein Interesse hat, etwa, weil schon absehbar ist, dass es keinen "Hebel" geben wird bzw. weil der Nutzen der Maßnahme für das tägliche Arbeiten nicht erkennbar ist. Mit den Maßnahmen wird aber der Scrum Master oder Teamcoach ruhiggestellt. Würde ein Team in seinen Retrospektiven (mit etwas Übung) immer wieder Maßnahmen finden, mit denen sich das Tagesgeschäft vereinfachen und die Zusammenarbeit spürbar verbessern ließe, würde es vermutlich auch mehr Spaß machen, eine Retrospektive abzuhalten, à la "Lasst uns mal gucken, was wir heute für tolle Sachen erfinden können, die uns das Arbeitsleben morgen leichter machen!"
Was man auch in schwierigen Lagen tun kann
Vielleicht hätte der/die eine oder andere einmal den Artikel "Retrospektiven mit Ergebnissen" /1/ hier im Teamworkblog lesen sollen. Hier bekommt das verbesserungsgeneigte Team (oder dessen Scrum Master) für alle Lebenslagen wertvolle Hinweise, z. B. auch, wie Teams, die in Abhängigkeiten zu anderen verstrickt sind, trotzdem ihren Arbeitsalltag optimieren können, indem sie etwa ihre eigene Lieferfähigkeit verbessern.
Liefern statt ausgeliefert sein
Es macht schließlich Spaß zu liefern. Viel mehr, als zig offene Tickets am Bein zu haben, mit denen man nicht wirklich weiterkommt und die einen zu fortwährendem Kontextwechsel zwingen. Das ist etwas, das insbesondere Entwickler gar nicht brauchen können. Das schlechte Gewissen, das man dauernd latent hat, weil man nie mit etwas fertig wird, braucht überhaupt niemand.
Baum mit der Axt oder der Motorsäge fällen?
Das Teamworkblog hält noch andere Artikel zum Thema "Retrospektive" bereit, etwa "Retrospektiven: Mehr als nur ein Meeting?"/2/ Darin finden wir die Aussage "(...) Wenn wir Erfahrungen und Erkenntnisse reflektieren und Maßnahmen zur Verbesserung identifizieren, können wir (...) die Arbeitsweise kontinuierlich optimieren (...). Aber eben nur wenn diese Maßnahmen auch wirklich umgesetzt werden." Ich frage mich, ob es sein könnte, dass Teams zwar Maßnahmen verabschieden, diese teilweise sogar als sinnvoll erachten, sie aber trotzdem nicht umsetzen, weil das Team vielleicht seit Jahren chronisch unterbesetzt ist und wildes Einhacken von Codezeilen für das Produkt(inkrement) doch als wichtiger erachtet wird als die Arbeit an kontinuierlichen Verbesserungen? Etwa so wie in dem humoristischen Beispiel mit dem Menschen, der einen Baum fällen möchte, eine Handsäge in der Hand hält und von jemandem, der eine Motorsäge besitzt, auf die Schulter getippt bekommt, der sich aber nicht umdreht mit dem Kommentar, dass er jetzt keine Zeit hat, weil er ganz schnell diesen Baum fällen muss?
Der Mensch als Gewohnheits- und Faultier
Oder ist es vielleicht so, dass das Heben von Verbesserungspotential einfach als langweiliger und vor allem anstrengender wahrgenommen wird als cooles Programmieren von besonderen Kniffen, bei denen man schon immer mal wissen wollte, ob sie funktionieren?
Die Erfahrung von Selbstwirksamkeit
Wenn man über den Sinn und Zweck von Retrospektiven in Büchern und Artikeln zum neuen hippen Projektmanagement liest (ok, Agilität im Projeltalltag ist schon seit Jahrzehnten am Markt, aber breiten Massen war diese Welt offenbar trotzdem eine ganze Weile lang nicht zugänglich), erschließt sich der Sinn dessen durchaus. Ich nehme an, dass da, wo Retrospektiven eher unbeliebt sind, nicht an der eigenen Lieferfähigkeit gefeilt wird, oder, wenn wir noch einen Schritt weiter zurückgehen, dass ein wirkliches Vetrautmachen mit agilen Konzepten bisher ausgeblieben ist. Es drängt sich der Verdacht auf, dass in solchen Fällen Teams noch nie erlebt haben, wie ihnen mittels der in Retrospektiven erarbeiteten Maßnahmen für die Zukunft (kleine) Flügel wachsen.
Es gibt immer noch viel zu tun für alle Scrum Master und Team Coaches. Sehr viel.
Quellen
- /1/ Jan Fischbach: "Retrospektiven mit Ergebnissen", https://www.teamworkblog.de/2022/07/retrospektiven-mit-ergebnissen.html
- /2/ Pierre Smits: "Retrospektiven: Mehr als nur ein Meeting?", https://www.teamworkblog.de/2023/04/retrospektiven-mehr-als-nur-ein-meeting.html
Liebe Doris, vielen Dank für deinen inspirierenden Post.
AntwortenLöschenHöre ich da einen ziemlichen Frust heraus? Den könnte ich aus meiner eigenen Erfahrungen mit Teams zumindest nachvollziehen. Das, was du schilderst, kennen viele Menschen, die als Teil eines Scrum Teams sind. Auch die Schlussfolgerungen und Ansätze lesen sich stimmig.
Allerdings wirken sie, fürchte ich, nur, wenn eine Grundvoraussetzung erfolgt ist: Dass die Teammitglieder verstehen, dass es tatsächlich auch Teil ihrer eigenen Verantwortung und damit eben eine ihrer (sogar wichtigsten) Aufgaben ist, die eigene Arbeit nicht nur inhaltlich, sondern vor allem auch strukturell auszuwerten und Schritt für Schritt zu verbessern. Also: Gemeinsam organisatorisch zu lernen.
Das merke ich deshalb so explizit an, weil ich glaube, dass es das ist, was viele entweder nicht verstanden haben. Wenn es ihnen überhaupt gesagt wurde, denn das wird bei aller agiler Methodenbesoffenheit oft vernachlässigt. Oder sie lehnen diesen Teil der Verantwortung ab - bewusst oder unbewusst.
Schließlich ist genau DAS, was Agilität von hierarchischen Ansätzen so wesentlich unterscheidet: Es gibt keine ManagerInnen mehr, welchen man diesen undankbaren (und unmöglichen) Auftrag mehr zuschustern kann.
Wir sind in Scrum (weitestgehend) selbst dafür verantwortlich, unsere Teamstrukturen sauber zu halten und uns alles zu organisieren, was es dazu braucht.
Das schmeckt nicht jedem, und zwar nicht nur deshalb, weil es im ersten Moment einfacher ist mit dem Finger auf das Management zu zeigen und zu sagen: Sorgt mal für bessere Strukturen, erst dann können wir hier besser liefern.
Was übrigens überhaupt NICHT heißen soll, dass das Management aus der Verantwortung entlassen ist, für möglichst gute Rahmenbedingungen zu sorgen.
Mir geht es nur um die Vermutung, dass Retrospektiven neben den von dir genannten Gründen oft schlicht AUCH deshalb so einen schlechten Ruf haben, weil Menschen, die Agilität umzusetzen haben - und damit sind MangerInnen, POs, Teammitglieder und Scrum Master gleichermaßen gemeint -, wichtige Informationen zu den jeweiligen Verantwortlichkeiten oft fehlen. Außerdem denken, fühlen und handeln viele von ihnen noch in hierarchischen Mustern denken, was die Gefahr von "Raider heißt Twix, sonst ändert sich nix" birgt. Und/oder sie sehen Agilität schlicht als nervigen "Trend" und wollen schnell wieder zur alten Arbeitsweise zurück.