Compte-rendu du petit-déjeuner organisé par OCTO et Strator « Retour d’expérience : l’agilité à grande échelle »
Introduction :
Gartner a prédit que 80% des projets de développement logiciel se feront suivant des méthodes Agiles à l’issue de 2012. Les statistiques tendent à confirmer cette prédiction ; le recours à ces méthodes s’est banalisé pour les petits projets, et nombre de sociétés les expérimentent depuis plus de 2 ans. OCTO accompagne ses clients dans ce domaine depuis plus de 6 ans. Néanmoins, le passage à l’échelle de gros projets (5000 J.H et plus), est loin d’être trivial.
Notre client, Strator, filiale d’Altadis Distribution France, développe des solutions logicielles à destination des buralistes et diffuseurs de presse. La nouvelle gamme devant répondre à de forts enjeux, Strator choisit l’Agile pour réduire rapidement les risques, s’assurer d’apporter rapidement de la valeur et mieux piloter ses risques.
La méthode Scrum est déployée sur les différents sites de développement : 9 équipes réparties dans 4 pays sont impliquées. Au bout de 6 mois, la gestion de projet s’avère très couteuse, et la production patine : les livraisons sont difficiles et les recettes douloureuses.
C’est dans ce contexte qu’OCTO est intervenu.
1/ Créer le flux :
Pour reprendre le contrôle de la chaîne de production logicielle, la première étape a été de matérialiser le flux de production de valeur, depuis les étapes de spécifications en amont, jusqu’à la mise en production de chaque User-Story.
Partagé de façon électronique avec les équipes off-shore, et affiché aux murs, le flux est visible de tous en permanence. Les problèmes sont ainsi mis en évidence et traités par les différents chefs d’équipes, dans un nouveau rituel quotidien, le « Scrum de Scrum meeting », qui fait suite aux différents Stand-up meetings menés localement dans chaque équipe.
Les itérations étaient trop longues, retardant d’autant le feedback sur le produit construit, élément essentiel dans un processus de création logicielle. Nous avons donc décidé d’accélérer le rythme des itérations, avec pour objectif 2 semaines.
2/ La qualité :
Pour atteindre ces 2 semaines, le premier travail a porté sur l’amélioration de la qualité du logiciel produit, à commencer par la fiabilisation des livraisons des composants produits par les différentes équipes, grâce à une usine de développement unique, partagée par les 45 développeurs (un commit toutes les 3 minutes !).
Vu l’étendue du périmètre fonctionnel, il est impensable de gérer la non-régression de façon manuelle, surtout lorsqu’on vise un rythme de 2 semaines. En impliquant les testeurs en amont des développements, par la rédaction de spécifications par les tests, les tests d’acceptance ont été automatisés, offrant ainsi un harnais de tests de non-régression très efficace.
La vérification permanente du logiciel sur l’usine de build, a permis la mise en œuvre de la politique « Stop the line » préconisée par le Lean management : lorsqu’un défaut est constaté, il est inutile de continuer à produire, il est plus rentable de s’attacher à la résolution immédiate du défaut.
3/ S’adapter au flux :
Une fois le rythme de 2 semaines atteint, le flux est amorcé, et il est primordial de maintenir un flux continu. L’exercice de planification « à la Scrum » en début d’itération est abandonné, car trop onéreux, au profit d’une planification au fil de l’eau. Le PO peut agir sur la priorisation en permanence, et l’engagement par itération sur le réalisable n’est plus nécessaire.
Pour fluidifier le flux, et éviter les ruptures de charge, il a fallu limiter les interdépendances entre équipes. Les équipes étaient organisées classiquement par composant, chaque équipe rassemblant les compétences nécessaires au travail sur chacun des composants de l’application (front, back, etc.), ce qui occasionnait fréquemment des blocages, dus à ces dépendances. Nous avons alors décidé de réorganiser les équipes par fonctionnalités métier (feature teams), chacune étant focalisée sur son périmètre fonctionnel, et pouvant livrer indépendamment des autres. Les équipes sont devenues multi-techno et même distribuées (membres on-site et off-shore au sein d’une même équipe), les rendant beaucoup plus autonomes, permettant une meilleure communication, et une expertise métier accrue.
Le risque d’une telle approche est bien sûr la perte de maîtrise et de cohérence du socle technique sur chacun des composants. Pour mitiger ce risque, des communautés de pratiques, sous la férule des leaders techniques, ont été mise en place pour animer le partage des pratiques, et garantir la diffusion des standards. Ces réunions « hands on » (les mains dedans) permettent de diffuser les bonnes pratiques de code, de se concentrer sur les aspects techniques, et de faire du design collaboratif.
4/ Piloter le flux :
Le pilotage de l‘avancement global s’est fait à l’aide de la story map, et de la mesure de vélocité comme dans les projets agiles classiques.
Malheureusement, les mesures de points de complexité ont inexorablement divergé d’une équipe à l’autre. L’impossibilité à consolider ces vélocité à l’échelle du projet ont mis à mal le pilotage et la planification des releases majeures.
L’équipe projet a choisi ainsi d’évoluer vers l’utilisation d’une métrique plus univoque, le lead time : temps moyen constaté pour une fonctionnalité entre le moment où elle entre en spécification, et le moment où elle est mise en production. Des statistiques en sont sorties et ont permis une meilleure prédictibilité sur la base des leads time moyen constatés par taille moyenne de Story (S, M, L). L’exercice de planification continue a ainsi pu reprendre son cours car à nouveau plus pertinent. Fort de cette meilleure maîtrise du flux, les livraisons sont devenues plus fréquentes et régulières : 1 livraison majeure par mois, 1 livraison mineure par semaine, avec un lead-time de 10 semaines de l’idée à la mise en prod.
5/ S’améliorer :
Il n’existe pas d’implémentation idéale des méthodes Agile. Chaque projet et chaque entreprise possède sa propre culture. Les premiers pas dans la mise en œuvre de l’agile seront pas tous les bons et c’est en ce sens, qu’il est primordial d’installer une dynamique d’amélioration continue des outils & des processus.
Par exemple, la pratique de l’amélioration continue entre les Dev et les Ops (DevOps) a permis la mise en place progressive d’une chaîne de build de déploiement totalement automatisée (permettant le déploiement serveur et des terminaux en 1clic et d’atteindre une centaine de déploiements en 18 mois). Cette collaboration, basée sur le partage des pratiques et des outils, a également fluidifié les relations, traditionnellement tendues entre les équipes.
La formation a également été primordiale, par exemple en formant les développeurs au problématiques métier de Strator (tabac et presse), ou encore en accueillant les équipes off-shore en France pour plusieurs semaines afin de partager pratiques techniques et méthodologies.
Concernant la gestion des problèmes, l’accent a été mis sur l’incitation à exprimer les problèmes rencontrés ; il faut installer un climat de confiance et travailler ensemble à leur résolution en facilitant les initiatives individuelles, et responsabilisant les personnes. Les rétrospectives, qui ont eu lieu à la fois en France et en off-shore, ont véritablement permis d’améliorer les processus.
Bilan après plus de 40 itérations
- Les équipes ont ré-internalisé les compétences métier,
- les rythmes de livraisons sont soutenus et les délais tenus,
- le marketing collabore au quotidien avec les équipes techniques
- les développeurs collaborent au quotidien avec les équipes d’exploitation (devops)
- et des équipes qui ne retourneraient pas en arrière !
Les méthodes agiles sont un excellent moyen de mener à bien un tel projet. Mais il faut :
- garder la maîtrise du flux de production de valeur
- s’adapter sans cesse, et s’améliorer en permanence
- faire le pari de la CONFIANCE !
Retrouvez les vidéos du petit-déjeuner sur Youtube :