Seite 3: Kritik an SAFe

Inhaltsverzeichnis

In der Praxis hören Berater häufiger kritische Fragen zu SAFe. Auf einige soll der Artikel ein paar Antworten geben.

SAFe ist doch nur neuer Wein aus alten Schläuchen?! Nicht direkt. SAFe bedient sich an schon "älteren" Frameworks und Methoden, das stimmt – bietet aber dazu noch weitere Vorgehensweisen, wie das PI Planning oder der Agile Release Train und versucht dadurch neuere "Modelle" mit bereits bestehenden zu kombinieren.

SAFe behauptet agil zu sein, aber durch die vielen Strukturen und Rollen geht doch eher Agilität verloren? Agil bedeutet nicht, dass Strukturen oder Rollen fehlen oder unnötig sind. Besonders in der Anfangszeit sind diese zwingend erforderlich. Wenn sich Erfolge zeigen, das Mindset in der gesamten Organisation verändert und agile Werte gelebt werden, können diese Strukturen etwas gelockert werden, um mehr Freiraum zu ermöglichen.

SAFe stoppt doch jegliche Flexibilität. In der Tat gibt es Frameworks wie LESS, das nach Einschätzung der Autoren um einiges agiler ist als SAFe. Warum? Weil LESS in den Scrum-Rollen bleibt und nur wenige bis keine hierarchische Strukturen bietet. Es soll dabei so viel wie möglich an die Entwicklungsteams übertragen werden, sodass Selbstorganisation noch stärker im Fokus steht. Das bedeutet jedoch nicht, dass SAFe keine Flexibilität ermöglicht. Es dient dazu agile Methoden einzuführen und Unternehmen dabei zu unterstützen. Die Umsetzung und Anpassungen können aufgrund der notwendigen Strukturen jedoch etwas länger dauern.

Gibt es in SAFe zu viele Rollen? Eine allgemeingültige Antwort ist nur schwer zu geben. Zusätzlich zu den bekannten Scrum-Rollen finden sich bei SAFe das Produktmanagement oder der Release Train Engineer. Oft herrscht Unklarheit bezüglich des Unterschieds zwischen Product Owner und Produktmanagement. Jedes agile Team hat einen Product Owner. Dieser ist, wie aus Scrum bekannt, für den Output eines Teams zuständig. Die übergeordnete Rolle Produktmanagement ist für den gelieferten Output aller agilen Teams verantwortlich – und damit sinnvoll und notwendig. Nach Ansicht der Autoren gibt es nicht zu viele Rollen in SAFe, wenn ...

• ... zu Beginn der Implementierung klare Rollenbeschreibungen festgelegt werden.
• ... klar festgelegt wird, welche Entscheidungen einzelne Rollen treffen müssen, und welche der häufigsten Entscheidungen die Entwickler selbst übernehmen können (zentral vs. dezentral).
• ... Transparenz gelebt wird und zu jedem Zeitpunkt erkennbar ist, woran die einzelnen Teams arbeiten. Wichtig ist ein guter Kommunikationsfluss.

Je nach Komplexität des Projektes können Aufgaben auf weniger Personen verteilt werden – beispielsweise kann ein Scrum Master mehrere agile Teams betreuen. Damit das funktioniert, müssen mindestens die oben genannten Punkte erfüllt sein und erste Erfahrungen bei der Entwicklung vorhanden sein.