Steve Marjot hat kürzlich zusammen mit Jon Terry, Chief Evangelist für Lean-Agile Strategy bei Planview, ein Webinar durchgeführt, in dem er den Weg der RBS Agile Transformation vom traditionellen Portfoliomanagement zu Lean Portfoliomanagement in den letzten Jahren diskutiert hat. Er erzählte von seinen Erfolgen und Erfahrungen, von den Hindernissen, die auf dem Weg dorthin überwunden wurden (der noch lange nicht abgeschlossen ist), und von seiner Fähigkeit, auf agile Weise von der Unternehmensebene nach unten zu schwenken.
Nachdem er über die Arbeit seines Teams berichtet hatte, nahm sich Steve Zeit, um Fragen aus dem Publikum zu beantworten. Die Fragen und Antworten finden Sie unten.
F: Wie sorgen Sie für eine gute Regierungsführung in diesem Prozess?
A: Ich glaube, hier wird davon ausgegangen, dass traditionell gut und agil schlecht ist, aber es geht um eine angemessene Governance auf jeder Ebene, und Sie gehen nicht von einem Ende der agilen Reise in einem Rutsch. Es ist ein Übergang, Schritt für Schritt.
Auf jeder Ebene nehmen Sie eine Änderung vor, überprüfen die Governance, um sicherzustellen, dass sie immer noch dem Zweck dient und angemessen ist, und wenden dabei die agilen Prinzipien an. Wenn wir auf Unternehmensebene zu einer Delegation von Finanzierungsumfängen übergehen, dann müssen wir einen Governance-Prozess haben, der für die Definition dieser Umfänge - Größe und Kategorisierung - geeignet ist und wie wir sie nach unten kommunizieren.
Auf der Ebene des Bereichs [Wertstroms] fangen wir an, uns mit der Governance zu befassen, d.h. mit der Freigabe von Geschäftsfällen und der Rechenschaftspflicht der Mitarbeiter für die Ergebnisse des Geschäftsfalls. Wenn wir die Programmebene [Agile Release Train-ART-Ebene] erreichen, geht es bei der Governance an diesem Punkt darum, dass sich die Führungskräfte in Dinge wie die Programminkrementplanung (PI) einbetten und das Äquivalent zum alten Programmboard, aber innerhalb des PI-Planungsereignisses durchführen - die Vision zu Beginn festlegen, die Ergebnisse im Laufe der Planung überprüfen, die Probleme im Laufe des Prozesses lösen und dann die Ressourcen und die Finanzierung am Ende absegnen - und sich damit letztlich für die Arbeit der nächsten drei Monate verpflichten.
Konzentrieren Sie sich auf die Veränderungen, die Sie vornehmen müssen, um diese innerhalb Ihrer Organisation zu steuern und zu unterstützen.
F: Wie viel von der RBS-Transformation wurde von der Softwareentwicklung/Technologie vorangetrieben und wie viel vom Geschäft, oder ist es ein gemeinsames Projekt?
A: Es ist eine sehr gemeinsame Anstrengung. Wir führen seit vielen Jahren agile Projekte durch, Teams, die Agile Scrum-Praktiken anwenden. Schon seit geraumer Zeit haben wir in unseren Kundenbereichen agile Designarbeit und in unserem Technologiebereich agile Lieferung.
Damit war ein Wendepunkt erreicht, an dem wir das Gefühl hatten, dass es für uns richtig war, uns auf Unternehmensebene und nicht nur auf lokaler Ebene umzustellen. Wir haben beschlossen, unsere Betriebsmodelle, Organisationsstruktur, Rollen, Prozesse und Tools zu verändern, um diesen Wandel zu unterstützen. Es war ein Zusammentreffen von Wirtschaft und Technologie, das dies ermöglichte.
Es war eine lange Entwicklungszeit - wir begannen Anfang 2014 und gingen bis Ende 2016, wobei wir im Wesentlichen diese eine Fähigkeit aufbauten, um das Unternehmen als Ganzes zu betrachten. Von Ende 2016 bis jetzt haben wir an der Umstellung auf Agile gearbeitet. Es war eine zweijährige Reise, und wir sind noch weit davon entfernt, sie erfolgreich in der gesamten Organisation zu verankern. Wir sind von 90% traditionellem Portfoliomanagement und 10% Agile zu etwa 70% traditionellem und 30% Agile übergegangen. Wir gehen langsam dazu über, den Ball über den Hügel zu bringen und das Agile oder Lean Portfolio Management schwerer zu machen als das traditionelle Portfolio Management.
"Ich denke, dass Agile nur dann wirklich erfolgreich sein kann, wenn beide Seiten [IT/Softwareentwicklung und Business] beteiligt sind. Wenn die Einführung von Agile hauptsächlich von der Technologieorganisation vorangetrieben wird, weil sie es einfach tun will, sind Ihre Geschäftskunden möglicherweise nicht ganz an Bord und verstehen nicht, warum. Um wirklich erfolgreich zu sein, müssen sie den Nutzen verstehen und wissen, was anders sein wird. Andernfalls werden alle Änderungen, die Sie vornehmen, einfach nur als schwerfällig angesehen." - Jon Terry, Chef-Evangelist Lean-Agile Strategie, Planview
F: Welches ist der größte Fehler, der bei der Einführung bei RBS gemacht wurde?
A: Um ganz ehrlich zu sein, fühlt es sich so an, als ob Sie jedes Mal, wenn Sie versuchen, eine Veränderung zu implementieren, drei Schritte vorwärts und zwei zurück machen würden. Selbst wenn es Befürworter und unterstützende Führungskräfte gibt, gibt es immer eine Gruppe oder jemanden, der einen Grund hat, warum diese Veränderung nicht umgesetzt werden kann. Es ist ein sehr schwieriger Prozess - es ist ein Kulturwandel und Change Management.
If I had to pick out one thing that totally floored me, it was when we deployed the organizational changes to support an Agile way of working. Some parts of the of the business employed non-change professionals in the Agile Release Train manager roles. These people came into this with no grounding in the governance, assurance, or risk-management processes that our change professionals know inside out. The thing we completely missed, was that while we’re talking about a 50 % reduction in data transfer and speeding up cycle times, they had no idea what these things meant. What these non-change professions see is 50 % imposed governance and data which is 50 % too much, as far as they’re concerned.
Wir haben festgestellt, dass es eine Herausforderung für die Bildung und die Reife gibt. Wenn Sie Run und Change zusammenbringen und sie gemeinsam zur Verantwortung ziehen, können Sie das nicht einfach tun und erwarten, dass es funktioniert. Im Rahmen dieses Prozesses muss ein grundlegender und signifikanter Wandel der Kultur und der Fähigkeiten stattfinden.
F: Wie vermitteln Sie den Wandel in der gesamten Organisation?
A: Es sind alle normalen Prozesse. Sie haben Ihre agilen Evangelisten, die aufstehen und sagen: "Ich werde Rechenschaft ablegen" - sie leben es und atmen es. Dann haben Sie Ihre Agile Coaches, die Ihnen dabei helfen, diese Änderungen in der gesamten Organisation umzusetzen. Sie beginnen mit der Auswahl der Scrum Master und Coaches. Letztendlich wird aber alles von der Spitze angeführt - Leadership. Sie müssen sich dafür einsetzen, die Hindernisse zu beseitigen, die dem Erfolg im Wege stehen.
F: Welchen Platz nimmt das Change Center of Excellence in Ihrer Organisation ein? Haben Sie immer noch Lenkungs- und Aufsichtsgruppen? Wie sieht diese Struktur heute aus?
A: Diese Gruppen gibt es immer noch, aber die Art und Weise, wie wir sie einsetzen, hat sich geändert. Auf der Ebene des Programms [ART] haben wir die Programmsteuerung in die Programmzeremonien eingebettet und bitten die Führungskräfte, zu den Zeremonien zu gehen, sich in Echtzeit an der Entscheidungsfindung zu beteiligen und die Ergebnisse und Entscheidungen dieser Gespräche zu dokumentieren. So entsteht eine prüfbare Aufzeichnung, die zeigt, wie die Führung diese Abhängigkeiten verwaltet und gute finanzielle Entscheidungen trifft.
Wenn wir über die Ebene des Bereichs [Wertstroms] sprechen, war das Wichtigste, dass die typische Governance nicht mehr erforderlich war, sondern durch etwas ebenso Robustes ersetzt werden musste. Wenn wir zum Beispiel über Architektur nachdenken, verlangten wir früher von jedem Programm, dass es einen Architekturentwurf erstellt, der mit dem Geschäftsplan des Programms einherging. Wir bitten nun jeden Bereich, einen Business Domain Blueprint zu erstellen, in dem dargelegt wird, wie er die Architektur der Bank nutzt, wie er die technologischen Voraussetzungen nutzt und welche Ergebnisse er im Laufe des nächsten Jahres durch die Finanzierung seiner Domain Business Cases erzielen möchte.
Es gibt eine Architekturbehörde, die diesen Prozess beaufsichtigt und sicherstellt, dass er in der gesamten Bank eingehalten wird. Früher haben wir dies auf der Programmebene getan, jetzt tun wir es auf der Domänenebene auf eine etwas andere Weise. Die Gruppe trifft sich immer noch häufig mit denselben Personen, aber diese Unternehmensarchitekten haben jetzt weniger Domänen zu betrachten und verbringen mehr Zeit damit, über die Anwendung dieser Architektur nachzudenken. Wir haben immer noch Lenkungsgruppen. Wo immer es möglich ist, versuchen wir, sie in die Zeremonien der Arbeit einzubetten oder sie so zu gestalten, dass sie für die Ebene der Governance, die wir zu erreichen versuchen, relevant und angemessen sind.
F: Hat sich Ihr Budgetierungsprozess geändert?
A: Wir haben immer noch einen jährlichen Budgetierungsprozess. Zum jetzigen Zeitpunkt haben wir nicht die Absicht, diesen Prozess zu ändern. Gegenwärtig legen wir die Mittel für die Finanzierung auf jährlicher Basis fest und verwenden den Mechanismus des Domain Business Case, um die Finanzierung für die kontinuierliche Entscheidungsfindung auf lokaler Ebene zu delegieren. Wir haben unseren jährlichen Finanzierungsprozess mit unserem Finanzteam nicht geändert, aber wir haben agile Prinzipien angewandt, was die Delegation von Arbeit, die Priorisierung und die Entscheidungsfindung angeht.
F: Gibt es eine Möglichkeit, den Wert dessen zu beziffern, was Sie Ihren Kunden durch diese neue Arbeitsweise bieten?
A: Mit unserem neuen Ansatz bauen wir die quantifizierbaren Ergebnisse in den Business Case und dann auf jeder Ebene ein. Auf diese Weise können wir die Domäne auf der Grundlage der Ergebnisse, die sie mit den zugewiesenen Mitteln erreichen möchte, zur Rechenschaft ziehen. Wenn wir uns auf die Programmebene begeben und anfangen, über Funktionen zu sprechen, die einen Teil der wertorientierten Arbeit darstellen, sollte jede Funktion einen Mechanismus haben, um zu bestimmen, was dieser Wert ist und wie er gemessen wird. Wenn wir das noch weiter aufschlüsseln, erwarten wir, dass jede Benutzergeschichte eine Definition hat, die den Wert beinhaltet, der sich aus ihr ergibt, wie z.B. die Zykluszeit. Weiter oben sehen wir uns die umsatzabhängigen Werte oder den NPS-Wert an. Jede Ebene muss mit dem entsprechenden Wert auf jeder Ebene verbunden sein. Letztlich müssen sie die Geschäftsergebnisse auf Unternehmensebene erreichen.
Wenn Sie mehr von Steves Geschichte hören möchten, wie er die agile Transformation bei RBS leitet, sehen Sie sich das on-demand Webinar an. Wenn Sie mehr über Lean Portfolio Management erfahren möchten und darüber, wie es die Wertschöpfung im gesamten Unternehmen verändert, laden Sie jetzt das Whitepaper the Lean Portfolio Management for the Enterprise herunter.
