Ob das du das SAFe nun magst oder nicht - du kannst es "richtig" anwenden oder so, dass du typische Fehler (oft unbewusst) machst. Die größten Scaled Agile Framework Fehler aus meiner Sicht schildere ich dir in diesem Artikel. Ich zeige dir damit, dass du ohne Probleme aus dem SAFe ein Konstrukt machen kannst, was definitiv nicht erfolgreich sein wird.
Die größten Fehler im Scaled Agile Framework
Ich persönlich finde es immer wieder spannend, wie viele Probleme und Fehler entstehen, wenn Unternehmen das Scaled Agile Framework anwenden. Ich habe mir dazu mal die Mühe gemacht, die größten SAFe Fehler aufzuschreiben. Diese Liste ist natürlich subjektiv und auch nicht abschließend. Ich habe mich auf die Dinge fokussiert, die ich selbst auch in der Realität viel sehe und erlebe.
EPICs als Projekte betrachten
Ein typischer SAFe Fehler der gerne gemacht wird ist es, die EPICs auf dem Portfolio als Projekte zu betrachten. EPICs sind in SAFe keine Projekte und diese EPICs haben in sich einen inkrementellen Ansatz für die Umsetzung. Sie werden (ohne zeitliche Fixierung) auf der Portfolioebene umgesetzt oder eben auch nicht.
EPIC Owner als Projektleiter betrachten
Wenn die EPICs keine Projekte sind, dann braucht es auch keinen Projektleiter. Dieser wird aber sehr gerne mit einem EPIC Owner gleich gesetzt und dann kollidiert diese Arbeitsweise natürlich mehrfach mit anderen Stellen im SAFe,
Das EPIC mit Lean Business Case als fix ansehen
Das EPIC ist keine 100% Spezifikation und wird so auch nicht im SAFe gehandhabt. Diesen SAFe Fehler findest du gerade bei Veränderungen von einer klassisch geprägten Arbeitsweise hin zu einer agileren Arbeitsweise. Ein Lean Business Case kann sich verändern, ebenso wie auch das EPIC selbst natürlich. Wichtig auch: der Lean Business Case hängt am EPIC dran, es ist kein extra "Artefakt", sondern es ist im Grunde eine Verfeinerung der Beschreibung.
Das Program Board als Projektplan nutzen
Das Program Board ist ein Hilfsmittel (welches im PI Planning erstellt wird), um bei Unternehmen mit vielen Abhängigkeiten die Fertigstellung von Features in dem kommenden Program Increment zu sehen. Es ist kein Projektplan und es müssen auch dort nicht alle Abhängigkeiten oder gar User Stories aufgelistet werden.
Program Increments als Releases verstehen
Das Scaled Agile Framework entkoppelt die Releases von den Interationen. Die Iterationen helfen dir für die gemeinschaftliche Planung und Synchronisation. Wann ein Release stattfindet, wie du deine Release Planung umsetzt oder eine neue Version veröffentlicht wird, ist nicht abhängig von diesen Interationen.
Natürlich müssen die Teams oder der ART darauf hin planen und dieses dann auch in Ihren Iterationen (Sprints) oder der PI Planung berücksichtigen.
Mathematische Genauigkeit im WSJF suchen
Mit dem Weightest Shortest Job First steht eine einfache, funktionierende Priorisierungsmethodik zur Verfügung, die aus meiner Sicht in großen Unternehmen gut funktioniert. Man darf nur folgendes in meinen Augen nicht machen (wie bei vielen anderen Priorisierungsmethoden auch): Priorisierungen sind immer falsch und nie genau. Durch häufige und schnelle Zyklen ist das bei einem iterativen und inkrementellen Vorgehen aber kein Problem und gleich sich schnell aus.
Wichtig für den WSJF ist allerdings, dass alle das Wissen über die zu priorisierenden EPICs haben. Häufig ist das nicht der Fall und dann wird oft die Methodik in Frage gestellt und nicht das grundlegende Problem.
Hierarchie in das SAFe einarbeiten, wo keine ist
Leider ist die Darstellung in SAFe von "oben nach unten" und es lässt den Anschein erwecken, dass auch eine Steuerung in dem Unternehmen unbedingt von oben nach unten erfolgen müssen.
Ich will das gar nicht zu tief an der Stelle weitergehend diskutieren, sehr oft bleibt aber gerade bei den agilen Teams hängen, dass sie "ganz unten" oder "ganz zum Schluss" dran kommen oder in die Fragen eingebunden werden.
Das EPIC als Planungsgröße verwenden
Ein EPIC ist wie ein Container. Sprich, es ist noch recht unklar, was am Ende heraus kommt. Natürlich gibt es Vorstellungen und Ideen, es gibt MVPs und Experimente. Aber grundsätzlich eignet sich ein EPIC nicht oder nur sehr begrenzt zum Planen. Erst bei den Features hast du im SAFe eine Grundlage mit der richtig gut geplant werden kann.
Das Pull Prinzip auf den Kanban Boards aushebeln
Ich bin ja absoluter Fan von Kanban und auch dem Pull Prinzip. Jetzt gibt es aber durchaus Unternehmen, die einen sehr stark phasenorientierten Prozess in dieses Portfolio einarbeiten. Dadurch passiert dann in der Regel folgendes: große Losgrößen, die wieder dazu führen, dass in "Batches" EPICs durchgeschobenen werden, dann werden meistens auch eine große Anzahl Features vorbereitet und es reift eine große Lawine an Arbeit, die meistens wieder sehr punktuell (wie früher) auf die Organisation
Vererbende Prioritäten zwischen EPICS und Features aufbauen
Die EPICs auf der Portfolioebene werden in bestimmten Teilen des Portfolio Kanban Boards bewertet und (meist mit WSJF) priorisiert. Da ein EPIC aber ein Container ist und viel zu groß, um etwas umzusetzen, bezieht sich die Priorisierung grundsätzlich auf dem Portfolio Board auf die Abarbeitung der Reihenfolge der EPICs. Eine Gesamtreihenfolge über alle EPICs macht genauso wenig Sinn, wie die Annahme, dass bei 5 zu bearbeitenden EPICs die Priorität (1-5) in den Features vererbt wird. Die Features selbst (siehe oben) sind die Planungsgröße und werden unabhängig priorisiert. Die Wahrscheinlichkeit, dass ein "wichtiges" EPIC auch "wichtige" Features hat, ist natürlich vorhanden und möglich, aber nicht zwingend.
Tipps für die erfolgreiche Umsetzung von SAFe (in größeren Unternehmen)
Hört auf mit den Anpassungen!
Jeder Kunde meint immer genau zu wissen, "bei uns ist etwas anders und wir sind aber besonders!". So richtig diese Aussage für die Einzigartigkeit seien mag, so falsch ist sie aus meiner Sicht für die Anpassung bereits existierender Frameworks. Wenn alle Unternehmen mal die bereits existierenden Frameworks richtig nutzen würden, hätten wir viel mehr erfolgreiche Transformationen.
Das hat zwar nichts direkt mit SAFe zu tun, denn auch in den anderen Frameworks - oder in Scrum selbst - verhält es sich ja nicht anders. Meistens werden genau die bereits existierenden Probleme gerne verschleiert.
Auch (richtiges) SAFe ist ein Change
Wer SAFe richtig anwenden möchte, der sollte natürlich auch bedenken, dass dieses ein Change für die Organisation ist. Es erfordert Begleitung, Verständnis und eine gute Akzeptanz.
Die (nachhaltige) Veränderung kostet Zeit
Veränderungen können schnell gehen. Das hängt von vielen Faktoren ab. Grundsätzlich tust du gut daran, dir vor Augen zu führen dass eine Einführung von SAFe dich erstmal einiges an Zeit kosten wird. Wenn wir dann noch die nachhaltige Veränderung berücksichtigen, dann brauchen wir alleine einiges an Zeit die Nachhaltigkeit auch bestimmen zu können.
SAFe ist umfangreich - Lernen und Verstehen!
SAFe ist nicht Scrum und Scrum hat recht wenig mit SAFe zu tun. Dort wo SAFe große Unternehmen überzeugt und immer das passende Bild hat, benötigt es aber ebenso ein sehr tiefes Verständnis in allen seinen Facetten. Das macht man mal nicht nebenbei und wer sich schon mit der guten und nachhaltigen Arbeit mit Scrum befasst hat, kennt auch den SAFe Fehler sich auf fehlende und falsche Perspektiven zu verlassen. Das Wissen zu etablieren ist ein sehr wichtiger Aspekt.
