Les événemts Scrum de Scrums : Scrum of Scrums (SoS) Events

Scaled Daily Scrum

Puisque SoS se veut offrir des réponses en temps réel, aux obstacles qui sont soulevés par les équipes participantes, au moins un représentant (généralement le Scrum Master ou toute autre personne capable de bien comprendre ou qui comprend bien l’obstacle auquel font face les équipes) de chacune des équipes participant doit assister au Scaled Daily Scrum (SDS). Le daily Scrum à l’échelle est à l’image du Daily Scrum en ce qu’il optimise la collaboration et les performances du réseau des équipes. Chaque personne ou groupe de personnes des équipes participantes doit participer selon le besoin. En plus, le SDS :

  • Est limité dans le temps (time boxé) à 15 minutes ou moins
  • Au moins un membre de chaque équipe (y compris de la Product Owner Team) doit être présent.
  • Est un forum ou les représentants des équipes discutent de ce qui fonctionne bien, ce qui est fait, et comment les équipes peuvent travailler ensemble plus efficacement.

Quelques exemples de ce qui peut y être discuté :

  • Quels sont les obstacles auxquels font face mon équipe et qui l’empêche d’accomplir son objectif de sprint (Sprint Goal) (ou qui impactent la livraison à venir) ?
  • Est-ce que mon équipe fait quelque chose qui pourrait empêcher une autre équipe d’atteindre son objectif de sprint (ou impacter la livraison à venir) ?
  • Avons-nous découvert une nouvelle dépendance entre les équipes ou découvert une façon de remédier à une dépendance existante ?
  • Quelles améliorations avons-nous découvert qui pourraient être exploitées au travers des équipes ?

Gérer les obstacles au sein d’un SoS

Le SoSM doit faciliter le raffinement d’un backlog d’obstacle dans lequel les obstacles sont identifiés comme prêts « ready » et priorisés pour être enlevés (comprenez gérés). Les équipes déterminent ensuite comment les enlevées au mieux et comment elles sauront quand ils seront traités « done ». Dans certains cas, la résolution peut requérir des développements (product development), dans ces cas-là, l’engagement du SoS CPO et de la Product Owner Team sera nécessaire.

Une attention particulière doit être portée à la rétrospective du SoS (SoS Retrospective) dans laquelle les représentants des équipes partagent toutes les leçons apprises ou les améliorations au processus qu’elles ont appliquées avec succès au sein de leurs équipes individuelles, ceci dans le but de partager les meilleures pratiques au travers des équipes au sein su SoS.

Notes personnelles

  1. La forme originale du paragraphe sur le Scaled daily Scrum dit : « the SoS needs to be … » comme une reconnaissance que Scrum à l’échelle, tout comme Scrum d’ailleurs, tendent, veulent, aspirent … à quelque chose de meilleur, à de meilleures pratiques, à un meilleur résultat. Cette forme d’expression récurrente dans les documents des pères de Scrum traduit selon moi l’humilité de Scrum, des fondateurs et une humilité que doivent partager tous les pratiquants de Scrum.
  2. On voit bien l’approche holistique : faire mieux, non pas par simple addition mais par la force du réseau.
  3. Ceci suppose que tous les membres de toutes les équipes faisant parties du SoS, n’ont pas à participer au SDS absolument, mais seulement selon le besoin.
  4. Le bloc SOS Events ne cite pas clairement les événements « naturels » de S@S. Naturels parce qu’ils doivent être entendus hérités par défaut de Scrum dont S@S n’est que la mise à l’échelle. Particulièrement, on pourrait s’attendre pour plus de clarté à un énoncé clair mais succinct (nous comprenons qu’on reste ici dans l’esprit d’un guide léger comme le cadre de travail qu’il est sensé exposé) de la SoS Retrospective et de la SoS review meeting.
The following two tabs change content below.
Romuald Franck - MSc, Scrum Master
Avec plusieurs années d'expériences en développement logiciel et formation, Romuald maîtrise plusieurs technologies et langages de programmation. pluri-certifié, Il travaille depuis à l'amélioration des produits délivrés ainsi que l'état d'esprit des parties prenantes autour des projets. Méthode 3R : Right Product, Done Right and Managed Right.
Romuald Franck - MSc, Scrum Master

Romuald Franck - MSc, Scrum Master

Avec plusieurs années d'expériences en développement logiciel et formation, Romuald maîtrise plusieurs technologies et langages de programmation. pluri-certifié, Il travaille depuis à l'amélioration des produits délivrés ainsi que l'état d'esprit des parties prenantes autour des projets. Méthode 3R : Right Product, Done Right and Managed Right.

Laisser un commentaire

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