Die Rolle als Designer im SAFe-Framework

Ein Balanceakt zwischen Skalierung und Nutzerzentriertheit

Title: Scaled Agile - Minimized UX?
Description: Navigating the troubled waters of a SAFe as a UX Professional
Speaker: Christian Korff

In der Session von Christian Korff ging es um seine persönlichen Erfahrungen mit dem SAFe-Framework (Scaled Agile Framework) in einem seiner Projekte.
SAFe ist ein skalierbares und flexibles Rahmenwerk, das darauf abzielt, agile Prinzipien und Praktiken auf Unternehmensebene zu implementieren, insbesondere in großen Organisationen mit mehreren hundert Entwicklern. Es wurde entwickelt, um diesen Organisationen zu helfen, Agile-Methoden wie Scrum, Kanban und Lean ĂŒber mehrere Teams und Abteilungen hinweg zu skalieren. SAFe bietet Anleitungen fĂŒr Rollen und Verantwortlichkeiten, die Planung und Verwaltung der Arbeit sowie die Verbesserung der Zusammenarbeit zwischen Teams. Das Framework stellt eine umfassende Anleitung bereit, wie große Organisationen agile Methoden auf eine Weise skalieren können, die Zusammenarbeit fördert, strategische Ziele unterstĂŒtzt und die kontinuierliche Lieferung von Wert sicherstellt.

Christian berichtete von seinen Erfahrungen als UX Professional in einem Projekt und wie unzufrieden er mit der Umsetzung des Frameworks war. Er fĂŒhrte Interviews mit anderen UX-Experten, und auch diese waren unzufrieden, da UX und Lean Startup im Framework zu kurz kommen. Lean UX, wie es vom Autor des Buchs Lean UX Jeff Gothelf empfohlen wird, wird nicht vollstĂ€ndig integriert. Zwar ist UX im Framework integriert, jedoch oft nur in einer ausfĂŒhrenden Rolle, die sich auf die Erstellung von Wireframes und Konzepten beschrĂ€nkt und erst bei der Umsetzung einbezogen wird. Customer Feedback wird berĂŒcksichtigt, aber das SAFe-Framework ist insgesamt wenig nutzerzentriert, da auch der Research-Aspekt zu kurz kommt. Es gibt zwar Research-Teams außerhalb des Frameworks, die man buchen kann, aber das ist nicht wirklich nutzerzentriert. Das Framework besteht aus mehreren Ebenen, wobei die oberste Ebene fĂŒr UX eine sogenannte Blackbox darstellt.


Christian ist der Meinung, dass die Lösung relativ einfach ist: Es braucht Rollen wie UX Lead, UX Management, ein UX Research Team oder einen Head of UX, damit UX mehr Gehör bekommt. Doch in der Praxis sieht es anders aus und man kann ein bestehendes Framework meist nicht einfach Ă€ndern. In solchen Teams muss man als Designer nach Strategien suchen, denn einfach mehr UX-Leute einzustellen wird wahrscheinlich nicht möglich sein. Daher ist es wichtig, ein gutes Stakeholder Management zu betreiben, um BrĂŒcken zu bauen und so viele Personen wie möglich fĂŒr UX-Themen zu sensibilisieren. Man muss herausfinden, wer einem hilft und wer einen blockiert. Es ist auch wichtig zu wissen, an welchen Meetings man teilnehmen muss, um zu wissen, was entwickelt wird. Nutze Daten, um zu ĂŒberzeugen, und involviere so viel wie möglich in deinen Prozess.

  1. Know that you are in SAFe.
  2. Do your stakeholder management.
  3. Get involved.
  4. Use your data.
  5. Involve the others.


Meine Gedanken zu SAFe

Den Frust von Christian konnte ich nachvollziehen, denn oft sind solche Frameworks genauso wie Methoden ein großes GeschĂ€ft, manchmal sogar wie ein Schneeballsystem, bei dem Menschen als Coaches ausgebildet werden und Coachings verkauft werden, um das Framework am Leben zu halten. Christian hat selbst noch kein Unternehmen gehört, das SAFe erfolgreich einsetzt. Persönlich kenne ich eine Person, die mit SAFe arbeitet, aber nicht in einer Design-Rolle, sondern in einer Scrum Master Rolle und zufrieden ist. Ich habe im Nachhinein recherchiert und laut Internet setzen folgende Firmen das Framework erfolgreich ein: Amazon, Bosch, Sony, Intel, Cisco, Nokia, Fitbit, Thales und American Express. Weitere Informationen findet man auf der SAFe-Seite: SAFe Customer Stories. Ob das stimmt, weiß ich nicht und fraglich, fĂŒr was es genau eingesetzt wird.

Ob das Framework funktioniert oder nicht, werde ich auch noch in meinem Netzwerk evaluieren und meine Erkenntnisse dann teilen. FĂŒr mich hören sich die Punkte von Christian auf jeden Fall logisch an und fĂŒr mich als UX Professional ist eine spĂ€te Integration von UX ebenfalls sehr unbefriedigend, da Projekte einfach lĂ€nger dauern und da spreche ich aus Erfahrung. Auf den ersten Blick sieht es schon sehr nach einem Wasserfallmodell aus, in dem Feature-Ideen im Backlog gesammelt werden und eins nach dem anderen gebaut wird. Das Framework kann in einer idealen Welt funktionieren, wenn man eine sehr schnelle Entwicklung hat und Konzepte sehr schnell evaluiert und angepasst werden. Aus meiner langjĂ€hrigen Praxiserfahrung sind solche Projekte aber eher die Ausnahme, und die Entwicklung dauert meist lĂ€nger aufgrund neuer Anforderungen. Erfahrene UX-Designer sollten so frĂŒh wie möglich im Prozess integriert werden und nicht nur als Wireframe- oder Konzeptgestalter agieren. Je erfahrener ein UX-Designer, desto unzufriedener ist man, wenn man nur Konzepte ausgearbeitet und bei Entscheidungen nicht dabei ist. Aus meiner Erfahrung kann ich nur sagen, dass die Lösung in crossfunktionalen Teams liegt, wo jede Disziplin zu Wort kommt und das so frĂŒh wie möglich.
In meiner Praxiserfahrung im KIND-Projekt (LINK) war ich von Anfang an im Projektaufbau integriert und durfte ĂŒberall dabei sein. Ich war mit dem Ergebnis der ersten Meilensteine und der Zusammenarbeit mit der Entwicklung sehr zufrieden, da ich alle Entscheidungen mitgetragen habe. 

Bei großen IT-Projekten mit wenig UX Ressourcen frage ich mich oft, wer sich um die Konsistenz im Design, die Weiterentwicklung und innovative AnsĂ€tze kĂŒmmert, die fĂŒr mich auf den ersten Blick bei dem SAFe Framework zu kurz kommen. Unternehmen mit einer hohen UX-Maturity wie Apple, Meta und AirBnB sind UX voll integriert. Es gibt Design Ops, Design Management und Lead-Rollen, um eine hohe QualitĂ€t zu gewĂ€hrleisten. Produkte und Services mĂŒssen nicht nur funktional und visuell, sondern auch nutzerzentriert gestaltet sein, somit mĂŒssen UX-Professionals an den Entscheidungstisch, um Business-Anforderungen so frĂŒh wie möglich zu verstehen und fĂŒr UX-Anforderungen zu sensibilisieren. Ansonsten passiert das, was ich schon so oft in Projekten beobachtet habe: Services werden gebaut, die irgendwann total ĂŒberladen sind und schließlich durch eine bessere, schlankere Lösung vom Markt verdrĂ€ngt werden.

Wie sind Eure Erfahrungen? Schreibt mich gerne ĂŒber LinkedIn an: Franziska Gronwald.

‍

Franzi Detail

Lust auf einen Kaffee? ✌

info@franzidesign.de