C’est fait. 2 semaines se sont écoulées et nous avons terminé notre premier Sprint Scrum avec mon équipe. Vendredi nous avons donc fait une Sprint Retrospective et ensuite une Sprint Review. Voici un premier retour sur expérience.
J’ai commencé pendant ces 2 semaines par mettre en place Scrum au sein de l’équipe que j’encadre. 3 développeurs et un stagiaire. Nous avons défini les différentes tâches il y a 2 semaines. Ensuite effectué les estimations pour appliquer Scrum. L’objectif du sprint était de sortir la fonctionnalité Kocktail pour un client à New-York ainsi que de mettre en place un système pour construire une suite de produit (plusieurs de nos produits ensemble) à la Microsof Office.
Notre Sprint backlog initial contenait aussi quelques éléments mal définis que l’équipe a refusés. Et ils ont bien fait. Au moment où je les avais ajoutés, ces demandes étaient « super-urgentes ». Finalement nous aurions été perturbés par ces tâches qui, d’un point de vue business, n’apportaient rien.
Pour les rôles j’ai joué le rôle de Product Owner. En allant voir les différentes équipes qui utilisent notre framework pour construire leurs produits, et avec les chefs de produits, je définis les demandes de corrections et d’améliorations, et nous nous accordons sur la priorité. Cela afin d’éviter que les développeurs des équipes tierces passent leur temps à venir nous voir ou nous téléphoner. De ce point de vue, j’ai déchargé l’équipe de répondre directement aux emails et aux sollicitations. L’idée est de ne pas les perturber pendant le travail… en théorie.
Avant de vous raconter ces 2 semaines, voici l’export Excel du Sprint Backlog terminé. Pour ceux qui ne connaissent pas, voici le principe : en début de Sprint, l’équipe s’engage à réaliser un certain nombre de points Scrum. Ici 85 pour l’équipe. Chaque matin nous effectuons une réunion debout de 3 mn devant un tableau. Je demande à chaque développeur : « Peux-tu raconter ce que tu as fait hier aux autres ? Que vas-tu faire aujourd’hui ? Est-ce que tu as tout ce qu’il te faut pour travailler aujourd’hui ? »
J’insiste pour que chacun parle aux autres et pas uniquement à moi. Cela force l’équipe à bien faire circuler l’information. A l’issu de ce tour rapide, nous mettons ensemble à jour le « reste à faire« . La courbe donne donc chaque jour la quantité estimée de travail à effectuer. Cela ne prend pas de temps car chaque personne ne donne une mise que sur la tâche qu’elle effectue.
Les premiers jours montrent que l’équipe part plus rapidement que la courbe théorique. En effet, les 3 premiers jours les tâches à effectuer sont les plus importantes, et c’est plus parce que l’équipe doit livrer quelque chose au client à New-York que parce qu’ils seraient allés plus vite. Le 6 ème jour, un de mes clients favoris sort du bois avec un bug important et urgent pour le coup. Nous sommes alors obligés de perturber le Sprint pour qu’un des développeurs travaille sur ce point. J’ai hésité entre ne pas le modéliser et l’ajouter. J’ai décidé d’ajouter au Sprint Backlog cette activité, et de demander à la personne de l’estimer. Forcément cela fausse la quantité de travail initial à faire… Mais d’un autre côté je me disais que nous pourrions ainsi voir l’impact de l’arrivée de cette demande urgente de ce client. Ensuite on constate que la courbe reprend la tendance, l’équipe terminant chacune des tâches petit à petit.
Durant le sprint par contre, rien n’interdit aux développeurs de modifier la quotation d’un élément. L’équipe le matin me disait que l’élément « Installation Weblogic – 12 points » coûtera plutôt « 16 points » car il faut prévoir l’installation d’une SUN, ce qui n’avait pas été fait. La première estimation était fausse, sans que ce ne soit de notre faute. Et ainsi de suite…
Enfin on voit qu’il reste 4 points à faire. En effet une des tâches ne s’est pas terminée car les intervenants extérieurs dont nous avions besoin pour le packaging n’étaient pas prêts. Elle est donc repoussée au sprint suivant.
Le bilan du Sprint pour le Scrum Master :
En tant que Scrum Master (et Project Leader) j’ai une vision quotidienne très claire de l’activité de l’équipe. Aucun micro-management nécessaire. Inutile d’utiliser Microsoft Project ou un diagramme de Gantt. A quoi bon perdre une heure chaque matin à jouer avec 3 cases grises sur Project ? Est-ce que cela sert ? Faire un suivi de projet avec du Gantt me semble complètement débile. Vous allez faire le tour de l’équipe et chacun vous dit ce qu’il a fait. Ensuite vous remplissez ce magnifique outil et finalement, au moment où votre diagramme est prêt il est déjà faux car l’équipe, elle, avance… Ok pour la gestion macro-projet. Par contre, débile pour suivre au quotidien l’activité d’un développeur.
Sinon durant le sprint, difficile pour moi de ne pas dire « toi tu peux prendre ce bug, et toi tu peux aider ce client sur ce point…« . L’équipe s’est partagé le travail, je ne les ai pas trop perturbés là-dessus. Cependant, lorsqu’un des membres de l’équipe termine une tâche et que le sprint backlog est vide, il faut que j’alimente une drop-zone sur notre tableau avec d’autres tâches non prévues. Ce que j’ai fait la deuxième semaine. Cela permet de laisser l’équipe s’auto-gérer. J’ai essayé de demander aux développeurs de s’aider mutuellement et de ne pas dépiler du tableau toutes les tâches, ce qu’ils ont fait.
Les limites de l’auto-gestion, surtout pour un framework comme le nôtre, c’est la gestion des incidents qui viennent de l’extérieur. Avec une durée de Sprint de 2 semaines, je pense couvrir et masquer à l’équipe une partie des bugs et des demandes classiques. Donc objectif rempli. Par contre, le souci c’est « faites-moi un patch ce soir sinon mon client se coupe un bras« . Et là c’est la vie, il faut gérer. La solution 1 : c’est un obstacle et le Scrum-Master se débrouille. Solution 2 : on arrête le Sprint et toute l’équipe se consacre à ce problème. Solution 3 : je sors un des joueurs de l’équipe, et il s’en charge. Un peu comme sur un terrain de foot. C’est la solution 3 qui me semble la moins violente pour le Sprint.
La Sprint Retrospective :
Le dernier jour d’un Sprint Scrum, le Product Owner, le Scrum Master et l’équipe se retrouvent pour faire la démo des éléments développés pendant les 2 semaines. Vendredi après-midi nous nous sommes donc installés dans une salle et avec un vidéo projecteur, nous avons passé en revue les items. Dans ma tête au départ, je me suis dit que cela allait être une perte de temps… Mais non !
Durant les présentations, chaque personne a expliqué et surtout répondu aux questions des autres sur son boulot. On a fait passer l’information bien plus efficacement que d’habitude. Nous avons même parlé pour une correction de bugs d’idées supplémentaires si la correction ne convenait pas…
Le plus heureux dans l’histoire c’est le stagiaire. Arrivé il y a 3 semaines, il a la chance de voir de A à Z le travail d’une équipe de développement, sans que nous soyons obligés de faire un gros tutorat comme l’an passé. Il nage un peu, mais je pense qu’il est super content de voir comment nous travaillons.
Donc ne surtout pas annuler la Sprint Retrospective. C’était un moment sympa.
La Sprint Review :
Ensuite sur un tableau blanc, je dessine 2 colonnes. Améliorations/Dégradations apportées par Scrum. Je fais un tour de table, c’est un peu le silence. Le premier point sur lequel nous discutions est la trop grande fréquence des stand-up meetings. L’équipe se demande si nous devons vraiment se voir chaque matin.
L’équipe n’est pas contre la réunion et son fonctionnement : elle prend 10mn avant le café de 10H, et ensuite on est tranquille pour la journée. C’est juste le fait de se réunir pour dire… quoi ?
N’ayant pas encore assez d’expériences, difficile pour moi de dire s’il faut modifier ou non. Cependant je reste convaincu qu’il faut maintenir ce rythme quotidien. Je retiens de la certification Scrum, que Jeff disait de ne pas changer les règles du jeu. Lorsque vous jouez au foot, vous n’allez pas arrêter de jouer à 60mn de jeu ou décider que le défenseur peut prendre la balle avec la main… Donc on reste sur l’idée d’un stand-up meeting chaque jour, et surtout de mettre à jour le backlog pour suivre l’évolution du projet. J’en reparlerai certainement dans quelques semaines.
Scrum on continue ?
J’ai posé la question. Tout d’abord nous travaillons depuis 2 ans en mode itératif, avec une release toutes les 3 semaines environ. Donc ce n’est pas une grosse révolution pour ma propre équipe. Nous nous sommes accordés pour dire que de toutes les façons, nous étions déjà dans un processus Agile.
L’équipe est ok pour continuer, moi je vais avoir encore plus de travail pour affiner mon processus et simplifier le travail de l’équipe. C’est aussi mon premier « sprint » et il faut être patient pour voir le retour. Là dessus tout le monde est d’accord.
Et les autres équipes ?
J’en ai discuté avec d’autres chef de projets… Scrum (ou scrumble comme m’a dit un collègue) est encore assez abstrait pour une grande partie des différents départements. J’ai une présentation de prévue en mai à un ensemble de chefs de projets, avec lesquels j’ai effectué une formation. Je vais pas présenter Scrum en mode « Convertissez-vous mes frères » mais plutôt en mode « Eh ! au fait si vous voulez tenter quelque chose…« . Un autre axe est d’arriver à en parler au top-management. C’est en bonne voie mais je marche sur des œufs.
Enfin voilà. Si vous êtes encore sur Word et Visio à essayer de décrire votre logiciel ou votre architecture, pensez que votre document ne va exprimer que 60% de vos idées, que 5 personnes au maximum seront capables de le lire et de le comprendre, 2 personnes seulement le liront en entier, et que le client final de toutes les façons n’aura rien compris. Donc vous me faîtes plaisir, vous arrêtez d’écrire du charabia et de l’UML et dès lundi vous rediscutez avec le client. Vous verrez qu’il a encore changé d’avis…
Bon week-end
0 no like
