Nach vielen Jahren umfangreicher erfolgreicher und gescheiterter IT-Projekte in Wasserfallmodellen, etablieren sich seit nunmehr 20 Jahren mehr und mehr agile Methoden vor allem in der Softwareentwicklung und -einführung. Die Vorteile der schlagkräftigen, kleinen agilen Teams sind auch in den höchsten Vorstandsetagen angekommen und so verwundert es nicht, dass ganze Unternehmen auf agiles Projektmanagement umgestellt werden.
„Agile Management, agile Leadership, agile Mindset“
Doch wie weit kann agiles Projektmanagement skalieren?
Viele agile Methoden befinden sich auf dem Sprung zu skalierten agilen Methoden, bei denen es vor allem darum geht, verschiedenste agile Teams zu organisieren. Einige mehr oder weniger verbreitete von ihnen sind:
In diese Kerbe schlägt seit 2011 das hier beschriebene „Scaled Agile Framework“ SAFe® mittlerweile in seiner fünften Iteration auf dem Markt. Dessen agiles Framework ist nicht nur in der Lage, einzelne Teams eines Projektes zu organisieren, sondern skaliert vom agilen Release Train über den Solution Train bis hin zum Value Stream, sodass ganze Unternehmen bzw. Unternehmensbereiche im Full Approach organisiert werden können. Es fokussiert dabei auf die drei Bereiche Agile Softwareentwicklung, Lean-Produktentwicklung und Systemdenkweise mit dem Ziel der Koordination und Zusammenarbeit mehrerer Teams.
„As Scrum is to the agile team, SAFe® is to the agile enterprise.”
(Dean Leffingwell)
Doch wohin führt das? Bleibt hier etwas auf der Strecke? Lassen Sie uns einmal die verschiedenen Skalierungsebenen von SAFe® ansehen, beginnend bei der einfachsten Ausbaustufe mit wenigen agilen Teams bis zum unternehmensweiten Einsatz:
Wie man sieht, ist SAFe® ein Schichtenmodell und wie viele Schichten man einsetzen möchte, muss weder vorher festgelegt werden, noch ist es eine Einbahnstraße. Die Möglichkeit, Agile Release Trains zu einer höheren Ebene zusammenzufassen, macht diese Form so flexibel.
Wie in meinem ersten Teil der SAFe®-Reihe beschrieben, leistet der sog. Release Train Engineer (RTE) eine ganz wesentliche Rolle in diesem skalierten agilen Vorgehensmodell. Man kann ihn je nach Ebene mit einem Projektleiter, Abteilungsleiter oder Bereichsleiter vergleichen. Gleichzeitig ist er aber auch Techniker, Seelsorger oder Peoplemanager.
Der RTE leitet zu Beginn eines PI (Program Increment) den PI-Planungsworkshop, ist mit den Stakeholdern aber auch den Product Ownern vernetzt und steuert über die Scrum Master auch die Einhaltung der agilen Prinzipien.
Bei einer einfachen SAFe® Struktur für beispielsweise ein einziges Projekt, steuert der RTE den „Flow of Value“ (siehe unten) für dieses definierte Projektziel. Doch mit jeder weiteren Strukturierung und Skalierung wandeln sich die Ziele des entsprechenden Trains, und der RTE muss seinen Fokus mehr und mehr auf die unternehmensweiten Ziele lenken und die Integration der zugrunde liegenden Trains vorantreiben. Er ist damit maßgeblich am Erreichen der Unternehmensziele beteiligt und verantwortet die Projektfortschritte gegen die Stakeholder. Darin liegt bereits ein ganz großer Vorteil eines nach SAFe® organisierten Unternehmens: Projekte und Services skalieren einfach über autonom arbeitende, schlagkräftige agile Teams, die wiederum über agil arbeitende RTE skalieren.
Erfahrungen zeigen, dass die intrinsische Motivation bei dieser Organisationsform weit über der klassisch organisierter Hierarchien liegt, und dass die darin enthaltene Fehlerkultur mit seiner Fokussierung auf die Lösungs- statt Schuldigenfindung die Motivation gerade bei innovativen Projekten stark fördert.
Der Vorteil eines komplett agil gemanagten IT-Bereichs oder gar ganzen Unternehmen liegt damit auf der Hand, ist aber mit vielen Risiken verbunden:
Wichtigster und risikoreichster Punkt:
Buchtipp: „Agile Organisationen. Transformation erfolgreich gestalten - Beispiele agiler Pioniere. Vom ehemaligen Startup bis zum Großkonzern berichten Unternehmen über ihren Weg in die Agilität.”
(André Häusling (Hrsg.))
Ob Ihr Unternehmen bereit ist für einen strukturellen Wandel in eine agile Steuerungsform, kann Ihnen ein von uns durchgeführter Check zeigen. Man trifft zu oft auf Fälle, bei denen vor einer „Agilisierung“ etablierter Strukturen eher abgeraten werden sollte. Nicht immer passt das agile Modell und nicht immer ist eine Skalierung erfolgreicher agiler Teams auf größere Unternehmensbereiche sinnvoll.
Der Hauptgrund, trotz aller möglicher Widrigkeiten eine Transition nach SAFe® durchzusetzen, ist, den Wert eines Services oder einer Leistung - und damit indirekt auch den Wert des Unternehmens - zu erhöhen. Mit dem Flow of Value wird die Wertorientierung jeder Aktivität, jedes Services in den Mittelpunkt gestellt. Althergebrachte Prozesse, die nur gemäß dem Motto „das machen wir halt schon immer so“ noch am Leben erhalten werden, müssen sich nach SAFe® ihrem Beitrag am Gesamtwert messen lassen. Eine Transition kann also auch bereinigend wirken. Alte Zöpfe abschneiden und Prozesse überdenken helfen. Mit kleinen Schritten dem Gesamtziel näherkommen.
Ob SAFe® nun eine geeignete Struktur für Ihre Organisation, Ihre IToder auch nur Ihr geplantes Projekt darstellt, kann hier nicht pauschal beantwortet werden.
Aber wenn Sie sich für eine Analyse dieses Vorgehensmodells entscheiden, können wir Ihnen helfen herauszufinden, wo SAFe® Sie unterstützen wird. Wir prüfen gerne die Möglichkeiten und planen eine optimale Struktur für die Einführung von SAFe® gemeinsam mit Ihnen durch.
Wenn Sie daran interessiert sind und von unseren Erfahrungen aus unseren zahlreichen Projekten nach SAFe® oder anderen skalierten Vorgehensarten profitieren wollen, sprechen Sie uns hierzu gerne an: Robert Meinl.
Besuchen Sie uns regelmäßig hier im Blog, um auch weitere Details zu SAFe® und andere agilen und klassischen Vorgehensmodellen zu erfahren.
Wir freuen uns über Ihre direkte Kontaktaufnahme!