Quel est le but du stand-up et sa durée dans les méthodologies agiles?
J'avais l'habitude de travailler dans une méthodologie cascade et maintenant je fais partie d'une équipe qui suit une méthodologie agile. Il semble qu'ils se trompent. Par exemple, nous avons des stand-ups qui durent plus de 25 minutes par jour, ce qui est vraiment ennuyeux. De plus, j'ai plus l'impression de justifier mon salaire à la direction qu'autre chose.
Ai-je tort de ressentir ça? Est-ce ainsi que les stand-ups sont généralement menés?
Pour Scrum, Ken Schwaber et Jeff Sutherland expliquer :
Scrum quotidien
Le Daily Scrum est un événement de 15 minutes encadré pour que l'équipe de développement synchronise les activités et crée un plan pour les prochaines 24 heures. Cela se fait en inspectant le travail depuis le dernier Daily Scrum et en prévoyant le travail qui pourrait être fait avant le prochain. Le Daily Scrum a lieu au même moment et au même endroit chaque jour pour réduire la complexité. Au cours de la réunion, les membres de l'équipe de développement expliquent:
Qu'est-ce que j'ai fait hier qui a aidé l'équipe de développement à atteindre l'objectif de sprint?
Que vais-je faire aujourd'hui pour aider l'équipe de développement à atteindre l'objectif de sprint?
Est-ce que je vois un obstacle qui m'empêche, moi ou l'équipe de développement, d'atteindre l'objectif de sprint?
L'équipe de développement utilise le Daily Scrum pour inspecter les progrès vers l'objectif de sprint et pour voir comment les progrès tendent vers l'achèvement du travail dans le carnet de sprint. Le Daily Scrum optimise la probabilité que l'équipe de développement atteigne l'objectif de sprint. Chaque jour, l'équipe de développement doit comprendre comment elle a l'intention de travailler ensemble en équipe auto-organisée pour atteindre l'objectif de sprint et créer l'incrément prévu d'ici la fin du sprint. L'équipe de développement ou les membres de l'équipe se réunissent souvent immédiatement après le Daily Scrum pour des discussions détaillées, ou pour adapter ou replanifier le reste du travail du Sprint.
Le Scrum Master s'assure que l'équipe de développement a la réunion, mais l'équipe de développement est responsable de la conduite du Daily Scrum. Le Scrum Master apprend à l'équipe de développement à maintenir le Daily Scrum dans le délai de 15 minutes.
Le Scrum Master applique la règle selon laquelle seuls les membres de l'équipe de développement participent au Daily Scrum.
Les Scrums quotidiens améliorent les communications, éliminent les autres réunions, identifient les obstacles au développement à supprimer, mettent en évidence et favorisent une prise de décision rapide et améliorent le niveau de connaissances de l'équipe de développement. Il s'agit d'une réunion clé pour inspecter et adapter.
D'autres méthodologies peuvent avoir des rituels différents et même différentes équipes Scrum peuvent optimiser la façon dont elles le font différemment. L'idée clé est de se réunir rapidement pour s'assurer que l'équipe est sur la bonne voie pour livrer. Il ne doit pas s'agir d'un rapport de gestion. C'est cependant l'une des idées agiles qui est plus facilement renversée.
TL; DR
Lorsqu'il est correctement exécuté au sein d'une équipe Scrum de taille appropriée, le stand-up quotidien ne devrait jamais prendre plus de 15 minutes environ. Si cela prend plus de temps, soit l'équipe est trop grande, soit vous avez un problème de processus.
Le but du stand-up
Le stand-up quotidien est une réunion d'engagement et de coordination pour toute l'équipe. Il est conçu pour s'assurer que toute l'équipe est au courant des obstacles, quelles histoires sont faites ou non, et quelles tâches sont prêtes à être retirées de la liste de tâches d'un membre de l'équipe dans celle de quelqu'un d'autre.
Il est important que le Scrum Master et le Product Owner soient des participants actifs dans le stand-up, mais si l'équipe ( rapporte à l'un d'eux, alors votre Scrum processus peut être bel et bien rompu. Une réponse connexe sur Project Management Stack Exchange a un liste en 10 points des "odeurs de projet" en bas, dont certains peuvent s'appliquer dans votre cas. Même s'ils ne s'appliquent pas, vous devriez certainement réévaluer l'efficacité de vos stand-ups lors de votre prochaine Sprint Retrospective.
Respectez le Time-Box
Bien que je n'aime pas les "trois questions" en tant que format concret précisément parce que elles ont tendance à conduire à des réunions qui ressemblent à une traction de statut, je m'en voudrais si Je n'ai pas souligné la description canonique de Mike Cohn de la Daily Scrum . La page dit, en partie:
En se concentrant sur ce que chaque personne a accompli hier et accomplira aujourd'hui, l'équipe acquiert une excellente compréhension de ce qui a été fait et de ce qui reste. La réunion Scrum quotidienne n'est pas une réunion de mise à jour du statut au cours de laquelle un patron recueille des informations sur les retards. Il s'agit plutôt d'une réunion au cours de laquelle les membres de l'équipe s'engagent les uns envers les autres.
Il y a beaucoup plus de détails et quelques exemples concrets sur cette page. Cependant, aux fins de votre question, il est explicitement déclaré que:
Les réunions quotidiennes de Scrum sont strictement limitées à 15 minutes. Cela maintient la discussion vive mais pertinente.
Le time-box est le fondement de Scrum. Bien que la plupart des boîtes de temps dans Scrum puissent être ajustées par l'équipe à la suite du cycle d'inspection et d'adaptation, il est considéré comme une mauvaise pratique d'étendre la longueur du stand-up. Si le principe de la boxe temporelle n'est pas respecté dans votre processus, c'est généralement une "odeur de projet" très odieuse.
Comme pour tous les processus Agile, le but est: "de ce que vous obtenez de la valeur".
Le standup quotidien est généralement un mécanisme permettant d'assurer la communication entre les membres de l'équipe de manière à faible impact, où tout le monde peut comprendre où se trouve l'équipe par rapport à l'ensemble actuel des tâches. Donc, un standup de 5 minutes où tout le monde dit "J'ai fait x hier et je vais y faire aujourd'hui" est très bien, tout comme 15 minutes où l'équipe décide entre eux sur quoi travailler ensuite et met à jour le tableau des tâches.
Cependant, il n'y en a pas besoin du tout, pas si vous communiquez ces choses d'une autre manière, par exemple en utilisant un système de notification sociale roulant, par exemple.
De même, si vous voulez que votre standup soit plus long et plus un rapport d'équipe, c'est bien aussi. Je le remets en question, mais je sais que certaines équipes préfèrent une approche plus dirigée au travail. Agile peut faire face à tous les types d'équipe après tout.
La vraie question que vous devriez vous poser est de savoir si vous en tirez de la valeur, et sinon - comment allez-vous la changer pour que vous en tiriez de la valeur. Faire le standup comme prescrit par un livre sacré de Scrum n'est PAS agile. Faire un standup qui signifie quelque chose pour votre équipe afin que vous puissiez tous mieux travailler ensemble est.
Ce que vous décrivez est une façon dont les "positions debout" peuvent échouer pour l'équipe.
Les meilleurs stand-ups sont courts car tout le monde comprend ce que font les autres, ils expliquent ce qu'ils ont accompli hier, ce qu'ils vont réaliser aujourd'hui et signalent tout ce qui peut/a pu affecter leur capacité à tenir leurs promesses. D'autres membres de l'équipe peuvent alors indiquer qu'ils peuvent aider à résoudre rapidement les obstacles les uns aux autres, mais que les solutions interviennent en dehors du stand up.
En bref, ils devraient être la colle qui lie l'équipe.
Cela ressemble plus à une mise à jour du statut, et vous êtes tenu responsable de la livraison/non de la livraison, mais l'équipe est dysfonctionnelle parce que l'équipe n'utilise pas les réunions debout pour se soutenir mutuellement pour livrer et supprimer les obstacles.
Dans les deux environnements que j'ai vus, cela a été causé par un maître de mêlée qui n'a pas délégué la responsabilité de s'assurer que l'équipe tient ses promesses d'itération. Dans un cas, cela a été particulièrement contre-productif et a généré une attitude us/them au sein de l'équipe.
Scrum concerne les équipes auto-organisées, où l'équipe s'organise pour résoudre rapidement les problèmes et respecter ses engagements