Qu’est-ce que la gestion de programme agile ?

La gestion de programme agile est une approche de gestion de plusieurs projets liés (un programme), qui s’appuie sur des principes agiles tels que la flexibilité, la collaboration, le développement itératif, la priorité donnée aux retours clients et l’amélioration continue.

La philosophie Agile qui repose avant tout sur un ensemble de principes, plutôt qu’une méthodologie unique. Cela dit, certaines méthodologies agiles bien établies, comme Scrum, l’Extreme Programming (XP) ou Kanban, font souvent partie intégrante de la gestion de programme agile. À l’origine conçue par et pour l’industrie du logiciel afin d’apporter plus de valeur aux clients plus rapidement, la gestion de programme agile s’applique aujourd’hui bien au-delà de ce secteur.

La gestion de programme agile inclut généralement plusieurs projets connexes. Il est possible de gérer les projets individuels avec un cadre Agile, mais la gestion de programme agile intègre un ensemble de projets dans un seul ensemble cohérent tout au long du cycle de vie. Au niveau supérieur, un ensemble de programmes et de projets sous-jacents peut être organisé dans le cadre d’une stratégie de gestion de portefeuille plus large.

La gestion de projet agile se concentre sur un projet spécifique et sur la gestion des objectifs, des délais, des ressources et des équipes liés à ce projet. La gestion de programme agile supervise un groupe de projets liés et la stratégie qui les unit dans le cadre d’objectifs organisationnels plus larges. Ces deux disciplines partagent bon nombre de fonctions, mais leur portée varie, les gestionnaires de programmes agiles jouant un rôle plus large dans la stratégie du programme, la gestion des risques, la communication avec les parties prenantes, etc.

Une façon rapide et un peu simplifiée de voir les choses est que la gestion de projet se concentre davantage sur l’exécution tactique et ponctuelle d’un projet spécifique, tandis que la gestion de programme adopte une approche plus stratégique, visant à coordonner la réussite globale de plusieurs projets distincts relevant d’un même programme.

La gestion de projet, en tant que discipline, a commencé à se structurer aux États-Unis dans les années 1950. Dans les années 1990, un ensemble de méthodes appelé «cycle en cascade » a été formalisé, selon lequel chaque phase d’un projet doit être entièrement achevée avant que l’équipe ne passe à la suivante. Mais à mesure que les logiciels gagnaient en importance et en complexité, les méthodes traditionnelles de gestion de projet, notamment le cycle en cascade, se sont révélées lourdes et peu adaptées à des projets évoluant rapidement et soumis à des changements fréquents.

En 2001, un groupe de développeurs de logiciels crée le manifeste Agile pour la gestion de projet agile, qui comprend quatre valeurs clés et douze principes. Voici ces valeurs clés :

• Les individus et leurs interactions plutôt que les processus et les outils
  
  
• Logiciel fonctionnel plutôt que documentation complète
  
  
• La collaboration avec le client  plutôt que la négociation de contrat
  
  
• L’adaptation au changement plutôt que le suivi d’un plan

Les valeurs préférées n’impliquent pas l’abandon des valeurs moins mises en avant. Par exemple, la philosophie agile n’interdit pas l’usage d’un plan, mais accorde davantage d’importance à la capacité de réagir et de se préparer aux changements inévitables.

Ces principes agiles ont été de plus en plus utilisés dans le processus de développement de logiciels, mais la philosophie va bien au-delà du développement logiciel agile. Les principes agile sont désormais employés dans de nombreux secteurs, de la mode à la biotechnologie et aux gouvernements.

Ce qui différencie l’approche agile des méthodes précédentes, telles que le cycle en cascade, c’est que les méthodes agiles sont, dès le départ, conçues pour être itératives, coopératives et flexibles. Dans un système de gestion de programme agile, les projets sont lancés rapidement et font l’objet d’évaluations, de discussions et d’ajustements réguliers en fonction des retours de l’équipe ou des clients. On part du principe, dès le départ, que les plans et les approches devront évoluer, sans attachement rigide à la planification initiale. Les membres de l’équipe sont encouragés à s’exprimer librement, dans une structure moins hiérarchique que dans d’autres approches.

Comme la gestion de programme agile est une philosophie plutôt qu’une méthodologie concrète, les pratiques agiles peuvent varier considérablement d’une organisation à l’autre, ou même d’un programme à l’autre. Il existe toutefois certains éléments communs à la plupart des approches.

La gestion de programme agile englobe plusieurs projets distincts : l’ensemble du programme, tout comme chaque projet individuel, peut être structuré selon un cadre agile. Elle adopte une vision globale et holistique d’un ensemble de projets, et inclut souvent des aspects absents de la gestion de projet isolée, tels que la budgétisation, la stratégie d’ensemble et l’analyse à long terme.

Réagir rapidement au changement est un principe fondamental de la philosophie agile. Ainsi, la gestion de programme agile accueille le changement comme une opportunité d’ajuster le cap et d’apporter des améliorations en cours de route, dans le but de créer de la valeur pour le client. Le découpage des projets en petites étapes à réaliser favorise la flexibilité des organisations et leur permet de s’adapter plus rapidement.

L’un des aspects clés de la gestion de programme agile réside dans son approche itérative. Chaque projet individuel au sein du programme passe par plusieurs itérations, les équipes de développement produit discutant des résultats à chaque fois pour les améliorer. Il est essentiel de fournir en permanence des résultats fonctionnels, qu’il s’agisse d’un projet entier ou d’un seul aspect. Il est également important d’affiner le produit à chaque itération en fonction des commentaires des clients, des KPI et de l’évolution des exigences.

La priorisation d’Agile privilégie les conversations en face à face plutôt que les longs échanges d’e-mails ou autres communications textuelles. Alors qu’un fil de discussion peut prendre des heures, des jours, voire des semaines en raison de contraintes de temps ou d’e-mails manqués, la même tâche peut être accomplie par une communication en personne en quelques minutes.

La gestion de programme agile, en tant que vision d’ensemble d’un programme, doit rester centrée sur l’efficacité et l’élimination des éléments superflus ou contraignants. La documentation n’est qu’un moyen, non une fin en soi, et ne doit contenir que ce qui est strictement nécessaire.

L’honnêteté et la transparence sont essentielles au succès d’un programme agile. Les échanges doivent permettre à chaque membre de l’équipe de s’exprimer. Dans cette approche, chaque voix compte et mérite d’être entendue.

En parallèle, il doit rester acceptable d’écarter les idées inexploitables sans que cela décourage leur auteur de participer à nouveau. Le bon déroulement des « rétrospectives », ces bilans de fin de projet servant à recueillir des retours, repose également sur cette transparence collective.

La gestion de programme agile, en tant que philosophie, n’impose l’usage d’aucun cadre spécifique. Toutefois, de nombreux cadres de gestion de projet, comme Scrum ou Kanban, sont aujourd’hui étroitement associés à la philosophie agile. Voici quelques-uns des cadres les plus couramment utilisés.

Scrum est un cadre méthodologique conçu pour le travail collaboratif en équipe sur des projets. Son nom, bien que ressemblant à un acronyme, provient en réalité du rugby : dans ce sport, une « mêlée » (scrum) implique que les joueurs s’agrippent les uns aux autres pour avancer ensemble contre leurs adversaires. C’est une sorte de charge de cavalerie… sans les chevaux.

Dans la méthode Agile, une équipe Scrum comprend trois rôles :

• Chef de projet : Il fait le lien entre l’équipe Scrum et les parties prenantes, qu’il s’agisse des utilisateurs, des clients ou d’une maison mère. Le chef de projet est responsable de la communication des facteurs externes (budget, ressources humaines, retours) vers l’équipe Scrum, et de la transmission de l’avancement de l’équipe aux parties prenantes.
  
  
• Scrum master : Le Scrum master n’est pas un « patron » au sens traditionnel du terme, mais plutôt un pédagogue de la méthode Scrum, un chef d’orchestre facilitant la communication, l’orientation et la résolution de problèmes. Les Scrum masters ne sont généralement pas responsables de l’embauche et du licenciement.
  
  
• Développeurs ou membres de l’équipe : Le terme peut varier selon le secteur, dans certains domaines non liés au logiciel, on parlera simplement de membres de l’équipe. Quel que soit le terme utilisé (développeur, membre de l’équipe ou membre du personnel), ce rôle n’est relié à aucune hiérarchie. Idéalement, une équipe Scrum compte entre trois et neuf membres ; au-delà, il devient plus difficile pour le Scrum master de bien la guider. Cela inclut également les équipes auto-organisées, où chacun décide des ressources nécessaires pour atteindre ses objectifs, sans planification excessive par la direction.

Scrum se distingue d’autres modèles organisationnels par quelques concepts spécifiques. Le product backlog (ou carnet de produit) est un répertoire de l’ensemble des tâches, idées, exigences, livrables et ressources dont l’équipe pourrait avoir besoin pendant le processus Scrum. Il peut (et doit) être constamment mis à jour et surveillé par l’équipe pour garantir son efficacité et son exhaustivité.

Dans un scrum, le travail est divisé en sprints, qui durent généralement entre une et quatre semaines. Dans le sprint, les membres de l’équipe s’efforcent d’atteindre un objectif spécifique et livrable. Cet objectif peut être un modèle fonctionnel, une maquette, un prototype, voire simplement une fonction ou un élément du produit fini ou de la solution.

Pendant le sprint, les membres de l’équipe se réunissent une fois par jour dans le cadre d’une « mêlée quotidienne » (daily scrum) ou d’un « stand-up ». Selon les principes Scrum, ces réunions doivent rester très générales. Elles ne doivent pas dépasser 15 minutes : chaque membre y partage brièvement ses avancées et les obstacles éventuels à son travail, avec le moins de détails possible. Parfois, certains membres se retrouvent après la réunion pour approfondir un point abordé.

À la fin d’un sprint, l’ensemble de l’équipe (membres, Scrum master et chef de projet) se réunit pour passer les réalisations en revue et en discuter. Le chef de projet peut alors relayer les retours ou changements émis par les parties prenantes comme les utilisateurs ou l’organisation à un niveau plus général, que l’équipe pourra intégrer au sprint suivant après discussion.

Kanban est un système visuel de gestion et de suivi de projet. Les tableaux Kanban représentent de manière visuelle l’avancée d’une équipe sur un projet en classant chaque sous-tâche dans des catégories, généralement :

• Backlog : toutes les tâches qui n’ont pas encore été déplacées dans une autre catégorie ; au début du projet, toutes les tâches sont dans le backlog
  
  
• En cours : tâches en cours de réalisation
  
  
• En revue : Tâches achevées sur le plan opérationnel initial, en cours d’évaluation par un tiers
  
  
• Terminées : tâches achevées.

Le mot « Kanban » vient du japonais : « kan » (signe) et « ban » (planche), évoquant l’idée d’un panneau d’affichage. On peut créer des Kanban aussi bien sous forme analogique que numérique. Dans leur version analogique, on utilise souvent des post-its physiques pour représenter des tâches individuelles, qui sont ensuite déplacées d’une colonne à l’autre à mesure de leur achèvement.

Dans leurs versions numériques variées, les tableaux Kanban peuvent être particulièrement utiles pour les équipes de projet distribuées ou travaillant à distance.

L’Extreme Programming, ou XP, est une méthodologie agile initialement conçue pour les ingénieurs logiciels afin d’améliorer la qualité, la réactivité et la rapidité du développement. Son principe de base repose sur une approche agile poussée à l’extrême, avec des cycles de création encore plus courts et testables.

Dans XP (Extreme Programming), chaque composant d’un projet est soumis à des tests répétés, parfois même à des tests destructifs visant à le faire échouer. Ensuite, ces éléments sont testés ensemble, souvent chaque semaine, pour garantir leur compatibilité maximale.

En matière de communication, XP mise sur la simplicité à l’extrême. La documentation est réduite au strict nécessaire, rédigée dans un langage simple, avec des concepts et des métaphores faciles à comprendre. Cette simplicité s’applique également à la conception même de la tâche : dans les projets XP, on évite souvent de prévoir des fonctionnalités futures jugées inutiles pour la version à livrer. Ce principe est souvent résumé par l’acronyme YAGNI : You Aren’t Gonna Need It (Vous n’en aurez pas besoin).

XP ne convient pas à tous les projets. Il vaut mieux l’appliquer uniquement à ceux qui ne nécessiteront ni évolutivité ni révisions importantes par la suite.

SAFe (Scaled Agile Framework) est un ensemble de principes et de pratiques basé sur la méthode de développement Lean-Agile, DevOps et la pensée systémique. Le Scaled Agile Framework (SAFe) SAFe est conçu pour étendre les cadres agiles à grande échelle, au sein d’organisations complexes, en alignant plusieurs projets tout en favorisant la transversalité et l’interopérabilité. Ce cadre repose principalement sur une structure impliquant des feuilles de route de planification par incréments.

Les tâches qu’elles contiennent portent différents noms selon leur nature : les « Enablers » (dépendances d’autres tâches), les « Epics » (initiatives plus larges conçues pour un besoin métier spécifique) et les « Stories » (fonctionnalité souhaitée, du point de vue utilisateur ou métier).

Disciplined Agile est considéré comme un ensemble de principes, d’engagements et de lignes directrices, plutôt qu’une méthodologie complète. Il s’agit d’une approche légère, minimale et hybride de la gestion de programme, offrant une grande liberté aux membres de l’équipe.

Certains cadres Agile, tels que Scrum et SAFe, incluent des méthodologies et des étapes prescriptives. Cette spécificité peut être intéressante pour certains projets, mais Disciplined Agile vise à donner plus de liberté et d’agilité aux membres de l’équipe. L’idée est de permettre à chacun de choisir les concepts et cadres qui s’adaptent le mieux à son flux de travail. Scrum conviendra à certains, mais pas à tous, surtout dans une perspective de programme à grande échelle. DA mise fortement sur l’autonomie des membres, ce qui en fait un bon choix pour des équipes aguerries, indépendantes et déjà familières des bases de l’agilité.

Le Large-Scale Scrum, ou LeSS, est une déclinaison de Scrum conçue spécifiquement pour les équipes de grande taille, ou les groupes d’équipes, au-delà de ce que Scrum peut gérer seul. Bien que LeSS conserve les sprints, les réunions quotidiennes (daily scrums) et les revues, il ajoute quelques lignes directrices supplémentaires afin de permettre aux grandes équipes d’atteindre leurs objectifs tout en conservant l’esprit Agile.

Dans LeSS, toutes les équipes travaillent sur un sprint commun, contrairement à la gestion de projet agile classique où chaque équipe planifie son propre sprint. Il existe également un backlog partagé, qui regroupe toutes les tâches nécessaires à l’ensemble du programme. La planification du sprint se fait en deux temps : une réunion de planification générale avec toutes les équipes, suivie de réunions de planification spécifiques pour chaque équipe.

Nexus est un cadre d’exigences similaire à Scrum, avec quelques ajouts, soustractions et modifications. La principale différence est l’ajout de l’équipe d’intégration Nexus, un groupe distinct de membres qui fonctionnent comme des coachs. Comprenant souvent des membres des équipes Scrum, le NIT est chargé de résoudre les blocages, de fournir une assistance et d’encadrer les équipes via des processus Agile. Le NIT a ses propres réunions, distinctes du Scrum quotidien.

Scrum est une solution brillante pour des projets spécifiques dans la gestion de projet agile. Mais quand il s’agit de gestion de programme agile (donc d’équipes d’équipes), on parle de Scrum@Scale.

Dans Scrum@Scale, tous les membres agiles font partie d’une équipe Scrum interchangeable, ce qui favorise la collaboration interdisciplinaire. Pour répondre aux défis d’un programme d’envergure en temps réel, de nouveaux rôles sont introduits : Le Chief Product Owner (CPO) crée un backlog unique pour tous les scrums et se coordonne avec les product owners individuels. Un rôle similaire est celui du Scrum of Scrums Master, qui coordonne les efforts entre les différents Scrum masters.

Lean est une méthode visant à réduire les inefficacités et à améliorer en continu la qualité des livrables. Elle est souvent considérée comme une sous-branche de l’agilité. Mais si l’agilité est une philosophie, Lean est une méthodologie, avec des outils et des directives plus précis. Lean se concentre sur la réduction des gaspillages et inefficacités, là où l’agilité mise sur l’itération, les retours et la flexibilité.

La méthodologie Lean repose sur cinq grands principes :

• Identifier la valeur : Définir précisément l’objectif, et éliminer tout ce qui n’apporte pas de valeur ajoutée.
  
  
• Cartographier le flux de valeur : Utiliser des outils de gestion (comme Kanban) pour visualiser la feuille de route du produit. Il s’agit essentiellement de visualiser le plan du projet du début à la fin.
  
  
• Créer un workflow : Construire le processus de production étape par étape en anticipant les obstacles, l’objectif étant de créer un workflow aussi fluide que possible.
  
  
• Mettre en place un système à flux tiré : Ne créer de nouvelles tâches que si la demande client l’exige et si l’équipe est prête à les traiter, souvent via une file de tâches.
  
  
• Amélioration continue : Utiliser diverses techniques pour créer de la valeur et améliorer le produit en continu. Il peut s’agir de méthodologies et de philosophies telles que Lean Six Sigma et Kaizen ou de cadres structurés comme Scrum, qui favorisent la fréquence des tests et les boucles de rétroaction bénéfiques.

La gestion de programme agile, avec ses méthodologies associées, offre de nombreux moyens d’améliorer la livraison des projets.

• Spécificité : Grâce aux itérations successives, les équipes peuvent cibler exactement ce que veut le client au lieu d’essayer d’améliorer le projet à l’aveugle.
  
  
• Efficacité : La gestion de programme agile inclut des principes visant à réduire le gaspillage, la documentation et les lourdeurs administratives.
  
  
• Polyvalence : Permettant de réagir rapidement aux commentaires des clients, la polyvalence est un élément fondamental de la gestion de programme agile. Les équipes agiles savent dès le départ que des changements surviendront, et elles y sont préparées.
  
  
• Moral de l’équipe : La gestion de programme agile encourage l’ouverture, la transparence et l’expression individuelle des membres de l’équipe. La hiérarchie importe moins que la sincérité et l’engagement collectif.