- Camille MARQUETTE
- Coach Agile / Scrum Master
- Membre de Nord Agile
Thèmes liés
Durant les périodes de confinement vécues en 2020, nous avons tous vécu des changements drastiques dans notre quotidien, aussi bien sur le plan personnel que professionnel.
Je vous propose donc de partager mon retour d’expérience sur cette période particulière, ce que j’ai appris et ce que nous avons pu construire pour faire face aux nouvelles contraintes.
Le début de l'aventure
Je suis à la fois Scrum Master et développeur pour une grande entreprise du retail. Le but de notre projet était de créer une nouvelle application pour les vendeurs en magasin. Cette dernière était destinée à remplacer l’ancienne qui était devenue trop complexe à maintenir et à faire évoluer. Elle se devait d’être iso-fonctionnelle avec l’ancienne. Nous souhaitions également créer et ajouter des fonctionnalités à forte valeur avec des efforts proportionnels à chacune.
Nous étions une équipe de 5 développeurs, prêts à développer notre application en Flutter, une technologie très récente et pour laquelle nous n’avions que peu d’expérience.
Après les phases d’analyses et de mise en place du projet, nous avons attaqué notre premier sprint de développement purement fonctionnel début mars, c’est-à-dire quand le confinement a débuté.
Début du projet et du confinement, l'état des lieux
Suite à l’annonce du confinement, nous avons été inévitablement contraints de passer en télétravail à 100%. À la fin de ce premier sprint inédit, nous avons pu faire l’état des lieux en rétrospective.
Bilan :
⁃ Nous arrivions a développer l’application en télétravail, les outils mis en place étaient opérationnels.
⁃ Les développeurs ressentaient une augmentation de leur concentration pour développer, ce qui les aidait à produire plus.
⁃ A contrario, nous étions tous d’accord sur le fait que nous avions perdu la communication dans l’équipe, ce qui était pourtant un de nos points forts auparavant.
⁃ Cette communication physique et verbale était perdue, et le management visuel ne nous permettait plus de nous projeter sur le sprint en cours et de prendre des décisions pour le mener à bien. En effet, nous disposions d’un Scrum board Azure (Microsoft), pratique sur bien des aspects (construction du backlog, liens avec Git, etc …). Nous avions aussi mis en place un Scrum Board physique qui nous permettait de centraliser toutes les informations importantes sur le sprint en cours. Ces indicateurs visuels ne pouvaient en revanche pas être dupliqués sur la plateforme en ligne.
⁃ Dû à ce manque de repères visuels, l’équipe de développement n’était pas entièrement autonome. Sans mon suivi régulier, elle avait également des difficultés à se projeter sur l’avancée des objectifs du sprint.
L’équipe avait l’impression de développer, beaucoup, mais tête baissée sans avoir un regard vers l’avenir.
Les contraintes fortes sur les délais pour produire l’application et le peu d’expérience de l’équipe en Flutter nous ont aussi amenés à devoir trouver des solutions pour que tous les développeurs montent en compétences rapidement. De plus, nous devions trouver un moyen de transmettre et de respecter des normes de développements communes.
La mise en place d'outils, ateliers, pratiques et leur amélioration continue
Le plus prioritaire et moins coûteux à mettre en place dans notre quotidien était la transformation des cérémonies du format physique au remote.
Ainsi j’ai pu tester le site EasyRetro qui permet de créer des rétrospectives en très peu de temps. Le site propose un template préexistant des ateliers les plus répandus (Start/Stop/Continue, Speed Boat, etc…). L’outil permet de créer des post-it et de les disposer en colonnes, de les liker et de les commenter. Ce site a pu nous dépanner pendant les premiers sprints, mais nous voulions un outil qui nous laisse plus de liberté sur le format. De plus, ce site permet uniquement de créer 3 boards avant de passer à la version payante.
L’équipe était habituée à devoir dessiner et manipuler des objets lors de nos rétrospectives physiques, je souhaitais donc trouver un outil permettant de retranscrire ce qui faisait le piment de celles-ci. J’ai testé le site Miro, qui propose la création de tableaux blancs, dans lequel nous pouvons inviter d’autres utilisateurs simultanément. Nous pouvons y créer des formes, des post-it, importer des images, dessiner, etc … Le terrain de jeu parfait !
C’est ainsi que j’ai pu adapter différentes rétrospectives assez originales de la version physique au format virtuel.
Un autre point important était d’assurer la qualité de développement de l’application. Pour que les développeurs montent en compétences, nous avons instauré le principe de pair pull request. Le principe est simple, la revue de code d’un développeur est faite par deux autres développeurs, dont un Tech Lead (notre équipe comptait 2 Tech Leads).
Les revues de codes permettaient ainsi de challenger 3 personnes autour de leur méthode de développement : le développeur et les 2 reviewers. En tant que développeur, cette étape m’a permis de m’interroger sur l’intérêt de différentes pratiques et de proposer également différentes solutions techniques. Le Tech Lead en profitait pour faire monter en compétences les 2 autres développeurs et identifiait le besoin de pousser plus loin ou non, le passage de connaissances au travers un atelier.
Cette étape de pair pull request nous a aussi montré un besoin de se retrouver collectivement autour du code. Nous avons instauré le Mob programming du vendredi matin. Le but était simple, les Tech Leads identifiaient un sujet sur lequel il était important que l’équipe se regroupe pour diffuser les bonnes pratiques, et s’accorder sur une seule méthode de développement sur certains sujets techniques. Le but étant l’amélioration continue de l’application et la qualité de celle-ci, l’équipe en profitait pour identifier les parties de code à retravailler si besoin.
La communication, retrouver la dynamique en remote
Un problème important évoqué lors de la première rétrospective fut la perte de communication entre les membres de l’équipe au quotidien.
Notre outil de communication était Teams (Microsoft), utilisé pour les chats, les visios et le calendrier pour les réunions. L’outil nous donnait beaucoup de possibilités pour communiquer facilement au sein d’une équipe, mais nous n’avions pas l’habitude de l’utiliser, car nous privilégions les échanges physiques.
Le premier essai pour ajouter de la communication et de la vision sur le sprint était un canal Teams permettant aux développeurs de partager ce qu’ils ont pu créer pendant la journée, et également d’échanger des informations utiles. Le but était pour chacun d’avoir un peu plus de vision au sein de l’équipe pendant le sprint et pas seulement à la fin de celui-ci.
Nous avons abandonné au bout de quelques semaines car nous n’avons pas senti d’amélioration majeure dans la vision, et cette pratique pouvait ressembler à un état des lieux quotidien qui faisait doublon avec le daily meeting. D’ailleurs, nos dailys étaient devenus très longs car beaucoup d’informations, habituellement échangées lors d’une conversation au bureau se retrouvaient dans cette réunion matinale.
Nous avons ensuite tenté un autre « rituel », le E-café.
Le principe était simple, nous avons défini une heure fixe à laquelle chaque jour ceux qui le désiraient se retrouvaient pour prendre une pause-café ensemble.
Cela a permis aux personnes de l’équipe d’avoir un contact visuel et verbal sans être en réunion, ce qui pouvait manquer en cette période de confinement.
Ce petit moment sympathique nous a aussi permis d’échanger sur nos problématiques du quotidien et astuces de développement de manière plus informelle. De plus, toutes les informations mineures mais essentielles au bon déroulement du quotidien, pouvaient également être échangés lors de ces E-cafés. Nos dailys ont ainsi repris un rythme normal. Ce petit rituel non obligatoire, mais utile autant pour le moral que pour véhiculer des informations est toujours maintenu aujourd’hui dans l’équipe.
Enfin, dernier point important, comment remplacer notre management visuel physique qui nous permettait d’obtenir une vision claire du sprint en cours en un seul coup d’œil ?
Nous avons recréé notre board physique avec ses éléments et indicateurs spécifiques en format virtuel avec Miro.
La peur était de passer trop de temps à recréer ce tableau chaque sprint, mais finalement cela a pris autant de temps à chaque fois, car il suffisait de copier le board sur chaque sprint et d’y ajouter les US. Cela fait maintenant plusieurs sprints que nous gardons ce principe et que nous faisons évoluer notre management visuel pour nous permettre d’avoir toutes les informations importantes à un seul endroit et mener à bien le sprint.
D’autres petits ajouts comme une version en ligne du Niko-Niko permettaient de reproduire les outils du quotidien que nous avions en physique.
Le bilan
Les essais de nouveaux ateliers, outils, habitudes nous ont permis de répondre aux problématiques de communication, de vision, et de monter en compétences techniques efficacement et rapidement. L’équipe a aussi pu retrouver une certaine autonomie grâce au management visuel mis en place.
Je pense que nous trouverons de plus en plus de moyens novateurs pour améliorer nos pratiques de travail à distance, et c’est pour cela qu’il faut toujours se remettre en question et tester !
H@cktivités Sur les mêmes thèmes
H@cktivité – Cartzzle
Comment nous utilisons le jeu de société Cartzzle pour parler de l'importance de la vision dans la gestion de projets
C'est parti >H@cktivité – KiKaVuKoi
KiKaVuKoi est un micro atelier / Icebreaker permettant de parler perspective et point de vue avec les équipes.
C'est parti >H@cktivité – Twin It
Découvrez l'utilisation du jeux de société Twin-It comme proposé par Edouard Perin et qui permet de mettre en évidence l'interêt des cycles courts.
C'est parti >