This article is also available in English
Il existe un mauvais comportement, qui est souvent présent dans les équipes qui s’engagent dans un sprint avec trop de points —ou trop de stories. En effet, certains membres peuvent ressentir le besoin de devoir faire des heures supplémentaires pour atteindre l’engagement qu’ils ont pris dans les prévisions. Ils font de la shadow-velocity.
Qu’est-ce que la shadow-velocity ?
Shadow-velocity est un terme qui m’est venu en écrivant “Scrum : quel est le bon jour pour commencer un sprint ?“. Il décrit le fait qu’un (ou plusieurs) membre(s) d’une équipe accompli du travail non planifié pendant la semaine, le week-end ou même pendant ses vacances.
Pourquoi ça arrive et pourquoi ça doit s’arrêter ?
Les raisons pour ce travail supplémentaire vont de “je veux commencer/finir une story” à “je corrige vite-fais un bug sous le manteau”.
Quoi qu’il arrive, il existe toujours une bonne raison pour commencer.
Pour garder une vélocité plate
Pourquoi ? Pourquoi l’équipe voudrait-elle avoir la même vélocité que pour le sprint précédent ? Chaque sprint est différent. L’équipe ne travaille pas sur les mêmes tâches et elle a appris tant que chose depuis les derniers sprints, c’est un nouveau monde !
Personne ne demande à l’équipe de garder une vélocité constante de sprint en sprint. Pourtant, si quelqu’un le fait, dites-leur qu’un sprint est unique et demander une vélocité constante ne peut que pénaliser le produit.
Pour compenser une prévision incorrecte
Si les membres de l’équipe ressentent le besoin de compenser une prévision, c’est un problème qui doit être discuté avec toute l’équipe, dont le Product Owner et même pourquoi pas des parties prenantes. La rétrospective est un bon moment pour relever ce problème, mais ce n’est pas le seul moment.
Les prévisions doivent être ajustées dès que nécessaire. Ajouter ou retirer des story-points est permis et ne devrait pas être une punis.
En 2011, le Scrum Guide a remplacé le terme “engagement” par “prédiction” en ce qui concerne le travail sélectionné pour un sprint, et ce, pour une bonne raison.
Un Sprint Backlog est assez complexe pour que l’incertitude soit toujours présent, et le sens commun nous dit que nous ne pouvons pas promettre ce que nous ne sommes pas sûr d’être capable de livrer. Lorsque nous utilisons le mot “engagement”, nous pouvons facilement être biaisé devant cette façon de penser devoir-obligation-promesse.
D’un autre côté, l’alternative “prévision” choisie consiste à faire des hypothèses basées sur des informations et des preuves fiables. Ceci est beaucoup plus proche du fonctionnement d’une équipe Scrum expérimentée.
[ … ]
Il n’est pas inhabituel (ou déraisonnable, franchement) pour les gens du métier d’apprendre que l’équipe de développement s’est engagée à livrer une liste d’articles en souffrance et à la prendre au pied de la lettre.
On ne fait pas confiance à l’équipe #super-munchkin
Le « syndrome du superhero ».
Le seul capable de corriger tel problème, parce que …
… il/elle est le/la meilleur(e), vraiment.
… il/elle a tout l’historique de ce vieux-projet-de-dix-ans.
… il/elle ne pense pas que quelqu’un d’autre peut le faire aussi bien.
Choisissez une réponse, ou ajoutez la vôtre.
Il faut de bons flics pour se passer de Batman #tuer_les_supers_heros #Agile #Scrum
— Constantin Guay (@cog_g) December 23, 2017
Et ensuite quoi ? Personne ne sera capable de remplacer ce superhero. Le produit dépends complètement de cette personne. Que se passe-t-il si il/elle gagne au Loto un jour et décide de tout quitter sans attendre ?
Cette personne met en péril tout le travail de l’équipe. Il faut vraiment laisser tous les membres apprendre et rater, aimer —ou détester— le produit. C’est agir en équipe.
Il/elle à simplement, le temps
Parfois, l’équipe estime les stories avec une valeur trop élevée pour ce qu’elles sont réellement. Dans ce cas, lorsque les membres de l’équipe terminent le sprint plus tôt que prévu et disposent de temps libre, ils se peuvent se dire pourquoi ne pas corriger un bug de longue durée, un environnement ou ajouter une petite amélioration à une fonctionnalité ?
Une telle action n’ajouterait ou ne supprimerait pas vraiment de la vélocité, mais en ajuste une ou ajoute une nouvelle tâche pour combler le vide. Si ce travail passe inaperçu, c’est un manque de communication qui peut conduire à de futur problèmes.
Ajouter un post-it à ce sujet, parlez à l’équipe de ce que vous allez faire.
Vous avez un problème à régler
Le problème principal est toujours le même: nous, en tant qu’individus, devons répondre aux attentes de notre modèle – nos parents, puis notre mentor, puis notre patron. Et cela nous fait faire de mauvaises choses pour leur plaire.
La shadow-velocity passe inaperçu, utilise votre énergie et souvent le sentiment d’accomplissement est diminué comparé au travail officiel.
La communication pendant ce temps est défectueuse et peut mener à plus de problèmes dus aux changements se produisant sans que l’équipe sache.
Le travail supplémentaire se produit et devrait être visible
Comment un Scrum Master peut-il aider l’équipe à révéler et éviter la shadow-velocity ?
- Cherchez les commits fait en dehors des heures de travail ou pendant les vacances
- Essayer d’utiliser les filtres de votre outils de gestion de projet pour extraire une liste des tâches réalisées en dehors des heures
- Soyez attentif, spécifiquement pendant le Daily Scrum, que chaque membre de l’équipe est assigné à au moins une tâche
- Posez des questions. Demandez à la fin du sprint, qui a dû travailler sur des tâches non planifiées et, pourquoi.
N’hésitez pas à partager votre expérience de shadow-velocity et comment cela à impacté votre produit.