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.
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.
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.
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.
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.
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.
https://twitter.com/cog_g/status/944687246782947329
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.
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.
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.
Comment un Scrum Master peut-il aider l’équipe à révéler et éviter la shadow-velocity ?
N’hésitez pas à partager votre expérience de shadow-velocity et comment cela à impacté votre produit.
Article publié à l’origine sur mon blog
