En tant que Scrum Master, je remarque que Scrum se démocratise de plus en plus ce qui, de mon point de vue, est une bonne chose. Les entreprises font le constat que ce qui fonctionnait il y a 40 ans n’est plus applicable dans le monde d’aujourd’hui et qu’un changement est nécessaire.

Ces nouvelles mises en pratique de Scrum se basent parfois sur l’expérience de collègues ou sur des articles lus sur Internet. Je constate que peu de personnes prennent le temps de revenir à la source et lire le Scrum Guide, un fascicule de 13 pages qui comme son nom l’indique contient les règles du jeu de Scrum. Du coup, Scrum est appliqué sans forcément comprendre le but derrière certains événements ou certaines responsabilités de l’équipe Scrum (comme celle du Scrum Master de faire comprendre et respecter Scrum).

C’est dans ce contexte que j’ai imaginé l’écriture de cette série d’articles sur les événements Scrum. J’ai le désir ici de réexpliquer les fondamentaux autour des événements, de présenter les améliorations liées à la nouvelle version du Scrum Guide sorti en novembre 2020 et de dézinguer certains mythes autour de Scrum.

Voici donc le deuxième article de cette série sur le Daily Scrum.

(Voir l’article sur Comprendre le but d’un sprint planning)

But

Inspecter le progrès vis à vis du Sprint Goal et créer un plan pour les prochaines 24 heures.

Qui

Ce meeting est pour les Developers par les Developers.

Si le Product Owner et / ou le Scrum Master travaillent activement sur des éléments du Sprint Backlog, ils participent en tant que Developers

Planning

Chaque jour, 15 minutes maximum. Pour réduire la complexité, il est tenu à la même heure et au même lieu, chaque jour ouvré du Sprint

Pourquoi

  • Mettre en place l’autogestion
  • Les Developers sont responsables de produire un incrément fini
  • Inspecter le progrès vis à vis du Sprint Goal et adapter le Sprint Backlog
  • Maximiser la transparence
  • Améliorer la collaboration et la communication
  • Lever les obstacles
  • Les Developers sont les propriétaires du plan du sprint

Le Scrum Guide 2020

En novembre 2020, un nouveau Scrum Guide est sorti avec plusieurs améliorations.

Dans le cas du Daily Scrum, nous pouvons constater que la description de cet événement passe d’environ 30 lignes à 15 lignes, soit 2 fois moins de texte. Comment cela est-il possible ? Simplement en étant moins prescriptif. De manière globale, le Scrum Guide 2020 l’est moins. Il a été constaté que quand des exemples étaient donnés, ces exemples étaient pris comme des règles à appliquer, du coup, ils ont été supprimés.

Pour le Daily Scrum, il n’y a plus de mention sur les 3 questions à poser (qu’est-ce que vous avez fait hier, qu’est-ce que vous allez faire aujourd’hui, y a-t-il des blocages), qui étaient présentes dans la version 2017 comme exemple.

Il y a également deux autres changements plus subtiles.

Les responsabilités vs Les rôles

Le Scrum Guide 2020 parle à présent de trois responsabilités spécifiques (“accountability” en anglais) au sein de la Scrum Team, au lieu de parler de trois rôles. Les trois responsabilités sont les Developers, le Product Owner et le Scrum Master. Nous remarquons également le changement de vocabulaire entre la Development Team et les Developers.

Tous ces changements ont été faits pour ajouter plus de cohésion et d’entraide au sein de l’équipe Scrum. L’équipe Scrum est une seule entité, il n’y a plus l’équipe de développement contre le Product Owner par exemple, comme cela a  pu se ressentir dans certaines équipes Scrum.

De plus, en parlant de responsabilités, cela implique qu’une même personne pourrait avoir plusieurs responsabilités au sein de l’équipe si cela s’y prête. Soyons vigilants tout de même avec cette notion pour éviter de se retrouver avec la personne à tout faire qui n’aura peut-être pas le temps, ni les compétences pour tout faire bien. 

Dans le cadre du Daily Scrum, cela implique que toutes les personnes au sein de la Scrum Team qui ont une responsabilité de Developers sur le sprint participent à cet événement. Par exemple, Christine est Product Owner dans une équipe Scrum, elle a également convenu durant le sprint d’écrire de la documentation fonctionnelle nécessaire pour le Sprint Goal. Elle participe donc au Daily en tant que Developer (personne qui participe à la création du produit) et non pas en tant que Product Owner.

Dans cet exemple, cela n’empêche évidemment pas d’avoir des échanges avec Christine qui sont reliés à ses responsabilités en tant que Product Owner, cela peut être même très utile.

L’autogestion vs l’auto-organisation

Ce qui nous amène sur le terme de l’autogestion. Précédemment, le terme auto-organisation était utilisé, cela signifiait que l’équipe de développement pouvait choisir qui faisait le travail et comment le faire. C’est toujours le cas avec l’autogestion, mais en plus, l’équipe Scrum (au complet cette fois-ci) doit pouvoir choisir qui, comment et sur quoi travailler. Là aussi, nous augmentons la collaboration au sein de l’équipe, les frontières sont moins tranchées et l’équipe Scrum dans son ensemble doit être autogérée, elle peut s’organiser comme elle le désire, elle constitue une cellule qui devrait être autonome pour se gérer et gérer son travail.

Même si c’était déjà le cas précédemment, il y a donc une emphase sur cette autogestion. Lors du Daily Scrum, les Developers ne subissent pas ce qui a été prévu lors du Sprint Planning mais adaptent continuellement leur plan en vue d’atteindre le Sprint Goal en collaborant étroitement avec le Product Owner.

Mythes

Ce n’est pas un status meeting

Veuillez s’il vous plaît penser :

  • Responsabilisation
  • Transparence
  • Emancipation

Il ne s’agit pas d’un meeting pour le Product Owner.

Ce n’est pas un standup meeting

Il n’est pas écrit dans le Scrum Guide qu’il est obligatoire d’être debout durant le meeting.

Cependant, c’est une bonne manière de faire en sorte que le meeting reste dans la timebox de 15 minutes.

À ce propos, la durée de 15 minutes maximum est obligatoire… elle.

Il n’y a pas de format prédéfini

Comme mentionné plus haut, le format des trois questions n’est plus présent dans le Scrum Guide.

Aujourd’hui, il est écrit que vous pouvez utiliser n’importe quel format pour autant qu’il vous permette d’atteindre le but de cette réunion : inspecter le progrès du sprint vis à vis du Sprint Goal.

Par exemple, avec une équipe, nous parcourons tous les éléments du Sprint Backlog, colonne par colonne en commençant par la colonne qui est la plus proche du Terminé. De cette manière, nous focalisons notre énergie sur ce qui peut être terminé au plus vite et nous avons plus tendance à penser équipe et entraide, plutôt que de parler chacun à son tour sans s’écouter.

Conclusion

J’espère que cette remise en contexte du Daily Scrum vous permettra de mieux comprendre ce qui vient de Scrum et ce qui est une adaptation liée à votre contexte ou peut-être à une mauvaise compréhension du Scrum Guide.

J’aimerais cependant souligner ici que les adaptations ne sont pas forcément mauvaises. L’important est de faire ces changements en pleine conscience et de comprendre ce que cela apporterait de le faire “selon la théorie”.

Je vous donne rendez-vous prochainement pour la suite de cette série avec un article sur la Sprint Review. En attendant, vous pouvez consulter le 1er article de la série sur le Sprint Planning.

Sabrina Ferlisi

Scrum Master et Coach Agile à Pyxis Suisse.

En 2014, après un master d’ingénieur en informatique et des années dans le développement logiciel et la gestion de projet, Sabrina tombe dans la marmite de l’Agilité en tant que Scrum Master et découvre un nouveau monde. Depuis, elle est passionnée par tout ce qui touche aux interactions humaines, à la communication et à l’amélioration continue.

Énergique, intuitive et organisée, elle met son savoir-faire au service des équipes et des organisations en donnant à la fois un cadre et de la souplesse aux environnements complexes.

Sabrina est également Scrum Trainer, et donne les formations Professional Scrum Master (formation certifiante de scrum.org).

Billet précédent

Des jeux, de la passion et de l’agilité !

Billet suivant

#6 – Anne Bourrit – au delà de l'outil, la Communication NonViolente® comme Art de vivre.

1 Commentaire

  1. fchampoux@nuglif.com'
    17/11/2022 at 12:07 — Répondre

    Comment est-ce que les dev peuvent collaborer étroitement avec le PO lors du daily si le PO n’est pas au daily ?

Laissez un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.