Devops for Growth

Nous proposons donc une figure unique pour illustrer la mécanique sur laquelle repose le fonctionnement de la GPP dans le but de proposer une vue d’ensemble qui permette de faciliter la compréhension, l’implantation et le pilotage du processus en temps réel au sein de votre organisation.

La figure ci-dessous montre les deux leviers (illustrés en gris) à partir desquels fonctionne le processus de GPP. L’objectif global du fonctionnement du processus de GPP consiste à maintenir en équilibre ces deux leviers4. Voyons plus en détail comment cela s’articule.

Le premier levier, situé au niveau stratégique, vise deux buts connexes qui consistent 1) à «équilibrer» l’orientation des initiatives soumises avec les objectifs stratégiques de l’organisation (alignement stratégique) et 2) à «équilibrer» le coût des initiatives soumises avec la capacité financière de l’organisation de les réaliser (alignement financier).

Le second levier, situé au niveau tactique, a lui pour but d’équilibrer les besoins en ressources avec la capacité de l’organisation. Autrement dit, le second levier cherche à «équilibrer» les ressources requises par les initiatives avec les ressources dont dispose réellement l’organisation à différents moments du déroulement. L’équilibre de ce second levier implique que les ressources financières et humaines doivent être réellement disponibles pour réaliser les initiatives, en quantité et au moment prévu. Ici réside la plus grande difficulté à surmonter pour l’ensemble des organisations.

La mécanique à deux leviers de la gestion de portefeuille de projet

La gestion de portefeuille à deux leviers5

Si l’équilibre du premier levier est relativement simple à réaliser et à maintenir dans le temps, l’équilibre du second levier est beaucoup plus difficile à atteindre et surtout complexe à maintenir au fil du temps et du déroulement des différentes initiatives.

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.

Différences Programme vs Portefeuille

Un portefeuille rassemble des projets qui n’ont pas forcément de rapport entre eux. Dans un programme, c’est justement le rapport existant – ou possible – entre les projets qui est la raison d’être du programme.

Le terme rapport est volontairement assez vague pour couvrir des situations diverses.

L’exemple évident de rapport entre les projets est la notion d’interdépendance (ex: le projet A utilise un résultat du projet B). Dans ce cas, le programme permet de renforcer le contrôle par une meilleure coordination entre les projets.

Mais un programme permet aussi de créer de nouveaux liens entre les projets afin de générer des bénéfices supplémentaires. Un programme permet de créer de nouvelles opportunités.

Par exemple, en réunissant plusieurs projets au sein d’un programme, on peut générer des offres combinées à plus grande valeur ajoutée. Sans programme, l’offre combinée risque de ressembler à un patchwork sans homogénéité.

De plus, la bonne coordination de plusieurs projets peut générer une valeur supplémentaire, par exemple en créant un effet d’annonce grâce à la sortie simultanée de plusieurs produits.

Enfin, le programme est aussi une source d’économies (par ex: passage d’appels d’offres plus importants, développements de composants réutilisables sur plusieurs projets, mutualisation des coûts publicitaires ou de communication etc.).

Le portefeuille et le programme ont des vocations très différentes. Le portefeuille est un outil de pilotage managérial. De son côté, le programme apporte une valeur business supplémentaire en plus d’être un outil de pilotage.