Scrum, temps passé en réunions et vélocité

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”?

les réunions dans Scrum

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 :

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!

Déployer une PKI: Pourquoi et comment (3ème partie)

Si vous n’avez pas lu les 2 premiers articles de la série, n’hésitez pas à faire un tour ici et ici. Sinon, vous savez déjà qu’un projet de déploiement de PKI n’est pas que technique. Bienvenue pour ce dernier article de la série “Déployer une PKI”. Aujourd’hui, nous allons parler des 2 dernières étapes d’un projet de déploiement: le paramétrage et l’audit.

certificat numérique
Continuer la lecture de « Déployer une PKI: Pourquoi et comment (3ème partie) »

Déployer une PKI: Pourquoi et comment (2ème partie)

Dans l’épisode précédent…

Dans le précédent article, nous avons vu que la PKI a rendu le chiffrement, la signature et l’authentification transparentes pour les utilisateurs. Elle permet la gestion et la protection de certificats numériques. Le tout en vue de protéger l’information dématérialisée (chiffrement, signature, authentification, etc).

pki puzzle

Nous avons aussi vu la première étape d’un projet de déploiement d’une Infrastructure de Gestion de Clés: L’analyse et la conception. Durant cette étape, on apporte la réponse aux questions liées aux usages de la PKI, à la documentation qui sera mise en place, aux coûts, sécurité, architecture etc.

Voyons maintenant l’étape suivante:

Continuer la lecture de « Déployer une PKI: Pourquoi et comment (2ème partie) »

Déployer une PKI: Pourquoi et comment (1ère partie)

Cet article est le premier d’une série visant à aider le lecteur en vue d’un projet de déploiement d’une Infrastructure à Clés Publiques (PKI)

PKI

Introduction et définitions

Depuis toujours il a été nécessaire de protéger des informations sensibles. Il peut s’agir d’informations confidentielles qui ne doivent être connues que par certaines personnes. Mais aussi il y a ce besoin de garantir la provenance et l’intégrité d’une information. Voici quelques exemples parmi tant d’autres : Données militaires, contrats d’affaires, actes authentiques (notaire, avocat)…

Continuer la lecture de « Déployer une PKI: Pourquoi et comment (1ère partie) »

L’utilité réelle de l’objectif de sprint et comment le mettre en œuvre

Dans cet article, nous allons aborder l’importance de l’objectif de sprint, ses liens avec les cérémonies Scrum, comment le définir et comment l’utiliser.

sprint goal archery target

Pizzapido…

Arthur est Product Owner de Pizzapido, une application qui permet de commander une pizza fraîchement cuite pour la retirer dans un automate. Avec son équipe ils terminent le sprint 14 qui met un gros focus sur la redéfinition de l’expérience utilisateur de création de compte. En effet, il s’est rendu compte que certains utilisateurs ne parviennent pas au bout du processus de création de compte et que cela fait donc une perte potentielle de commandes et donc de revenus. Il a donc inclus dans le sprint 14 plusieurs User Stories pour améliorer cette partie de Pizzapido.

Continuer la lecture de « L’utilité réelle de l’objectif de sprint et comment le mettre en œuvre »

Burndown chart Scrum: A quoi ressemble le votre?

Burndown chart Scrum

Pour les équipes Scrum, le Burndown chart (graphique) est un outil de mesure visuel qui montre le travail restant à faire par rapport au taux d’achèvement prévu. Son objectif est de permettre au projet d’être sur la bonne voie pour fournir l’incrément attendu à la fin du sprint.

Le taux de progression d’une équipe Scrum s’appelle “vélocité”. Il exprime la quantité de story points complétés par itération. Une règle pour calculer la vélocité est que seuls les stories « finies » à la fin du sprint sont comptés. On ne comptera donc pas les travaux partiellement terminés (par exemple: codage terminé mais test manquant).

Continuer la lecture de « Burndown chart Scrum: A quoi ressemble le votre? »