Steve Marjot, s'est récemment joint à Jon Terry, évangéliste en chef de la stratégie Lean-Agile chez Planview, pour un webinaire afin de discuter du parcours de transformation Agile de RBS, de la gestion de portefeuille traditionnelle à la gestion de portefeuille Lean au cours des dernières années. Il a partagé les succès, les apprentissages, les obstacles surmontés tout au long du voyage (qui est toujours en cours), et leur capacité à pivoter, d'une manière Agile, du niveau de l'entreprise vers le bas.
Après avoir partagé le travail effectué par son équipe tout au long du voyage, Steve a passé un peu de temps à répondre aux questions du public. Les questions et les réponses sont ci-dessous.
Q : Comment maintenez-vous la bonne gouvernance dans ce processus ?
R : Je pense que l'hypothèse ici est que le traditionnel est bon et que l'Agile est mauvais, mais il s'agit d'une gouvernance appropriée à chaque niveau, et vous ne passez pas d'un bout à l'autre du voyage Agile en une seule fois. C'est une transition, étape par étape.
À chaque niveau, vous apportez un changement, vous révisez la gouvernance pour vous assurer qu'elle correspond toujours à l'objectif et qu'elle est appropriée, tout en appliquant les principes Agile. Au niveau de l'entreprise, si nous nous dirigeons vers la délégation d'enveloppes de financement, nous disposons d'un processus de gouvernance approprié pour définir cette enveloppe, sa taille et sa catégorisation, et la manière de la communiquer vers le bas.
Au niveau du domaine [flux de valeur], nous commençons à examiner la gouvernance autour de la signature des analyses de rentabilité et à tenir les gens responsables des résultats de l'analyse de rentabilité. Lorsque nous arrivons au niveau du programme [niveau Agile Release Train-ART], la gouvernance à ce stade consiste pour les dirigeants à s'intégrer dans des éléments tels que la planification de l'incrément de programme (PI) et à gérer l'équivalent de l'ancien conseil du programme, mais à l'intérieur de l'événement de planification PI - définir la vision au début, examiner les résultats au cours de la planification, résoudre les problèmes au fur et à mesure, puis signer les ressources et le financement à la fin - en s'engageant finalement à travailler pendant les trois prochains mois.
Au fur et à mesure que vous vous déplacez, concentrez-vous sur le changement que vous devez opérer pour gouverner et continuer à soutenir cela au sein de votre organisation.
Q : Quelle part de la transformation de la RBS a été impulsée par le développement de logiciels / la technologie, et quelle part a été impulsée par l'entreprise, ou est-ce conjoint ?
R : Il s'agit d'un effort conjoint. Nous menons des projets Agile, des équipes appliquant les pratiques Agile Scrum, depuis de nombreuses années. Depuis un certain temps, nous avons des poches de travail de conception Agile dans nos franchises clients et de livraison Agile dans notre espace technologique.
Cela a atteint un point de basculement, où, sur le plan organisationnel, nous avons senti qu'il était bon pour nous de nous transformer au niveau de l'entreprise, plutôt qu'au niveau local. Nous avons décidé de transformer nos modèles opérationnels, notre structure organisationnelle, nos rôles, nos processus et nos outils pour soutenir cette transformation. C'est la réunion des entreprises et de la technologie qui a permis d'y parvenir.
Il s'agissait d'une longue période de gestation - nous avons commencé au début de 2014 et sommes allés jusqu'à la fin de 2016, en construisant essentiellement cette capacité unique de regarder l'entreprise dans son ensemble. De la fin 2016 à aujourd'hui, nous avons travaillé à la transformation vers Agile. Ce fut un voyage de deux ans, et nous sommes encore loin de l'avoir intégré avec succès dans toute l'organisation. Nous sommes passés de 90% de gestion de portefeuille traditionnelle et 10% d'Agile à environ 70% de traditionnelle et 30% d'Agile. Nous effectuons une transition lente pour faire passer la balle par-dessus la colline et la rendre plus lourdement Agile ou Lean Portfolio Management que la gestion de portefeuille traditionnelle.
"Je pense que pour que la méthode Agile soit vraiment un succès à grande échelle, il faut que les deux parties [IT/Software Dev et Business] soient impliquées. Si l'adoption d'Agile est principalement dirigée par l'organisation technologique parce qu'elle veut simplement le faire, vos clients commerciaux risquent de ne pas être totalement à bord et de ne pas comprendre le pourquoi. Pour réussir véritablement, ils doivent comprendre l'avantage et comprendre ce qui sera différent. Sinon, tous les changements que vous effectuez seront simplement considérés comme des poids lourds." - Jon Terry, évangéliste en chef de la stratégie Lean-Agile, Planview
Q : Quelle est l'erreur majeure commise lors du déploiement chez RBS ?
R : Pour être tout à fait honnête, l'ensemble du processus donne l'impression que vous faites trois pas en avant et deux pas en arrière chaque fois que vous essayez de mettre en œuvre un changement. Même avec des champions et des dirigeants qui les soutiennent, il y a toujours un groupe ou quelqu'un qui a une raison pour laquelle ce changement ne peut pas être mis en œuvre. C'est un processus très difficile - il s'agit d'un changement de culture et de gestion du changement.
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.
Ce que nous avons découvert, c'est qu'il y a un défi d'éducation et un défi de maturité. Lorsque vous réunissez la course et le changement et que vous les rendez conjointement responsables, vous ne pouvez pas vraiment faire cela et vous attendre à ce que cela fonctionne. Un changement fondamental et significatif de culture et de capacité doit être effectué dans le cadre de ce processus.
Q : Comment évangélisez-vous la transformation à l'ensemble de l'organisation ?
R : . Il s'agit de tous les processus normaux. Vous avez vos leaders évangélistes agiles qui se lèvent et disent : "Je vais être responsable" - ils le vivent et le respirent. Ensuite, vous avez vos coachs Agile qui aident à effectuer ces changements dans toute l'organisation. Vous commencez à semer les Scrum Masters et les coaches. Mais en fin de compte, tout est dirigé par le sommet - le leadership. Ils doivent s'engager à contribuer à la suppression des obstacles pour en assurer le succès.
Q : Quelle est la place du Change Center of Excellence dans votre organisation ? Avez-vous encore des groupes de pilotage et de surveillance ? Comment cette structure se présente-t-elle aujourd'hui ?
R : Ces groupes existent toujours, mais la façon dont nous les mettons en œuvre a changé. Au niveau du programme [ART], nous avons intégré la gouvernance du programme dans les cérémonies du programme et nous demandons aux dirigeants d'assister aux cérémonies, de participer à la prise de décision en temps réel et de documenter les résultats et les décisions de ces conversations. Cela crée un dossier vérifiable pour montrer comment le leadership gère ces dépendances et prend de bonnes décisions financières.
Lorsque nous parlons du niveau du domaine [flux de valeur], l'élément clé était de ne plus exiger une gouvernance typique, mais de la remplacer par quelque chose d'aussi robuste. Par exemple, lorsque nous pensons à l'architecture, nous avions l'habitude d'exiger que chaque programme produise un plan d'architecture qui s'inscrivait dans le cadre de son analyse de rentabilité. Ce que nous demandons maintenant, c'est que chaque domaine crée un plan d'affaires de domaine qui articule la manière dont il exploite l'architecture de la banque, la manière dont il exploite les facilitateurs technologiques, et les résultats qu'il essaie d'obtenir au cours de l'année prochaine par le biais du financement de ses affaires de domaine.
Il existe une autorité d'architecture qui supervise ce processus et s'assure qu'il est maintenu dans toute la banque. Nous avions l'habitude de le faire au niveau du programme ; nous le faisons maintenant au niveau du domaine d'une manière légèrement différente. Le groupe se réunit toujours fréquemment avec les mêmes personnes, mais ces architectes d'entreprise ont maintenant moins de domaines à examiner et passent plus de temps à réfléchir à l'application de cette architecture. Nous avons toujours des groupes de pilotage ; dans la mesure du possible, nous essayons de les intégrer dans les cérémonies du travail ou de les rendre pertinents et appropriés au niveau de gouvernance que nous essayons d'atteindre.
Q : Votre processus budgétaire a-t-il changé ?
R : Nous avons toujours un processus de budgétisation annuel. Pour l'instant, nous n'avons pas l'intention de modifier ce processus. Ce que nous faisons actuellement, c'est définir les enveloppes de financement sur une base annuelle et utiliser le mécanisme d'analyse de rentabilité du domaine comme moyen de déléguer le financement vers le bas pour une prise de décision continue au niveau local. Nous n'avons pas changé notre processus de financement annuel avec notre équipe financière, mais nous avons appliqué les principes Agile, en termes de délégation du travail, de priorisation et de prise de décision.
Q : Existe-t-il un moyen de quantifier la valeur de ce que vous apportez aux clients grâce à cette nouvelle façon de travailler ?
R : Avec notre nouvelle approche, nous intégrons les résultats quantifiables dans l'analyse de rentabilité, puis à chaque niveau. Une fois ces éléments en place, nous tenons le domaine responsable, sur la base des résultats qu'il souhaite atteindre avec les fonds alloués. Lorsque nous descendons au niveau du programme et que nous commençons à parler des fonctionnalités qui sont une partie du travail axé sur la valeur, chaque fonctionnalité doit avoir un mécanisme pour identifier ce qu'est cette valeur et comment elle est mesurée. Si nous allons plus loin, nous nous attendons à ce que chaque histoire d'utilisateur ait une définition qui inclut la valeur qui en découlera, comme la durée du cycle. Plus haut, nous regardons les revenus générés ou le score NPS. Chaque niveau doit être lié à une valeur applicable à chaque niveau. En fin de compte, ils doivent atteindre les résultats commerciaux au niveau de l'entreprise.
Si vous souhaitez en savoir plus sur l'histoire de Steve, qui dirige la transformation Agile chez RBS, consultez le webinaire à la demande . Pour en savoir plus sur le Lean Portfolio Management et sur la manière dont il modifie la création de valeur dans toute l'entreprise, téléchargez dès maintenant le livre blanc sur le Lean Portfolio Management pour l'entreprise.
