Récemment, je discutais avec un client et il m’expliquait que depuis que l’équipe est passée à Scrum, le temps passé en réunions a augmenté et la vélocité a diminué. D’un autre côté, les équipes apprécient beaucoup le « backlog grooming » car cela leur permet de mieux comprendre le sens de leur travail ainsi que la vision du produit (à ce sujet n’hésitez pas à (re)lire l’article sur l’objectif de sprint).
Alors, doit-on s’inquiéter d’une perte de productivité lors d’un passage à Scrum? Passer à Scrum est-il forcément synonyme de « réunionite aigüe »?
Scrum et le temps passé en réunion
Penser que l’on passe trop de temps en réunion est une notion subjective. Or, il est facile de mesurer le temps qu’une équipe scrum devrait passer en réunions en théorie, alors pourquoi rester sur une impression? Pour un sprint de 1 mois ça donne:
- Sprint planning : 8h maxi
- Revue de sprint : 4h maxi
- Daily Scrum: 15mn maxi x20 jours = 5h
- Rétrospective: 3h maxi
- Backlog grooming: 10% de la capacité mais c’est peut être un peu trop. Disons 8h (2h/semaine).
Cela nous fait un total de 28h, soit 18.6% de la capacité. Il faut savoir qu’une moyenne de 20% du temps passé en réunions est courant en Scrum. Ces événements sont les seuls nécessaires pour que l’équipe soit en mesure de délivrer. Voici ce que vous pouvez faire pour optimiser cet aspect de votre activité:
- Mesurer le temps réellement passé en réunions (le Scrummaster peut se charger de consolider)
- Examiner en rétrospective les raisons possibles si cela prend plus de temps (laisser l’équipe s’améliorer). Ces événements sont limités dans le temps (time boxed), donc il est nécessaire d’aider l’équipe à respecter les durées maxi. Quelques raisons possibles de dépassement :
- On fait les réunions Scrum EN PLUS d’autres réunions traditionnelles (restes de waterfall, etc)
- Des personnes sont à cheval sur plusieurs équipes (et donc multiplient les réunions)
- Les réunions ne sont pas assez préparées à l’avance
- Une culture d’entreprise propice aux réunions
La vélocité de l’équipe Scrum
La vélocité est un outil qui permet de mesurer la capacité d’une équipe à délivrer de la valeur dans le temps. Il arrive qu’il serve d’outil de mesure de productivité destiné au management (à tord ou pas, là n’est pas la question), mais cela peut être trompeur.
Il n’est pas rare qu’elle varie dans le temps: augmentation durant les premiers sprints, puis stagnation, voire diminution si le cycle de développement du produit passe par des défis techniques, ou de la dette technique à résorber.
Evitez aussi de comparer la vélocité entre équipes. Comme c’est basé sur des estimations en story points, chaque équipe a ses références et la valeur d’un SP n’est pas la même d’une équipe à une autre. Que mesurer en plus de la vélocité pour avoir une vision globale? Quelques exemples :
- Le nombre d’interruptions/imprévus durant le sprint
- La dette technique
- Le nombre de bugs en cours
- L’aspect du burndown chart
- Le taux de couverture de code (tests unitaires)
- La satisfaction des équipes
Ces indicateurs vont permettre de voir si la baisse de vélocité se fait en gagnant sur d’autres points (qualité, motivation etc), ou si elle est due à ces mêmes points qui se sont dégradés. Là encore, si problème il y a, ce sera à l’équipe d’aborder le point en rétrospective et à trouver une solution. Si elle y parvient, elle fera un pas de géant en termes de maturité, de cohésion et de solidarité.
Pour régler un problème en rétrospective, je conseille généralement ces 4 étapes :
- Etat des lieux du problème (avec métriques)
- Lister toutes les options possibles pour améliorer la situation (au moins 3)
- En choisir une et la mettre en œuvre
- Evaluer le résultat et adapter
Et vous? Avez-vous l’impression que le passage à Scrum a dégradé certains indicateurs de performance? Vous avez l’impression d’enchaîner les réunions? Votre productivité semble avoir baissé? Comment avez-vous géré la situation? N’hésitez pas à partager vos commentaires!