safe-1561239Die Skalierung von Scrum auf mehrere Teams ist eine Sache, die Skalierung in eine weit größere Umgebung über mehrere Ebenen ist eine ganz andere. Wenn wir über Programm, Portfolio und große Organisationen sprechen, dann kommen wir mit den gängigen Mitteln Chief Product Owner und Scrum of Scrums usw. sehr schnell an unsere Grenzen. Eine Lösung verspricht SAFe (Scaling Agile Frameworks), das auf größere Organisationen zugeschnitten ist, aber ist das wirklich die Lösung?

Zunächst einmal muss man wissen, dass SAFe ein Monster ist. Dem eigentlichen Scrum-Prozess werden zahlreiche Rollen und Artefakte hinzugefügt, um Agilität auf eine höhere Ebene zu bringen. Einen Überblick zum Einstieg findet man auf den Seiten http://scaledagileframework.com/ als interaktive Grafik. Wem das auf den ersten Blick zu verwirrend scheint, der hat schon genau das Problem erkannt: es ist ein sehr komplexes System, das eine tiefe Einarbeitung und weitreichende Änderungen auf vielen Ebenen erfordert. Die Schwierigkeiten bei der Einführung von Scrum werden somit potenziert, oder doch nicht?

Wenn wir uns SAFe genauer ansehen, dann entdecken wir z.B. ein Portfolio- und ein Programm-Backlog. Damit sollte schon klar sein, wofür dieses Framework gedacht ist. Beschäftigen Sie sich mit der Skalierung von Scrum von zwei auf vier Teams, dann ist SAFe vollkommen überdimensioniert. In diesem Rahmen sind Sie mit den üblichen Verdächtigen (Scrum of Scrums usw.) ganz gut bedient. Dass auch das seine Schwierigkeiten und Hindernisse hat, ist vollkommen klar (ich helfe Ihnen gern, sprechen Sie mit mir), aber schon allein die Anzahl der beteiligten Personen macht eine Skalierung in diesen großen Dimensionen weit schwieriger.

Vergessen wir nicht, dass die Einführung von Agilität vor allem mit einer Änderung von Gewohnheiten verbunden ist, und nun kümmern wir uns nicht nur um gewohnte Vorgehensweisen bei Entwicklern und angehenden Product Ownern sondern auch um eine Veränderung des Mindsets bei Programm-Mangern. Damit aber nicht genug: eine solche weitreichende Umstellung erfordert zwingend nicht nur die Tolerierung durch die Geschäftsleitung sondern die aktive Unterstützung. Möglicherweise liegen sogar dort die größten Probleme. Die unternehmensweite Einführung von Agilität hat Einfluss auf alle möglichen Abteilungen und Bereiche und macht viele Dinge (scheinbar) sehr viel schwerer kalkulierbar.

Das ist aber ein grundsätzliches Problem einer unternehmensweiten Einführung von Scrum (oder anderer Agiler Frameworks) in einer größeren Organisation und hat nicht direkt etwas mit SAFe zu tun. Also zurück zum Thema: Welche Stärken und welche Schwächen hat SAFe?

So albern es auch klingt, aber die größte Stärke von SAFe liegt darin, dass es überhaupt existiert. In diesen Größenordnungen ist es sehr schwierig, auf Erfahrungswerte von Anderen zurückzugreifen. Es haben sich noch keine Best Practices etabliert. Man steht weitestgehend allein vor einer sehr schwierigen und komplexen Aufgabe. Der größte Kritikpunkt ist, dass viele neue Regeln und Artefakte hinzugefügt werden, was dem eigentlichen Agilen Gedanken widerspricht, nämlich, dass Personen und Interaktionen im Vordergrund stehen, und nicht Regeln und Werkzeuge.

Meine Kritik an dieser Kritik ist allerdings, dass es fast nicht möglich ist, eine sehr komplexe Organisation auf wenige Regeln einzudampfen. Wenn wir hier versuchen, alles in dieser recht lockeren Scrummigkeit zu erledigen, werden wir sehr bald auf massive Probleme stoßen, weil es so viele Abhängigkeiten der einzelnen Akteure und Gruppen untereinander gibt, dass sich das nicht mehr selbst organisieren kann. Wir sind also dazu gezwungen, Organisationselemente hinzuzufügen.

Nun können wir uns lang darüber streiten, wie viele und welche das sein sollten. Ich würde jedoch sagen, dass das ganz vom Unternehmen und den dortigen Gegebenheiten abhängt. Damit sind wir in unseren Gedanken also schon einen Schritt weiter gekommen: Wir wissen, dass komplexe Organisationsstrukturen nicht vollkommen unorganisiert arbeiten können, und wir wissen, dass sich ein Schema nicht einfach auf jede Umgebung anwenden lässt. Das führt zwangsläufig zu dem Schluss, dass SAFe nur ein Ansatz sein kann, der diskutiert und geprüft werden muss. Es ist ein Ausgangspunkt für eigene weiter reichende Überlegungen. Der Versuch, SAFe kommentarlos und unreflektiert auf eine komplexe Organisationsstruktur anzuwenden, wird scheitern.

Wie sollte man also vorgehen?

Wenn Sie keine Erfahrung mit der Skalierung von Scrum auf größere Organisationen haben, holen Sie sich Unterstützung. Im nächsten Schritt gilt es, die aktuellen Procedures zu analysieren. Nur wenn Sie alle Vorgänge sehr genau kennen, sind Sie überhaupt in der Lage, Agile Alternativen zu entwickeln. Nun folgt die Abbildung der aktuellen Prozesse in Agilen Äquivalenten. Dies alles ist bislang noch reine Theorie. Wir müssen Konzepte entwickeln, Testballons starten, alle Beteiligten ins Boot holen und uns vor allen Dingen die Unterstützung der Geschäftsleitung sichern. Das erfordert Überzeugungsarbeit, Erklärungen und sehr viel Zeit. Je größer und komplexer die Organisation ist, desto länger werden Sie brauchen.

Es fällt mir auch hier sehr schwer, eine genauere Zeitangabe zu machen, aber als grobe Einschätzung: Gehen wir von etwa 20 Entwicklungsteams und einem Portfolio von 4-5 Produkten aus, darüber die Managementebene. In einer solchen Konstellation würde ich von ungefähr einem Jahr ausgehen. Nageln Sie mich bitte nicht darauf fest. Der tatsächliche Zeitbedarf hängt von sooo vielen Faktoren ab. Es geht hier nur um eine Größenordnung.

Wenn wir ein (hoffentlich) tragfähiges Konzept entwickelt und das »Go« von der Leitung haben, stellen wir dies den beteiligten Personen vor. Ich rate Ihnen dazu, sich hierbei nicht auf eine Powerpoint-Präsentation im großen Rahmen zu verlassen. Sie werden viele Einzelgespräche führen, Feedback einholen und Ihr Konzept sogar noch verändern müssen, bevor Sie mit den ersten Piloten abheben können.

Die Umstellung erfolgt nun schrittweise. Bitte versuchen Sie keinesfalls, alles in einer großen Aktion zu ändern. Bereiten Sie sich darauf vor, dass es in jeder betroffenen Abteilung anfänglich noch nicht rund laufen kann – das ist ganz natürlich. Diese Probleme potenzieren sich und begünstigen sich gegenseitig über die Grenzen der Teams und Abteilungen hinweg. Wenn Sie schrittweise vorgehen, entzerren Sie diese Situation und können sich einem Schmerz nach dem anderen widmen.

Versuchen wir also ein kurzes Fazit: SAFe ist erst dann interessant, wenn wir über wirklich große Organisationen sprechen, und auch dann sollten Sie es nur als Richtlinie betrachten, die eine Grundlage für Ihre eigenen Überlegungen darstellen sollte. Der Versuch, es unreflektiert auf ein komplexes System anzuwenden, wird – meiner maßgeblichen Meinung nach – scheitern. Als Ausgangspunkt Ihrer eigenen Überlegungen kann es jedoch genau die richtigen Impulse bringen.

Unabhängig davon würde ich Ihnen immer dazu raten, sich bei einer so tiefgreifenden Veränderung Unterstützung ins Haus zu holen.

twitterrssyoutube
Facebooktwitterredditpinterestlinkedintumblr