Macht SAFe dich langsam und träge?

SAFe, das Scaled Agile Framework, verspricht das effiziente Skalieren agiler Organisationen. SAFe pflegt Methoden wie Scrum, Kanban und Design Thinking in eine Logik, die im Kontext eines ganzen Grossunternehmens funktioniert. Tönt zu gut, um wahr zu sein? Ja, denn oft ist es leider nicht ganz so einfach.

Arbeiten mit SAFe liegt in Grossunternehmen im Trend. Und wie bei jedem Trend ist auch hier Vorsicht geboten. Falsch angewendet, kann das vermeintlich agile Framework Unternehmen schnell komplizierter und träge machen. Das pure Gegenteil des eigentlichen Ziels.

Der «State of Agile Report» zeigt: SAFe setzt sich als Methode trotz Defiziten durch. Source: https://digital.ai/resource-center/analyst-reports/state-of-agile-report

‍Warum bremst SAFe Unternehmen aus?

SAFe ist ein grossartiges Orchestrierungsframework. Es fügt sich nahtlos in die Unternehmensstrategie ein, leitet diese bis auf Featureebene ab und managt Abhängigkeiten zwischen verschiedenen Teams. Doch gerade Product Owner merken häufig, dass auch nach der Einführung von SAFe ihre Teams nicht wirklich schneller sind.

Wo ist nun die vermeintliche Effizienz, welche die gesamte Organisation schneller machen sollte?

Nun: Dass Vorhaben nicht mit der gewünschten Geschwindigkeit umgesetzt werden, liegt an zu vielen Abhängigkeiten. Diese sind gerade in Grosskonzernen sehr schwer zu umgehen.

Um die Abhängigkeiten der verschiedenen Scrum-Teams zu managen, visualisiert SAFe im Product Increment Planning (PI Planning) die Verbindungen zwischen den Teams und lässt dies in deren Arbeitsplanung einfliessen. Diese Abhängigkeitsdiagramme sehen dann oft aus wie der Flight-Radar von London Heathrow.

Source: Twitter Michael P. Stump

Was passiert? In der teaminternen Planung werden jene Storys, die aus einer Abhängigkeit eines anderen Teams entstanden sind, vor den eigenen Storys priorisiert. Das soll helfen, Blockaden zu vermeiden.

Die Abhängigkeiten anderer Teams aus der Welt zu schaffen, hat also eine hohe Priorität. Und je mehr Abhängigkeiten ich als Team lösen muss, desto weniger komme ich meinen eigenen Zielen näher. Das bremst aus.

Wir beobachten diesen Konflikt schon länger bei unseren Kund:innen. Und auch in den einschlägigen Agile-Blogs ist der Frust über das Managen von Abhängigkeiten deutlich spürbar. Artikel mit Titeln wie «Stop Managing Dependencies!» oder «Eliminate Dependencies, Don’t Manage Them» sind keine Seltenheit. Die Frage ist also: Wie eliminieren wir diese Abhängigkeiten?

Gar nicht mal so einfach. Aber wir haben einen Ansatz für unsere Kund:innen gefunden:

Nur validierte Storys dürfen überhaupt Abhängigkeiten produzieren!

Was bedeutet das konkret? Das Produkt mit der höchsten Portfoliorelevanz hat Vorrang. Wir gehen aber noch mehr in die Tiefe und fragen: Welches Kundenproblem löst eine User Story, und welche Abhängigkeiten verursacht sie?

So kommen wir schnell auf die Folgefrage, ob eine User Story überhaupt einen Kund:innennutzen stiftet – und wenn ja: Wie gross ist er?

Wir validieren User Storys deshalb konsequent, bevor andere Teams mit dem Lösen von Abhängigkeiten belastet werden. Sonst laufen wir Gefahr, dass das aufwendige Produktfeature gar keinen Kund:innennutzen stiftet und wir bloss andere Teams ausbremsen. In der Kaizensprache sprechen wir dabei von «Waste».

Produktteams wissen anfangs oft sehr wenig über ihre Kund:innen

Gerade wenn neue Produkte am Markt getestet werden, wissen die Produktteams anfänglich noch sehr wenig über ihre Kund:innen. Das führt dazu, dass falsche Annahmen getroffen und Features gebaut werden, welche die Kund:innen gar nicht interessieren.

Werden Interviews oder Umfragen gemacht, ist das sicher besser, als einfach draufloszuraten. Doch es gibt eben auch jene Fälle mit substanziellen Unterschieden im Userverhalten. Das gilt besonders, wenn die Anzahl der befragten Kund:innen eher klein ist. Die Implikation: Wir verlassen uns auf einige wenige Kundenaussagen. Das kann dann schnell zur Folge haben, dass wir unrelevante Features produzieren.

Der einfachste Weg, nicht in diese Grube zu fallen, ist, ein Feature im ersten Moment möglichst «lean» und mit einem MVP-Ansatz zu entwickeln. Nach dem Veröffentlichen messen wir dann das echte Verhalten der User mittels Produkt Analytics wie zum Beispiel Amplitude (INNOArchitects-Partnerin).

Bestätigt sich unsere Hypothese, dass es sich um ein nachgefragtes Feature handelt, kann es in «Corporate-SAFe-Manier» gebaut werden. Jetzt dürfen auch Abhängigkeiten entstehen, die andere Teams lösen müssen. Wir INNOArchitects warten hier aber meist noch zu, bis das gesamte Produkt eine gewisse Reife erreicht hat. Wir nennen das dann «Product Market Fit». Ist dieser erreicht, integrieren wir gleich mehrere Features auf einmal. Aber nicht vorher!

Mit unserem Ansatz werden nur Abhängigkeitsstorys umgesetzt, von denen wir auch wissen, dass sie Relevanz bei den Kund:innen haben. So bauen wir Produkte, die auch wirklich ein Bedürfnis adressieren, und reduzieren ganz nebenbei den «Waste» in der gesamten Kund:innenorganisation.

Kennt dein Unternehmen diese Herausforderungen auch? Suchst du Unterstützung, wie du deine Abhängigkeiten reduzieren kannst?

Dann melde dich einfach bei mir: sandro.felder@innoarchitects.ch

‍