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

null

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.

Commentaires

Ludovic Jeudi 11 septembre 2014 - 18:04
Suite à un twit fait à @happyculteurs et qui m'a proposé de répondre directement sur ce billet, je reporte ici le message d'origine (twitter ) : On a trop peu de remonté de ce type, utiliser SCRUM sans équipe (officielle) peut sembler un non sens, mais pas là. Je rajouterais que SCRUM est vraiment très bien même pour un projet solo, mais il faut vraiment adapter la méthode, chose qui n'est pas évidente et demande parfois des ajustements en cours de route. Bref, avoir un retour sur ce cas est vraiment bienvenue, j'aimerais donc savoir si d'autres développeurs (peut être freelance) ont adaptés la méthode SCRUM et leur retour d'expérience. Félicitation en tout cas pour l'auteur du billet ! Ludovic.
En réponse à par Ludovic
Artusamak Jeudi 11 septembre 2014 - 19:42
Merci à toi. Tu t'es toi même retrouvé devant cette situation ? Si d'autres personnes se sont retrouvées dans cette position nous sommes curieux de savoir comment vous avez réagi. Multiplier les points de vue enrichis les échanges.
Ludovic Vendredi 12 septembre 2014 - 03:32
Hello Artusamak, Effectivement, j'ai été dans ce cas. Mais dire que j'ai exploité SCRUM est exagéré. J'ai repris les principes de cycles courts pour assurer des livraisons ou des éléments livrables de façon régulière, placé des réunions (ou point projet) à terme de ces cycles. Démontrer les livrables devant le client, j'ai pas eut besoin du fait qu'on fonctionnais en flux tendu, ce qui a la fâcheuse tendance d'alimenter un peut trop vite le backlog (on l'appelait pas comme ça) et qu'on doit nettoyer la liste avec le Client par moments. Pas de planning pocker non plus. Quand aux stories, j'ai adapté tout au long du projet la forme pour avoir a chaque fois un support d'échange cohérent avec la problématique ou fonctionnalité abordée. Si j'avais eut avec moi un Srum Master, je pense qu'il serait devenu fou au bout des deux premiers sprints. Mais bon, on a réussi a avancer comme ça, j'ai ajusté tout au long du projet et finalement, tout c'est bien passé. La plus grosse difficulté reste quand même de garder cette pratique quand on a les mains sur le code, des urgences à traiter en urgence des autres urgences et que là, sans équipe, il est difficile de conserver la cohérence et la continuité que Scrum propose. Au plaisir donc d'avoir des retours d'autres développeurs :)
hamon quentin Mercredi 10 mai 2017 - 17:17
Bonjour, J'ai lu l'article et cela m'a fasciné. Le détail des problèmes exposés dans l'article aide vraiment. Dans les jours qui vont arriver je vais commencer un projet ayant la même configuration que celui de l'article. Je ne sais pas si ce blog est encore visité mais je peux vous faire un retour d'expérience du projet. S'il y a d'autres conseils pour un projet agile scrum en 6 semaine je vous écoute :)
Artusamak Mercredi 10 mai 2017 - 17:32
Merci pour votre retour. Chaque projet a ses spécificités, s'il y a beaucoup de choses qui méritent d'être mentionnées, nous en ferons peut être un nouveau billet. ;)

Votre commentaire

Le contenu de ce champ sera maintenu privé et ne sera pas affiché publiquement.
Votre adresse servira à afficher un Gravatar et à vous notifier des réponses. Votre commentaire sera anonymisé si ce billet est dépublié pendant plus de 3 mois.

À propos de Julien

Gérant - Co-fondateur - Scrum master & Expert technique

Utilisateur de Drupal depuis 2008, j’ai fait mes armes comme développeur chez Commerce Guys puis me suis mis à encadrer les nouveaux arrivants avant de donner des formations, participer aux avant ventes et accompagner les équipes au passage à Scrum.

Je suis impliqué dans la communauté française de Drupal depuis 2009, j’ai été tour à tour président puis vice-président de l’association Drupal France et francophonie entre 2011 et 2013.