On m'a récemment demandé d'expliciter un peu plus l'affinage dans une organisation agile à l'échelle. C'est effectivement un sujet qui bien que théoriquement simple se révèle assez complexe à mettre en œuvre correctement dès lors qu'on y implique plusieurs équipes.
Qu'est-ce que l'affinage ?
L'affinage, refinement en anglais, est le travail permettant de clarifier, détailler, découper, estimer et prioriser les éléments du Backlog Produit pour que le ou les équipes puissent les réaliser. L'affinage est clairement évoqué dans le Scrum guide où il est recommandé que l'équipe réserve une petite partie de son temps pour préparer les futurs sujets.
Deux échelles de temps
Pourtant l'affinage porte en lui-même un décalage avec le mode de fonctionnement de Scrum. En effet Scrum insiste sur le fait que l'équipe se concentre sur ce qui est à réaliser pour le sprint en cours sans être parasitée. Or la préparation de futurs sujets rentrent bien dans la liste des éléments en dehors de l'objectif concret du sprint. De plus on travaille bien sûr deux échelles de temps différentes, un temps court de réalisation pour les développements du sprint et un temps long pour préparer les sujets qui pourraient venir dans un, deux, trois Sprint plannings ou plus , voir même qui ne seront jamais en réalisation.
C'est cependant un compromis important pour permettre de garder un flux de travail régulier. Afin de réduire l'impact de cette distraction sur le sprint en cours il est conseillé de limiter le temps consacré à cette pratique. Les anciennes versions du Scrum guide indiquaient de limiter à moins de 10% du temps de l'équipe.
Affinage à l'échelle
A l’échelle, nous retrouvons le même concept. L'affinage permet de clarifier, détailler, découper, estimer et prioriser les éléments de travail. Mais à la différence de l’affinage au niveau de l’équipe, il s’agit de préparer les éléments de plus grosse granularité, c'est-à-dire des features ou des epics qui concernent plusieurs équipes, sur plusieurs sprint. Il faut donc impliquer et coordonner plus d’une équipe dans le processus récurrent d’affinage. Il est également important de veiller à ne pas trop détailler les éléments en restant au niveau Features/Epics pour ne pas empiéter sur la liberté et l’autonomie de l’équipe qui va définir les User Stories sous-jacentes.
L'affinage au sein d’une organisation agile à l'échelle est également unanimement recommandé. Parfois on prête moins attention à la préparation au niveau des features/epics du programme car celles-ci seront retravaillées également par les équipes au niveau des User Stories, il est fréquent de voir cette étape cruciale malheureusement mise de côté.
Avec le framework SAFe, il est considéré comme inacceptable de ne pas avoir affiné le Backlog du programme avant un PI Planning. Même si aucune prescription sur le rythme et façon de faire n’est précisée, c’est l’activité continue du Product Management visible dans le Program Kanban. Quelques détails sur le site de ScaledAgile.
Le framework LeSS, de son côté insiste également sur l’importance de cet affinage qui peut être considéré comme l’evènement le plus important pour l’alignement des équipes. LeSS va plus loin en préconisant plusieurs niveaux d’affinage, un affinage global, un affinage détaillé multi équipe et un affinage uniquement avec une équipe.
Plus de détails sur l'article dédiée sur le site de LeSS
En pratique
En pratique, dans une organisation Agile à l'échelle, on constate quelques dérives qui brident ou empêchent l'affinage.
- Des experts dédiées
C'est un des principaux écueils que j'ai pu observer. Les équipes étant beaucoup sollicitées, il est souvent plus facile de demander l'avis d'experts externes aux équipes pour préparer le travail en amont, d'autant que cette équipe existe parfois déjà. Si cette démarche part d'une intention louable, il exclut les équipes de la préparation de la suite de ses travaux et peut causer encore plus de divergence si les experts et les équipes qui réaliseront ne sont pas alignées.
- Mobiliser uniquement les équipes concernées
Le deuxième écueil courant est un problème d'organisation et d'implication. Une organisation à l’échelle suppose plusieurs équipes ayant des spécialités propres et des contraintes différentes. Il est déjà difficile d'arriver à coordonner tout le monde, en plus des réunions déjà existantes mais cela pose encore plus de questions lorsque les sujets discutés lors de l'affinage ne concernent qu'une petite partie des équipes voire une seule. La tentation est grande de ne mobiliser qu'une partie des équipes ou de ne solliciter que les équipes à priori concerné au risque de démobiliser une partie des intervenants et manquer des dépendances ou remarques essentielles. Bien entendu, dans le cas où il est clair que le sujet ne concerne bien qu’une seule équipe, il n’est pas nécessaire, voire contre-productif d’inclure tout le monde. En revanche, s’il est possible que le sujet soit partagé entre équipes travaillant sur des composants différents, une bonne pratique consiste à discuter tous ensemble des sujets, identifier les équipes concernées et dédier des ateliers indépendants pour les sujets qui n'impliquent qu'une ou deux équipes. C’est une pratique mise en avant et conseillée par LeSS. Cela étant il est important que tous aient la visibilité sur les sujets abordés pour identifier d'éventuelles adhérences.
- Un affinage à la demande
Un autre écueil consiste à ne pas faire des affinages réguliers mais à en créer à la demande. On observe principalement, mais pas exclusivement, ce fonctionnement corrélé à une organisation de livraison en grosses releases. On a alors beaucoup d'affinage avant et au début de la réalisation d'une version puis très peu, ce qui revient peu ou proue à refaire une organisation en mode Cycle en V. Ce rythme saccadé ne permet pas un flux de travail régulier et accentue un travail par à-coups. Le principal risque est d'oublier ou de bâcler des affinages essentiels arrivée au mauvais moment. De plus, il est plus difficile pour les équipes de s'organiser efficacement autour de ses alternances de rythme.
- Beaucoup, beaucoup de sujets
La dernière dérive présentée ici est probablement la plus courante et ne concerne pas que l'affinage mais c'est encore plus vrai dans le cas de l'affinage à l'échelle. En effet, lorsqu'il s'agit de défricher des sujets à potentielle valeur concernant un grand nombre d'équipes à moyen long terme, on ouvre la porte à tout. Et c'est normal car c'est justement l'affinage qui va permettre de clarifier les choses. Cela étant,pour que les équipes ne soient pas submergées, il est important que le nombre de sujets soit explicitement limité par un seuil arbitraire, à la manière d’une Work In Progress Limit utilisé en Kanban. Ce seuil va forcer encore plus de priorisation mais va garantir un rythme de travail réaliste et soutenable.
A retenir
L’affinage à l’échelle est essentiel pour aligner les équipes et préparer sereinement les sujets à réaliser régulièrement. Ce n’est pas une option.
L’effort d’affinage, indispensable, doit être limité pour ne pas prendre trop sur la réalisation en cours.
Quelques conseils de mise en place:
- Impliquer un membre de chaque équipe et pas seulement des experts
- Mobiliser toutes les équipes au moins pour la vue d’ensemble et dédier des affinages multi-équipes et des affinages d’équipes pour les sujets plus spécifiques
- Planifier des sessions d’affinage régulièrement
- Limiter arbitrairement le nombre de sujets présentés
*
