Donnerstag, 10. Dezember 2020

Das Problem mit SAFe (II)

Bild: Pixabay / Geralt - Lizenz

Es ist nicht so, dass der Einsatz von SAFe grundsätzlich Proble nach sich ziehen würde, sinnvoll eingesetzt kann dieses Framework in vielen Organisationen zu Verbesserungen im Vergleich zum Ist-Zustand führen. Es ist aber leider so, dass bestimmte Probleme doch immer wieder auftreten. Eines davon kann besonders schwerwiegende Folgen haben, und  um das soll es heute gehen: auf viele traditionell sozialisierte Manager wirkt die grosse Prozess- und Rollenübersicht auf (je nach Blickwinkel) verlockende oder fatale Weise bekannt.


Unabhängig davon was die eigentliche Intention des Frameworks ist, in den verschiedenen organisatorischen Ebenen lassen sich die alten Hierarchien wiedererkennen. Ganz unten die (SAFe-)Scrum-Teams mit ihren (SAFe-)Scrum Mastern und (SAFe-)Product Ownern1, ganz oben die Epic Owner und Solution Manager, dazwischen ein Mittelbau aus Release Train Engineers, Business Ownern, System Engineers und Product Managern - das alles weist grosse Ähnlichkeiten zu dem klassischen unteren, oberen und mittleren Management auf.


Alleine dieses Gleichsetzungs-Potential wäre schon problematisch genug, es wird aber noch um eine weitere Dimension erweitert: auf jeder der mittleren und oberen Ebenen ist zwischen den Rollen ein horizontaler Aufgabenschnitt erkennbar. Business Owner, Product Manager, Release Train Engineers und System Engineers können als Entsprechung bekannter tayloristischer Aufteilungen in Anforderungsmanagement, Projektmanagement, Prozessmanagement und technisches Management gesehen werden. Die Gefahr besteht, dass hier wieder die Verteter der alten Silos zusammensitzen und ihre jeweiligen Partikularinteressen vertreten.


Auch auf der Zeitebene kann ein (scheinbarer) Wiedererkennungseffekt eintreten. Programm-Incremente die über Monate hinweg erstellt werden haben ähnliche Zeithorizonte wie die alten Release- oder Quartalspläne, Feature- und Enabler-Epics können so verstanden werden, dass Komponententeams getrennt von einander auf eine späte Integration hinarbeiten und den ganz rechts abgebildete "Release on Demand" kann man auch so verstehen, dass es einen Big Bang-Release ganz zum Schluss gibt, da es ja vorher keinen Bedarf nach halbfertigen Lösungen gibt.


Die Problematik dieser und ähnlicher Gleichsetzungen ist offensichtlich - Wenn sie zu der Ansicht führen, dass man nur die bestehenden Strukturen umbenennen muss um sich erfolgreich in Richtung Agil zu transformieren steht am Ende eine Mischung aus Missverständnis und Etikettenschwindel, aber ganz sicher kein Erfolg. Und um es noch einmal zu betonen: ein derartiges Ergebnis ist sicher nicht im Sinn von SAFe, es ist aber eines das dadurch sehr wahrscheinlich wird, dass traditionell sozialisierte Manager in der grossen Prozess- und Rollenübersicht vieles erkennen werden was ihnen fatale Weise bekannt vorkommt.



1Ganz bewusst mit diesem Präfix, um zu zeigen, dass das nicht die gleich benannten Rollen/Verantwortlichkeiten aus Scrum sind

Related Articles