Scrum tous les jours - Posez les 3 questions par développeur ou passez par des tickets?
Nous sommes une petite équipe d'environ 5 développeurs.
Nous utilisons un système de gestion des tickets qui a un Scrumboard virtuel.
Sur le Scrumboard se trouvent plusieurs colonnes. Les éléments des colonnes sont triés par priorité:
New | Consultation | Working | Waiting | Test & Review | Done
Consultation = Nous avons besoin de la rétroaction de quelqu'un de l'extérieur
En attente = Attendre quelqu'un ou quelque chose
Nous avons environ 40 à 50 tickets actifs tout en faisant un sprint de 2 semaines.
Dans un Scrum-daily standard, chaque développeur répond généralement à 3 questions:
Qu'ai-je fait hier?
Que vais-je faire aujourd'hui?
Quels sont mes obstacles?
D'une manière ou d'une autre, notre processus est différent:
On passe par colonne puis par chaque ticket dans la colonne.
Nous faisons cela pour plusieurs raisons:
- ce processus s'est développé tout seul, nous ne l'avons pas planifié, c'est juste arrivé
- certains développeurs «espaceraient» quand d'autres parlaient et n'écoutaient pas. Oui, il ne s'agit généralement que de 15 minutes par jour, on peut donc s'attendre à ce que l'écoute pendant cette période soit possible. Mais comme nous travaillons tous à domicile, nous ne pouvons pas remarquer si quelqu'un écoute ou non.
- lorsqu'un développeur a terminé ses 3 questions, il se peut qu'il n'écoute pas les autres, car son objectif est parti
- le développeur est visible sur le ticket, mais la recherche de votre propre nom afin de trouver les tickets sur lesquels vous travaillez prend un peu de temps. Il existe des moyens de changer de vue, mais la commutation constante de la vue devient assez vite ennuyeuse pour tout le monde
- si nous passons par un développeur, il oubliera parfois un ticket important lors de sa présentation
Passer par des colonnes puis des tickets semble plus "naturel", aussi tout le monde semble plus actif à l'écoute, puisque le prochain ticket peut être le sien. De plus, nous ne négligeons aucun détail ou billet important. La plupart du temps, les développeurs répondent indirectement aux 3 questions de cette façon, mais pas toujours. Ce processus semble encore quelque peu supérieur - du moins dans notre environnement!
Alors devriez-vous TOUJOURS passer par les 3 questions, ou devriez-vous opter pour les billets?
Ou y a-t-il un moyen de savoir quand quelle approche est «meilleure»?
(Peut-être que cette image pourrait aider à comprendre mes questions)
Réponses
Alors devriez-vous TOUJOURS passer par les 3 questions, ou devriez-vous opter pour les billets? Ou y a-t-il un moyen de savoir quand quelle approche est «meilleure»?
La version 2020 du Guide Scrum a supprimé les trois questions, tandis que la version 2017 du guide dit ceci:
La structure de la réunion est définie par l'équipe de développement et peut être menée de différentes manières si elle se concentre sur la progression vers l'objectif de sprint. Certaines équipes de développement utiliseront des questions, d'autres seront davantage axées sur la discussion.
Alors faites ce que vous pensez être le mieux ou demandez à votre équipe ce qu'elle préfère et trouve plus utile.
Les trois questions sont un exemple de la façon dont le quotidien peut être mené, car elles concentrent la discussion sur les choses de base que vous devez couvrir pour coordonner vos efforts vers l'objectif. Si vous trouvez que discuter des billets est une approche supérieure, allez-y.
Assurez-vous simplement de ne pas vous perdre dans trop de détails (vous pouvez toujours discuter plus en détail après le quotidien) et d'aller au-delà de la boîte de temps qui à son tour transformera les choses en réunion et donnera aux gens plus d'occasions de payer mentalement.
TL; DR
Devriez-vous parcourir le tableau par développeur ou par colonne? Ni. Les deux sont des anti-modèles.
Ne considérez pas le standup comme une extraction de statut de l'équipe et ne l'utilisez certainement pas comme un mini-examen du statut de chaque tâche planifiée pour l'ensemble du Sprint. Si vous gardez la portée du stand-up au travail de la journée en cours, la question de savoir comment "marcher sur la planche" (indice: il n'y en a pas, parce que vous ne devriez pas faire cela) disparaît.
Recentrer sur la coordination d' équipe
Votre question part d'une hypothèse fondamentalement erronée: la réalisation d'un rapport d'état sur tous les tickets est bénéfique voire souhaitable dans Scrum. C'est vraiment un problème X / Y dans la mesure où l'équipe manque tout l' intérêt du stand-up quotidien, qui est d'effectuer une planification et une coordination juste à temps pour les activités de la journée en cours.
Les "trois questions" ne sont qu'un moyen pour parvenir à une fin. Dans les équipes moins matures, avoir des lignes directrices ou des points de discussion peut aider les membres de l'équipe à identifier les dépendances entre les tâches. L'intention n'est cependant pas de fournir un rapport de situation. L'objectif est toujours d'aider l'équipe à planifier en collaboration le travail de la journée en cours. Par exemple:
Sandy: Hier, j'ai travaillé sur l'amélioration du widget central. Aujourd'hui, j'ai besoin de réduire le rouage primaire, mais j'ai besoin du whatchamacallit de Susan pour le faire.
Susan: Hier, j'ai terminé le whatchamacallit, donc c'est prêt pour Sandy. Aujourd'hui, je voulais travailler sur le frobnosticator, mais je suis bloqué jusqu'à ce que l'histoire de MacGuffin soit terminée. Quelqu'un travaille-t-il encore là-dessus?
En d'autres termes, n'utilisez pas le stand-up quotidien pour «marcher sur la planche». Utilisez-le pour permettre à l'équipe de s'auto-organiser autour du travail de la journée! Si les questions aident l'équipe à le faire, tant mieux. Sinon, jetez-les.
De même, seuls les travaux déjà en cours ou prévus pour la journée doivent être discutés au stand-up. Le travail dans le Sprint Backlog ou dans un état en attente n'est pertinent que s'il s'agit d'une dépendance d'une tâche en cours, d'un bloqueur pour quelque chose d'autre, ou si quelqu'un envisage de le récupérer comme travail en cours aujourd'hui .
Si vous voulez vraiment un statut Sprint, tirez parti de votre colonne Terminé et de votre graphe déroulant pour déterminer si vous êtes sur la bonne voie pour atteindre l'objectif de Sprint. Si le statut de l'objectif de sprint est en question, cela mérite probablement une réunion séparée en dehors du stand-up quotidien, et très certainement une certaine attention de toute l'équipe Scrum lors de votre prochaine rétrospective de sprint. Au mieux, marcher sur la planche est un palliatif pour dissimuler les communications inefficaces ou les radiateurs d'informations manquantes / invalides. Au pire, cela empêche activement l'équipe de collaborer sur la planification juste à temps en privilégiant les rapports d'état par rapport aux interactions entre les membres de l'équipe.
L'approche à trois questions est centrée sur l'individu, mais l'approche du conseil d'administration se concentre sur l'équipe et les objectifs du sprint. (Ou, du moins, le but sur le côté droit du tableau.) D'après mon expérience, un écueil des trois questions est lorsqu'un individu sent qu'il doit prouver qu'il a travaillé. Mais avec les billets, vous ne parlez peut-être même pas à tout le monde.
Comme je l'ai indiqué ci-dessus, ce qui est le mieux dépend de vos objectifs.
Si l'équipe est cohérente et que le tableau reflète le chemin menant au but, alors utilisez-le certainement. (Je suggère d'aller plus loin et d'utiliser le tableau explicitement de droite à gauche: mettre l'accent sur la fin des choses.)
Mais si l'équipe est nouvelle ou ne travaille pas encore bien ensemble, ou si le tableau ne représente pas vraiment l'objectif, alors les trois questions pourraient être un meilleur pari. Le but du sprint pourrait en fait être «faire geler cette nouvelle équipe» ou «intégrer Frankie pour qu'elle soit efficace». Si tel est le cas, vous voulez absolument vous assurer que tout le monde a la possibilité de parler de ce qu'il fait et de ce qui fonctionne et de ce qui ne fonctionne pas.
Ou y a-t-il un moyen de savoir quand quelle approche est «meilleure»?
Une chose avec le développement Agile est qu'il offre une flexibilité aux objectifs et à l'organisation du projet. Une chose que vous pouvez être flexible sur la façon dont vos quotidiens sont réalisés est de l'améliorer de manière itérative. Recueillez les commentaires de votre équipe, discutez de la structure quotidienne dans votre rétrospective de sprint et n'ayez pas peur d'expérimenter les suggestions de votre équipe.
Je travaille actuellement dans une équipe où nous avons en fait les deux approches - nous avons tous les deux un quotidien axé sur les tâches et un «trois questions» par jour. La première est de dix minutes par jour entre les développeurs pour discuter du tableau actuel et avoir de l'espace pour quelques observations techniques; le second est un quotidien de quinze minutes qui est beaucoup plus centré sur les «trois questions» dans une tentative d'avoir un quotidien plus humain avec l'équipe au sens large.
Nous avions un parcours quotidien des développeurs et de leurs tâches, mais nous avons décidé de mettre fin au processus pour les deux raisons que vous avez mentionnées concernant la concentration, les problèmes de temps et le manque de compréhension cohérente du statut des tâches associées. Et oui, filtrer constamment les tâches par développeur était également un problème pour nous.
Je ne peux pas faire de commentaire, alors j'ai ajouté mes deux cents en guise de réponse.
Si je peux suggérer: «les trois questions» pourraient être «regarder votre nombril», alors que vous voulez vraiment qu'elles «regardent autour de vous».
La première chose que je ferais est de trouver un moyen de regrouper votre liste de tâches d'une manière qui vous permette de considérer les tâches connexes ensemble d'une manière «utile pour l'entreprise». (Aussi, trouvez un moyen fonctionnel de "baliser" les tâches qui pourraient être liées à plus d'un groupe. Dans les logiciels, tout est généralement lié à tout le reste.)
Ensuite, je demanderais à l'équipe de considérer chaque groupe avec vous, et de vous aider tous à choisir (!) Ce qui - par consensus mutuel et éclairé - devrait être les «trois questions pour la journée» de l'équipe.
D'une part, les développeurs de logiciels ont appris à acquérir une capacité supérieure à se concentrer sur tout ce qui est le problème du jour. Pour ainsi dire, «ils savent exactement comment plonger profondément et rester en bas». Mais - en parlant d'expérience personnelle maintenant - il est horrible de réaliser, trop tard, que vous ne saviez pas que vous venez de plonger au mauvais endroit pour la mauvaise raison et que vous venez de vous faire prendre par un ouragan. "Vous aviez su ..."
Et donc, la question fondamentale est claire: puisque les développeurs sont - et doivent être - des «plongeurs profonds», qui sont toujours assis dans le bateau, toujours au sec, toujours à regarder la situation dans son ensemble? Vous surveillez les requins? Les aider à savoir, alors qu'ils pagayent en surface, où et pourquoi plonger ensuite? Ce serait toi.
Maintenant - pour compléter la réflexion - parfois ces plongeurs reviendront à la surface avec une nouvelle découverte importante que vous ne pouviez pas savoir. Laissez toujours les développeurs eux-mêmes apporter des «tickets» à votre mix.
Comme mentionné par d'autres, le Guide Scrum ne prescrit plus les 3 questions. Et, pour être honnête, la plupart des mêlées quotidiennes basées sur les 3 questions contredisent le but de l'événement. Lorsqu'il est orchestré par un Scrum Master et que les membres de l'équipe doivent rendre compte de leurs dernières 24 heures, c'est à 0% d'auto-organisation. Cela n'entraînera pas une véritable inspection de l'état du Sprint et la planification de la journée avec l'esprit d'atteindre avec succès l'objectif de Sprint. Il devrait s'agir d'une discussion interne de l'équipe de développement où les membres de l'équipe sont intéressés par leur propre succès.