Réussir la transformation Agile d’une organisation existante chez SpotMe

Tout d’abord, il a passé son premier mois de travail en décembre 2018 à auditer l’existant pour comprendre les besoins et le fonctionnement actuel. Avec certains team leader déjà en place, ils ont parlé et écouté les membres du département pour lister ce qui fonctionne bien et moins bien. 

Mettre en avant les bonnes pratiques était nécessaire pour deux raisons : 

• les intégrer dans le processus de transformation agile à venir : pourquoi changer ce qui fonctionne ? 
• éviter de faire passer le message que “rien ne fonctionne” ou “tout ce que vous avez fait jusqu’à maintenant est bon à jeter”.

Toutefois, expliciter ce qui ne fonctionne pas fut tout aussi important pour faire prendre conscience aux équipes de la nécessité de changer. Afin de créer cet engouement au changement, une liste d’objectifs d’améliorations et de problématiques à résoudre fût dressée tel que suivant : 

• Améliorer la prédictibilité de nos “releases” en termes de dates de livraison et contenu
• mieux estimer la complexité et la taille de certaines fonctionnalités à développer
• procéder à une meilleure découpe des gros projets 
• adopter le concept de MVP afin de pouvoir tester la nouvelle fonctionnalité au plus vite et enfin s’assurer d’une utilisation optimale de nos ressources en gérant mieux le séquençage des tâches par équipes et la parallélisation du développement.
  

Introduire un processus agile dans une organisation existante représente un changement significatif et important tant dans la manière de penser que d’opérer comme le témoigne les 4 valeurs du manifeste agile sur lequel repose toutes les méthodes agiles.

Par rapport aux méthodes traditionnelles de gestion de projet, l’agile est plutôt axée sur les individus et les interactions que sur les processus et outils en tant que tels. Aussi, le mode de pensée est tourné vers le besoin du client à travers une livraison régulière de valeur (nouvelles fonctionnalités, meilleure qualité du produit en termes de stabilité ou réduction des défauts, etc.). 

Former et prendre le temps de la mise en œuvre de ce changement est nécessaire, car tout le monde va en bénéficier dans le temps. Il a ainsi été question, durant ce même mois de décembre 2018, de planifier le changement pour créer de l’engouement. Son début a été marqué par un kick-off en janvier 2019 de deux jours et demi en dehors des bureaux avec le programme suivant : 

• Workshop de réflexion sur ce qui fonctionnait et ne fonctionnait pas 
• Session sur la culture agile pour acculturer à ce changement culture (ex: vidéos de Spotify)
• Exercices de team building
• Formation à la méthodologie de SCRUM : comment évaluer, comment travailler en story point, etc. 

Le premier jour était plutôt centré sur de la théorie tandis que dès le deuxième jour, les équipes sont passées à la pratique. La formation est une étape clef dans la mesure où les méthodologies peuvent vite être mal appliquées tel que les équipes le faisaient jusqu’ici : faire des sprints et des stand-ups ne suffisent pas pour se dire agile. 

En termes d’accompagnement, le kick-off a été un moment très marquant pour Marc. Durant le premier Sprint Planning, chaque équipe était dans une partie de la salle pour faire son planning avec des post-its. Durant les 5-10 premières minutes, il ne se passait pas grand chose. Les équipes ne savaient pas comment approcher cette nouvelle méthode. Marc et un ou deux des teams leader engagés dans le processus étaient présents pour coacher les équipes et leur expliquer comment avancer. Après un quart d’heure, ils ont senti monter, d’un coup, une effervescence, une énergie où les gens commençaient à se parler, à échanger. Et là ils se sont dits : c’est bon, c’est parti, ça prend.

Face à la nouvelle méthodologie de travail et la nouvelle culture que cela supposait, les réactions ont été diverses dans l’équipe de Marc. Certains ont eu peur face au formalisme, la lourdeur et le côté orienté processus de la méthodologie SCRUM. Par exemple, à la fin d’un sprint planning, les collaborateurs doivent dire “je m’engage” à livrer toute la liste de tâche. Ce côté formel peut amener des réticences. Toutefois, beaucoup ont été rassurés de voir que cela amenait de la structure qui pouvait manquer jusqu’alors. Aussi, au fur et à mesure de l’utilisation de la méthodologie, chacun a commencé à se l’approprier et à voir son utilité. C’est assez paradoxal car pour introduire agile, ce formalisme est requis, et pourtant on s’attend ensuite à ce que chacune des équipes s’approprie la méthode et l’adapte à ses besoins.

Dans la phase de lancement d’un projet de changement de ce type, on voit que les personnes ont un rôle clef à jouer.  Comme illustré sur le graphique ci-dessous, tout changement de fonctionnement interne à une équipe va amener à un moment donné une perte de performance, le temps que l’équipe s’habitue au nouveau mode de fonctionnement et finalement performe encore mieux.

C’est ainsi déterminant d’adopter une stratégie d’accompagnement au changement en s’appuyant sur les alliés à l’intérieur de la structure. Comme le montre ce mapping des postures de changement, il existe différents profils face au changement, dont une grande majorité de personnes qui sont à convaincre sans pour autant être détracteurs.

Repérer et s’appuyer sur les ambassadeurs du modèle va permettre d’aider à passer plus rapidement cette courbe descente en termes de performance, car ils pourront permettre de convaincre les hésitants. Gérer les détracteurs est aussi un élément clef, car ils auront tendance à entraîner avec elles d’autres personnes.

Une fois la phase de lancement réalisée, la méthode est apprise et elle peut commencer à évoluer pour l’adapter à ce qui ne fonctionne pas ou plus en fonction des évolutions du contexte ou des besoins des équipes ou des métiers. 

Chez SpotMe, plusieurs adaptations ont été faites. Tout d’abord, par la force des choses, à travers le temps, à force de pratiquer les diverses cérémonies dont les Sprint planning, les équipes ont maturé. Elles sont devenues plus précises dans leur estimation de ce qu’elles sont capables de livrer. Grâce à cette connaissance sur les capacités, elles peuvent vraiment vivre l’agilité en s’adaptant à n’importe quel changement. 

Un des changements les plus conséquents qu’ils ont vécu fut, comme pour beaucoup, la période de crise sanitaire engendrée par la COVID19. Tous leurs services étaient conçus pour des événements en présentiel. Ils se sont donc vus obligés de revoir rapidement le cœur de leur produit pour aller vers du virtuel.  L’agilité a permis de mettre en pause certaines tâches pour se focaliser sur de nouvelles priorités liées à l’implémentation des projets liés au streaming vidéo et à l’interaction en ligne. Ils ont dû également sortir d’une focale orientée mobile pour se focaliser sur la version desktop ‘WebApp’. Cela a amené un changement de priorité et une accélération pour pouvoir rapidement réagir à temps et redynamiser le business avec l’acquisition de nouveaux clients. 

Durant cette période de COVID, ils ont dû également passer leur propre organisation de travail à un fonctionnement en ligne. Ils ont ainsi adapté certaines choses, notamment le fait d’avoir des tableaux de bord visuels en ligne (ex: Miro, Mural, etc.) ainsi que des outils de gestion des tâches pour remplacer les tableaux physiques et les posts-it utilisés jusqu’ici en présentiel. Ils sont depuis lors restés en ligne puisqu’ils sont devenus encore plus efficaces. Pour pallier les besoins de sociabilité, toutes les équipes de l’ensemble de l’entreprise se retrouvent tous les trois mois durant 3 à 4 jours en présentiel. C’est l’occasion de faire une revue des objectifs fixés et de les ajuster sur la base de ce qui s’est bien ou moins bien passé ainsi qu’en fonction des nouvelles opportunités. Durant ces moments, ils vont aussi passer des moments informels ensemble, faire des activités non reliées au travail pour se reconnecter les uns aux autres. Ces moments aident à la cohésion et mettent un rythme avec un cycle de tous les trois mois. Pour en savoir plus sur toutes adaptations du travail en ligne, vous pouvez aussi consulter cet article réalisé par le directeur, Pierre Métrailler, à ce sujet.

Au-delà de l’organisation en ligne, ils ont aussi revu la durée de leur sprint. Chaque mois, ils livrent de la nouveauté aux clients. C’est fortement apprécié par les clients et cela les rend compétitifs. Or, l’équipe a grandi et cela implique que chaque mois il y avait encore plus de changement à déployer en production. Ils se sont donc rendu compte qu’ils avaient atteint un point de bascule où l’équipe avait tellement grandi qu’ils déployaient beaucoup trop de changements à mettre en production. Or, s’il y a beaucoup de changement de code, cela implique significativement plus de risques. Ils se sont donc rendu compte qu’ils devaient passer à un cycle de développement de deux semaines pour avoir des incréments produits plus petits. Cela amène d’autres défis avec des changements toutes les deux semaines qui peuvent être plus compliquées pour le client. Ils essaient de pallier ça en réalisant des changements moins visibles toutes les deux semaines, tandis que tous les mois, ils annoncent des changements avec des fonctionnalités qui ont des impacts plus grands et visibles.

Un autre élément clef qui a été mis en place chez SpotMe depuis 2020 afin d’aligner les objectifs de l’ensemble de l’entreprise, mesurer le progrès et adapter ses objectifs au cours du temps , c’est la méthodologie des OKR, les Objectives and Key Results. 

Chaque année, et sur la base d’une révision trimestrielle, la direction donne des objectifs que l’entreprise doit atteindre. Ensuite, chaque département contribue à ces objectifs globaux d’entreprise en y alignant ses propres objectifs. A savoir que ces objectifs sont découpés en Key Results ou résultats clefs en français, qui doivent être mesurables et faciles à évaluer. Le plus délicat, dans cette méthode, est de définir des résultats clés qui sont valables. Dans le cas de l’équipe engineering, ce fut plutôt naturel d’implémenter une telle méthode qui s’appuie aussi sur une logique de cycle, de trois mois cette fois. Ainsi, il s’agit encore de segmenter le but à atteindre en plus petites parties. Un résultat clé du département engineering devient une épic, qui est découpée ensuite en stories qui vont être réalisées au fur et à mesure des sprints. 

La méthodologie OKR permet ainsi à la fois la gestion de la transversalité et des interdépendances entre équipes en créant un alignement dans une direction commune, et ceci en se basant sur des principes similaires aux méthodologies de gestion de projet agile : la définition de la direction commune est réalisée en segmentant, les différents axes et selon une approche itérative puisqu’elle est revue et ajustée à raison de cycle de trois mois.

La prédictibilité sur ce que l’équipe peut livrer est, comme on l’a vu, gage d’agilité, puisque cela permet de pouvoir définir les changements possibles à faire en tenant compte des ressources à disposition et de leur capacité. Cette prédictibilité ou vélocité se définit qu’au cours du temps. Au début, c’est très aléatoire et ce n’est qu’après 6 ou 7 cycles de sprint qu’elle devient correcte car il y a suffisamment d’expérimentation faite et de données pour pouvoir estimer le temps qu’il faut pour réaliser certaines tâches.

Cette prédictibilité se mesure grâce à l’exercice d’estimation de la taille et complexité des tâches réalisée lors du Sprint planning avec la pratique du Poker Planning issue de SCRUM. Comme expliqué sur l’image ci-dessous, durant le Sprint Planning, une série de ’User stories’ sont définies, ce qui découle ensuite sur des tâches. Les membres de l’équipe vont ensuite estimer en nombre de points pour chacune des stories et des tâches.

C’est volontairement un nombre de points qui est estimé et non pas un nombre de jours ou d’heures. En effet, si l’estimation se faisait sur une échelle en temps réel cela biaiserait l’estimation. De plus, en un jour, une personne ne réalisera pas la même chose qu’une autre en fonction de ses compétences et de son niveau d’expérience. 

Ainsi, l’estimation se réalise en utilisant une séquence de Fibonacci, par une mesure en T-Shirt, tel que présenté ci-dessous. Cela permet de mieux réfléchir l’estimation de tâches importantes, qui mériteraient peut-être d’être encore découpées en sous-tâches.

Pour réaliser cette estimation, l’équipe peut utiliser une application où il est possible de voter sans influencer un autre membre de l’équipe. Le team leader ou scrum master lit à haute voix la story, puis les membres de l’équipe peuvent poser des questions de clarification. Ensuite, chacun des estimateurs va sélectionner une carte représentant la taille sur son application. Puis, toutes les cartes sont montrées à tous et les membres peuvent ainsi discuter des différences. Finalement, suite aux discussions, une ré-estimation peut être faite. 

Ce qui est intéressant avec cette technique du Poker Planning, c’est qu’elle va tenir compte du certain niveau ou d’une certaine aptitude que certains pourraient avoir dans une certaine partie du produit. Il pourrait y avoir trois personnes de l’équipe qui sont très à l’aise sur une partie et deux autres qui le sont moins. Les personnes qui sont moins à l’aise vont mettre plus de points alors que les autres vont en mettre moins. Cela va ensuite se moyenner. Cette manière de faire tient donc forcément compte de la composition de l’équipe. Aussi, un autre avantage est de pouvoir permettre aux membres de l’équipe de discuter de leurs différences de perception pour ajuster leur compréhension respective du travail à effectuer. Si les estimations divergent trop, cela est en général dû à une mauvaise compréhension de la tâche à accomplir. Dans ce cas, l’équipe rediscute la tâche pour mieux la comprendre et essaie aussi de comprendre pourquoi une personne a voté très bas et une autre très haut. Une fois la tâche bien comprise, il est possible de refaire un vote.

Si cet exercice est pratiqué à chaque sprint, au bout d’un certain temps, il est possible de définir la vélocité, c’est-à-dire le nombre de jours que cela représente. Il existe deux possibilités : soit en additionnant le nombre de points et divisant cela par le nombre de sprint ou en additionnant le nombre de jours réalisés puis en le divisant par le nombre de points. Au début c’est compliqué d’estimer la valeur d’un point, mais il faut bien commencer quelque part. 

Ces courbes ci-dessus représentent les vélocités des cinq équipes de chez SpotMe. Sur la deuxième ligne, il y a trois courbes : 

• En rouge : ce que les équipes se sont engagées à faire 
• En jaune : ce que les équipes ont effectivement livrés en fin de sprint
• En bleu : le forecast, l’estimation des points qu’ils vont avoir dans les sprints successifs basés sur les hommes jours disponibles

Ici, c’est un graphe global sur tous les sprints. Cela pourrait être possible aussi de faire un tel graphe sur le sprint pour regarder si le sprint va atteindre ses objectifs. Cela permet de s’arrêter si l’écart est trop important et de procéder à un sprint replan. Celui affiché ici est plus global et permet de mesurer la manière dont l’équipe progresse dans sa précision. Ici, on voit que certaines équipes sont plus précises et expérimentées que d’autres, notamment la dernière où les courbes se suivent tout le long. Dans le cas de la quatrième équipe, on voit un écart entre ce qu’ils se sont engagés à faire et ce qu’ils ont livré, certainement dû à un événement externe, un changement de direction ou plus de temps passé à fixer des bugs.

Les indicateurs de performance liés au Poker Planning sont disponibles pour les membres des équipes. De prime abord, nous pourrions nous demander si cette évaluation de la performance n’induit pas une forme de pression sur les équipes. Or, ce n’est pas le cas puisque cet outil est justement utilisé comme garde-fou au surengagement. Les jours-hommes étant indiqués, les équipes s’appuient sur ces données pour savoir combien de capacité ils ont dans le prochain sprint. Ainsi, cela leur permet de s’assurer qu’une personne ne s’engage pas plus qu’elle ne pourraitet cela garantit donc la livraison des éléments promis. 

Aussi, cela ne met pas de pression sur un individu plutôt qu’un autre puisque ce sont les données globales de l’équipe qui sont mesurées et non pas les données individuelles. D’ailleurs, cela prend en compte que suivant les projets, il va y avoir des gens qui auront une aptitude naturelle à aimer le sujet ou à être très fort dans le sujet et d’autres moins, puis ensuite cela s’inverse au cours du temps. Ainsi, l’outil est axé davantage sur de la précision de l’équipe plus que de la performance pour toujours obtenir plus. Cela s’inscrit dans une démarche d’amélioration continue.

Ensuite, s’il y a une personne qui performe moins, cela va se voir très rapidement, car c’est du travail pas effectué, il y aura des stories qui manquent. Ce n’est donc pas avec ces données que cela ressort. D’ailleurs, les équipes de Marc se trouvent soulagées de toutes ces méthodologies de travail et de ce fonctionnement, car le matin lorsqu’ils se lèvent ils savent sur quoi travailler. Les choses sont établies en avance et il y a une structure. Ensuite, s’il y a des imprévus, il est possible de réagir en connaissance de causes.

Tout à fait. Pour voir comment, vous pouvez notamment vous inspirer de l’approche de Claude Aubry, qui dépeint la manière d’organiser une équipe de travail sous forme agile en illustrant la démarche par l’exemple d’une entreprise qui réalise de la production de légumes en permaculture. Ce que relève Marc, c’est qu’il est avant tout important de s’adapter à l’environnement et aux ressources à disposition de l’équipe qui implémente la méthode.