Guide Scrum | 35. Scrum Quotidien

Le Daily Scrum ne dure pas plus de quinze minutes et se tient toujours au même endroit et à la même heure pour réduire la complexité inutile. Il est fréquenté par tous les Développeurs travaillant ensemble sur le Produit et, éventuellement, le Scrum Master. Le principal objectif 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 du Daily Scrum
3. Problèmes avec le Daily Scrum et la méthode des 5W
4. Questions de soutien
5. 5 Pourquoi
6. Résumé

Introduction

Le Daily Scrum est l’Événement Scrum le plus court et le plus fréquent, un aperçu duquel peut être trouvé dans un article séparé. La tâche des Développeurs participant au Daily Scrum est de définir rapidement des objectifs de travail pour les 24 heures suivantes. De cette manière, chacun d’eux sait sur quoi les autres travaillent et comment ils avancent vers un objectif de Sprint commun.

La formule du Daily Scrum

Il n’existe pas de formule unique pour le Daily Scrum. Chaque Équipe de Développement élabore un format de réunion qui lui convient. Cependant, il existe un cadre général pour faciliter sa conduite.

Un Daily Scrum bien conduit devrait permettre à chaque participant de répondre à deux questions :

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

Cependant, les poser directement n’est pas une formule obligatoire. Ce sont des questions d’exemple qui définissent l’axe de la réunion. Le Daily Scrum vise à améliorer la communication au sein de l’Équipe de Développement, à prioriser les tâches et à réduire le risque de goulets d’étranglement.

Le Daily Scrum est un événement équivalent au Daily Standup dans d’autres méthodes Agile. Et il se déroule souvent de manière très similaire – bien que le Guide Scrum officiel n’exige pas que les Développeurs se tiennent debout pendant cet Événement court. 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 soient beaucoup pour discuter des tâches quotidiennes, la pratique montre que ce type de réunion est le meilleur 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 le progrès fluide de l’équipe par rapport aux résultats individuels.

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

Un des problèmes avec le Daily Scrum est que les Développeurs prolongent le temps de réunion. Si tel est le cas, il est judicieux d’introduire une politique de notation sur un tableau – qu’il soit physique ou virtuel – des problèmes problématiques qui ne sont pas centraux au Daily Scrum mais qui sont importants pour l’Équipe. De cette manière, il sera possible de revenir sur les problèmes qui ont été laissés à discuter lors des discussions informelles au cours de la journée. Et aussi, si nécessaire, lors de la Rétrospective de 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 alors 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 du travail menant à l’objectif de Sprint est très importante. Cependant, consacrer le Daily Scrum à des tâches déjà complétées ne favorise pas l’efficacité.

Questions de soutien

Si l’Équipe ne tire pas profit du Daily Scrum, le Scrum Master peut aider les Développeurs à identifier les problèmes en observant la réunion pour 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 Whys ou 5W par Sakichi Toyoda. Elle consiste à poser plusieurs questions “Pourquoi ?” à la suite. Cela permet de diagnostiquer la cause profonde du problème, et donc 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 se présenter comme suit :

1 x POURQUOI ?

Q : Pourquoi les Développeurs ne proposent-ils pas différentes façons de résoudre les problèmes qui se posent ?

A : Parce que le Développeur Harry est toujours le premier à proposer une solution.

2 x POURQUOI ?

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

A : Parce que personne d’autre ne parle.

3 x POURQUOI ?

Q : Pourquoi personne d’autre ne prend la parole ?

A : Parce que les autres Développeurs n’ont pas envie de chercher de meilleures solutions.

4 x POURQUOI ?

Q : Pourquoi les autres Développeurs n’ont-ils pas envie de chercher de meilleures solutions ?

A : Parce que trouver des solutions nécessite de la concentration et qu’il est plus facile de considérer que la solution de Harry est suffisante.

5 x POURQUOI ?

Q : Pourquoi ont-ils considéré que la solution de Harry était suffisante ?

A : 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 pensent à se mettre au travail.

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

Résumé

Le Daily Scrum est une partie clé du travail quotidien de l’Équipe de Développement. Cependant, chaque Équipe doit élaborer pour elle-même la formule optimale pour cette réunion. Un Daily Scrum bien conduit permet de définir en continu des sous-objectifs pour atteindre l’objectif de Sprint. Il permet également de diagnostiquer rapidement les problèmes de communication et d’améliorer la coopération entre les Développeurs.

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