Abenteuer in SAFe - Mehr ist mehr (Rollen, Rollen, Rollen)

Das Unternehmen, in dem ich als ScrumMaster arbeiten darf, hat seine Art Software zu entwickeln vor etwas mehr als einem Jahr von einem klassischen Wasserfallmodell hin zur Nutzung des Scaled Agile Framework (SAFe) umgestellt.

SAFe definiert verschiedene Ebenen an Verantwortung - sie sollen den Fluss einer Anforderung vom Groben ins ganz Feine und den umgekehrten Weg zur fertigen Softwarelösung in Unternehmen abbilden. Dieses sogennate “Big Picture” zeigt schon, dass SAFe natürlich bei all jenen Punkte sammeln möchte, die daran glauben, dass Agilität in “echten” Unternehmen (Stichwort Enterprise) nicht funktioniert, sondern nur in kleinen Software-Bastelbuden erfolgreich sein kann.

Mehr ist mehr ist mehr

In jeder dieser Ebenenen existiert ein wahrer Zoo an Rollen, Methoden und Metriken - das lässt sich natürlich als “Best-of-Breed”-Ansatz verkaufen! Und tatsächlich ist nahezu jeder Begriff, der in den letzten Jahren durch die Software-Prozesslandschaft gegeistert ist vorhanden. Vom fast schon antiquiert wirkenden “lean”, über “DevOps”, “Scrum”, “XP” und “Kanban” ist vieles dabei, was dem Framework das Prädikat besonders agil einbringen kann. Die zahlreichen Rollen sorgen natürlich für ein gewisses Wohlbefinden in Unternehmen, die über SAFe nachdenken: Es ist für jeden etwas dabei - Enterprise Architekt, UX-Designer, Release-Train-Engineer, ScrumMaster, Product Manager, Tester, Administrator, Lead-Developer…

Viele der Rollen implizieren ein einfaches, naheliegendes Mapping zu denen aus anderen Prozessen, ein Umlernen oder gar eine Umstrukturierung des Unternehmens scheint gar nicht notwendig zu sein! Klingt erstmal gut, oder?

Vorteil: Keine Veränderung bedeutet keine Veränderung

Der Umstieg in die SAFe-Welt mag in anderen Unternehmen problemlos und ohne große Hürden vonstatten gehen, in meinem konkreten Fall habe ich allerdings das Gefühl, dass durch das Angebot an Rollen die notwendige Veränderung in der Unternehmenskultur, welche für den Erfolg agiler Methoden der kritische Erfolgsfaktor ist, nicht begünstigt, sondern eher gebremst wird.

Jede dieser Rollen benötigt ein genaues Verständnis des Aufgabenbildes, die entsprechenden Personen müssen gewillt sein, sich mit der Rolle auseinander zu setzen und ihre Arbeitsweise teilweise gravierend anzupassen. Sie benötigen Schulungen und Coaching, aber gerade wegen des scheinbar naheliegenden Mappings von “alten” zu SAFe-Rollen wird dies eher vernachlässigt. In der täglichen Arbeit zeigt sich dann häufig, dass die Aufgaben eines Produktmanagers oder Product Owners leider doch denen eines Requirement Engineers nicht so ähnlich sind wie man es bei der Rollenverteilung annahm. Wenn man es feststellt, ist das natürlich schon ein sehr guter erster Schritt. Häufig genug stellen es aber weder der Betroffene noch seine Teammitglieder (inklusive des nicht geschulten und gecoachten ScrumMasters) fest. Man wundert sich nur, warum es diese Teams nicht schaffen so großartig zu werden, wie es die Literatur immer vorzeichnet. Oder es ist seltsam das nur Bruchteile der angeforderten Features in einem SAFe-Release fertig werden (eventuell sind die Features von Produktmanager einfach zu groß oder zu breit definiert?).

Weiterer Vorteil: Schuldzuweisungen bleiben einfach

Ein weiterer “Vorteil” der Ebenen und Rollen ist das hohe Potenzial für “Fingerpointing”. Jede Ebene, jede Rolle und jedes Teams hat in SAFe definierte Aufgaben, die mit einer Übergabe an Verantwortung von einer Stufe zur nächsten einhergeht (das werden SAFe-Freunde dementieren!). Also geht es prima weiter wie im Wasserfall: Das Feature wurde nicht komplett umgesetzt? Klar, da ist der Produktmanager schuld, der es definiert hat (zu groß, zu vage, unzureichende Akzeptanzkriterien). Eventuell aber auch das Entwicklungsteam (zu langsam, hat doch das falsche gemacht)? Egal, ich bin auf jeden Fall nicht schuld! Der Integrationstest klappt nicht? Die Kollegen im “System Team” haben es wohl nicht drauf, das sollten wir vom Entwicklungsteam machen! Oder hat man nicht die Vorgaben des Meister-Architekten der Programm-Ebene befolgt?

Wie schon geschrieben: Das Potenzial ist da. Hoffentlich ist das Klima im Unternehmen gut genug, damit es nicht abgerufen wird…

Geht es denn besser?

Die Frage, die nach meinem Abriss natürlich kommt ist: Wie kann man es denn besser machen? Das hängt natürlich davon ab…

Ich selbst glaube daran, dass man Agilität nicht über ein Framework einführen oder skalieren kann. Ich bin auch davon überzeugt, dass es auch in Unternehmen, die eher traditionell ausgerichtet sind, möglich ist auf agile Methoden zu setzen. Es tut nur mehr weh als Ansätze wie SAFe, muss man doch nicht nur den Rollen im Unternehmen neue Namen geben, sondern tatsächlich an der Organisationsstruktur arbeiten.

Bei jeder neuen Rolle, die man schafft, muss man sich fragen, ob deren Aufgaben nicht besser durch eine der Rollen in existierenden Methoden (die sich als praktikabel erwiesen haben) abgedeckt sind.

In jedem Fall muss ein Weg gefunden werden, nicht nur das eine oder andere Framework einzuführen. Es müssen die richtigen Personen in die richtigen Rollen befördert werden, damit Agilität funktionieren kann!

Alles weitere ist dann eher eine Frage der Kultur im Unternehmen als eine nach der richtigen Framework-Auswahl…