Sabrina Ferlisi Cet article met en évidence l’importance de la réactivité dans le travail d’une équipe Scrum, en se concentrant sur les mises en production et le processus de refinement. Il aborde également l’automatisation des mises en prodpuction.
Cette série d’articles aborde les facteurs qui sont déterminants pour qu’une équipe Agile soit efficace selon une étude scientifique. Le premier article abordait l’axe de l’Amélioration continue, le deuxième parlait de l’Autonomie de l’équipe et le troisième du Soutien du management. À chaque fois, pour ancrer ces concepts dans des éléments tangibles, je les présente dans le contexte d’une équipe Scrum qui développe un produit informatique et que j’accompagne en tant que Scrum Master.
Plongeons aujourd’hui dans un aspect crucial de notre travail : la réactivité, en se focalisant sur les mises en production et le processus de refinement.
La fréquence des mises en production
Avant l’arrivée d’un gros programme qui a complétement modifié notre manière de fonctionner, notre routine était de faire une release au moins une fois par sprint. Cela nous a poussés à travailler sur la capacité de découper nos éléments en petites unités qui apportent malgré tout de la valeur, afin de garantir que quelque chose d’utile soit toujours achevé à chaque sprint. Le fait de mettre fréquemment en production, nous permet de :
- Pivoter facilement si on se rend compte qu’un choix fonctionnel n’est pas le bon. Pour cela, soyons francs : il faut aussi s’inquiéter d’aller valider après la mise en production que nous avons bien fait les bons choix… mais c’est un autre débat.
- Eviter le gaspillage en réduisant nos développements en tout petits morceaux avec juste la “substantifique moelle”.
- Valider les choix techniques en nous confrontant à la vraie vie au plus vite.
Cependant, avec le programme, le rythme nous est imposé, et de nombreuses dépendances entravent notre agilité. Comme nous dépendons d’autres systèmes, nous sommes contraints d’adopter un cycle de release plus long. Aujourd’hui, nous n’avons pas mis en production depuis plusieurs mois et pourtant nous continuons à développer et à avoir des éléments terminés à la fin de chacun de nos sprints.
Cet état de fait implique selon moi :
- Accroissement du risque : Nous continuons à faire de l’inventaire… c’est-à-dire que tout ce que nous développons continue à être des hypothèses et nous ne savons pas si cela est vraiment utile pour notre utilisateur final, si nous allons bien dans la bonne direction. Chaque mise en production serait une opportunité de valider si la direction choisie est bien la bonne et de pivoter en conséquence si besoin. Ici, il ne nous est pas possible de pivoter et l’option choisie est de tout développer dans les détails sans validation.
- Démotivation de l’équipe : Il y a une forte corrélation entre la motivation de la Scrum Team et les mises en production. Ici, le sentiment est de “faire des choses”, encore une fois, sans savoir s’il s’agit de la bonne chose. Il nous est demandé de revoir l’interface graphique par exemple, car, en interne, une partie prenante a estimé que cela n’allait pas. Mais quid de l’utilisateur final ? Ce qui amène un sentiment à l’équipe d’être juste occupé, sans pour autant amener de la valeur.
Automatisation des mises en production
Pour notre travail quotidien, notre système de mise en production est entièrement automatisé et simplifié. Cela nous permet une grande réactivité et flexibilité.
Cependant, dans le contexte de ce programme, nous faisons face à des limitations, notamment l’absence d’environnements de tests adaptés, ce qui représente un défi significatif pour maintenir notre efficacité et notre qualité. À nouveau, le risque de découvrir que quelque chose n’est pas correct augmente considérablement dans un contexte où il ne nous est pas possible de valider l’intégration de nos développements avec les autres systèmes au plus tôt.
Le processus de refinement
Pour assurer une préparation optimale à chaque sprint, notre équipe a institué quatre séances de refinement d’une heure dans nos sprints de trois semaines. Ces sessions sont essentielles pour la clarification et la décomposition des éléments à venir. Elles permettent une discussion ouverte entre les développeurs pour assurer une compréhension uniforme de la complexité des tâches et de la décomposition technique. Nous utilisons ces séances pour découper au maximum nos éléments tout en gardant de la valeur (je parlais plus tôt de “substantifique moelle”).
Parallèlement, le refinement avec les parties prenantes est géré par un Business Analyst externe à l’équipe, qui assure la liaison avec le métier. Les informations sont ensuite transmises au Business Analyst interne à notre équipe et au Product Owner. Bien que ce fonctionnement avec le BAM soit efficace, il crée un goulot d’étranglement et renforce la posture de notre Product Owner en tant que Proxy, très orienté opérationnel et qui n’a pas de pouvoir sur les décisions stratégiques.
Cette quatrième partie met en lumière les défis et les stratégies que nous adoptons pour rester réactifs et agiles malgré les contraintes extérieures. De manière générale, nous avons compris au sein de l’équipe à quel point il est indispensable de découper nos tâches pour maintenir le rythme, et à automatiser autant que possible nos processus. Le refinement, un processus clé dans la préparation de nos sprints, illustre bien notre approche collaborative et notre désir de comprendre en profondeur ce que nous développons.
