Guide de mêlée | 35. Mêlée quotidienne

Le Daily Scrum ne dure pas plus de quinze minutes et se tient toujours au même endroit et au même moment pour réduire la complexité inutile. Il réunit tous les Développeurs travaillant ensemble sur le Produit et, éventuellement, le Scrum Master. L'objectif principal de cet événement Scrum est de planifier les tâches sur lesquelles ils se concentreront pour la journée.

Daily Scrum – table des matières :

1. Introduction
2. La formule Daily Scrum
3. Problèmes avec Daily Scrum et la méthode 5W
4. Questions complémentaires
5. 5 pourquoi
6. Sommaire

Introduction

Daily Scrum est le plus court et le plus fréquent des événements Scrum, dont un aperçu peut être trouvé dans un article séparé. La tâche des développeurs participant à Daily Scrum est de définir rapidement des objectifs de travail pour les prochaines 24 heures. De cette façon, chacun d'eux sait sur quoi les autres travaillent et comment ils travaillent vers un objectif de sprint commun.

La formule Daily Scrum

Il n'y a pas de bonne formule Daily Scrum. Chaque équipe de développement développe un format de réunion qui lui convient. Cependant, il existe un cadre général pour en faciliter la conduite.

Un Daily Scrum bien mené doit permettre à chaque participant de répondre à deux questions :

• Quelle est la tâche la plus importante que je vais effectuer aujourd'hui ?
• Quels sont les obstacles à l'accomplissement de cette tâche ?

Cependant, leur demander directement n'est pas une formule obligatoire. Ce sont des exemples de questions qui définissent l'axe de la rencontre. Daily Scrum vise à améliorer la communication au sein de l'équipe de développement, à hiérarchiser les tâches et à réduire le risque de goulots d'étranglement.

Le Daily Scrum est un événement équivalent au Daily Standup dans les autres méthodes Agiles. Et il fonctionne souvent de manière très similaire - bien que le guide Scrum officiel n'exige pas que les développeurs se tiennent debout pendant ce court événement. Très souvent, ses participants se tiennent simplement debout tout en parlant dans un groupe informel.

Bien qu'il puisse sembler que 15 minutes par jour, c'est beaucoup pour discuter des tâches quotidiennes, la pratique montre qu'une telle réunion est la meilleure pour l'efficacité de l'équipe de développement. Avec des mises à jour fréquentes et régulières sur les objectifs et les engagements, tous les développeurs se concentrent sur les tâches prioritaires et privilégient la progression fluide de l'équipe sur les résultats individuels.

Problèmes avec Daily Scrum et la méthode 5W

L'un des problèmes avec Daily Scrum est que les développeurs prolongent l'heure de la réunion. Si c'est le cas, c'est une bonne idée d'introduire une politique d'inscription sur un tableau - physique ou virtuel - des problèmes problématiques qui ne sont pas centraux pour le Daily Scrum mais qui sont importants pour l'équipe. De cette façon, il sera possible de revenir sur les problèmes qui restaient à discuter lors des discussions informelles de la journée. Et aussi, si besoin, lors de la Rétrospective Sprint, que nous décrirons plus en détail dans un article séparé.

Un autre problème qui se pose souvent lors des Daily Scrums est de les transformer en réunions pour résumer le travail de la veille. Les développeurs se concentrent ensuite sur la discussion des résultats déjà obtenus. Ce n'est pas une bonne pratique. Certes, l'orientation actuelle des Développeurs sur l'état des travaux menant au Sprint Goal est très importante. Cependant, consacrer le Daily Scrum à des tâches déjà terminées ne favorise pas l'efficacité.

Questions complémentaires

Si l'équipe ne bénéficie pas du Daily Scrum, le Scrum Master peut aider les développeurs à identifier les problèmes en observant la réunion pour obtenir des réponses aux questions suivantes :

5 pourquoi

Après l'identification initiale du problème, une technique efficace pour déterminer la cause du problème peut être la méthode des 5 Pourquoi également appelée 5 Pourquoi ou 5W par Sakichi Toyoda. Il s'agit de se demander plusieurs « Pourquoi ? » questions à la suite. Cela permet de diagnostiquer la cause profonde du problème, et ainsi de le résoudre plus facilement.

Par exemple, prenons le dernier élément du tableau : le problème se pose dans le domaine de l'engagement à résoudre les problèmes par l'équipe de développement. Les cinq questions pourraient ressembler à ceci :

1 fois POURQUOI ?

Q : Pourquoi les développeurs ne proposent-ils pas différentes manières de résoudre les problèmes qui surviennent ?

R : Parce que le développeur Harry est toujours le premier à proposer une solution.

2 fois POURQUOI ?

Q : Pourquoi le développeur Harry est-il toujours le premier à proposer une solution ?

R : Parce que personne d'autre ne parle.

3 fois POURQUOI ?

Q : Pourquoi personne d'autre ne parle ?

R : Parce que les autres développeurs n'ont aucune envie de chercher de meilleures solutions.

4 fois POURQUOI ?

Q : Pourquoi les autres développeurs n'ont-ils pas envie de rechercher de meilleures solutions ?

R : Parce que trouver des solutions nécessite de la concentration et qu'il est plus facile de considérer la solution de Harry comme suffisamment bonne.

5 fois POURQUOI ?

Q : Pourquoi ont-ils considéré la solution de Harry comme suffisamment bonne ?

R : Puisqu'ils ne sont pas récompensés pour avoir proposé des alternatives, ils ont discuté de leurs plans pour aujourd'hui au début de la réunion et réfléchissent à se lancer.

Dans ce cas, le problème du manque d'engagement à résoudre les problèmes peut être résolu en modifiant l'ordre du Daily Scrum et en commençant par ce problème. Ou imaginer un système de récompense de la meilleure solution, par exemple en introduisant une récompense symbolique pour l'auteur du plus grand nombre de solutions acceptées par la Team dans un Sprint donné.

Sommaire

Daily Scrum est un élément clé du travail quotidien de l'équipe de développement. Cependant, chaque équipe doit trouver par elle-même la formule optimale pour cette réunion. Une mêlée quotidienne bien menée permet la définition continue de sous-objectifs pour atteindre l'objectif du sprint. Il permet également de diagnostiquer rapidement les problèmes de communication et d'améliorer la coopération entre Développeurs.

Si vous aimez notre contenu, rejoignez notre communauté d'abeilles occupées sur Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Auteur : Caroline Becker

En tant que chef de projet, Caroline est experte dans la recherche de nouvelles méthodes pour concevoir les meilleurs flux de travail et optimiser les processus. Ses compétences organisationnelles et sa capacité à travailler sous la pression du temps font d'elle la meilleure personne pour concrétiser des projets complexes.

Afficher tous les articles

Guide de mêlée :

1. Glossaire des termes, rôles et notions de base
2. Qu'est-ce que Scrum ?
3. Valeurs Scrum
4. Comment implémenter Scrum dans votre entreprise ?
5. Scrum Team - qu'est-ce que c'est et comment ça marche ?
6. Qui est un Product Owner ?
7. Les erreurs les plus courantes du Product Owner
8. Qui est le Scrum Master ?
9. Caractéristiques d'un bon Scrum Master
10. Les erreurs les plus courantes du Scrum Master
11. Quelles statistiques et métriques le Scrum Master doit-il suivre ?
12. Coopération entre Product Owner et Scrum Master
13. Équipe de développement dans Scrum
14. Les erreurs les plus courantes des développeurs
15. Artefacts Scrum
16. Mise à l'échelle Scrum
17. Carnet de sprint
18. Qu'est-ce que le carnet de produit ?
19. Qu'est-ce qu'une User Story ?
20. Créer la meilleure User Story avec INVEST
21. Les erreurs les plus courantes de la User Story
22. Critères d'acceptation des user stories
23. Estimation et Story Points dans Scrum
24. Planification Poker
25. Jeu d'estimation d'équipe
26. Définition de l'incrément
27. Événements Scrum
28. Qu'est-ce que Sprint dans Scrum ?
29. Engagements de l'équipe Scrum - Objectif du produit, objectif du sprint et définition de l'achèvement
30. Qu'est-ce qu'un Burndown Chart ?
31. Comment créer et interpréter un burndown chart ?
32. Avantages et inconvénients du burndown chart
33. Tableaux Kanban dans Scrum et Scrumban
34. Velocity in Scrum - Vitesse de l'équipe de développement
35. Mêlée quotidienne
36. Planification des sprints
37. Revue de sprint
38. Qu'est-ce qu'une rétrospective Sprint ?
39. Erreurs courantes lors d'une rétrospective de sprint
40. Nourrir le backlog produit