La réussite d’un programme agile multi-équipes repose sur les mêmes principes que pour une seule équipe : Simplifier l’organisation et miser sur les interactions pour libérer l'intelligence collective.
La façon la plus simple, la plus participative et la plus agile -selon moi- d’assurer le lancement de ce type de programme est d’appliquer la démarche de “croissance organique”.
La particularité de cette approche réside dans le fait de ne mobiliser qu’une seule équipe dans les premiers mois du projet puis de construire progressivement l’organisation en s’appuyant sur les fondations posées par cette équipe coeur.
Le cas théorique
Imaginons que votre programme (aka “gros projet 4.0 du patron”) vise à livrer une machine à café révolutionnaire, bardée de capteurs IOT, connectée au cloud et dotée d’une interface tactile, d’un assistant vocale et ceci pour que, par la grâce du machine-learning, tous les utilisateurs reçoivent un café personnalisé tant en terme de goût, de température que de taux de caféine et qu’ils puissent consulter l’évolution de leur consommation via une interface mobile qui communique avec leur application “Santé” préférée.
Jusque là rien de surprenant mais, puisque le projet a été annoncé aux actionnaires, vous devez réaliser ce petit bijou dans l’année en misant sur une partie des équipes existantes et votre plus grand défi va être de les faire travailler ensemble. Là ou il est habituellement difficile de faire collaborer deux équipes de développement, vous allez devoir synchroniser des développeurs back-end, front-end et d’applications natives, des ops, des architectes, des électromécaniciens, des designers, des experts en UI tactile, des consultants en IOT, des experts BI, des métiers, des testeurs, des responsables sécurité et j’en oublie volontairement.
En pratique
Pour commencer et plutôt que de mobiliser 200 personnes, il suffit de monter une seule équipe pluridisciplinaire en suivant la recette suivante :
Réunissez 7 à 12 personnes représentant chaque métier nécessaire à la conception et à réalisation du projet.
Confiez-leur un espace de travail collaboratif.
Ajoutez un coach agile chargé de faciliter le cadrage du projet et d’accompagner l’équipe dans la durée.
Donnez-leur le temps et les moyens nécessaires au cadrage 360° (3 à 6 semaines) :
1 journée de team building pour faire connaissance et apprendre à travailler ensemble
1 journée de définition du “pourquoi de l’équipe”: pour qui, pour quoi, pour répondre à quels enjeux d’entreprise, avec quelle proposition de valeur et pour quels critères de succès
Quelques jours de design thinking et d’interactions avec des clients finaux
1 journée de story mapping pour définir et prioriser les fonctionnalités
1 journée de roadmapping pour se donner une vision commune des phases du projet, des dépendances mutuelles et des risques associés
Autant de jours de cadrage technique qu’ils le jugeront nécessaires
1 journée pour partager une même vision de l’agilité, définir les processus et les outils de l’équipe
Donnez-leur le temps de “l’itération 0” soit 2 à 3 semaines dédiées au set-up technique du projet, à la mise en place des conditions de prototypage, au rodage de leurs processus et aux travaux nécessaires pour répondre aux questions restées en suspens pendant le cadrage (arduino est-il compliant ? le besoin client inclue-t-il le thé? notre projet d’architecture cloud est-elle déployée? le patron a-t-il vendu tout ou partie du projet aux actionnaires ?...).
Donnez-leur carte blanche pour produire le “M.V.P” : la solution minimum qui permettra de valider ou non les premières hypothèses produit et d’apprendre au contact du client (une maquette en carton, une vidéo youtube, une bonne vieille machine à café connectée à SIRI ou Alexa…) tout en leur donnant le temps de mettre en place les pré-requis techniques (“Je vous avais dit que le projet BigData n’avait pas avancé…”).
Laissez-les itérer en vous assurant qu’ils continuent d’apprendre, en les protégeant des perturbations extérieures (“non parce qu’il y a cette urgence qui n’a rien à voir mais sur laquelle il faudrait qu’une partie d’entre eux travail”) et en répondant à leurs besoins (“nous avons besoin d’une salle à proximité pour le prototype”).
Faites venir régulièrement le patron et autres stakeholders pour aligner les attentes et la réalité du terrain.
Enfin, assurez la croissance progressive de l’équipe au fur et à mesure de ses demandes.
Dès que celle-ci dépasse les 7 à 12 personnes, assurez les conditions de la création d’une nouvelle équipe.
Pour composer la nouvelle équipe, faites confiance à ses membres en posant les conditions suivantes de la croissance organique :
Chaque équipe doit mixer “membres historiques” et “nouveaux membres”
Chaque équipe doit être aussi pluridisciplinaire que possible car les équipes ultra-spécialisées dites “composants” doivent être l’exception et non la norme afin d’éviter les effets “bottleneck”.
Chaque équipe doit avoir le temps de procéder à un nouveau cadrage 360° de quelques jours
Chaque équipier est dédié à 100% au projet sauf rares exceptions concernant des métiers intervenant de manière plus ou moins importante selon les phases du projet (tel que les designers ou certains architectes) et dans ce cas, ils font partie de l’équipe dite “élargie” et ce projet doit rester leur priorité
Les équipes doivent se synchroniser régulièrement pour conserver une vision commune et gérer leurs dépendances et ce par des événements collaboratifs d’1 à 2 jours toutes les 6 à 12 semaines et impliquant tous les équipiers, par de la synchronisation hebdomadaire des représentants métier et IT, par le partage régulier des rituels de démonstration et de rétrospective
Les équipes doivent suivre une démarche produit itérative et incrémentale. Elles doivent donc régulièrement livrer au minimum des prototypes visant à recevoir du feedback client et, de préférence, des solutions partielles mais suffisantes pour apporter de la valeur sur le marché (qui a dit qu’il fallait attendre un an (ou deux) d’avoir la super coffee machine du patron plutôt que de tester la vente de machines un peu augmentées au bout de quelques mois ?).
Continuer à assurer la croissance des équipes en suivant ces règles et ce jusqu’à atteindre la limite de Dunbar d’environ 150 personnes. Si vous pensez devoir dépasser cette limite, vérifiez d’abord vos calculs de ROI. Si vous êtes toujours convaincu, repartez à 0 en ouvrant un 2nd écosystème à partir d’une équipe pluridisciplinaire sur un scope clairement défini et limitant les dépendances avec le premier.
Je ne peux pas vous promettre que la super machine à café du Patron sortira dans l’année, pas plus que je ne peux m’engager sur la pertinence de son idée mais, à la différence de l’approche classique, la démarche de cadrage agile et de croissance organique vous apportera les avantages suivants :
Vous éviterez l’effet tunnel qui accompagne généralement les grands programmes
Vous apporterez plus rapidement le produit sur le marché
Vous aurez plus de chance d’apporter de la valeur en répondant à un besoin client
Vous réduirez le gâchis et le coût de coordination des équipes
Vos équipes seront engagées et mobilisées autour d’objectifs communs qui font sens
Vous pourrez créer les conditions de la transparence, de l’agilité et de l’émergence d’une culture centrée sur la collaboration
Une fois suffisamment “terminé” ce projet, vous pourrez vous appuyer sur les équipes pour développer une organisation “produit” à même de faire évoluer rapidement et en continu vos “machines à café “ et leurs différentes fonctionnalités.
La dernière fois que j’ai exposé cette solution, mon interlocuteur m’a répondu :
“C’est génial ! Mais ce n’est pas possible pour nous : Le “gros projet du patron” est en attente depuis 2 ans, la machine à café du futur a déjà été entièrement spécifiée par les chefs de projet, les 5 ou 6 équipes concernées doivent commencer le mois prochain car il faut impérativement livrer dans 6 mois.”
Qu’à cela ne tienne ! Nous pouvons préparer un bon repas même quand nous n’avons pas le temps d’acheter des produits frais au marché ni de passer une journée en cuisine. Dans ce cas extrême et pourtant courant, je propose de préparer une Big Kick Off agile car ce n’est pas parce que le programme a mal démarré qu’il faut se priver de toute agilité.
Quelque soit votre contexte et vos contraintes, je vous invite à chercher constamment à SIMPLIFIER l’entreprise, son organisation, ses process, de manière à privilégier les individus et leurs interactions afin de libérer l’intelligence collective et la mettre en action.
La FAQ
Le projet ne risque-t-il pas d’être livré plus tard ?
Lancer simultanément plusieurs équipes n’est pas plus rapide en raison du coût de set-up puis du coût de synchronisation. La première équipe pluridisciplinaire assure un cadrage rapide et un set-up prenant en compte les contraintes de tous les métiers. Grâce aux bases solides posées par cette équipe, il sera plus simple et plus rapide d’embarquer les autres équipes. Il est par ailleurs plus réaliste de mobiliser à 100% 6 à 12 personnes que 50 ou 100. Rien n’est plus coûteux que d’affecter 100 personnes qui ne seront pas focus car ils auront des tâches à réaliser liés à d’autres projets. La répartition progressive des membres de cette « core Team » dans les autres équipes facilitera les échanges transverses et permettra de garder un Cap commun. Enfin, en mobilisant cette équipe sur la production rapide d’un MVP, l’entreprise pourra rapidement obtenir du feed-back clients et ajuster ses choix pour, finalement livrer plus rapidement de la valeur business.
Comment maintenir la dynamique agile et gérer les dépendances tout au long du programme ?
Pour maintenir la dynamique agile tout au long du programme, je vous recommande :
Un “Big Room Planning” toutes les 6 à 12 semaines pour assurer la synchronisation et la gestion des dépendances
Une “Big Rétro” (carticle à venir) sur le même rythme pour assurer l’amélioration continue et maintenir la dynamique collective
Un Kanban de programme (article à venir) ou les représentants métiers et IT pourront fluidifier le travail et partager de l’information tous les jours ou toutes les semaines.
L’important est de chercher la simplicité et de multiplier les événements ou les individus interagissent et expérimentent ensemble de nouvelles façons de faire.
Combien de coachs agiles sont nécessaires en croissance organique ?
Un coach agile expérimenté et comprenant les principes d'agilité à l’échelle est nécessaire pour toute la durée du cadrage de la première équipe ainsi que pendant ses premières itérations. Il en sera de même pour chaque création de nouvelle équipe. Une fois la taille critique atteinte, compter environ 1 coach pour 3 équipes.
Coachs internes ou coachs externes ?
Les coachs internes constituent un facteur clef de succès dans ce type de démarche. Pour autant, je vous conseille de faire également appel à un coach externe qui pourra plus facilement challenger l’entreprise dans ces manières de penser et de faire.
Les équipes doivent-elles être co-localisées ?
La colocalisation simplifie les interactions et doit donc être privilégiée mais ce n’est pas toujours possible. Mes recommandations sont les suivantes :
Si toutes les équipes ne peuvent pas être co-localisées, assurez-vous de rapprocher les équipes qui seront amenées à interagir régulièrement.
Assurez-vous que l’équipe coeur soit colocalisée au moins pendant la phase de cadrage et les premières itérations.
Essayez de toujours co-localiser au moins les membres d’une même équipe.
Si vos contributeurs sont dispersées, essayer de réunir ceux qui interviennent sur les mêmes segments techniques.
Si vous avez deux sites, vous pouvez également composer des équipes mixtes. Essayez d’avoir une majorité des membres sur un site.
Si vous êtes très en avance sur votre temps et que la plupart de vos employés sont en “remote” (à distance), investissez dans des outils de communication de qualité. Il est indispensable d’assurer des communications très fréquentes. Les daily meeting, rétrospective, backlog grooming, code review etc. sont possibles et même nécessaires avec des équipes à distance et c’est pourquoi il faut investir dans des outils de qualité.
Quoi qu’il en soit et dans tous les cas, je vous recommande d’organiser des rendez-vous régulier (toutes les 6 à 12 semaines) ou les personnes se retrouvent physiquement.
Peut-on lancer un programme agile sans équipes agiles ?
La Croissance Organique permet d’acculturer progressivement l’organisation même si cette dernière n’est qu’au début de sa transition.
Si l’agilité est entièrement absente de votre organisation, quelques sensibilisations pourront être glissées dans les ateliers pour assurer l’initiation et l’alignement sur les questions d’agilité. Les coachs agiles pourront, ensuite, accompagner les équipes dans leur montée en compétence.
Attention
Faites confiance aux équipes
Il n’est pas rare avec ce type de programme que la date de livraison et le périmètre envisagé ne soient pas réalistes. Il faut donner la liberté aux équipes d’exprimer leurs doutes en la matière car, dans le cas contraire, elles livreront des plannings qu’elles ne pourront pas tenir et lorsque la date approchera chacun cherchera un coupable au lieu de trouver des solutions.
Le focus est à faire sur la valeur que l’on souhaite délivrée, sur les problèmes clients que l’on souhaite résoudre et non dans le nombre de fonctionnalités de la machine à café. Les plannings des équipes sont le plus souvent sur-estimés à hauteur de 30%; il est inutile de les challenger pour qu’elles prennent plus d’items qu’elles ne se sentent capables d’en réaliser. C’est pourquoi il est importante de faire venir les stakeholders régulièrement pendant les phases de cadrage et de planification. Ces derniers tendent à donner plus de respect aux équipes quand ils sont face aux travaux de cadrage accomplis et les équipes disposent de tous les arguments et ressources nécessaires pour négocier date et périmètre. Plus tôt le périmètre est négocié avec les décideurs, moins importants seront les risques de dérives.
Le “Big Room Planning” toutes les 6 à 12 semaines pour assurer la synchronisation et la gestion des dépendances
La “Big Rétro” pour assurer l’amélioration continue et maintenir la dynamique collective à l'échelle du programme (article à venir)
Le Kanban de programme ou les représentants métiers et IT fluidifient le travail et partagent de l’information tous les jours ou toutes les semaines (article à venir)
