J'ai testé pour vous le sprint d'une semaine avec une équipe mono-équipier

Ce titre de billet fait un peu explorateur mais ça fait partie du métier de tenter quelques expérimentations. Nous venons de terminer une mission au format particulier, le budget était d'une trentaine de jours homme et lorsque nous avons réfléchi au dimensionnement de l'équipe et des sprints s'est dressé un dilemme.
D'un côté un nombre de sprints trop faible est problématique pour faire émerger les avantages de l'agilité et de l'autre une taille d'équipe trop petite empêche l'émulsion d'un groupe et la possibilité de varier les points de vue. Après quelques échanges nous avons opté pour la seconde option, c'est moi qui ai géré la mission et nous étions d'accords qu'être seul à gérer le client, produire et se remettre en cause n'allait pas faire trop car cela n'allait durer que 6 semaines.

Le format

Au démarrage du projet, il a fallu expliquer au client que l'équipe ne serait composée que d'une seule personne, ça ne l'a pas choqué mais j'ai choisi de toujours parler de l'équipe au lieu de dire "moi" afin de l'habituer aux principes et mécaniques de Scrum bien que nous n'étions que deux (lui et moi) à être impliqués. L'objectif était de ne pas le perdre si demain nous venions à retravailler ensemble sur une mission plus large ou s'il allait travailler avec d'autres prestataires employant les méthodes agiles. Passons donc en revue les rituels et le déroulé du projet pour voir les particularités d'être seul dans une équipe pendant des sprints d'une semaine.

Chez Happyculture nous travaillons pour nos clients seulement 4 jours par semaine, le déroulé d'un sprint est donc minuté, le lundi matin démarrage en douceur avec la démo puis la rétrospective. Ensuite nous enchaînons avec la sprint définition l'après-midi pour convenir du plan de bataille pour les 3 jours suivant. La semaine se poursuit avec les jours de développement.

Les particularités des rituels

Premier point particulier, lorsque vous êtes seul si vous voulez éviter les longs blancs embarrassants (ou non) avec votre client pendant que vous réfléchissez à la liste des taches et à la façon dont vous allez implémenter le projet (chose que vous feriez normalement à voix haute avec vos autres équipiers) vous décidez de zapper cette partie. Du moins c'est ce que j'ai fait.
Habituellement nous passons un peu de temps avec le product owner en fin de sprint pour passer en revue le backlog du produit. Cela permet d'aider à la priorisation si des dépendances techniques sont nécessaires et pour confirmer au product owner que les critères d'acceptation sont bons pour les stories éligibles pour le sprint qui s'annonce.
Pour ce projet j'ai volontairement gardé cette partie pour la sprint définition, l'exercice s'est résumé à prendre connaissance du backlog au début de la sprint définition et de passer les stories et critères d'acceptation en revue avec le client en posant les questions nécessaires lorsque cela s'impose. La liste des taches a disparu du projet, remplacée par plus de critères d'acceptation si nécessaire ou l'ajout de stories si le besoin doit être découpé. De cette façon les sprints définitions restent dynamiques puisque orientées vers l'échange.

Les jours suivants sont restés dédiés au développement, ponctués par les points quotidiens, pas de différence notoire sur ce point si ce n'est le problème classique de disponibilité du client pour tester les livraisons. La semaine de 4 jours a permis au client de garder un jour supplémentaire pour effectuer ses derniers tests et si des choses n'étaient pas validées le reste à faire était déversé dans le sprint suivant.

L'enchaînement des sprints

En début de semaine suivante avait lieu la démo et la rétrospective. Pour la démonstration, rien de bien original, votre client a connaissance de tout ce que vous lui montrez puisqu'il l'a testé quelques jours avant et à moins que votre dépôt ne se soit fait hacker, vous avez pris connaissance de toutes les fonctionnalités livrées puisque c'est vous qui les avez implémentées ! La rétrospective, elle, est un peu plus particulière lorsque vous n'êtes que deux. C'est sur ce point que j'ai ressenti le plus gros manque car le dynamisme et la vision croisée de plusieurs personnes sont très importants pour faire remonter les pistes les plus intéressantes. L'expérience permet de compenser pour aider à faire remonter des points et aiguiller les discussions avec le product owner mais l'exercice reste plus enrichissant lorsque vous êtes plus nombreux.

Les sprints s'enchaînent assez rapidement, une semaine passe en un claquement de doigts. Cela signifie que dès que vous passez plus de temps que prévu sur un point cela se ressent irrémédiablement sur votre vélocité. J'ai pris conscience de ce point très vite et me suis appuyé sur mes collègues pour éviter les ornières dès que je sentais poindre un sujet dans lequel ils pouvaient m'apporter quelque chose. Vous n'avez pas d'équipe sur le projet mais fort heureusement vous en avez une en dehors, servez-vous en.

Eté oblige, j'ai dû faire face à une difficulté supplémentaire au cours du projet : les congés. J'ai menti en disant que nous n'étions que deux, le rôle de product owner était en fait partagé par deux personnes afin de gérer la période d'intérim des vacances. La contrainte ayant été remontée dès le démarrage du projet nous avons choisi de doubler le poste pendant les sprints définition / démo et rétrospectives afin de transmettre l'historique. Cela a permis d'éviter d'avoir à former deux fois une personne aux principes de scrum et de répéter tout l'historique lors de débats à trancher. Cette précaution a porté ses fruits car lors de la bascule de product owner aucune perturbation ne s'est faite ressentir dans la fluidité de l'avancement.

6 semaines plus tard le projet s'est terminé, c'était un défi de taille compte tenu de la nature du client très habitué à des projets (très) très longs. Réussir à démarrer, produire et terminer un projet en six semaines a relevé de l'exploit à leurs yeux. Avec un peu de recul le format sprint d'une semaine / un seul équipier a plutôt bien fonctionné, comme vous pourrez le lire ailleurs Scrum apporte un cadre, il faut ensuite l'adapter à la situation (même si je vous l'accorde elle était extrême).
Ce projet aurait pu être réalisé en cycle en V car le périmètre était assez limité et adapté à ce format mais comme le projet devrait avoir une suite cela a permis de poser des bases pour l'avenir.
Je vous invite à expérimenter lorsque vous vous trouverez dans des cas particuliers, parfois cela fonctionnera, parfois non, dans tous les cas ce sera un bon prétexte pour apprendre et vous améliorer.