Depuis la mise en place de Scrum au sein d'INVIVOO, il y a plus de 10 sprints, nous avons fait évoluer notre framework de travail en l’adaptant à nos contraintes et nos souhaits. Découvrez ce que cette transformation agile à apporter.
En 10 sprints, nous avons :
Renforcé la proximité entre l'équipe de développement et les PO.
Changé notre mode de chiffrage.
Rendu le rôle de Scrum Master tournant dans l’équipe.
Redonné plus du sens à nos Sprints.
Réservé du temps à autre chose que le développement de nos produits
Un nouveau workflow pour plus de synergies
Au début de notre transformation, nous avions mis en place un workflow que l’on retrouve dans beaucoup d’équipes Scrum à savoir : To Do / In Progress / Review / Test / Done, avec plusieurs règles de transition qui permettent de passer une User Story d’une colonne à une autre.
Après plusieurs Sprints, nous nous sommes rendus compte que beaucoup de User Stories ne passaient pas l’étape de Test (tests réalisés par les POs) et revenaient en développement.
Les causes étaient multiples :
Manque de détails dans la User Story
Mauvaise compréhension du développeur
Bug (et oui cela arrive à tout le monde ! )
Pour les deux premières causes, nous avons cherché la racine du problème et sommes vite arrivés à la conclusion d’un manque de synergie entre le développeur et le PO associé à cette User Story. Nous ne voulions pas tomber dans l’excès de détails dans nos User Stories car cela reviendrait à écrire des spécifications détaillées de chaque fonctionnalité. Et cela ne laisserait plus de place d’expression aux développeurs. Nous avons donc apporté successivement deux modifications à notre workflow de travail.
Inversion de la revue de code et de la validation PO
Notre premier objectif a été de faire intervenir le PO au plus près de la phase de développement pour réintroduire plus de synergie.
Ce premier changement a consisté à renommer l’étape « Test » en « ValidationByPO » et la placer en amont de +- la review.
L’idée sous-jacente est de faire travailler le développeur et le PO en binôme comme on peut le retrouver dans les pratiques de « Pair Programming ». Ce mode de fonctionnement favorise le dialogue mais a un coût :
Une présence accrue du PO
La nécessité de colocaliser le PO et l’équipe de développement.
Introduire du flux pour la construction du Product Backlog
Le deuxième changement que nous avons apporté à notre framework de travail a été la mise en place d’un processus en amont du Product Backlog pour faciliter sa construction. L’objectif ici était de répondre au manque de préparation des User Stories qui impliquait des aller retours réguliers entre l’équipe de développement et le PO.
La solution apportée repose sur un flux Kanban décrivant les différentes étapes nécessaires pour la maturation d’un besoin technique ou fonctionnel à des éléments concrets du Product Backlog : Epic et User Stories.
Nous avons établi les règles suivantes :
Toute personne de l’équipe Scrum (Développeur, PO, Scrum Master) peut émettre un besoin, une idée d’évolution… et la matérialiser par un Post-it dans un parking lot
Chaque Post-it (donc chaque besoin) dans le parking lot est porté par une personne (owner) qui a pour responsabilité de faire avancer ce sujet jusqu’au stade où il se trouve dans le Product Backlog
Tout élément dans le parking lot a une durée de vie fixée initialement à 3 semaines. Au-delà de ce délai, si l’élément n’a pas été choisi pour être maturée, on considère qu’il n’est pas prioritaire en termes de valeur pour le moment. Il peut bien sûr revenir dans le parking lot plus tard
Le flux de maturation des besoins est bien un flux tiré propre à l’approche Kanban avec des limites à chaque étape du workflow
Le flux Kanban est géré au fil de l’eau avec des moments privilégiés pour traiter le statut de chaque sujet sous « un format daily », c’est-à-dire un format court et efficace, à une fréquence fixée initialement à 2 par semaine
Dans notre contexte, nous avons retenu les étapes suivantes pour la maturation d’un besoin :
ToDo : sélection des éléments du parking lot que l’on souhaite prioriser
Kickoff : présentation succincte du besoin par son porteur au reste de l’équipe. A ce stade, le besoin doit être décrit sur un format A4 comportant au minimum le pourquoi, le quoi (avec les éventuelles limitations) et le qui
Spécification: phase de maturation du besoin autour d’un ou plusieurs workshops faisant intervenir différents rôles (PO, développeur …). L’objectif est de transformer le format A4 en élément de backlog : Epic et User Stories
Présentation: présentation à toute l’équipe Scrum pour partager les User Stories qui seront intégrées dans le Product Backlog. Le besoin est alors suffisamment maturé pour être potentiellement développé. Il peut donc être ajouté au Product Backlog.
Il s’agit ici de mettre en place un nouveau processus qui sera peut-être que temporaire, mais qui permet de fluidifier la collaboration entre les personnes de l’équipe. Comme on le reverra un peu plus bas dans cet article, ce processus permet aussi d’améliorer la vision du produit et de mieux la partager mais pas que.
Une meilleure maitrise de notre flux de travail
La mise en place du Kanban pour l’équipe PO a eu deux effets immédiats :
Une meilleure qualité des sujets traités par les POs.
Une amélioration de notre lead time.
L’amélioration de la qualité du backlog grâce au processus en amont est assez évident. Le cadre de maturation, le format de description et la co-construction avec l’équipe de développement ne peut avoir que des effets positifs sur la qualité.
L’amélioration du lead time est moins évidente à percevoir pour les moins aguerris du Kanban mais est pourtant un des premiers buts recherchés. En imposant des limites contraignantes dans chaque colonne de notre Kanban, nous avons limité le flux de sortie du processus de maturation de notre Product Backlog. Cette limitation a permis de garder le contrôle sur le backlog et éviter d’avoir une croissance du backlog plus importante que la capacité de réalisation de l’équipe.
Par cette limitation du flux en amont, nous avons donc réussi à :
Maitriser la taille de notre backlog de produit, alimenté par 3 POs, qui a pour bénéfice :
D’éviter de submerger l’équipe de développement
De perdre du temps à rédiger des User Stories qui ne seront pas traitées (ou en tout cas pas dans l’immédiat)
Améliorer la qualité des User Stories, qui a pour bénéfice :
Une meilleure compréhension et appropriation des US par l’équipe de développement
Des estimations plus efficaces (plus rapides avec un taux de convergence nettement meilleur)
Renforcer la vision produit, qui a pour bénéfice :
De donner plus de sens et de conserver la motivation de l’ensemble de l’équipe
.
Une estimation plus efficace
Le choix de ne pas changer de mode de chiffrage au démarrage de notre transformation avait pour but de minimiser l’impact de la mise en place de Scrum. Nous sommes donc restés sur un mode de chiffrage en jours/homme.
Avant chaque Sprint, durant la cérémonie de chiffrage, les POs présentaient les User Story et une séance de poker planning permettait d’appliquer une estimation sur chacune d’entre elles. Lors du Sprint Planning, le Scrum Master remonte la capacité d’exécution de l’équipe en jours/homme, le tout aboutissant au Sprint Backlog.
Une estimation étant par définition incertaine et donc dans l’absolu fausse, le choix de cet étalonnage a eu un effet négatif sur l’équipe et les relations avec les POs. En effet, le fait de choisir le jour/homme comme étalon ouvre la porte à des discussions sur le pourquoi du soi-disant « dérapage » ou de l’estimation trop importante par rapport à ce qui est demandé.
Le changement vers un mode d’estimation en complexité a permis de se recentrer sur la fonctionnalité et comment elle était appréhendée par l’équipe de développement et non le coût qu’elle engendre. Ce changement a été réalisé sur plusieurs Sprints pour avoir une liste de User Stories terminée suffisante pour établir une base de référence. Pendant ces Sprints, l’équipe n’a pas chiffré mais a évalué à postériori la complexité de chaque ticket.
Le fait d’évaluer à postériori permet d’enlever l’incertitude du chiffrage en remontant et prenant en compte les problématiques rencontrées dans les futures estimations.
Le but, vous l’avez compris, est de :
Ne plus engendrer de tensions sur le sujet des chiffrages
De minimiser le temps passé à chiffrer car ce n’est pas le chiffrage qui apporte de la valeur
De fiabiliser les chiffrages en s’inscrivant dans une démarche d’apprentissage continu. Fiabilité discutable car cela ne reste finalement que des estimations.
Un rôle tournant
Nous avons comme croyance que l’apprentissage ne peut se faire sans de la pratique. Nous avons donc poussé toute l’équipe de développement à faire un « vis ma vie » avec le Scrum Master et de prendre cette responsabilité au moins une fois sur une durée d’un Sprint, avec un accompagnement bien entendu.
L’idée est de faire prendre conscience aux personnes de l’équipe de l’importance de ce rôle et des problématiques qui lui incombent. Par ce procédé, chaque personne de l’équipe est maintenant sensibilisée aux problématiques que peut rencontrer le Scrum Master dans son travail journalier et de l’importance de ne pas minimiser ce rôle dans une équipe et dans un processus de transformation. La charge de travail du Scrum Master et la complexité qu’il rencontre diminuent mécaniquement du fait qu’elles soient mieux comprises par l’équipe.
Un cap et une direction
L’équipe a besoin de comprendre son travail et la direction que prend le produit, on parle de vision produit.
Sans pour autant transformer tous les POs en Jack Sparow, l’analogie avec un capitaine et son navire est ici évidente. L’équipage est en demande constante du but de la traversée et d’un cap pour y arriver, comme l’équipe de développement.
Cette vision est représentée à travers les Users Stories et les Epics dans Jira mais cela n’est pas suffisant. En rester à ce mode de diffusion d’information, au compte-gouttes et uniquement à chaque itération, ne permet pas le partage d’une vision globale du produit. C’est une erreur trop souvent constatée.
Pour s’assurer que le message est bien partagé et compris par toute l’équipe, chaque cérémonie de chiffrage et de Sprint Planning commence dorénavant par un rappel de l’objectif du Sprint, du chemin emprunté et de l’impact sur la vision long terme du produit. Ce moment d’échange facilite la remontée d’interrogations que pourrait avoir l’équipe sur le chemin que prend le PO. Ce message est rappelé lors des cérémonies Daily Scrum pour garder le cap.
D’autre part, l’utilisation du management visuel pour la construction du Product Backlog évoqué plus haut est aussi un élément permettant de mieux partager la vision du produit et les choix de priorisation qui sont faits le plus en amont possible du processus. En effet, le fait d’utiliser un tableau physique présent au milieu des équipes pour montrer le travail de construction du Product Backlog permet à chaque acteur de s’y intéresser et de mieux comprendre certains arbitrages faits sur le produit.
Un temps libre pour apprendre et proposer
La proposition a émergé de l’équipe de développement. Dans sa première version, l’idée était de réserver un temps de 2 jours par Sprint à certaines personnes de l’équipe pour travailler sur des sujets annexes de type R&D.
Nous vous avouons que cette proposition n’a pas été accueillie à bras ouverts par l’équipe de POs par peur de baisser la vélocité de l’équipe. Le manque d’information, dans un premier temps, sur le but de ces « temps libres » a remonté beaucoup de questions :
A quoi cela va réellement servir ?
Qui choisit les sujets ?
Comment mesure-t-on le gain que cela apporte ?
Est-ce que c’est le bon moment pour diminuer la vélocité de l’équipe ? Etc …
Après quelques réunions, il a été conclu d’inclure ces phases de R&D dans le Sprint pour :
Donner de la vision sur les sujets abordés dans un souci de transparence.
Profiter des cérémonies de fin de Sprint, et notamment des démos pour présenter l’avancement des sujets avec un double objectif :
Partager la connaissance et faire monter en compétence les personnes de l’équipe
Ouvrir des pistes de réflexions aux POs
L’objectif premier est évidement de favoriser l’innovation et l’apprentissage au sein de l’équipe. Le second objectif est d’apporter une source de motivation supplémentaire à l’équipe. En effet, ces moments ont eu un effet dopant et motivant pour l’équipe, élément indispensable de la réussite de la transformation.
Que penser de ces changements ?
Les changements effectués tout au long de cette transformation et le fait que ces changements émanent de l’équipe elle-même et non essentiellement du Coach qui les accompagne est un signal fort que l’équipe se sent à l’aise avec les nouvelles méthodes de travail et se les approprie. Nous sommes rentrés dans la phase « RI » du « SHU-HA-RI » dans laquelle l’équipe est autonome, créative et passe outre le cadre même de Scrum (qui peut devenir limitant dans certain cas).
Si l’on se réfère à la courbe théorique d’acceptation du changement (ou le modèle de Tuckman), une fois passé l’effet d’annonce, une phase de creux s’installe et toute la difficulté est d’en sortir.
Cette phase de creux est, comme indiqué, une phase de doute et de crainte sur la capacité à atteindre l’objectif. C’est dans cette période que le travail du Coach prend tout son sens en gardant les équipes mobilisées et focalisées sur l‘objectif.
Sortir de cette zone de doute passe par des victoires (à chacun de les identifier). L’appropriation et l’amélioration des processus mis en place dans le cadre d’une transformation Agile par l’équipe est une victoire qui permet de se situer sur la partie croissante de la courbe d’acceptation.
Le mot d’un des membres de l’équipe de développement
« La transformation agile est un chemin périlleux, semé d’embûches, avec des hauts et des bas. Mais il est surtout important de comprendre que la méthodologie et l’outillage ne sont pas le point essentiel. C’est le côté humain, c’est-à-dire une bonne communication entre tous les membres de l’équipe et l’adhésion de tout le monde (devs, POs) à cette nouvelle façon de penser, qui est garant du succès d’une transformation agile. »
LES AUTEURS
Jérôme a travaillé pendant dix ans dans une grande banque d’investissement. Diplômé de l’Ecole nationale supérieure de l’Electronique et de ses Applications en 2006, il commença sa carrière comme développeur et a su évoluer vers des postes de Directeur de projet. Ses connaissances techniques et fonctionnelles et son goût pour les méthodologies agiles lui ont permis de mener à bien des projets d’envergures dans des contextes aussi contraignant que les sujets régulateurs. Depuis 2018, il est Partner chez Invivoo et contribue au lancement de nombreux projets autour de l’innovation et de la transformation digitale pour les banques d’investissement..
Ingénieur diplômé de l’INSA Rouen en 2002, Christophe dispose d’une quinzaine d’années d’expérience en tant que développeur sur l’écosystème Java / JEE, leader technique et chef de projet technique dans plusieurs secteurs d’activités dont celui des banques d’investissement depuis début 2011, date à laquelle il a rejoint Invivoo. Agiliste convaincu, Christophe s’est orienté vers des projets agiles et le rôle de Scrum Master, en étant Certified Scrum Master depuis 2015. Eternel amoureux du code bien fait, il continue à développer en appliquant au quotidien des pratiques agiles comme le TDD, le BDD ou le Continuous Delivery qu’il évangélise autour de lui. En 2017, il relève un nouveau challenge chez Invivoo en devenant Manager de l’expertise Méthodologies & Pratiques Agiles.
