Dans la continuité des projets informatiques agiles qui ont permis de mettre rapidement sur le marché de nouveaux services, le plus souvent sur des périmètres fonctionnels restreints, les grandes entreprises du CAC40 adressent des programmes impliquant désormais des équipes projets de plus de 50 personnes. Nous parlons alors d’Agile à l’échelle dès lors que le programme agile embarque plusieurs équipes sur différents chantiers interdépendants et qu’il devient alors nécessaire de synchroniser.
Des frameworks tels que SAFe et LeSS offrent un cadre méthodologique, des outils qui visent à assurer la bonne conduite de ces programmes, qui s’appuie sur des valeurs clairement définies :
- Une exécution du programme au travers d’itérations courtes (projets agiles) pour garantir un alignement avec les objectifs fixés ;
- Un alignement contrôlé par des points de rencontre réguliers appelés Program Increment Planning au sein du programme. Les équipes projets y partagent alors leur avancement, identifient les dépendances et les prochaines étapes ;
- Un accent mis sur la qualité dans toutes les phases de conception à la réalisation du produit afin de pérenniser le produit et limiter le « rework » ;
- De la transparence dans le pilotage via une approche basée sur des faits (avancement, difficultés…)
QU’EN EST-IL DE L’AGILE À L’ÉCHELLE DANS LES DSI DU CAC 40 ?
Dès lors que ces cadres méthodologiques sont transposés dans les grandes DSI, des verrous émergent, bien souvent pour trois raisons :
- Les programmes d’envergure affectent des pans entiers de l’entreprise, y compris ces fameux systèmes Legacy dans une technologie complexe et / ou obsolète. Dans ces conditions, il est difficile de suivre le rythme de l’agile.
- Les progiciels / ERP sont légions. Les éditeurs de ces solutions ont souvent des feuilles de route calées à l’avance sur un ou deux ans. L’approche agile devient alors une mission plus complexe, d’autant plus si une couche de développement spécifique y a été apportée.
- L’approche agile bouscule la culture d’entreprise : prise de décision décentralisée, vision économique de la solution, mesure de la valeur d’usage, culture du test et de l’automatisation. Les équipes IT et métiers doivent être formés à ces approches afin d’en tirer les bénéfices.
En attendant une transition agile à l’échelle qui prendra du temps, sur le terrain nous rencontrons plutôt un modèle que nous allons nommer Programme hybride, dans lequel se mêlent projets agiles itératifs et projets cycle en V séquencés.
DU PROGRAMME HYBRIDE AU FULL AGILE : Y ALLER SANS (TROP) SE FAIRE MAL ?
La transition du cycle V à l’agile est un changement de paradigme qui s’avère déstabilisant pour les équipes. Bien que l’agile soit l’approche la plus sécurisante pour réussir les phases d’intégration – grâce aux temps de cycles courts qui permettent de rectifier le tir -, il convient d’en maîtriser parfaitement l’exécution.
Les approches agiles sont donc à faire évoluer pas à pas pour augmenter progressivement le nombre de projets en mode agile du programme.
COMMENT PILOTER UN PROGRAMME HYBRIDE ?
Nous noterons que là où le pilotage d’un projet agile fait état d’un avancement réel – car basé sur des faits (fonctionnalités qualifiées et livrées en production : définition du done) – le pilotage d’un projet cycle en V est estimé – car basé sur un déclaratif (pourcentage d’avancement des livrables). Dès lors se pose la question de l’intégration de ces projets aux cycles différents dans un programme hybride et de ses implications au niveau de la gouvernance du programme.
LE BENCHMARK AGILE : THÉORIE ET BONNES PRATIQUES
Un certain nombre de bonnes pratiques permettent de faciliter ces fameux points d’intégration.
- Acculturer le métier et le Product Owner aux approches MVP. Ces trois lettres sont bien plus qu’un acronyme et amènent une révolution dans l’expression des besoins. Nous visons avant tout à livrer des produits utiles en priorisant les besoins par la valeur. Notre benchmark Agile montre une corrélation directe entre l’arbitrage des user stories par les Product Owners expérimentés et la tenue du budget.
- Réduire les temps de cycle du programme et prévoir des points d’intégration réguliers. Plus les cycles sont courts, plus nous réduisons les problématiques d’intégration avec les autres projets. La clé : identifier le dénominateur commun des fonctionnalités (par exemple les progiciels) à livrer par les équipes cycle en V, ce qui va permettre un accostage avec les projets agiles (pour accéder aux données du progiciel par exemple).
- Automatiser les tests au plus tôt dans l’ensemble du programme. En effet, réduire les temps de cycle risque d’altérer la qualité des développements. Les équipes Legacy pourront par exemple scripter les tests sur le nouveau code (une bonne pratique est à minima 60% du nouveau code testé automatiquement) afin d’éviter des volumes de régressions impossibles à corriger dans les délais d’un incrément. Notre benchmark agile montre une corrélation entre l’automatisation des tests et la qualité des sprints.
- Découpler les architectures. Ce n’est plus un secret : les points d’intégration sont des périodes compliquées, qui soulèvent les problèmes de communication entre projets. Le développement d’une architecture ouverte sur les applications avec des API sous la responsabilité de leurs fournisseurs évitera les surprises le jour J (par exemple, la découverte d’une évolution de la règle d’accès à une donnée externe, non APiséee).
- Démarrer avec des indicateurs simples et objectifs, à partager entre toutes les équipes. Notre retour d’expérience montre que trop de programmes mettent en œuvre des tableaux de bord complexes et inexploitables. Notre conviction est qu’il faut démarrer avec deux ou trois indicateurs fondés sur l’avancement des réalisations testées. L’étude de cas ci-dessous est un exemple d’une mise en œuvre réussie.
Par ailleurs, ces bonnes pratiques sont aussi une excellente porte d’entrée pour évoluer vers une plus grande agilité.
ÉTUDE DE CAS
Nous sommes intervenus auprès d’un acteur majeur de l’assurance-crédit sur un programme stratégique de déploiement de sa nouvelle offre d’assurance pour la banque de détail du Groupe. Le programme a mobilisé 50 ETP dans une approche hybride mêlant chantiers réalisés en Agile et en Cycle en V. Quatre chantiers principaux étaient identifiés :
- Chantier Front-Office Assurance (Agile)
- Chantier progiciel Back-Office Assurance (Cycle en V)
- Chantier outils GED / Editique Assurance (Cycle en V)
- Chantier SI Bancaire (Cycle en V)
Le choix de la méthodologie Agile pour le chantier Front Office a été réalisé pour deux raisons : une incertitude sur le détail des fonctionnalités requise par le métier de la banque et des délais de mise en œuvre particulièrement serrés.
Le programme est séquencé en deux phases avec une mise en production majeure à la fin de chaque phase. Voici comment l’approche de conduite de programme a évolué entre les phases, avec la montée en compétence Agile des différents intervenants.
Phase 1 : le démarrage avec une maturité Agile faible
Au démarrage du programme, le niveau de maturité Agile des équipes intervenant sur le programme et de l’organisation IT en général était faible. Par ailleurs, les actions d’automatisation des tests et des déploiements en étaient à leur balbutiement.
Nous avons mis en place un pilotage global du programme fondé sur l’approche Cycle en V avec des points d’intégration uniques (SI Assurance et SI Bancaire) juste avant le démarrage de la phase de recette utilisateurs et de la mise en production.
Cette recommandation s’est fondée sur la nécessité de laisser le temps aux équipes (métiers et IT) de maîtriser les fondamentaux de l’agilité apportée par le projet Front-Office et de finaliser les actions d’automatisation des tests et des déploiements sans mettre en péril l’objectif de mise en production du programme.
Ce choix s’est avéré payant ! D’une part, la démarche Agile sur l’outil Front-Office Assurance a permis de gérer les risques sur ce chantier sans déstabiliser les équipes des autres chantiers. D’autre part, la phase 1 du programme s’est achevée avec succès et sans décalage de la date de mise en production.
Le point névralgique a été la phase d’intégration finale. En effet, les tests de bout-en-bout ont montré que certaines hypothèses de travail des chantiers (versus les autres chantiers) se sont avérées erronées ou incomplètes. Il a donc a fallu apporter des correctifs en urgence.
Concluons cette partie avec un focus sur le pilotage de l’avancement. Malgré la cohabitation des méthodologies Agile et Cycle en V, il était important de présenter aux décideurs une grille de lecture commune pour tous les chantiers, indépendamment de leur méthodologie.
Par conséquent, nous avons demandé à chaque chantier de fournir deux indicateurs : 1) Le pourcentage d’avancement constaté ; 2) Le niveau d’avancement théorique attendu pour le respect du jalon final.
Charge à chaque chef de chantier de calculer ces indicateurs en fonction de la méthodologie de son chantier.
Phase 2 : l’évolution de la maturité Agile
Avec le retour d’expérience de la phase 1, les progrès en maturité Agile et la montée en puissance des outils d’automatisation des tests et des déploiements, nous avons recommandé d’augmenter le nombre de points d’intégration intermédiaires et de réduire le cycle de développement des chantiers Cycle en V. Cette recommandation a pour objectif de donner plus de flexibilité d’arbitrage / d’évolution fonctionnels pour le métier et de mieux gérer les risques d’intégration au niveau du programme.
En pratique, le chantier Agile fonctionnera avec des sprints de trois semaines et les chantiers Cycle en V décomposeront leur périmètre en des lots de six semaines (l’équivalent de deux Sprints Agile).
Toutes les six semaines, l’ensemble des chantiers réalisera l’intégration des périmètres développés et l’équipe de recette réalisera ses tests de recette sur les nouveaux périmètres développés. La batterie de tests automatisés se chargera d’identifier les éventuelles régressions.
Notons que même si cette approche disposera de nombreux avantages, elle nécessitera une plus grande synchronisation entre les chantiers. C’est pourquoi des rituels hebdomadaires de revue des dépendances et de gestion des risques seront mis en place avec l’ensemble des chantiers pour s’assurer une coordination optimale.
Concernant le pilotage de l’avancement, nous proposons de continuer à fournir une vision commune basée sur les indicateurs Pourcentage d’avancement constaté et Niveau d’avancement théorique attendu. La différence majeure : pour les chantiers Cycle en V, nous nous baserons sur un niveau de fonctionnalités développées et intégrées et non plus sur les déclaratifs des chefs de chantier. In fine, cela nous permettra de mieux projeter la fin effective du programme.
CONCLUSION : UN ÉQUILIBRE ENTRE AUTONOMIE ET ALIGNEMENT
L’Agile à l’échelle c’est aussi l’art de trouver un équilibre subtil entre l’autonomie revendiquée des projets (choix de la méthode agile dans le prochain épisode) et la nécessaire coordination des programmes.
Nous préconisons à nos clients de faire un état des lieux objectif de la maturité agile de leurs équipes et des métiers avant de lancer leurs programmes. En effet, tout comme un barreur doit apprendre à naviguer en haute mer, le chef de projet agile doit passer son permis d’agilité délivré par la direction du programme, qui en aura défini les règles et les outils.
À vouloir se précipiter trop vite vers l’agilité, le risque d’arriver à une situation chaotique mettant en péril le programme est une réalité. Pour prendre l’image du sport automobile, il faut savoir se laisser le temps de faire des tours de chauffe avant de se lancer dans la vraie course où toutes les voitures sont alors lancées à pleine vitesse.
