Hilfe, mein Unternehmen macht SAFe

Survival Guide für Agile Coaches

Geschrieben von Andreas Schliep am 20.11.2016
Oh no! SAFe!

Du hast alles gegeben. In unzähligen Sitzungen, Gesprächen, Präsentationen und Intranet-Artikeln hast du von A bis Z dargelegt, warum es Sinn macht, als Unternehmen agil zu werden, was Agilität bedeutet, warum im komplexen Kontext definierte Prozessvorschriften nicht funktionieren können. Du hast agilen Teams geholfen, eine herausfordernde Definition of Done zu formulieren und vermeintlichen Product Ownern geholfen, ihren Beitrag als Anforderungsspezialist im Team zu leisten. Dem Management hast du die Lean-Gedanken ans Herz gelegt - und im Change-, Transition- oder Transformation Team alles gegeben. Schliesslich haben alle eingesehen, dass ein Unternehmen zu dieser Zeit agil werden muss. Es gab sogar einen grossen Vortrag des Managements mit Bildern von Tankern und Schnellbooten.

Und jetzt das: Das Management hat sich von externen Beratern davon überzeugen lassen, dass SAFe - Scaled Agile Framework - für euch genau die richtige Lösung sei. Denn schliesslich wollt ihr ja nicht nur mit einzelnen Teams Scrum oder Kanban machen, sondern Agile als Massgabe für die gesamte Entwicklung festlegen. Und statt jetzt auf der grünen Wiese anzufangen, nimmt man doch lieber gleich einen Ansatz, der für jede Aufgabenstellung schon gleich die passenden Handlungsanweisungen mitbringt. Gemeinsame Planung? Release Trains! Vernünftige Architektur? Architektenrolle! Viele Projekte? Portfolio-Kanban! Und ist es nicht so, dass SAFe doch auf Lean und Agile aufbaut? Ist doch alles da: Sprints, User Stories, Product Owner, Meetings mit Post-Its...

Da ist es doch wirklich schon reaktionär und konterproduktiv, wenn du immer wieder diese kleine Stimme im Hinterkopf hörst, die dir sagt dass man doch nicht sportlicher wird, wenn man ein Fitnesscenter baut. Dass SAFe bei allen Inhalten und schönen bunten Postern irgendwie wirkt, wie ein klassisch tayloristisches Konstrukt mit agilem Anstrich. Wie ein Tanker, auf dem lauter kleine Schnellboote aufgemalt sind. Die SAFe-Experten, vielfach klassische Projektleitungs-Consultants, die eine dreitägige Folienschlacht wach genug überstanden haben, versichern euch, dass das ja so nicht sei. Man müsse doch von SAFe gar nicht alles einsetzen. Am wichtigsten sei doch Einheitlichkeit, Konformität zu einem gemeinsamen Ansatz, die Ausrichtung auf die Lieferfähigkeit.

Wenn das denn so einfach wäre. SAFe hat eine sehr starke Ausrichtung auf die Planung. Wenn wir denn nur genau wissen, und ausführlich planen, was wann vom wem wie gemacht werden soll, dann funktioniert der Rest. SAFe ist so gut, dass es keiner empirischen Prozessteuerung mehr bedarf - welche doch eigentlich die Grundlage vieler agiler Ansätze wie Scrum ist. Gegebenenfalls gibt es ein Update von SAFe. Das klingt nicht nur nach klassischen Ansätzen wie RUP oder SAP. Es ist das gleiche Geschäftsmodell. Verspreche den Unternehmen eine klare, einfache Lösung für ihre komplexen Probleme. Bringe jede Menge Berater unter. Mache das Unternehmen abhängig von deinem Ansatz. Wenn es nicht funktioniert, müssen mehr Berater her. Und so weiter und so fort.

Doch jetzt haben wir den Salat. Du überlegst dir schon, ob du das Weite suchen solltest. Das ist nicht die Agilität, die du dir gewünscht hast. Das macht doch keinen Spass mehr. Als agiler Coach findest du bestimmt ein anderes Unternehmen, in dem du deine Talente und Fertigkeiten einbringen kannst. Doch noch ist nicht alles verloren! Es gibt drei Wege, in deinem Unternehmen für mehr Verständnis und Bereitschaft für Agilität zu sorgen. Ich nenne diese Wege Widerstand, Konformität und Verantwortung.

Widerstand

Schare eine Reihe Gleichgesinnte um dich. Wann immer eine neue Regelung eingeführt wird, sei bereit diese Regelung zu hinterfragen. Was Sinn macht wird toleriert, was keinen Sinn macht - umgangen. So haben Entwicklungsteams schon seit Jahrzehnten gearbeitet. Ihr wollt übergreifende Retrospektiven? Ein Verbesserungsbacklog? Übergreifende Communities of Practice? Her damit! Die Agilität entsteht trotz der eingeführten Prozesse. Das Brechen von Regeln wird zur einzigen gültigen Regel. Wie früher im Wasserfall, sorgst du nun als agiler Coach dafür, dass deine Teams liefern können, dass ein enger Kontakt zu den Anforderern gelebt wird, dass Lernen in den Vordergrund gestellt wird. Allerdings musst du dir einer Sache sicher sein: Wenn deine Gegenmassnahmen funktionieren, wird es so dargestellt, dass SAFe funktioniert. Wenn deine Gegenmassnahmen nicht funktionieren, liegt es an dir. Und du kannst dir wahrscheinlich eine neue Stelle suchen.

Konformität

So wie der Kapitalismus sich systemisch irgendwann selbst zerstören soll, kann SAFe auf Dauer nicht funktionieren. Also sorgst du dafür, dass ihr SAFe buchstabengetreu nach Blaupause einsetzt. Wie, da fehlt noch eine Rolle? Was, ihr habt nicht alle Entwickler im Planungsmeeting sitzen? Sorge als Prozesspolizei dafür, dass ihr eine 100%ige Ausrichtung auf den SAFe-Rahmen erreicht. Vermeide insbesondere alle inoffiziellen Kommunikationswege - was nicht in der Prozessbeschreibung steht, wird nicht gemacht. Irgendwann muss sich doch zwangsläufig die Dysfunktionalität von SAFe zeigen - und eure Projekte den Bach runtergehen. Diese Vorgehensweise könnte aber dazu führen, dass SAFe als funktionierend dargestellt wird. Es könnte immer noch klappen. Wenn nicht, lag es aber sicher aus Management-Sicht nicht an SAFe, sondern an den Mitarbeitern. Dann könnt ihr euch vielleicht alle neue Stellen suchen.

Verantwortung

"Wie jetzt", magst du dir sagen, "die Veranwortung für die Einführung von SAFe liegt doch nicht bei mir, das war unser Management!" Bist du dir sicher, dass du hier nicht über "Schuld" sprichst? Entgegen einer vielfach verbreiteten Ansicht geht es bei dem Weg der Verantwortung nicht darum, den Verantwortlichen zu finden. Auch nicht darum, sich selber Vorwürfe zu machen, die SAFe-Einführung nicht durch bessere Gegenbeispiele verhindert zu haben. Und schon gar nicht, sich mit den Gegebenheiten abzufinden und einfach nur Dienst nach Vorschrift zu machen. Verantwortung übernehmen heisst, ständig über die eigene Position, Einstellung und den möglichen Beitrag zu einer besseren Situation nachzudenken. Immer wieder zu einer durchdachten Reaktion auf die Gegebenheiten zu kommen. In der Praxis führt das natürlich auch zu Situationen, in denen du Widerstand ausüben wirst, oder dich für die Konformität entscheidest. Doch die Verantwortung, die du aus eigenen Stücken übernimmst, eröffnet dir noch weitere Möglichkeiten. Übernehme die Verantwortung für dich, dein Team, dein Umfeld, deine Wahrnehmung. Nutze deine Einflussmöglichkeiten, deine Stimme, deine Erfahrung und deinen Respekt für deine Mitarbeiter. Hier sind ein paar Beispiele:

  • Moderation: Sorge dafür, dass eure Meetings nicht von elektronischen Tools dominiert werden, sondern ein Höchstmass an Zusammenarbeit ermöglichen. Agilität wird durch Zusammenarbeit gefördert - bessere Verbindungen zwischen Menschen führen automatisch zu besserer Handlungsfähigkeit.
  • Vereinfachung: De-Skalierung ist schwieriger als Skalierung. Dennoch kannst du daran mitwirken, die Organisation zu vereinfachen - zum Beispiel durch den Abbau von Rollen ausserhalb der Teams. Das funktioniert durch Überzeugung, Übung und Resultate.
  • Transparenz: Besinne dich auf die Grundlagen von Scrum. Wenn eine der Spielregeln durch Aktionen von Aussen verletzt wird, mache die Auswirkungen sichtbar. Radikale Transparenz ist der natürliche Fressfeind von dysfunktionalen Entscheidungen.

Übernehme Verantwortung. Am Ende des Tages zählt, wie sehr eure Organisation die Grundprinzipien der Orientierung auf den Menschen, Lieferung von echtem Wert und der kontinuierlichen Verbesserung verinnerlicht hat. Erspare dir überflüssige Grabenkämpfe, aber gib deine Leidenschaft für echtes agiles Arbeiten und Leben bitte nicht auf. SAFe geht vorbei.

Andreas Schliep

Andreas „Andy“ Schliep

Andy ist einer der ersten deutschsprachigen Scrum-Trainer und ein Gründungsmitglied von DasScrumTeam. Nach seinem Studium an der Hochschule Bremerhaven begann Andreas seine Karriere zunächst als Softwareentwickler, später dann als Projektleiter, Teamleiter und schließlich als Bereichsleiter. Zu Scrum fand Andreas zwischen 2003 und 2004 durch seine damaligen Kollegen bei WEB.DE. Nach der Implementierung von Scrum bei WEB.DE wechselte Andreas im Jahr 2006 zu SPRiNT iT und entschied sich 2008, als Coach und Trainer selbstständig zu machen. Heute fokussiert er sich neben der Einführung von Scrum vor allem auf agile Führungskompetenzen und die nachhaltige Transformation von Organisationen. Als Co-Autor hat Andy an der Erstellung der Lernziele der Scrum Alliance für Scrum Master, Product Owner und Entwickler mitgewirkt.

Mehr Posts zum Thema

Immer informiert mit dem DasScrumTeam Newsletter

Das Beste in Sachen Scrum. Einmal im Monat. Jeden Monat.