Testez le sprint de 1 jour ! Retour d’expérience
Essayez, votre équipe en ressortira grandie
J’ai récemment accompagné une équipe en leur faisant faire un sprint d’une journée. Mais pour quoi faire me direz-vous ? Pour leur apprendre à travailler ensemble, en même temps, sur la même chose, du début jusqu’à la fin :
- Faire la conception des éléments du backlog produit tous ensemble, et au dernier moment
- Travailler tous ensemble sur le même élément de backlog produit, en même temps
- Mettre en production en tant qu’effort collectif, notamment dans la partie non-régression manuelle
Au-delà de l’aspect humain des caractères de chacun, la difficulté réside surtout dans la diversité des compétences qui forment l’équipe : chacun a son expertise et se restreint naturellement aux tâches qui touchent à son champ d’expertise.
Voici mon retour d’expérience de cette journée.
La journée s’est conclue par un debrief, pendant lequel la plupart des apprentissages ont été relevés.
Spoiler: c’était génial !
Rappel de l’exercice
Après l’arrivée de tous les membres de l’équipe et le partage de viennoiseries, la journée commence par une session de questions-réponses et surtout en recadrant l’exercice. Pourquoi le faire ? D’où nous vient l’idée de faire des sprints de 1 jour ?
Choisir un sujet, un seul et unique. C’est la seule chose à faire aujourd’hui. Tout doit être fait : depuis l’idée, depuis les premiers éléments de conception, jusqu’à sa mise en production. Du début, du vrai début, jusqu’à la fin, la vraie fin.
Choix du sujet
Et c’est parti !
La journée démarre enfin réellement en définissant le sujet de la journée.
On creuse un peu dans le backlog pour essayer de trouver un bon candidat.
On finit par trouver notre bonheur, quelque chose de petit mais qui apporte quand même de la valeur à l’utilisateur.
On commence à échanger un peu autour du fonctionnel et on se rend compte qu’il y a en fait plus de choses à faire qu’initialement imaginé.
En tant qu’animateur je les enjoins à réduire leur périmètre au maximum pour effectivement réussir à tout faire dans la journée. Je rappelle également que le but est bien d’aller jusqu’au boût, c’est à dire mettre en production ou du moins être prêt à mettre en production. L’optimisme est de mise mais dans le doute on se range à mon avis. On découpe donc.
La journée se terminera à 17h pour laisser le temps de debriefer de l’exercice ensuite, et l’équipe visera 16h pour la fin des développements et laisser le temps à réussir à préparer complètement la release ensuite.
Conception
Sans transition, l’équipe s’embarque dans la conception de la nouvelle fonctionnalité. Quels sont les cas d’usage ? Quel fonctionnel mettre en place ? Quelle architecture ?
C’est d’abord là que la véritable magie de l’exercice opère. Le plus naturellement du monde, toute l’équipe reste ensemble pour “cadrer” la nouvelle fonctionnalité.
La salle est pleine d’énergie, les échanges fusent dans tous les sens.
Il n’y a aucun silo, tout le monde participe et conçoit ensemble la nouvelle fonctionnalité.
Et si on estimait ?
Avant de quitter la salle de réunion pour rejoindre leur open-space et passer au développement, l’équipe sort les jeux de Planning Poker pour estimer. Je leur demande pourquoi ils estiment. La réponse n’est pas très claire. Ca sent le Cargo Cult, l’habitude ancrée dans les moeurs qu’on pratique par réflexe, sans trop comprendre l’intérêt.
La conclusion de l’échange est que pour cette journée, estimer n’a pas trop d’intérêt. Je sens comme un soulagement dans la salle. Visiblement tout le monde est rôdé à l’exercice mais ce n’est pas pour autant qu’il est apprécié.
Temps passé
Au final, 20% du temps du sprint de la journée sera consacré à cette partie de conception en amont du développement. C’est un temps tout à fait raisonnable et normal, la différence est qu’habituellement ce temps est utilisé pour “préparer l’avenir” alors qu’aujourd’hui il est utilisé pour directement travailler.
Par ailleurs nous verrons en fin de journée que finalement 20% ce n’est peut-être pas encore assez. L’équipe aurait gagné à passer plus de temps encore afin :
- D’aller au bout de la définition du périmètre,
- D’être vraiment au clair de ce qui fait partie du sujet du jour et de ce qui n’en fait pas partie,
- Et de découper encore plus le périmètre.
Développement
L’équipe se met au travail. Il y a de l’effervescence. On voit des échanges entre développeurs front-end et back-end qui se synchronisent pour bien définir et utiliser les API. Le Product Owner est sollicité à plusieurs reprises pour éclaircir des détails du périmètre. Certains développeurs se mettent en pair-programming et en profitent même pour faire du TDD, ou Test-Driven Development.
Il se passe clairement quelque chose dans l’open-space.
L’erreur du stand-up
15h. La pression monte sérieusement. Le Product Owner est de plus en plus présent dans l’open-space. Tant et si bien que s’organise un stand-up pour faire le point sur la situation.
On ne détecte pas à ce stade que l’objectif est en péril. Cependant ce stand-up est plutôt subi par l’équipe, qui n’en est pas réellement l’instigateur, et certains ont le sentiment de perdre du temps, un temps précieux vu la situation.
Pourquoi a-t-on fait ce stand-up ? Pour les mauvaises raisons. Ce n’est pas réellement l’équipe de développement qui l’a sollicité mais les parties prenantes et le Product Owner, inquiets de savoir où ça en est et à la perspective de “rater” ce sprint d’un jour.
On peut noter que les schémas classiques de stress se reproduisent malgré l’enjeu dérisoire de la situation (seulement un jour de développement). L’exercice permet de les mettre en valeur et de les analyser sereinement.
La préparation de la release
La limite de 16h est allègrement dépassée et c’est le gros stress face à la fin du sprint à 17h. Quel est le coupable ? La machine et les scripts de build qui mettent beaucoup de temps à s’exécuter. “On ne la sollicite pas autant d’habitude, là on travaille tous en même temps” me dit-on.
En parallèle le plan de test manuel de non-régression est préparé. Fait unique, toute l’équipe sera mise à contribution pour le dérouler.
J’annonce qu’il ne reste que 10 minutes. Le stress est à son comble…
Fin du sprint
Il est 17h : c’est la fin du sprint. Le résultat est sans appel : on est toujours à attendre le déploiement en environnement de staging de la release, la phase de test n’a donc même pas pu être commencée. L’équipe enrage en se disant qu’ils étaient si près du but…
Sauf que certains membres de l’équipe annoncent avoir pris de l’avance en testant en local, et avoir trouvé au moins une régression. L’équipe était donc bien plus loin de l’objectif que ce qu’ils imaginaient !
Debrief et apprentissages
J’anime alors une rétrospective sur le pouce : qu’est-ce qui a empêché l’équipe de réussir à terminer le sujet de la journée, et surtout quels apprentissages en retire-t-on ?
- Lors du démarrage, le matin, tout le monde s’est naturellement mis à échanger ensemble pour définir le périmètre, définir les scénarios d’usage, parler architecture, etc. Tous ensemble, sans rentrer dans une logique de cadrage en amont.
- Pendant la journée certains développeurs ont fait du pair-programming et du TDD. Une première.
- L’outillage est visiblement à retravailler vu qu’en fin de journée ils ont eu droit à 30 min de délai à attendre l’exécution de leurs outils. On pourrait penser que c’est uniquement dû au cas particulier du sprint d’une journée et qu’en temps normal c’est secondaire. Mais peut-être que demain ils devront corriger en urgence un bug critique sur la production, et dans ce cas-là ces 30 minutes de délai seront un vrai problème…
- Il y a de la dette technique et l’exercice l’a bien mise en valeur. L’exercice a par ailleurs démontré en quoi cette dette ralentit l’équipe, tout en mettant en péril sa prédictibilité : le matin cela semblait facile de réussir à finir le sujet du jour dans les délais.
- Beaucoup d’échanges tourne autour de comment bien spécifier les comportements attendus. En particulier, faut-il gérer les cas d’erreur ou pas ? Faut-il l’intégrer dans la DoD (Definition of Done) ou bien l’expliciter dans les User Stories ? En conséquence il semblerait que les 20% de la journée passés le matin à préparer le sujet ne suffisent pas encore.
- Travailler en sprint d’1 jour n’est pas nécessairement plus lent ! Un rapide calcul comparé à la vélocité indique qu’on n’est pas si éloigné sur cette journée de la vélocité habituelle de l’équipe.
- La question de la gestion d’erreur tire une autre ficelle. Cette gestion d’erreur partait d’une problématique purement front-end, mais on finit par parler du back-end pour réussir à bien la gérer, l’uniformiser, et avoir des codes d’erreurs parlants et utiles. Au final, on se rend compte que c’est aussi une problématique qui embarque le back-end…
C’était définitivement une super expérience, un véritable team building ainsi qu’une mine d’or d’apprentissages.
- L’exercice met en valeur tous les problèmes de l’équipe. Il démontre qu’il n’est pas nécessaire de cadrer les sujets en amont pendant les sprints précédents. Enfin, travailler tous ensemble c’est bel et bien possible.
Je recommande vivement l’exercice !
Pour aller plus loin
John Cutler : pourquoi le sprint d’1 jour est une bonne idée
Ron Jeffries : il faut réduire la durée des sprints jusqu’à ce qu’on arrive à les finir avec succès
Que pensez-vous de cet article
J’apprécierais vraiment si vous pouviez me laisser un commentaire pour me dire ce que vous appréciez ou ce qui pourrait être amélioré dans cet article.
Et si vous avez aimé cet article, merci d’applaudir 👏 et de le partager !
À bientôt 😊