Méthodologie et process

Rex d’une équipe qui cherche son modèle (2/2)

// 11 juin 2020

Rex d’une équipe qui cherche son modèle (2/2)

Si dans la première partie nous nous sommes focalisés sur le choix de nos outils, nous allons maintenant nous intéresser au voyage en lui-même et quelles aides nous avons embarqué avec nous pour rester sur la route et éviter les embûches. 

 

Nous avons vu les avantages et inconvénients du cycle en V, du Scrum, du Kanban et après une analyse de notre environnement ainsi que de nos contraintes, nous avons choisi de partir sur un modèle de production qui se rapproche du Kanban. 

 

Essentiellement, le Kanban nous permettait d’être plus flexibles et perméables face aux imprévus. Cette capacité à toujours garder la production focalisée sur des choses importantes malgré les secousses nous à permis de délivrer le maximum de valeur ajoutée sans perte de temps ou de potentiel. Cependant, nous avions de grosses échéances à ne pas rater. Des blocs d’itération qui s’achevaient par le franchissement d’une étape importante pour notre entreprise, un rendez-vous qu’il ne fallait pas manquer.

 

Pour ne pas manquer ces rendez-vous, il nous fallait un moyen d’être prévisible. Le plus gros challenge étant de savoir quand le backlog commençait à dépasser notre capacité pour la période donnée et quand faire des arbitrages. Nous avions décidé de faire une croix sur Scrum et ses sprints planifiés à l’avance, la question était ; comment obtenir le même confort sans les inconvénients d’un planning rigide.

 

 

Partager tôt, détailler plus tard

Toute notre logique de production était organisée autour de ces gros caps à franchir. Chaque cap comprenait un ensemble de features et la plupart du temps le nombre de features était réduit au maximum pour tenir sur une période de trois mois. 

 

Comment faisions-nous pour avoir la négociation initiale autour des features à intégrer ? Comment suivre la progression à travers l’avancée du projet ? 

 

Nous partagions les idées tôt, à un stade où elles n’étaient probablement pas prêtes à être produites et nous raffinions au fur et à mesure si la négociation initiale était validée. Cela nous permettait d’investir un minimum de ressources en amont de cette phase de négociation et réduisait donc grandement le coût engagé dans une feature si elle devait être mise au placard. 

 

De l'infiniment grand à l'infiniment petit

Pour arriver à estimer tôt, mais quand même être précis, nous avons adopté un système de double évaluation des fonctionnalités, chacun dans son propre paradigme et servant un objectif différent.

La première étape de calibrage réside dans l’infiniment grand. À ce stade les estimés nous servent à faire la négociation initiale du mvp. On parle de grosses fonctionnalités dont l’ux mériterait plus de travail, l’ui est peu définie et la stratégie technique encore grossière. Nous faisions des estimés en taille de T-shirt en jugeant de la taille d’une feature par sa complexité à être testée. Plus une feature intègre d’équipes différentes et contient des cas particuliers, plus elle est grosse. A l’inverse, une feature est petite si elle peut être réalisée par une seule équipe et comporte peu de cas particuliers.

 

Le scope des features est validé grâce à cette négociation initiale et n’attend plus qu’à être bouleversé. La première étape est donc terminée.

 

 Les premières features sont découpées en user story et le cycle de production se met en route. Une question demeure, au bout de combien de petits bugs, ajustements de wordings ou modifications de padding le charriot va-t’il quitter la route ? Nous avons des estimés macro pour des features qui peuvent prendre des semaines à être réalisées, comment comparer ça à des plus petites tâches pour ne pas perdre de vue la date d’arrivée ?

Nous faisions une deuxième étape d’évaluation durant le cycle de production. Cette fois-ci, les évaluations sont en story points sur des sujets précis dont les tenants et aboutissants sont définis. Évaluer à nouveau nos features quand elles sont découpées en user story nous permet plusieurs choses. 

 

La première est de vérifier que nous ne nous étions pas trompés sur la taille de T-shirt. Si vos M font entre 18 et 25 points une fois découpés et qu’un dernier M fait 50 points, vous n’avez plus qu’à faire une résolution de problème sur le sujet et réévaluer la pertinence de la fonctionnalité ou son implémentation. 

 

La deuxième chose que cela nous permettait est de pouvoir comparer la production actuelle avec notre macro planning. Un changement de couleur, un changement d’icône, l’ajout d’un texte, ces modifications n’ont pas leur place dans le macro planning, mais peuvent faire déraper le projet. Avoir une échelle adaptée à ces plus petits changements permet de maîtriser leur impact.  

 

Réunir les deux mondes

Pourquoi ne pas tout évaluer en story points dès le début et utiliser les plus grands nombres de la suite de Fibonacci pour les features ? 

 

Car nous comparions deux choses très différentes. Au début, nous nous intéressons à des larges portions de travail dont la définition est perfectible, à la fin nous nous intéressons à des petits incréments définis. Le fait de changer de paradigme de notation nous permet aussi de changer nos exigences et notre approche de la chose.

 

Pour concilier ces deux mondes nous faisions une traduction grossière et empirique des tailles de T-shirt vers les story points. Un S vaut entre A et B points, un M entre C et D points et ainsi de suite, le tout pour obtenir un burn-up qui nous permet la projection et l’inspection tout au long du bloc.

Sur ce burn up, l’espace gris représente la somme de nos tailles de T-shirt convertis en story points. C’est une fourchette qui représente la charge de travail que nous imaginons en début du bloc.

 

La courbe rouge représente les user story que nous avons définies et qui ont été soumises au vote lors d’un poker. Idéalement, cette courbe rouge viendra s’arrêter dans la zone grise.

 

La courbe Jaune elle représente le travail que l’équipe est en train de produire. Cette courbe nous donne une image très rapprochée de ce que l’équipe fait et peut nous permettre quelques analyses sur l’efficacité de production. Entre le 10 et le 20 septembre, par exemple, je vois une période assez plate ce qui m’indique un problème.

 

La courbe verte, elle représente ce que l’équipe a terminé et ce qui est actuellement en production. Encore une fois, cette courbe peut alerter sur des potentiels problèmes sur le processus de mise en production.

 

Ainsi, je peux voir que l’équipe aura terminé toutes les user story actuellement évaluées le 25 octobre et qu’ils auront terminé l’ensemble du travail projeté en début de bloc entre le 10 et 23 novembre.

 

C’est donc grâce à ce guide visuel et tout ce qu’il fallait pour le mettre en place que nous avons réussi à rester sur la route. Nous avons réalisé le premier bloc sans ce guide et les blocs suivants ont été sans comparaison tant au niveau du stress que de l’aisance de l’équipe à prioriser ou rajouter des sujets dans son backlog. 

Rex d’une équipe qui cherche son modèle (2/2)

Clement Brottier

// 11 juin 2020

Partager