Le sprint vient de se terminer, les engagements pris par l’équipe ont été tenus et l’équipe est impatiente de redémarrer le nouveau sprint… Bref, tout c’est bien déroulé. Ca vous parait trop beau? Pourtant ces situations existent bien souvent au sein d’équipes Agiles.
Alors, vous allez faire comme d’habitude :
En tant que Scrum Master ,Je vais présenter avec l’équipe la revue de sprint au P.O,Afin de valider les users stories.
Puis…
En tant que Scrum Master,Je vais récolter les impressions de l’équipe durant la rétrospective,Afin d’améliorer l’équipe.
Et enfin…
En tant que Scrum Master,Je vais préparer le nouveau sprint avec le P.O durant une session de backlog grooming,Afin de pouvoir mener le planning poker dans de bonnes conditions.
Pourtant même si tout va bien, vous avez l’impression que des obstacles freinent votre vélocité.
Quelques effets de bord au bout de quelques sprints
- Vous accumulez de la dette technique sur certaines parties du code moins bien maitrisé.
- Vos livraisons sont globalement bonnes mais il vous arrive parfois de livrer de mauvais packages ou des fichiers non voulues.
- Vos différentes BDD sont maîtrisés dans l’ensemble mais malgré tout aucune synchronisation n’existe entre la base de test, la base local, la base de preprod…
- Vos outils de développement sont bons mais il serait peut-être bon d’introduire de nouveaux outils plus productifs, plus récents.
On en parle en rétrospective mais on n’a jamais de temps à consacrer à ces sujets d’ordre plus technique. 🙁
Alors comment faire pour pallier à ce genre de situations ?
Adoptez le lab’day en fin de sprint !! 🙂
Mais qu’est ce qu’un lab day me direz-vous ? Eh bien, il s’agit de glisser une demie journée voir une journée entre deux sprints afin de relâcher un peu l’équipe, laisser souffler les développeurs et surtout proposer d’améliorer certains points techniques qui posent problème ou encore étudier de nouveaux outils ou process (veille technique).
Ainsi durant les sprints, si vous vous rendez compte d’un point d’attention qui pourrait faire l’objet d’une étude technique (veille sur un outil de synchronisation de base de données, ajout d’un framework de test BDD, beHat par exemple 😉 ), ou encore tout simplement de la refactorisation, des revues de code qui pourraient aider certains développeurs débutants à monter en compétence et résorber par la même occasion de la dette technique…
Pour ne pas oublier ces idées survenues durant le sprint, il vous suffit d’afficher sur le radiateur d’informations une nouvelle « petite » partie qui contiendra l’ensemble des sujets qui pourront être traités durant les futurs lab days! 😉
Bon et ca fonctionne ton histoire de journée laboratoire?
Pour l’avoir mis en place dans différents projets, je peux vous assurer que c’est super motivant pour l’équipe qui n’attends que ca de démarrer les lab days !! Ils sont content de disposer d’un peu de temps pour lever la tête, sans avoir le scrum master qui les stresse pour finir dans les temps les users stories…
De plus, il n’y a pas que mes projets qui ont bénéficié de cette pratique, Google utilise un principe assez proche qui vise à développer la créativité de ses employés et à pousser les initiatives de projets personnels en fin d’itération.
Si vous aussi vous utilisez ce type de pratique, n’hésitez pas à me donner votre point de vue là dessus en commentaire, j’aimerais avoir un retour d’expérience d’autres Scrum masters, développeurs, voir même de P.O !
A bientôt sur le blog ou sur twitter (@_adesousa)
0 Commentaire