Published by

Il y a 1 mois -

Temps de lecture 7 minutes

Commencer une transformation agile à l’échelle par le portefeuille

Récemment, j’ai eu l’opportunité de travailler sur une transformation agile voulue par une entreprise qui souhaitait sécuriser son portefeuille de projets. La seule mise en place d’une gestion de portefeuille lean (ou LPM pour Lean Agile Portfolio) a eu immédiatement des effets bénéfiques sur l’agilité de l’entreprise et les schémas mentaux des collaborateurs. Elle a permis une prise de conscience immédiate et collective de la nécessité de mener une transformation agile à l’échelle dans toute l’entreprise.

Cette expérience m’a convaincu qu’il est très intéressant d’initier une transformation agile par la mise en place d’un LPM contrairement à ce que conseille la Scale Agile foundation dans sa feuille de route d’implementation du cadre de travail SAFe.

Budgétiser la stratégie de l’entreprise

Dans les entreprises que j’ai accompagnées, la DSI est souvent soumise à une triple contrainte. D’un côté, elle est vue comme un centre de dépense dont on cherche à limiter le budget. De l’autre il y a une forte injonction côté métiers à innover et à se digitaliser qui se traduisent en de nouveaux investissements dans le système d’information.

En parallèle, pour répondre plus rapidement aux demandes métier et être plus efficiente, la DSI doit se moderniser et réduire sa dette technique. Si cela se traduit à moyen terme par des coûts récurrents moindres, il est nécessaire dans un premier temps d’investir pour y arriver.

Tout ceci amène à de grandes frustrations et à un cercle vicieux. La DSI va souhaiter répondre au mieux aux demandes des métiers tout en restant dans son budget restreint. Elle va, pour y tendre, mettre de côté ses projets de modernisation en se cantonnant au strict nécessaire. Les métiers vont être frustrés de ne pas pouvoir réaliser tous leurs projets et pointeront du doigt une DSI peu efficace et vieillissante.

En constituant un portefeuille de projets ordonnés par priorité entre les différents métiers et la DSI, il devient plus facile de répondre à la question : jusqu’où devons-nous investir pour réussir la stratégie de l’entreprise ? (voir figure 1). Le budget de la DSI se décide en pleine conscience de ce qui doit être  fait ou non pour répondre à la stratégie. Les investissements nécessaires aux métiers et à une modernisation de la DSI pourront être financés.

Figure 1

Impliquer et aligner les métiers dans la transformation

De mon expérience les métiers sont parfois difficiles à embarquer dans une transformation agile, vu souvent comme un sujet purement DSI. Lorsqu’on commence la transformation par le portefeuille projet, ils y sont impliqués de facto car le portefeuille constitue le point de jonction entre les projets métiers et DSI. La gestion de ce portefeuille est souvent vue comme étant opaque et il est source de frustration côté DSI qui se voit arbitrer les projets à la place des métiers qui ne veulent pas le faire entre eux.

En mettant en place un LPM, et plus particulièrement en mettant en place une mécanique de priorisation par la valeur, on établit un dialogue et une prise de conscience des enjeux des uns et des autres particulièrement bénéfique à l’ensemble de l’entreprise. En effet chacun des métiers sera amené à se faire challenger par les autres et devra justifier la valeur de ses projets par rapports aux autres et démontrer en quoi ils répondent à la stratégie de l’entreprise.

Pour que le dialogue puisse se faire de manière apaisée il sera nécessaire au préalable que cette  stratégie soit clairement définie et communiquée aux différentes lignes métier. Les OKR (Objectives and Key Results) sont, par exemple, un très bon moyen d’y arriver.

Ce travail de justification par la valeur et de priorisation constitue une première étape primordiale dans la transformation agile. La seconde étape, la réduction des lots, moins facile et naturelle se met en place plus difficilement, mais encore une fois le LPM peut y aider.

 

Un point central d’apprentissage

J’ai souvent remarqué, dans le cas d’une transformation agile initié par la DSI, un certain déséquilibre. On demande aux métiers de se mettre en capacité de livrer un flux d’user story. Cela est bien utile pour que l’équipe de développement puisse travailler en sprint. A contrario le métier, lui n’en voit que rarement les bénéfices car l’équipe de développement n’est souvent pas encore assez mâture pour déployer de manière continue. Elle ne peut donc pas produire l’avantage réciproque au métier : un feedback plus fréquent (voir figure 2).

Figure 2

 

En mettant en place une mécanique de priorisation comme le WSJF, les acteurs du portefeuille vont vite apprendre que non seulement il faut mettre en avant la valeur apportée par un projet, mais aussi qu’il faut apporter le meilleur ratio/travail. D’une manière assez naturelle les lots de projet vont être amenés à se réduire au fur et à mesure pour se réduire aux parties donnant le plus de valeur. Dans le même temps la DSI se modernisera et s’automatisera de manière à réduire les coûts de transaction des déploiements et donc de rendre bénéfique la réduction des lots (voir figure 3). Les livraisons deviendront donc plus fréquentes et les feedbacks aussi.

Figure 3

 

Initier une collaboration en amont des projets

Cela nous amène vers mon troisième et dernier point. Afin de créer le meilleur ratio valeur/travail les acteurs du portefeuille vont devoir réaliser une analyse rapide de la valeur apportée ainsi que du travail nécessaire à la bonne réalisation du projet. Si pour la première partie, les métiers sont autonomes, pour la deuxième ils vont avoir besoin de collaborer avec la DSI pour obtenir un ordre de grandeur du travail nécessaire à la réalisation du projet.

L’analyse du travail à faire se fait par l’implication très en amont du portefeuille d’architectes DSI. Ceci va leurs permettre de comprendre au plus tôt les besoins des métiers et donc de lancer les prérequis technologiques rapidement. Les architectes vont aussi pouvoir conseiller les métiers en leur proposant des raccourcis apportant de suite beaucoup de valeur, ou de nouvelles approches technologiques issue de leur veille qui pourraient les aider à innover.

Cette collaboration en amont du portefeuille est donc doublement vertueuse en permettant à la DSI de comprendre la vision métier, de s’y préparer, et en permettant aux métiers de bénéficier plus rapidement de nouvelles innovations.

 

La mise en place du LPM permet un changement radical

SAFe est un framework qui n’a plus à faire ses preuves. Il est implémenté dans de nombreuses entreprises et il est aujourd’hui la référence des cadres de travail agile à l’échelle. On peut en dire ce qu’on veut il est une boîte à outil très complète et très efficace pour une transformation agile à l’échelle.

Pourtant, suite à mon expérience et aux vues des bénéfices exposé ci-dessus, je considère comme une erreur de positionner la mise en place d’un LPM tardivement dans la feuille de transformation. Il me semble que le biais pris par la Scale Agile Foundation vient de l’habitude d’initier les transformations agiles à l’échelle par la DSI de manière bottom-up.

Nous le savons, une transformation agile à l’échelle n’est pas que l’affaire de la DSI. L’initiation d’un LPM au début du plan de transformation agile permet de répondre rapidement à beaucoup de frustrations de l’entreprise et implique l’ensemble des plus hautes fonctions de l’entreprise dès le départ en traitant des sujets qui sont fondamentaux : stratégie de l’entreprise, dialogue et coopération entre les silos de l’entreprise, répartition budgétaire.

Published by

Commentaire

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Sapient, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.