Remarque : le site a été traduit automatiquement. Passe à l'anglais pour une expérience de lecture optimale.

photo-1541960071727-c531398e7494

Scrum of Scrums – le développement optimal de l'équipe comme base pour la mise à l'échelle

Qu'est-ce que le développement d'équipe et Scrum of Scrums ont en commun ? Ils s'occupent de la croissance et de l'optimisation des équipes. La règle de base est la suivante : avant de développer des méthodes agiles, l'équipe doit être développée de manière optimale. Pour savoir quand une équipe est développée de manière optimale, consulte ici ou notre Article de blog. 

Qu'est-ce que Scrum of Scrums ?

Scrum of Scrums est une manière de faire évoluer Scrum sur de nombreuses équipes et, le cas échéant, sur des trains. D'autres méthodes sont par exemple SAFe, LeSS ou Nexus.

Mêlée de mêlées est particulièrement efficace lorsque tous les membres de l'équipe Scrum travaillent vers un objectif commun, se font confiance, se respectent et tirent dans le même sens. Pour cela, il faut d'abord développer l'équipe.

La phrase 

"Assez petit pour rester agile et assez grand pour accomplir des tâches importantes en un seul sprint". 

tu connais peut-être. Alors, quel est le bon moment pour changer d'échelle ? Quelle est la taille optimale d'une équipe et à quoi faut-il penser lors du développement d'une équipe ? Existe-t-il une recommandation de développement d'équipe pour cela ?

Avant d'aller plus loin, un petit rappel. Récemment, nous avons accueilli 11 experts agiles internationaux lors d'un webinaire – sur une question : comment faire évoluer correctement les méthodes agiles ?

Il en résulte ce fantastique enregistrement vidéo (en anglais) qui aborde par exemple les questions suivantes :

  • Faut-il plutôt commencer par le bas ou par le haut ?
  • Comment réussir à mettre les dirigeants d'accord sur une vision commune ?
  • Comment choisir le bon framework agile – et pourquoi ce n'est pas si important en fait ?

 Ma recommandation la plus chaleureuse : jette un coup d'œil ! C'est relativement long, mais chaque minute en vaut la peine.

Tout d'abord, l'histoire de Scrum of Scrums

Jeff Sutherland et Ken Schwaber étaient à la recherche d'une méthode qui permette de travailler de manière agile avec plusieurs équipes. L'important était que chacun ne travaille pas de son côté, mais que tous travaillent ensemble de manière coordonnée. C'était une étape importante dans le développement agile. Jeff Sutherland a écrit un livre à ce sujet. "Agile Can Scale : Inventer et réinventer SCRUM dans cinq entreprises"qui a été publié en 2001. 

Scrum of Scrums et l'évolutivité des méthodes agiles s'imposent de plus en plus depuis. Mais on peut dire que la pandémie COVID-19 a probablement donné le plus grand coup de pouce au développement agile –, du moins pour son application dans d'autres domaines que le développement de logiciels. En principe, les méthodes agiles peuvent toujours être utilisées lorsque les exigences et les technologies sont complexes. Les Matrice de Stacey Et ça Cadre Cynefin t'aident à te situer. Dans le Guide Scrum@Scale tu trouveras toutes les informations sur la mise à l'échelle.

Un conseil : tu ne devrais pas changer d'échelle tant que ton équipe individuelle ne travaille pas bien ensemble et ne fonctionne pas. Si tu as déjà des problèmes avec Scrum au niveau des équipes individuelles, tu ne devrais pas non plus passer à l'échelle. Ma recommandation pour le développement de l'équipe est la suivante : Développe d'abord l'équipe et traite ses problèmes avant de commencer la mise à l'échelle.

D'ailleurs, un petit conseil dans le contexte de la transformation agile : tu veux t'assurer que tu as actuellement les bonnes priorités dans ton agile La transformation ? 

Alors fais notre test de maturité pour ta transformation agile – ne prend que 3 minutes. Tu obtiens même un benchmark basé sur plus de trois cents autres participants*. Bouton 🙂

Commence dès maintenant : Évaluation de la maturité agile
Évaluation de la maturité agile

But de la mêlée des mêlées

Scrum of Scrum est la première extension logique de Scrum, lorsqu'il s'agit de passer de l'agilité de l'équipe à l'agilité de toute une entreprise. Une condition décisive pour la mise à l'échelle est la bonne composition de l'équipe. Il convient de répondre aux questions suivantes : 

  • Qui travaille dans quelle position dans l'équipe ?
  • Qui travaille avec qui ?
  • Qui s'harmonise particulièrement bien ensemble ?
  • Qui a quel rôle ?

Nous avons découvert que la clarté des rôles joue un rôle très important. By the way : si tu veux savoir avec quels leviers tu peux créer des innovations dans une équipe, regarde ce Vidéo à la vie. Les équipes ont aussi toujours besoin de suffisamment de temps et d'espace pour se développer. Ici, tu peux aussi regarder Tuckman's Modèle de phase pour le développement de l'équipe Je te conseille d'y jeter un coup d'œil : 

  1. Former (phase d'entrée et de découverte),
  2. Storming (phase de confrontation et de dispute)
  3. Norming (Phase de régulation et de convention)
  4. Performing (phase de travail et de performance).

Source : Le modèle de phase de Tuckman pour le développement de l'équipe

L'objectif est de coordonner des équipes plus petites, agiles et autonomes, entièrement axées sur les besoins et les souhaits des clients. Le thème de la Customer Centricity, tu peux le voir ici Tu peux aussi regarder en détail. C'est pourquoi tu devrais te rendre assez tôt dans les Parcours du client Entre dans la peau de ton client. Sois simplement ton client et commence à changer de perspective. Dans la pratique, les clients doivent malheureusement encore assez souvent s'adapter aux processus de l'entreprise qui travaille avec eux. Surtout dans les administrations publiques, mais aussi dans certaines grandes entreprises ou sociétés. Mais ce n'est pas l'idée de Scrum. 

 

La "croissance" n'est pas la "mise à l'échelle".

Dominic Price écrit dans "Désapprendre ces cinq erreurs te rendra plus innovant." sur les 5 fausses idées dont tu devrais te défaire pour devenir plus innovant.

  1. La "croissance" n'est pas la "mise à l'échelle".
  2. "Transformation" n'est pas synonyme d'"évolution".
  3. "Perturber" n'est pas synonyme de "perturber". 
  4. "Temps de présence" n'est pas synonyme d'"initiative". 
  5. Les "outputs" ne sont pas les "outcomes".

En résumé, l'efficacité c'est bien, l'effectivité c'est mieux. Veille toujours à l'efficacité.

Par expérience, nous pouvons dire que plus il y a de personnes travaillant sur le même problème, plus il est difficile de parvenir à une solution. Surtout s'il s'agit de membres d'équipe cross-fonctionnels et autonomes. La solution pour les équipes de plus en plus grandes est cependant la mise à l'échelle. Le Guide Scrum offre une base aux équipes et aux entreprises qui ont besoin de soutien dans ce domaine. Cependant, la mise à l'échelle de Scrum au-delà des équipes individuelles nécessite une autre approche. La technique Scrum of Scrums (Technique SoS).

 

Source : Professionnels RFC

 

Structure et déroulement de Scrum of Scrums

Scrum of Scrums Structure de l'équipe

La communication est essentielle dans le monde agile et la clé du succès. Plus l'équipe est grande, plus les voies de communication peuvent rapidement souffrir. Les informations arrivent mal ou pas du tout. La confiance au sein de l'équipe s'en trouve affectée à plus ou moins long terme, la proximité fait défaut et il devient plus difficile de poursuivre un objectif commun.

L'objectif est de faire évoluer l'équipe de manière à ce que tous les obstacles soient éliminés (Scrum Master) et qu'elle soit en mesure de fonctionner dans le cadre de l'équipe. Flow travaille. En théorie, une "équipe parfaite" avec des performances optimales se compose, selon les Recherches de Hackman et Vidmar de 4,6 personnes. Des équipes trop petites peuvent ne pas être suffisantes pour résoudre un problème. Dans le cas d'équipes trop grandes, les relations personnelles et l'agilité par rapport à la capacité d'action et aux intérêts du client en pâtissent.

Dans certains cas, cela nécessite une division de l'équipe. Mais attention, il y a des choses à prendre en compte ici. On intervient dans un système déjà établi. Les compétences entre les équipes doivent être réparties de manière équilibrée, les interfaces qui fonctionnent doivent être redéfinies et les tâches doivent être redistribuées ou redéfinies. Les dépendances inattendues et les nouveaux goulots d'étranglement peuvent ralentir le processus dans son ensemble. Ici aussi, il est important de communiquer ouvertement et d'accorder du temps et de l'espace à l'équipe. La patience et l'ajustement aux bons endroits sont également très importants.

La technique Scrum-of-Scrums nécessite une coordination lorsque plusieurs équipes sont formées. Le graphique suivant illustre une possibilité :

Un diagramme montre comment de nombreuses voies de communication peuvent nuire aux équipes Scrum évolutives.

Source : Atlassian

 

Autres rôles dans la mêlée des mêlées

Le Chief Product Owner : le Chief Product Owner est responsable de la vision globale du produit. Il priorise le backlog de produit et est l'interface et le porte-parole du client.

Le Scrum of Scrums Master : il contribue en permanence à une plus grande efficacité de Scrum of Scrums. Il se concentre sur les progrès et les obstacles qui sont visibles pour les autres équipes, habilite et soutient l'équipe dans l'accomplissement de ses tâches. Il va aussi Leader de service appelé

 

Réunion de la mêlée

Les membres de l'équipe désignent une personne qui participe à la réunion Scrum of Scrums au nom de l'équipe Scrum. Selon l'endroit où se trouve le point focal au sein du projet, l'équipe peut toujours désigner un autre représentant. En général, c'est celui qui est le plus proche du sujet qui est désigné. S'il s'agit de l'expérience utilisateur, il faut envoyer un représentant qui s'y connaît. Si l'accent est mis sur les tests, le représentant devrait être issu du domaine des tests. Dans certains cas, si l'équipe SOS devient trop petite, il peut être conseillé de faire participer deux représentants par équipe à la réunion. Souvent, le Scrum Master accompagne alors la personne désignée par l'équipe. Si le travail des réunions de la mêlée des mêlées est coordonné lors d'une réunion à un niveau supérieur, on appelle cela la réunion de la mêlée des mêlées.

Fréquence et timebox de la mêlée des réunions de la mêlée

L'équipe détermine la fréquence de la réunion Scrum of Scrum. Pour simplifier, on s'en tient aux directives du Daily, qui a lieu tous les jours et dure en général 15 minutes maximum..

Mais selon la taille et le nombre d'équipes, il s'agit très souvent de réunions plus longues, qui ne sont pas aussi fréquentes. Par exemple, 2 à 3 fois par semaine. Contrairement à la réunion quotidienne, les problèmes qui surviennent lors de la réunion de la mêlée sont si possible résolus directement ou au moins abordés. Les problèmes qui surviennent lors de cette réunion sont très importants et peuvent rapidement affecter plus de 100 personnes.

Agenda pour une réunion

Source : Unsplash

Un bon agenda pour une réunion Scrum of Scrums est l'agenda d'un Mêlées quotidiennes Très similaire. Comme la réunion Scrum of Scrums n'a pas lieu tous les jours dans la pratique et que chaque personne représente toute son équipe lors de la réunion, les réponses aux questions sont légèrement modifiées :

  • Qu'est-ce que ton équipe a fait depuis la dernière fois que nous nous sommes vus ?
  • Qu'est-ce que ton équipe aura fait avant la prochaine réunion ?
  • Y a-t-il des obstacles qui rendent le travail de l'équipe difficile ?
  • Est-ce que quelque chose que ton équipe fait pourrait gêner une autre équipe ?

La dernière question est très axée sur le processus et les effets possibles sur les autres équipes. Se pencher sur cette question peut être très utile. Elle envisage plusieurs scénarios à l'avance afin d'organiser une collaboration sans problème. Dans ce cas, la pensée en silo est pour ainsi dire dissoute. La réponse à la dernière question est particulièrement importante, car les connaissances doivent impérativement être transmises par les représentants à leurs propres équipes.

En plus de répondre aux questions, la réunion offre également le temps et l'espace pour discuter de tous les sujets, problèmes ou défis qui ont été soulevés auparavant et les aborder. La réunion permet de documenter les progrès et de créer une compréhension commune. Les solutions et les mesures sont consignées afin de pouvoir les suivre.

Pour rester à un niveau objectif et neutre lors de la réunion, les noms ne sont pas cités dans les discussions. De même, la longueur des sujets est clairement distinguée de l'importance des sujets. L'objectif est de former un regard objectif depuis le méta-niveau, tout en alternant les perspectives.

Conclusion

Scrum of Scrums est donc un bon moyen de passer à l'échelle si tu travailles déjà avec Scrum et que tu souhaites évoluer vers l'agilité d'entreprise. Si tu veux en savoir plus sur l'évaluation de la performance du Scrum Master, tu peux aussi regarder cet article là maintenant

Scrum of Scrums et SAFe – deux concepts différents

Scrum of Scrums, SAFe et LeSS sont tous des cadres différents pour la mise à l'échelle agile, avec des approches différentes pour la mise en œuvre du leadership et la construction d'une feuille de route. Si tu veux en savoir plus sur les autres concepts, je te conseille de lire nos articles de blog sur SAFe et LeSS à lire.

Partage cet article dans ton réseau

Tu as besoin de booster ton équipe ? Fais ce qui suit La rétrospective Spotify Health Check!

Première question Health : "😍 Nous aimons aller au travail et nous avons beaucoup de plaisir à travailler ensemble".

Envie d'en savoir plus ? Essaie dès maintenant notre outil rétro.

Articles qui pourraient vous intéresser

Echometer Bulletin d'information

Ne manque pas les mises à jour sur Echometer & reçois de l'inspiration pour travailler de manière agile