Depuis quelques semaines je vis une situation assez particulière au courant du Sprint. Plusieurs membres de l’équipe de développement prennent des journées par ci par la ce qui nuit a la capacité planifiée au Sprint planning. Comment vous gérez ce genre de situation ?
Est-ce que on est sensé ajuster la capacité de l’équipe au courant du Sprint ? Ceci revient à quasiment retirer des WI qui ont été planifiés et qui constituent des éléments de l’objectif du Sprint ce que je ne veux pas faire. Ceci nuit énorméement a l’ensemble des objectifs produit
Précision : je ne parle pas des exceptions de vie privée, mais je parle d’un minimum d’absence de 2 à 3 1/2 journée par semaine ce qui revient a presque 3 jours d’absence du Sprint d’un DEV seniors.
Comme ça j’ai 2 choses principalement qui me viennent à l’esprit
La première : cultiver l’esprit d’équipe et d’engagement. Se fixer un objectif, en équipe, par l’équipe, devrait aboutir à ce que les personnes veulent atteindre l’objectif, mais c’est pas si simple. Pour ça on peut revenir à la Pyramide de Lencioni :
Confiance : La base de la pyramide est la confiance mutuelle entre les membres de l’équipe. Cette confiance est construite grâce à des interactions honnêtes et ouvertes, la transparence et la vulnérabilité.
Conflits : Les conflits constructifs sont essentiels pour permettre à l’équipe d’examiner les idées, les opinions et les perspectives différentes. Les membres de l’équipe doivent être capables d’avoir des désaccords sains et productifs.
Engagement : Les membres de l’équipe doivent être pleinement engagés dans les objectifs de l’équipe et les résultats qu’elle souhaite atteindre.
Responsabilité : Les membres de l’équipe doivent être prêts à être tenus responsables de leurs actions et de leurs résultats.
Résultats : En fin de compte, l’équipe doit être capable de produire des résultats solides et cohérents.
=> chaque étape doit être atteinte avant de passer à la suivante, et l’engagement d’une équipe nécessite à minima confiance entre les membres et communication ouverte sans peur des conflits.
La seconde : Un objectif n’est pas une série de user-stories à réaliser, il y a en cours de sprint des affinages possibles voire nécessaires pour délester l’équipe de travaux non pas inutiles, mais superflus. Il faut se dire qu’à la fin du sprint j’aurai un incrément viable, pas forcément 100% identique à l’image que je m’étais fait au début du sprint, mais viable et répondant à une problématique définie
Salut, ces absences sont dû à des imprévus ? Théoriquement en planning on commence par parler des absences justement pour prévoir un objectif de sprint réalisable.
Je sens que la question provient de la perspective d’un.e PO, corrige moi si je me trompe. Du coup, ma réponse de Scrum Master serait : l’équipe se gère elle même pour atteindre l’objectif de sprint. Du coup, si elle est consciente des absences possibles dans le sprint, bah… Où est le problème ? Donc, ma question suivante serait: Pour l’instant, est-ce que cette situation à porté préjudice à l’atteinte des vos objectifs de sprints ?
ma réponse est oui, d’ou ma question. lors de la planification du Sprint nous prévoyons les absences de chaque membre de l’équipe. Absence ici ce sont : des congés prévus, des rdv familliale ou personnel, des formations …etc.
Tel que tu le décris, ça me fait davantage penser à un problème de personne bottleneck qu’un problème de workforce. Un dev absent 3/2j par semaine sur une équipe de 5 dev (je ne connais pas ton équipe mais c’est une bonne moyenne) ça ne fait que 6% de « perte » de workforce. Ca ne me parait pas assez significatif pour justifier un échec du sprint.
Par contre, un dev absent 3/2j et qui bloque les autres par son absence, c’est beaucoup plus dommageable.
Prenez-vous bien en compte les dépendance entre les taches lors de la planif ?
Pour l’impact . (je récupères les réponses précédentes)
Comment ?
Mais, à quoi sert donc la capacité ? (Qu’est-ce que la capacité ? la vélocité ?)
à se donner un ordre d’idée de ce qu’on peut raisonnablement envisager sprint planning suivant ?
Pour la parti « pourquoi ces absences ? »
La on est plus dans l’humain
J’ai envie de poser la question autrement :
Ces absences sont en fait des « impediments » au même titre que les meetings imprévus qui vous tombent dessus (opportunité de rencontre avec un client, un fournisseur, …), les incidents de production, les maladies, …
Comment sont gérés ces impédiments ?
Je pense qu’il faut gérer de manière séparée les effets et les causes de ces absences imprévues.
effets => impediments
absences => root cause
Motivation ? Pas d’esprit déquipe ? Pas de perception de l’impact ? Pas de chance ? …
Les absences sont gérées au moment du Sprint planning, la situation est que j’ai plusieurs DEV qui ont des absconses non prévu plus souvent ce qui nuit à l’objectif du Sprint. Ce dont je cherche à savoir en tant que PO si on devrait réajuster cette capacité au courant du Sprint ou pas.
Mon point ici ce n’est pas les raisons d’absence des DEVs ni de gérer l’humain mon adjectif c’est plus de mieux gérer le prochain Sprint.
Si des devs ont des absences non prévues, le mieux c’est d’aller voir le reste de l’équipe en tant que PO et de négocier pour revoir le Sprint Backlog et enlever des tâches qui n’ont pas de lien, ou qui ne sont pas des « must haves » pour l’objectif de sprint.
C’est aussi important de savoir, à ce moment-là, quels sont les objectifs de sprint de l’équipe. Si c’est « faire toutes les tâches » ou bien « finir ce périmètre fonctionnel exactement défini », ben… C’est sûr que ça diminue l’agilité de l’équipe Si par contre ce sont des objectifs de sprints qui ne prennent pas 100% de la capacité de l’équipe (ce que je conseille totalement), alors il ne devrait pas y avoir de problème à revoir le plan, le Sprint Backlog ?
Mais donc sur le sprint en cours, une fois qu’on connait l’objectif et qu’on a un backlog, et qu’on prend bien un item à la fois, la capacité n’est plus qu’une information pour le cas extrême de l’interruption de sprint. Revoir la capacité en cours de sprint pour autre chose ca me fait vraiment penser à faire du msproject sur la durée du sprint, vérifier qu’on sera dans les temps pour « livrer tout ce qu’on a promis »
Et pas livrer bien ce qu’on aura pu tant que ca rempli l’objectif de sprint.
Comme Moosh, je ne pense pas que l’on doive réestimer la « capacité » en cours de Sprint.
La capacité est une information qui peut être utile en Sprint Planning pour tenter de comparer l’appétit de l’équipe, la « taille » (temps, complexité,…) de ce qui est placé dans le Backlog du Sprint, et ce que l’équipe serait théoriquement en mesure de faire d’après ce qu’elle a réussi à accomplir sur les Sprints précédents.m, en tenant compte des différences (congés, on boarding exceptionnel des experts, nouvelles automatisation de tâches, …)
C’est l’équipe qui prend l’engagement, c’est elle qui sait, qui a l’expertise et doit a chaque fois qu’elle dispose de nouvelles informations (absence, travaux terminés plus rapidement que prévu, meeting, feedback client) se demander si elle doit changer son plan pour atteindre l’objectif du Sprint.
Changer de plan, cela peut être simplifier une interface (charger des donnes a la main plutôt que via un écran), supprimer ou ajouter des fonctions, revoir la solution technique, …
Si elle ne réussi pas à atteindre son objectif, il faudra en parler en Sprint Review et certainement inviter l’équipe a trouver comment mieux s’adapter en Rétrospective.
Elle pourrait se rendre compte qu’il existe des bottle neck et que des formations/passages de connaissances seraient utiles, ou que des tâches pourraient être automatisées, scriptées ou documentées pour être réalisé par d’autres membres de l’équipe, ou que ce qui est pris dans le Sprint Backlog est trop important au regard des aléas rencontrés par l’équipe.
En effet, si ces absences ‹ exceptionnelles › sont récurrentes, cela devient une difficulté « habituelle ». Il faut traiter, mais il faut aussi que l’équipe prenne en compte cette information pendant le Sprint Planning : « Il est raisonnable de penser que pendant ce Sprint il y aura des absences que l’on ne sait pas encore déterminer. Quel impact sur notre Sprint ? »
Si par contre ce sont des objectifs de sprints qui ne prennent pas 100% de la capacité de l’équipe (ce que je conseille totalement), alors il ne devrait pas y avoir de problème à revoir le plan, le Sprint Backlog ?