Avez-vous, comme moi, remarqué que le matériel de formation du Scaled Agile Framework for enterprises (SAFe) porte en majorité sur les bases de l’Agilité ? Et bien, c’est normal ! Même si les grandes organisations ont trouvé dans la mise à l’échelle (scaling) des cadres agiles à leur mesure (SAFe, DaD[1], Nexus et LeSS[2]), cela n’exclut pas que pour les mettre en place, les fondations demeurent les mêmes : le manifeste Agile, Scrum, Lean, Extreme Programming, la planification par la valeur d’affaires, l’architecture émergente, etc.
Cela m’a donné envie de concevoir un petit livre de jeu (playbook) de la mise à l’échelle Agile, sans cadre (framework), pour tous ceux ayant une certaine expérience Agile et voulant aborder la mise à l’échelle de manière directe.
Jeu de base – La grande équipe
Une des forces de Scrum, c’est d’avoir mis de l’avant une condition de réussite importante : l’équipe multidisciplinaire et auto-organisée. C’est à dire une seule équipe avec toutes les compétences pour construire de manière autonome un nouvel incrément de produit. Ajoutez à cela la recommandation qu’elle soit co-localisée et vous avez une recette gagnante pour réduire la complexité liée aux échanges, aux dépendances, à la rétroaction peu fréquente, au manque de disponibilité des individus ainsi qu’à leurs faibles motivation et engagement. Malheureusement, dès qu’une nouvelle équipe s’ajoute, la complexité liée à la synchronisation augmente de nouveau. .
Ainsi, si vous ne rencontrez aucune tension avec votre équipe, je vous conseillerais de la conserver telle quelle, indépendamment des limites recommandées par le guide Scrum (3 à 9 individus) ou Mike Cohn (7 ± 2 individus). J’ai moi-même contribué au sein d’équipes Agiles de plus de dix personnes qui n’avaient aucun avantage à se subdiviser. Par contre, ayant dépassé les recommandations de la littérature, nous étions prêts à revoir notre configuration dès l’apparition de certains symptômes :
- vélocité nettement insuffisante demandant l’ajout d’un nombre important de nouveaux membres ;
- incapacité à maintenir une relation directe entre nous tous (c.-à-d. one-on-one), menant à la formation officieuse de sous-groupes au sein de l’équipe ;
- rencontres d’équipe trop longues et épuisantes, où la compréhension partagée et la participation de tous sont difficiles à maintenir.
Jeu nº 1 – Les équipes multidisciplinaires (Features Teams)
Lorsque la grande équipe atteint ses limites, alors il peut y avoir des avantages à la diviser. En Agilité, la façon la plus naturelle de le faire est de constituer des équipes multidisciplinaires. À l’exemple de l’équipe de base, les équipes multidisciplinaires possèdent toutes les compétences pour construire de manière autonome un nouvel incrément de produit.
Toutes les équipes multidisciplinaires sont en mesure de travailler de manière autonome sur la même base de code. Elles peuvent donc s’alimenter du même carnet de produit (Product Backlog) et collaborer avec le même Responsable de produit (Product Owner).
Pour que cette configuration soit pérenne, il est important que toutes les équipes respectent la même définition de « terminé » (Definition of done, DOD). Il est également préférable que les équipes synchronisent le code entre elles le plus fréquemment possible.
Avantages
- Offre une très grande souplesse dans la planification, puisque chaque équipe peut prendre n’importe quel élément sans que cela n’impose de contrainte sur la planification des sprints : ni dans le contenu ni dans la durée.
Inconvénients
- Demande une grande discipline de la part de toutes les équipes pour maintenir l’intégrité du produit. Cette discipline est souvent assurée par une DOD commune.
- Nécessite d’avoir suffisamment de joueurs ayant les bonnes compétences.
Considération importante : Pour permettre la planification de sprints de durées différentes, les équipes devront s’entendre sur un mécanisme de soumission, de mise à jour de la base de code, d’intégration et de gestion des dépendances. L’important est de trouver une manière de réduire la boucle d’inspection entre les versions des différentes équipes, pour éviter les mauvaises surprises lorsque le code d’une équipe fusionnera à celui du tronc commun.
Jeu nº 2 – Les équipes de composantes (Componant Teams)
Lorsqu’il est impossible de former des équipes multidisciplinaires, parce qu’il n’y a pas suffisamment d’experts ou parce que les champs de compétence se mélangent difficilement, les équipes de composantes peuvent devenir intéressantes. Il y a deux axes par lesquels il est possible de diviser les équipes : l’axe des activités d’affaires et l’axe des couches d’architecture.
Par exemple, pour une solution d’achat en ligne, un découpage par activités ressemblerait à ceci : l’équipe du processus d’achat, l’équipe du processus de paiement et l’équipe du processus de livraison. Quant à lui, un découpage par couches d’architecture ressemblerait plutôt à ceci : l’équipe des applications mobiles, l’équipe Web, l’équipe des services Web et l’équipe d’infrastructure.
Bien que cette configuration soit pratique dans certains contextes, elle entraîne une contrainte importante : la synchronisation des itérations. Parce qu’aucune équipe n’est en mesure de livrer une fonctionnalité de manière autonome, et parce que l’on s’attend à avoir un incrément respectant la définition de « terminé » à la fin de chaque itération, les équipes doivent coordonner le travail interéquipes de manière à livrer un seul incrément intégré à la fin de chaque itération. Sans cette règle de fonctionnement, les équipes s’exposent à une dette de travail supplémentaire, car la validation du travail prétendument terminé ne sera pas complète avant l’intégration dans un sprint ultérieur.
Avantages
- Permets de regrouper les experts, en raison de ressources limitées ou pour l’efficacité.
- Permets à un Responsable de produit de distribuer la charge de gestion d’un carnet de produit à d’autres Responsables de produit.
Inconvénients
- Demande de synchroniser les sprints.
- Demande de synchroniser la planification des différents carnets d’itération.
- Demande d’ajuster la composition pour balancer la cadence entre les équipes.
Système de jeu dynamique
Même si nous avons tendance à garder la configuration stable pour gagner en prévisibilité, il est possible de changer la configuration pour s’adapter à une situation le demandant.
Voici un exemple vécu. Dans une entreprise responsable de la plateforme Web de diffusion des matchs de football européens, nous étions divisés en deux équipes : une responsable de la diffusion Internet et l’autre de la diffusion mobile. Les deux équipes étaient multidisciplinaires, car nous pouvions livrer de nouveaux incréments de manière autonome sur nos plateformes respectives, même si nous partagions le code de la plateforme de diffusion.
Un jour, des travaux importants ont dû être effectués sur la plateforme, et il était difficile d’imaginer que ces travaux pourraient être planifiés par un travail conjoint des équipes. Nous sommes alors passés, pour quelques itérations, à des équipes de composantes, le temps d’effectuer des travaux. Une fois les travaux terminés, nous avons repris notre configuration multidisciplinaire, pour récupérer notre autonomie.
Cet exemple démontre comment la mise à l’échelle n’est pas nécessairement immuable, et qu’il est possible de passer d’un jeu à un autre selon les besoins. Cette connaissance des différents jeux peut offrir aux organisations et aux programmes la souplesse qui est parfois requise pour faire face à une situation complexe dans laquelle on retrouve de multiples équipes.
[1] Disciplined Agile Delivery
[2] Large-Scale Scrum
Intéressé par les autres jeux ?
Consultez notre livre blanc sur l’Agilité à grande échelle.
Pas de commentaire