Your new post is loading...
Lors du Sommet SAFe, j’ai participé à un atelier sur la priorisation des investissements au sein du portefeuille projet. Le contenu était excellent et m’a permis de développer une meilleure vue d’ensemble du processus LPM, mais un sondage à mains levées a montré que moins de 15% des participants à mon atelier étaient « totalement SAFe ».
Cela signifie qu’au sein de notre petit groupe d’une centaine de participants, environ 85 % appartiennent à des organisations où il existe une combinaison de d’Agile Release Trains et d’équipes projet classiques. Cela génère des problèmes intéressants au niveau de la gestion de portefeuille.
Une approche, et peut-être la plus évidente, consisterait à diviser la planification des activités en deux groupes de portefeuilles distincts : un pour SAFe et LPM, et un autre pour les projets classiques. Mais ceci ne pourrait fonctionner que s’il y a peu ou pas d’interactions entre les deux groupes de portefeuilles, et si les responsables de chaque portefeuille sont relativement indépendants les uns des autres.
Ce n’est pas très courant étant donné le lien étroit qui ont tendance à s’établir entre, disons, une équipe de développement de nouveau produit et une équipe IT qui fournit l’infrastructure et le support pour le site Web du nouveau produit.
Une meilleure approche consisterait à explorer la manière de créer des « portefeuilles hybrides pour un monde hybride ». Dans cette approche, un portefeuille projet serait en mesure d’apporter son soutien à la fois à des development value stream composés d’ART SAFe, de projets Stage-Gate, de projets Agile et de projets Hybrid Agile Stage-Gate. Cette approche prend en compte le fait que différents groupes utilisant des méthodologies et des framework différents doivent travailler sur des flux de travail interdépendants.
Toutefois, cette approche peut générer un nouvel jeu de problèmes au niveau cette fois de l’exécution. L’idée que les équipes Agiles ont besoin de liberté pour redéfinir les priorités de leur backlogs signifie qu’elles ne peuvent pas être contraintes à rentrer dans le cadre de projets Stage-Gate rigides où les spécifications et les process ne peuvent pas changer.
A la place, les praticiens Stage-Gate doivent adopter le process Stage-Gate Next-Gen proposé par Robert Cooper : plutôt qu’un process rigide, Stage-Gate Next-Gen intègre les mêmes principes que ceux privilégiés par les praticiens Agile (et par extension, SAFe). Il est tout à fait permis de sauter ou de répéter des Stages, de faire évoluer et de modifier les spécifications, de changer la définition du produit, à condition que tout cela réponde aux exigences économiques du projet.
Il est difficile d’affirmer que cette approche hybride est optimale sur le long terme, mais aucun doute : les Release Trains sont de plus en plus couramment utilisés, et il faudra des années à la plupart des entreprises pour s’adapter. Afin de mener à bien la transition, il deviendra donc essentiel de réfléchir en terme de portefeuille hybride qui intègre toutes les activités de développement de produit, peu importe la méthodologie ou le framework.