De juin 2017 à avril 2018,  j’ai accompagné une mutuelle montpelliéraine à la mise en place du RUN d’un projet de refonte majeure de son système d’information. Dans ce cadre, j’ai proposé et mis en place une approche de type Kanban pour assurer le pilotage des différents chantiers préalables à la mise en production des nouveaux outils. Cet article a pour objectif de partager un retour d’expérience sur l’utilisation de ce mode de pilotage, en expliquant la manière dont je l’ai mis en place, les bénéfices observés et les limites rencontrées au fil du projet.

Mise en œuvre de l’approche Kanban

La première étape de mon intervention a consisté à faire le recensement la formalisation de la liste des tâches à réaliser au niveau des différents services concernés (exploitation, infrastructure, études et développements, AMOA) sous la forme d’un backlog.

En m’appuyant sur l’expertise des différents responsables de services, complétée par ma vision des bonnes pratiques d’industrialisation du Système d’Information acquises au sein du Groupe La Poste, nous avons ainsi défini un plan d’actions réparti en 5 chantiers :

• Préparation des environnements de RUN (pré-prod / prod)
• Préparation de l’exploitation (ordonnancement des batchs, supervision, déploiements automatisés, sauvegardes & restauration…)
• Recette technique (tests bout en bout, tests de montée en charge, audit de sécurité…)
• Préparation de la bascule
• Montée en compétence des équipes

Pour avoir une vision exhaustive des actions à réaliser, nous avons positionné dans le backlog différents types d’items :

• Opérations techniques (paramétrage, installation des machines, réalisation de tests, mise en place de la réplication SGBD, scripting des déploiements…)
• Documentation (liste des batchs, matrice des flux, procédures de déploiement…)
• Instructions techniques & préparatoires (solution d’ordonnancement, stratégie de bascule, stratégie & outillage de TMC…)

Dans la foulée, nous avons réalisé la priorisation des actions et positionné des objectifs de délais macros sur les différents items, en tenant compte des dépendances et de la capacité des équipes.

Pour finir, j’ai proposé et animé un point de suivi hebdomadaire de l’avancement des chantiers avec l’ensemble des responsables des services concernés et le Directeur du Système d’Information. Pour ce point de suivi, j’ai utilisé le backlog pour mettre en évidence l’état d’avancement macro des différents items (démarré, terminé) et le dépassement des délais prévisionnels. J’ai complété cette vision détaillée par une représentation sous forme de burndown chart par chantier et d’un burndownchart global, avec une trajectoire non linéaire, calée sur les objectifs de délais. Enfin, j’ai ajouté au suivi d’avancement un suivi des actions complémentaires au backlog et un suivi des risques.

Bénéfices

Le mode de pilotage Kanban a été très apprécié par les différents services concernés. D’une part, cela a permis de concrétiser la vision des actions à réaliser, que chacun de son côté avait commencé à envisager, mais sans forcément la formaliser, et à la mettre en évidence auprès de l’ensemble des acteurs concernés et du DSI. Cela a également soulevé dès le départ un ensemble de questions transverses qui ont pu être traitées de manière précoce, en donnant aux équipes de la marge de manœuvre, en termes de délais, pour la mise en œuvre (par exemple, le principe d’automatiser les déploiements applicatifs).

D’autre part, le positionnement de macro jalons et d’objectifs de délais pour chaque item a permis de donner un cadencement aux différents chantiers et d’assurer la synchronisation des différents services sur les actions interdépendantes. Réalisée en très peu de temps, cette planification simple (uniquement la date de fin prévisionnelle) et adaptative, a été bien plus rapide à mettre en place qu’une planification complexe de type Gantt, et aussi utile pour chacun des responsable de service, assurant de son côté la gestion des ressources pour la réalisation des actions dans les délais prévus.

Avec au final un backlog comportant plus d’une centaine d’items, il a été possible d’établir, et de maintenir, une vision claire et synthétique des actions à réaliser sur 9 mois par 3 équipes. Avec un point hebdomadaire, il a été possible de suivre l’avancement des actions de manière très synthétique, de visualiser très rapidement la tendance des chantiers en termes de trajectoire, et d’identifier les points de blocages et les actions en retard pour engager quand nécessaire les actions correctives.

Limites

1/ Hétérogénéité des items de backlog

L’objectif de rassembler dans un même backlog l’ensemble des actions à réaliser sur les différents chantiers a induit une forte hétérogénéité des items du backlog en termes de charge de mise en œuvre. Avec un suivi global réalisé au nombre d’items, la volumétrie du backlog a permis d’obtenir un lissage statistique pertinent, mais la différence significative entre certains items (ex. ordonnancement d’une centaine de batchs VS test de la procédure de sauvegarde) a induit un biais dans l’analyse du reste à faire au regard du temps disponible, d’autant plus que les « gros » items ont eu tendance à se cumuler sur les derniers mois du projet.

Pour éviter cet effet de distorsion, plusieurs solutions auraient pu être pertinentes :

• Découper davantage les gros items et/ou rassembler les petits items en items plus conséquents
• Introduire une notion de mesure de complexité ou de charge estimée pour pondérer les items dans le suivi d’avancement global au regard de la quantité de travail à fournir

Sur les items les plus complexes du backlog (ordonnancement, recette techniques d’environnements), j’ai proposé la mise en place de modalités de suivi dédiées complémentaires (y compris sous la forme d’un backlog spécifique, avec burndowchart)

2/ Définition du « terminé »

Un second point de difficulté rencontré au cours de ce projet a été la définition du « terminé » pour certains items, en particulier les actions de documentation, et a fortiori dans un contexte d’architecture très évolutive, nécessitant de très fréquentes mises à jour.

J’ai pris le parti, pas toujours bien compris, de considérer les chantiers terminés lorsque la base était établie et exhaustive à la date de réalisation, en considérant que la mise à jour ou les travaux complémentaires consécutifs aux évolutions du cadre technique et/ou de l’architecture étaient soit pris en charge de manière récurrente en dehors du pilotage principal, soit devaient faire l’objet de nouveaux items dans le backlog (lorsqu’ils étaient particulièrement significatifs).

Cette approche a généré quelques débats, et une véritable incompréhension de certains de mes interlocuteurs (« comment peut-on considérer la matrice des flux comme terminée, alors que l’étude d’architecture sur la partie éditique n’est pas terminée ? »). Mon argument principal étant qu’à défaut de ce parti pris, certains items ne seraient jamais terminés, nous avons maintenu cette approche. Avec du recul, une autre réponse, certainement plus satisfaisante, aurait été pertinente :

• Rebaptiser l’item « initialisation de la matrice des flux », ce qui constituait déjà une avancée compte tenu de l’absence de ce type de documentation au départ
• Contrôler en parallèle la mise à jour régulière de la documentation, via un suivi ad hoc.

Il me semble a posteriori que cette incompréhension, pourtant mineure au regard de l’ensemble du suivi d’avancement des actions, a pénalisé globalement le crédit de l’approche kanban dans sa globalité auprès de certains interlocuteurs.

3/ Maîtrise de la dérive

Au fil du projet, il s’est avéré que certains items ont dérivé en termes de planning. L’approche Kanban a permis de mettre en évidence assez rapidement les items présentant du retard, et les points de suivi hebdomadaire ont permis de partager les risques et d’établir des plans d’actions correctifs.

Cependant, le pilotage ne remplace pas les arbitrages, la mise à disposition des moyens ou le suivi d’exécution des plans d’actions correctifs pour aider les équipes, en difficultés sur certaines actions, à tenir leurs engagements de délais.

Conclusion

Au final, l’approche Kanban s’est révélée parfaitement adaptée pour le pilotage de chantiers techniques, avec une vision globale des chantiers, complétée par un suivi détaillé de certains items.

En apportant les bons éléments d’information pour les arbitrages et les actions managériales, elle a permis de fournir aux différents managers et au DSI les éléments nécessaires pour assurer le pilotage des travaux. Cependant, l’approche Kanban reste une modalité de formalisation du suivi d’avancement, et doit être complétée par une implication forte du management pour permettre la « tenue » du plan d’action et des délais, et la résolution des difficultés rencontrées par les équipes.