Le Scrum de Scrums peut être utilisé pour étendre le daily stand-up meeting quand plusieurs équipes sont impliquées. Son objectif est de supporter les équipes agile pour collaborer et se coordonner dans leur travail avec les autres équipes. De nombreux auteurs ont partagé leurs visions du scrum de scrums, grâce à leurs expériences de son utilisation.
Charles Bradley a écrit une publication sur La résurrection du si décrié scrum de scrums dans laquelle il décrit la façon dont le scrum de scrums peut aider les équipes qui travaillent ensemble sur un même produit à (re-)planifier et coordonner le travail de développement :
Je pense, et j'en ai fait l'expérience, qu'une approche centrée sur l'Equipe de Développement honore les principes de Scrum, honore les principes de la pratique du Daily Scrum au niveau de l'équipe, et résulte en plus de valeur délivrée plus tôt aux clients. D'après mon expérience, un vrai Scrum de Scrums, pour et par les Equipes de Développement, mène à une progression importante des capacités d'auto-organisation de celles-ci, dont les obstacles sont éliminés plus vite, les produits sont de meilleure qualité, et des produits de valeur supérieure sont délivrés plus tôt.
Dans sa publication, Charles regroupe les visions du scrum de scrums de Ken Schwaber, Mike Cohn, Craig Larman, Bas Vodde et Jesse Houwing. Sa conclusion est que le Scrum de Scrums devrait se concentrer à aider les membres de l'équipe de développement à se coordonner et collaborer de manière auto-organisée ; ça ne devrait pas devenir une réunion d'avancement des scrum masters.
Quand je coache des équipes Scrum, j'accorde beaucoup d'importance à honorer les principes fondamentaux de Scrum lorsqu'il s'étend. J'encourage les Scrum Masters, lorsqu'ils participent au Scrum de Scrums, à se tenir "hors du cerle" des membres de l'Equipe de Développement pendant que ceux-ci collaborent. Comme je crois à l'extension basée sur les principes, vous ne serez sûrement pas surpris que j'enseigne la même technique pour Scrum Masters lors des Daily Scrums individuels des Equipes de Développement. Je veux que les membres de l'Equipe de Développement soient habilités à véritablement s'auto-organiser dans leurs efforts de coordination et de collaboration. Oui, évidemment, j'apprends aux Scrum Masters à être des leadeurs-serviteurs et à faciliter autant que voulu ou nécessaire - mais je les encourage aussi à s'effacer à l'arrière-plan dès que l'Equipe de Développement peut tenir un Scrum de Scrums efficace par elle-même.
Dans l'article Modèles organisationnels efficaces de produit scrum - Partie 2, Robert Galen fournit aux entreprises de développement de produit à grande échelle une solution pour connecter le scrum de scrums de leurs équipes aux services de production. Il décrit trois niveaux auxquels la connection peut se faire :
Au plus bas niveau, il y a un Product Owner par équipe, qui dirige les efforts grâce à un Product Backlog qui s'aligne sur les compétences des équipes.
Au niveau du Scrum de Scrums, les Product Owners doivent collaborer. Souvent, il a un rôle de "Lead Product Owner", dans lequel un des Product Owners oriente la vision globale à travers les différents Backlogs.
Au niveau du Scrum de Scrums de Scrums, il y a typiquement un Chef ou un Super Product Owner, qui fait la liaison entre les roadmaps métier de plus haut niveau et les engagements de livraison des équipes qui les exécutent. Ils suivent et maintiennent généralement l'équilibre entre les engagements perçus et la véritable vélocité de leur(s) équipe(s) de livraison Scrum.
Etablir la liaison entre les équipes scrum et les product owners à plusieurs niveaux favorise l'adoption de l'agilité dans les entreprises à grande échelle :
L'essence de ce modèle est la transformation organisationnelle. Les services de production efficaces reconnectent leurs structures à la façon dont leurs équipes techniques délivrent à présent les produits. Au fil du temps, ils apprennent à composer, décomposer et recomposer les backlogs qui guident le travail de leurs équipes Scrum.
Giuseppe De Simone écrit à propos du Mythe du Scrum de Scrums et mentionne un mythe à propos de l'extension de l'agilité :
Quand vous étendez Scrum à plusieurs équipes, vous gérez les dépendances et la coordination entre les équipes grâce au Scrum de Scrums.
Il fait la liste des choses que les équipes scrum font qui devraient réduire la nécessité de coordination entre les équipes :
En fait, en Scrum, on gère les dépendances en les éliminant ou au moins en les minimisant. Cela se fait sur plusieurs dimensions et voici 5 éléments clés que vous ne pouvez pas rater :
Tout d'abord, les équipes de développement doivent être pluridisciplinaires, ce qui signifie qu'elles doivent contenir toutes les compétences nécessaires pour transformer un élément du product backlog en version du produit potentiellement livrable. En complément, on adopte une appropriation collective du code, où tout le monde est autorisé à toucher n'importe quelle ligne de code nécessaire pour délivrer une version du produit à la fin du sprint : dans le cas contraire, vous exposez votre équipe à beaucoup de dépendances extérieures.
Les éléments du backlog doivent prendre la forme d'une User Story de bout en bout, traversant le système à travers toutes ses couches depuis le front-end jusqu'au back-end pour produire une partie d'une fonction potentiellement livrable : un développement basé sur les composants engendre d'incroyables dépendances à la place.
Les User Stories doivent respecter le principe INVEST, dans lequel "I" fait référence à Indépendantes, pour que travailler dessus soit plus simple.
Dans une approche Scrum étendue, l'Equipe de Product Owners construit un Product Backlog unique pour fournir toutes les équipes de développement et s'assurer qu'elles sont aussi indépendantes que possible pour qu'elles puissent avancer vite sans avoir à beaucoup se coordonner.
Les équipes scrum font le planning ensemble pour que les dépendances résiduelles soient détectées le plus tôt possible.
En faisant faire cela aux équipes scrum, la nécessité et l'objectif de faire un scrum de scrums changent :
Ce n'est pas une réunion de Scrum Masters pour rapporter un avancement, mais la possibilité pour une personne qui a un problème de le signaler et de se faire aider et supporter rapidemment par les autres équipes.
[Le scrum de scrums] n'est pas conçu en tant que énième structure de coordination, mais plutôt comme une procédure de secours à adopter lorsqu'une équipe a mis ou est en train de mettre quelque chose sur le dos d'une autre équipe.
Dans la publication Scrum of Scrums - un thermomètre de communication, Morgan Ahlström partage une expérience d'utilisation du scrum de scrums. Le projet qu'il décrit consiste en sept équipes dans trois pays qui tiennent un scrum de scrums normal :
Tous les Scrum Masters et le chef de projet participent à une téléconférence trois fois par semaine, durant laquelle les Scrum Master donnent chacun leur tour le rapport d'avancement (!) et se plaignent des problèmes qu'ils ont recontrés. J'ai été approché par certains des Scrum Masters qui me demandaient si nous ne devrions pas tenir ces réunions moins fréquemment puisque "rien de nouveau n'est dit. Les mêmes problèmes sont remontés à chaque réunion".
Il est apparu que les équipes n'étaient pas capables de résoudre les problèmes entre les réunions. Morgan suggéra que les scrum masters commencent à écrire les problèmes et travaillent dessus au lieu de s'en plaindre pendant le scrum de scrums. Il procura aussi une opportunité aux scrum masters de se rencontrer en personne et d'apprendre à mieux se connaître :
Je me suis débrouillé pour obtenir les fonds nécessaires à faire venir tous les Scrum Masters sur l'un de nos sites et à tenir une rétrospective ainsi que d'autres ateliers. C'était une bonne journée qui permit aux gens d'apprendre à se connaître, mais ce n'est pas suffisant. Quand, à la fin de la journée, j'ai demandé si tout le monde dans la pièce avait enregistré le numéro des autres en favoris, la réponse effrayante fut que personne n'avait le numéro de portable de qui que ce soit dans son téléphone. Résoudre ce problème fut simple, le problème étant de les faire utiliser leurs téléphones.
Après cette journée ensemble, j'ai commencé à demander aux Scrum Masters d'appeler les autres quotidiennement. Qu'ils aient un problème dont discuter ou non, ils devaient au moins appeler de façon sociale pour savoir comment les autres allaient. Cela ne se fit pas immédiatement ; la plupart d'entre eux pensèrent qu'ils pouvaient s'en sortir sans appeler mais je continuais à leur poser des questions à ce sujet lors de nos tête-à-tête.
Morgan remarqua que les problèmes résolus étaient plus nombreux depuis que les scrum masters avaient établi des relations entre eux :
(...) de moins en moins de problèmes étaient remontés lors du Scrum de Scrums. A la place, les gens tenaient des discussions sociales et parlaient de problèmes au passé. (...) il y avait toujours une quantité importante de problèmes, mais ils étaient à présent résolus hors du Scrum de Scrums. Les équipes (ou au moins leurs Scrum Masters) avaient commencé à faire attention aux autres. Une équipe proposa même d'envoyer certains de ses développeurs dans un autre pays pour aider une des équipes là-bas avant que celle-ci ait trouvé le courage de demander une aide extérieure.
En l'espace d'un peu plus d'un mois, nous sommes passés de réunions qui ne nous aidaient pas du tout à coordonner la moindre question ou résoudre le moindre problème, à des réunions où il n'y avait ni question ni problème à coordonner. Cela me permit de réaliser que le Daily Stand-up et le Scrum de Scrums pourraient ne pas être une solution en eux-mêmes, mais plutôt des indicateurs de la qualité de la communication dans nos équipes - hors des réunions.
Utilisez-vous le scrum de scrums ? Comment cela aide-t-il vos équipes à se coordonner et à collaborer ?