3 clés pour garantir la livraison d’un programme de projets en méthodologie AGILE

Les projets sont agiles et les programmes doivent le devenir

En période de transformation digitale, les entreprises sont fréquemment confrontées à la difficulté de piloter en mode agile à l’échelle d’un programme. Le programme voit coexister des projets traditionnels (Plan-Build-Run), des projets de développement d’applications (produits) par des équipes agiles, des projets d’étude, des phases de déploiement touchant de grandes populations, une gouvernance de direction générale « traditionnelle » soumis au cycle budgétaire sans parler du rythme de reporting aux actionnaires.

Ces dernières années, des méthodologies (comme SCRUM ou KANBAN) se sont développées pour accompagner les projets en mode agile. Elles reposent sur des principes tels que :

  • Une priorisation des besoins à forte valeur ajoutée par le « client » (User Story)

  • La livraison à des intervalles réguliers d’un produit fonctionnel (Sprint)

  • Une organisation de l’équipe projet visant à une autonomie et un poids du collectif forts (Equipe Agile)

  • Une approche et des rituels favorisant l’amélioration continue de l’équipe (Vélocité )

[Voir Manifesto for Agile Software Development].

Mais à l’échelle du programme, des difficultés voient le jour

Une équipe fonctionnant en mode agile bénéficie d’ une forte flexibilité et autonomie vis-à-vis du produit à livrer. Cette autonomie a pour objectif de  permettre la livraison d’une première version du produit fonctionnelle (intégrant les fonctions de base principales) et ainsi optimiser le ROI. Pour autant dans le cadre d’un programme, les différents produits s’inscrivent dans un objectif global pour lesquels il existe des interdépendances fonctionnelles, temporelles ou de ressources.  Des difficultés apparaissent.

Par exemple, comment positionner dans la roadmap du produit A (backlog) les fonctionnalités non prioritaires pour ce produit A mais prioritaires pour un produit B ?  Comment faire cohabiter des impératifs de date (hard milestone) par exemple pour des déploiements ou des formations quand la logique agile se veut plutôt séquentielle et progressive ? Comment garantir le respect d’un budget pour la livraison d’un ensemble de fonctionnalités définies à l’avance ?

L’approche agile se trouve confrontée à des difficultés externes à son fonctionnement :   des contraintes globales liées aux interdépendances projets/produits dans le cas d’un programme global et le fonctionnement traditionnel des entreprises, notamment au niveau des comités de direction, habitués à travailler avec des engagements financiers et temporels.

Comment faire cohabiter ces deux philosophies  afin de garantir la livraison des principaux livrables du programme ? Une équipe agile doit-elle s’engager à livrer un produit avec périmètre fonctionnel minimum défini à une certaine date ou un comité de direction doit il travailler avec un périmètre de projets susceptible de changer régulièrement ? La solution passe forcément par un compromis.

Le retour d’expérience issu de l’accompagnement dans de récents programmes de transformation, nous a permis d’identifier 3 facteurs clés de réussite dans la livraison d’un programme de projets en méthodologie AGILE.

3 clés pour garantir la livraison d’un programme de projets en méthodologie AGILE

1. Limiter en amont la complexité technique

Cet axe est primordial pour limiter les incertitudes et les risques quant à la livraison des principaux éléments de chaque projet ou produit. Nous l’avons fréquemment constaté, trop de projets ou développements de produits démarrent leurs sprints sans que les prérequis techniques soient suffisamment définis ; en conséquence aux incertitudes de la roadmap fonctionnelle s’ajoutent les inconnues techniques. On peut citer en particulier les prérequis suivants :

  • Des principes d’architecture et couches techniques validés et mis en place

  • Des référentiels de données, en particulier ceux partagés par les produits à réaliser, La maîtrisés et bénéficiant d’une formalisation robuste

  • Des procédures et méthodes interproduits actées et testées (couche API)

  • Des compétences sur les nouvelles technologies à mettre en œuvre développées ou accessibles

Cela implique un ordonnancement du programme et un phasage suffisant.

2. Mettre en place une coordination des équipes Agile

 En complément des rituels auxquels les équipes agiles sont habitués, il faut mettre en place des moments de partage et de coordination des équipes entre elles. Différents moments de rencontre, courts et interactifs pourront se concentrer sur des aspects opérationnels particuliers dans la même logique que les rituels agiles et articulé autour d’une roadmap globale construite à partir des backlogs des produits. Par exemple à un rythme calé sur la durée des sprints, une réunion pourra se focaliser sur la priorisation fonctionnelle de façon similaire à un sprint planning. Ainsi l’ordonnancement de la livraison des fonctionnalités sera fait de façon optimale pour ne pas bloquer le delivery et le release management des produits.

Pour se focaliser sur les difficultés rencontrées au fil de l’eau, une réunion « chemin critique » pourra se concentrer sur les difficultés opérationnelles liées activités au chemin critique ; cette réunion devra suivre les principes d’un « daily meeting ; » en plus des acteurs habituels issus des équipes agiles, d’autres participants pourront être invités de façon ad hoc comme des architectes, des représentants des cellules test, production, support …

En cas de désaccord, les équipes agiles devront aller chercher un arbitrage auprès d’un organe ad hoc. »

3. Se doter d’un organe capable d’arbitrer et prendre des décisions.

Ce comité doit avoir la souplesse d’une équipe agile et être capable d’acter rapidement sur la priorisation de ses produits et fonctionnalités, ainsi qu’analyser les impacts et risques associés. Idéalement cet organe de décision pourrait être réduit à une personne : un «super Product Owner ». En général nous avons rencontré des personnes portant ce rôle mais sur un périmètre limité à une ligne de produits. Le champ des responsabilités et des activités d’un Product Owner pour l‘ensemble des produits d’un programme est très large, est beaucoup plus difficile à identifier et relève plutôt de celles d’un directeur des opérations ou d’un directeur digital. Bref s’il n’est pas possible de faire porter les activités et responsabilités nécessaires par une seule personne, un comité ad hoc devra être mis en place. Dans ce cas l’enjeu sera celui de l’agilité !

3 clés à mettre en place de façon adaptée à son contexte d’entreprise.

Plusieurs méthodologies comme Scrum of Scrum ou SAFe ont fait leur preuve pour répondre à ces problématiques. Mais comme il s’agit de faire co-exister une approche Agile avec les habitudes de gestion de programme de votre entreprise, il est conseillé de couvrir les trois clés de réussite en adaptant une méthodologie à votre contexte.

Les équipes Nexance peuvent vous accompagner dans la mise en place d’un dispositif sur mesure pour accompagner votre entreprise dans le pilotage de sa transformation Agile


English version: 3 keys to guarantee the delivery of a program of projects in AGILE methodology

About the Author

One thought on “3 clés pour garantir la livraison d’un programme de projets en méthodologie AGILE

  1. Olivier Beix - 8 juin 2020 at 13 h 49 min

    Merci José pour ce retour d’expérience.
    Un pré-requis important qui n’est pas directement mentionné ici est l’existence et le pilotage de la stratégie « Produits » globale. Elle permet de fournir un cadre pour la coordination des équipes agiles.
    Il est important que le positionnement des produits les uns par rapport aux autres soit clairement établi en lien avec l’organisation et les activités de l’entreprise.

    Reply

Leave a Reply