Direkt zum Hauptbereich

Safe mit SAFe?

Über die Schwierigkeit, in diesem skalierten Framework zu Potte zu kommen, und warum das offenbar doch nicht alles ganz allein meine Schuld ist

 

Vor einiger Zeit sprach ich über Zoom mal wieder mit einem meiner Kontakte. Wir tauschten uns aus über diverse mögliche und tatsächliche Engagements, und ich bekannte, dass ich inzwischen (mit sogar nur wenig Erfahrung in diesem Umfeld, aber die reichte aus) Schwierigkeiten damit habe, in einem bestimmten Framework zu arbeiten. Ein anderer Kontakt, erfahren u. a. in der Personalvermittlung, bezeichnete mir gegenüber die solchermaßen aufgebauten typischen Riesen-Initiativen einmal als "Energievernichtungsmaschine".

Richtiges Scrum

Mein Kontakt berichtete, dass er, wenn er SAFe angeboten bekäme, meist abwinke, "nein, er wolle richtiges Scrum machen", für ihn sei SAFe kein Scrum (Wasser auf meine Mühlen...). Seine Haltung leuchtete mir ohne weitere Erklärung sofort ein, aber gleichzeitig beschlich mich ein komisches Gefühl. Auf der anderen Seite wettern nämlich Teile der Branche über den zusätzlich geschaffenen Job "Agile Coach" - auch hier werden womöglich Glaubenskriege entfesselt - denn ursprünglich war es der Scrum Master, der die frohe Kunde über das agile Arbeiten in selbstoganisierten Teams und das Verständnis hierzu in die Organisationen tragen sollte. Inzwischen ist dieser teilweise auf die zu begleitenden Teams zurückgeworfen, während nicht selten der Agile Coach, die vermeintlich höherwertige Position, in den Chefetagen herumwuseln darf (oder ist "darf" hier vielleicht das falsche Wort? Kommt wahrscheinlich auf das Unternehmen an...).

Pipi Langstrumpf oder: Ich mach' mir die Welt, wie sie mir gefällt?

Alle jedenfalls, die den Scrum Guide kennen, wissen, dass der Scrum Master unter Anderem die Aufgabe hat, das gesamte Unternehmen zu lehren, agil zu arbeiten. Das kann man natürlich nicht nur bequem von seinen Teams aus. Wenn ich also abwinke, "nee, ich will kein SAFe", kneife ich dann nicht? Bin ich nicht vielleicht selbst dafür verantwortlich, dass ich irgendwann in diesem Umfeld gut arbeiten und inhaltlich vorankommen kann? Bin ich eventuell selbst dafür verantwortlich, dass dieses SAFe funktioniert? Viele Stellenausschreibungen legen das zumindest nahe: Der Scrum Master ist ständig "verantwortlich" für diese und jene Verbesserung. Man hat als Unternehmen also immer einen Buhmann oder eine Buhfrau, wenn das ganze dann nicht klappt, ungeachtet der Hintergründe.

 

Scrum Master als SAFe-Rettung (?)

Wenn ich mir mit meinem bisherigen Erfahrungshintergrund vorstelle, ich sollte die Umstände dahingehend ändern, dass SAFe-Initiativen in Konzernen - diese Programme mit unzähligen Beteiligten und den typischen vielen Abhängigkeiten untereinander und dem großen Zeitdruck durch extern, aus einer höheren Hierarchieebene heraus, gesetzte GoLive-Termine, chronische Budget-Klammheit und trotzdem dem fast ständigen Wechsel von Personalien (am besten erst nach ihrer vollständigen Einarbeitung), weil immer wieder neue Projekte aus der Deckung kommen (Liste beliebig fortsetzen) - funktionieren, dann fühle ich immer noch eine Welle der Überforderung. Kann es sein, dass ich einfach zu wenig weiß? Sehr gut möglich. Ich habe andererseits zwei Jahrzehnte Berufserfahrung auf dem Buckel, wenn auch nur die Spitze des Eisbergs im agilen Umfeld stattfand, und ich weiß, wie es sich anfühlt, wenn man auf Leute trifft, die wirklich etwas gemeinsam erreichen und sich auf ein gemeinsames Ziel hinbewegen wollen, wenn ehrlich gemeinte Verbesserungsvorschläge grundsätzlich erst mal geschätzt werden. Ich kenne auch echte und scheinbare Kooperation, kenne die Gesichter der Bagatellisierung oder Ignoranz. Auch ich habe schon in SAFe-Initiativen gearbeitet und immer wieder von ähnlichen Mustern in SAFe-Projekten von meinen Kontakten gehört. Die Wahrheit liegt also vermutlich irgendwo dazwischen.

Das große Missverständnis...

Kürzlich teilte eine inoffizielle Quelle, die nicht genannt sein will (danke, Jan! :-)), auf LinkedIn einen Artikel - samt ausgedehnter Diskussion der Leserschaft - mit mir, und da fielen mir die Schuppen vollends von den Augen. Ein Mensch namens Maarten Dalmijn (ja, ich habe es nicht so mit den Größen einer Branche*) räumt mit allen Zweifeln auf und bezeichnet SAFe als "Marketing-Framework".

"Friss oder stirb" und die Reaktion des Unternehmens

SAFe-Initiativen, die in klassischen Unternehmen von wem auch immer aufgesetzt werden, um - einfach mal so - schneller und günstiger sowie qualitativ hochwertiger ein gesetztes Ziel erreichen zu können, werden nach meinem momentanen Wissensstand häufig monolithisch in den Rachen des Unternehmens gerammt, à la "friss oder stirb", und achten nicht darauf, ob sich das Unternehmen an diesem großen sehr fremden Brocken entsetzlich verschluckt. Unterdessen, so der Autor des o. g. Artikels, wird der Organisation erzählt, dass sie mit SAFe ohne großen Aufwand Großes erreichen kann. Inhaltlich beschreibt es Dalmijn griffig als "ein couch potato bleiben können, aber trotzdem ein sixpack bekommen."

Agile Anstrengungen wider den Willen des "Kunden"

Beim Lesen des Artikels fand ich meine Ahnung bestätigt, dass man in den beschriebenen Initiativen im ernsthaften Bemühen, agil zu arbeiten und andere auf diesem Weg zu begleiten, deswegen oft nicht wirklich vorankommt, weil man damit eigentlich permanent gegen den Willen der Organisation arbeitet. Über kurz oder lang reibt sich so manche/r dabei auf, das ist dann vielleicht die Rache des Unternehmens... Im Kopf des Beraters skaliertes Scrum - falls das funktioniert, auch da sind sich nicht alle einig, aber das ist wieder ein anderes Thema - in den Köpfen der Geschäftsführung des Unternehmens dagegen die Marketingversprechen von SAFe.

Kohärenz wiederhergestellt

Ich jedenfalls bin jetzt beruhigt, dass mir jemand ein so klares Bild vermittelt hat, das sich mit dem komischen Rumoren in meinen Eingeweiden deckt. Auch als Berater:in/Coach (hier gibt's komischerweise noch keine "Coachin")/Mentor:in/Facilitator:in muss man seine eigene Leidensfähigkeit austesten. Jede/r mag nun die eigenen Schlüsse für künftige Engagements ziehen.


* Es ist wie damals beim Rudern: Ich trainierte, bewegte mich selbst über dem Wasser und versuchte, bei Wettkämpfen "Radaddelchen" zu sammeln - so heißen die Medaillen beim Rudern - wusste aber nicht mal, wer im aktuellen Deutschlandachter saß, geschweige denn, wann wo welche Medaillen gegen wen gewonnen wurden

 

Weiterführende Information

https://medium.com/serious-scrum/safe-is-a-marketing-framework-not-an-agile-scaling-framework-cbdc000154a8



Kommentare

Beliebte Posts aus diesem Blog

Transparenz als Schlüssel zum Erfolg: 20 Reflexionsfragen für moderne Organisationen

Transparenz ist das Herzstück erfolgreicher Teams. Sie schafft Vertrauen und fördert Zusammenarbeit. Wenn alle Zugang zu den notwendigen Informationen haben, können sie fundierte Entscheidungen treffen und gemeinsam Lösungen erarbeiten. Dies führt zu höherer Effizienz, schnelleren Entscheidungsprozessen und besseren Arbeitsergebnissen. Transparenz ist mehr als ein Schlagwort – es gilt, sie greifbar zu machen, ein gemeinsames Verständnis davon zu entwickeln und es in die Praxis umzusetzen. Wie das gelingt und welche Vorteile es für Euer Team und Eure Organisation bringt, erkunden wir im Folgenden.

Microsoft Teams: Die neuen Besprechungsnotizen - Loop-Komponenten

  Haben Sie in letzter Zeit in einer Teams-Besprechung die Notizen geöffnet? Dort sind inzwischen die Loop-Komponenten hinterlegt. Die sind zwar etwas nützlicher als das, was zuvor zur Verfügung stand. Trotzdem ist noch Luft nach oben. Und es gibt sogar einige ernstzunehmende Stolperfallen. Hier ein erster, kritischer Blick auf das was Sie damit tun können. Und auch darauf, was Sie besser sein lassen.

Zu viel zu tun? Planen Sie Ihre ideale Woche

Wir hören immer wieder, dass Teams zu viel zu tun haben. Aber woher wissen wir eigentlich, was zu viel genau bedeutet? Hier ist ein ungewöhnlicher Tipp: Treffen Sie Annahmen über eine gute Menge. Planen Sie eine ideale Woche.

Wenn dein Team die Anforderungen blockt: 12 Tipps für Product Owner*innen

Liebe Product Owners, wir müssen reden. Schon wieder eine Anforderung, die im Nirgendwo landet? Zeit, das Ganze anders anzugehen. Ihr kennt das Spiel: Anforderungen sind ausgearbeitet, und doch läuft es im Team holprig. Was fehlt? Oft sind es Klarheit, realistische Erwartungen und ein bisschen Fingerspitzengefühl. Doch keine Sorge! Mit ein paar praktischen Tipps könnt ihr Missverständnisse vermeiden, Blockaden umgehen und den Entwicklungsprozess so richtig in Fahrt bringen – natürlich in Zusammenarbeit mit eurem Scrum Master. Hier sind zwölf Regeln, die euch helfen, das Team auf Kurs zu bringen und das Chaos in produktive Zusammenarbeit zu verwandeln. Wir zeigen dabei auch, wo der Scrum Master unterstützen kann, damit ihr eure Rolle als Product Owner noch besser erfüllen könnt. Häufige Stolperfallen: Warum Anforderungen oft scheitern Bevor wir ins Eingemachte gehen, kurz zu den typischen Stolperfallen. „Klare Anforderungen“? Klingt gut, scheitert aber sehr häufig an der realen Praxis. ...

Rebellieren für den Wandel: die 8 Regeln des totalen Stillstandes von Prof. Dr. Peter Kruse

In einem legendärem Vortrag skizzierte Peter Kruse 8 Regeln des totalen Stillstands. Ihm zufolge wurden die Regeln entwickelt, um Managern und Führungskräften dabei zu helfen, Bereiche mit potenziellem Widerstand gegen Veränderungen zu erkennen und Menschen auf strukturierte Weise durch den Veränderungsprozess zu führen.

Pragmatisch oder nur “Quick and Dirty”?

“Wir müssen aber pragmatisch vorgehen”, drängt der Kollege. Hm… Im Wörterbuch finde ich für “pragmatisch” in etwa: sachbezogenes, praktisches Handeln. Klingt gut. Leider zeigt sich in meinen Erfahrungen, dass pragmatisch für viele doch eher “quick and dirty” bedeutet. Es soll schnell fertig werden. Aber auf welche oder wessen Kosten? Wo ist die Grenze? Warum steht “praktisch” im Konflikt mit einem langfristigen “Nützlich”? Muss das sein?

Und jetzt alle zusammen! Teams - OneNote - Aufgaben - To Do

Ein Meeting jagt das nächste. Sich da nicht zu verzetteln, wird  im Zeitalter virtueller Besprechungen  noch anspruchsvoller. Kein Wunder, dass  im Zusammenhang mit Microsoft 365  zwei Fragen besonders häufig auftauchen: Wie dokumentiert man Besprechungen gut? Was hilft, offene Aufgaben nachzuhalten? Eine gute Lösung: Das in MS Teams integrierte OneNote-Notizbuch als gemeinsame Plattform auch für den Aufgabenüberblick zu nutzen.

Kategorien in Outlook - für das Team nutzen

Kennen Sie die Kategorien in Outlook? Nutzen Sie diese? Wenn ja wofür? Wenn ich diese Fragen im Seminar stelle, sehe ich oft hochgezogene Augenbrauen. Kaum jemand weiß, was man eigentlich mit diesen Kategorien machen kann und wofür sie nützlich sind. Dieser Blogartikel stellt sie Ihnen vor.

5 Gründe, warum wir jetzt über die Zukunft nachdenken sollten

Wer hätte im Jahr 2019 gedacht, dass so viele Menschen heute im Home-Office arbeiten können und dass die Firma trotzdem funktioniert? Wer hätte damals gedacht, dass wir heute wie selbstverständlich KI-Werkzeuge nutzen können? Ich will mich nicht der Aussage anschließen, dass sich die Welt immer schneller dreht. Es ist egal, wie schnell sie sich dreht, weil es sich immer lohnt, über die Zukunft nachzudenken. Und das muss nicht kompliziert sein.

Meetings in Scrum Teams: Mehr Fokus, weniger Kontextwechsel

  Meetings in Scrum Teams: Mehr Fokus, weniger Kontextwechsel  „Wir arbeiten agil“ – das bedeutet für viele von uns: Daily Stand-up am Morgen, dann Refinement, dazwischen eine Demovorbereitung, später noch ein kurzes Scrum of Scrums (SoS) und am Nachmittag ein Community-Meeting. Gleichzeitig soll ich an meinen Sprint-Aufgaben arbeiten. Wenn dir diese Situation bekannt vorkommt, les dir gerne meinen Beitrag an. Hier sprechen wir über den Einfluss von häufigen Kontextwechseln auf die Arbeit in agilen Teams und zeigen Best Practices, um diese Wechsel zu minimieren. Viel Spaß & Let’s grow, Michi.  Foto von Matt Bero auf Unsplash