Scrum de Scrums v2
Auteur : Cesario Ramos (@cesarioramos)
Source : Scrum of Scrums (Published Patterns)
Ancienne version : Scrum de Scrums v1
Traduction :
... L'Equipe Scrum travaillant sur un unique produit s'agrandit et a besoin de se scinder en plusieurs équipes. Les Equipes de Développement doivent maintenant suivre les progrès des différentes parties du produit, maîtriser les dépendances et les problèmes d'alignement. Les questions qui ne peuvent être résolues au sein des équipes individuelles deviennent un défi partagé par toutes les équipes.
✥ ✥ ✥
Lorsque plusieurs Equipes Scrum ont besoin de travailler ensemble pour créer un incrément produit potentiellement déployable, la coordination inter-équipes nécessite une grande attention.
Plusieurs Equipes Scrum travaillant sur le même produit doivent coordonner leur travail et résoudre les problèmes de dépendance inter-équipes. Mais vous pouvez rarement connaître à l'avance toutes les dépendances et savoir comment les résoudre. Même avec une planification à l'avance, au cours du Sprint, des dépendances imprévues peuvent émerger et nécessiter d'être traitées par les équipes.
Dans l'idéal, une Equipe de Développement devrait être en mesure de développer complètement et indépendamment un Item du Backlog Produit (PBI). Dans ce cas, vous vous inquiétez uniquement de l'intégration de multiples PBI indépendants pour faire un seul produit. Dans certains cas cependant, il n'est pas possible ou pas souhaitable pour une seule équipe de développer un PBI et nous nous retrouvons avec des PBIs qui couvrent plusieurs Equipes de Développement. Une collaboration et synchronisation fréquentes permettent à l'Equipe de Développement de produire un Incrément Produit Périodique à chaque Sprint. Chaque Equipe de Développement développe indépendamment de son côté, mais toutes les Equipes de Développement doivent produire un tout intégré.
Aucune équipe ne devrait être seule responsable de l'intégration du travail des différentes Equipes Scrum, c'est de la responsabilité de toutes les Equipes Scrum. Si une équipe distincte est responsable de l'intégration du travail, d'inutiles transferts de connaissance et retards de feedback sont générés. D'autre part, si aucune équipe n'est explicitement responsable de produire un Incrément, les notions de propriété et d'engagement sont mises à rude épreuve. Le travail d'Intégration est laissé de côté. Les Equipes de Développement concernées devraient donc explicitement s'engager pour traiter les zones de chevauchement.
Par conséquent : Ritualisez un événement Scrum de Scrum pendant lequel les représentants de l'Equipe Scrum créent un plan partagé pour découvrir et résoudre les dépendances inter-équipes et les obstacles.
Vous pouvez identifier les dépendances entre les Equipes Scrum lors de la Planification du Sprint. La Planification du Sprint porte sur deux sujets qui répondent respectivement aux questions suivantes :
Répondre à la première question permettra d'identifier les zones de chevauchement et les dépendances. L'Equipe de Développement choisit les PBIs à implémenter, elle sait donc aussi avec quelle autre Equipe de Développement elle devra travailler dans le Sprint à venir pour traiter les zones de chevauchement. En répondant à la deuxième question, l'Equipe de Développement impliquée planifie le travail nécessaire pour traiter les zones de chevauchement.
L'événement Scrum de Scrums a lieu régulièrement et aussi souvent que nécessaire. Lors des événements Scrum de Scrums, les participants expliquent :
Les membres de l'Equipe de Développement, qui travaillent réellement sur les zones de chevauchement, participent au Scrum de Scrums. Le Scrum de Scrums peut permettre de découvrir de nouvelles zones de chevauchement et ainsi permettre de résoudre les obstacles inter-équipes et les dépendances. Les participants restituent ce travail de façon transparente à leurs équipes de développement en le ramenant dans le Backlog du Sprint de leurs équipes.
Bien que le Scrum de Scrums soit un événement dédié à résoudre les dépendances inter-équipes et les obstacles, leur résolution ne doit pas être reportée au prochain événement Scrum de Scrums. Les obstacles sont traités dès qu'ils apparaissent. Les Equipes de Développement sont autorisées à s'auto-organiser pour faire leur travail et minimiser les risques de dépendance en appliquant le principe Les Dépendances D'abord. Le ScrumMaster aide à éliminer les obstacles bloquant la progression de l'Equipe de Développement et peut invoquer la Procédure d'Urgence en dernier recours.
✥ ✥ ✥
Les Equipes Scrum organisent chaque Sprint pour planifier le travail sur les zones de chevauchement et livrer un Incrément Produit Périodique. Le Scrum de Scrums permet à l'Equipe Scrum d'étendre sa Définition du Fini plus facilement. Du coup, le feedback émerge rapidement sur les problèmes de dépendance, et celles-ci peuvent être traitées de manière plus efficace.
Source : Scrum of Scrums (Published Patterns)
Ancienne version : Scrum de Scrums v1
Traducteur : Fabrice Aimetti
Date : 16/04/2015
Traduction :
... L'Equipe Scrum travaillant sur un unique produit s'agrandit et a besoin de se scinder en plusieurs équipes. Les Equipes de Développement doivent maintenant suivre les progrès des différentes parties du produit, maîtriser les dépendances et les problèmes d'alignement. Les questions qui ne peuvent être résolues au sein des équipes individuelles deviennent un défi partagé par toutes les équipes.
✥ ✥ ✥
Lorsque plusieurs Equipes Scrum ont besoin de travailler ensemble pour créer un incrément produit potentiellement déployable, la coordination inter-équipes nécessite une grande attention.
Plusieurs Equipes Scrum travaillant sur le même produit doivent coordonner leur travail et résoudre les problèmes de dépendance inter-équipes. Mais vous pouvez rarement connaître à l'avance toutes les dépendances et savoir comment les résoudre. Même avec une planification à l'avance, au cours du Sprint, des dépendances imprévues peuvent émerger et nécessiter d'être traitées par les équipes.
Dans l'idéal, une Equipe de Développement devrait être en mesure de développer complètement et indépendamment un Item du Backlog Produit (PBI). Dans ce cas, vous vous inquiétez uniquement de l'intégration de multiples PBI indépendants pour faire un seul produit. Dans certains cas cependant, il n'est pas possible ou pas souhaitable pour une seule équipe de développer un PBI et nous nous retrouvons avec des PBIs qui couvrent plusieurs Equipes de Développement. Une collaboration et synchronisation fréquentes permettent à l'Equipe de Développement de produire un Incrément Produit Périodique à chaque Sprint. Chaque Equipe de Développement développe indépendamment de son côté, mais toutes les Equipes de Développement doivent produire un tout intégré.
Aucune équipe ne devrait être seule responsable de l'intégration du travail des différentes Equipes Scrum, c'est de la responsabilité de toutes les Equipes Scrum. Si une équipe distincte est responsable de l'intégration du travail, d'inutiles transferts de connaissance et retards de feedback sont générés. D'autre part, si aucune équipe n'est explicitement responsable de produire un Incrément, les notions de propriété et d'engagement sont mises à rude épreuve. Le travail d'Intégration est laissé de côté. Les Equipes de Développement concernées devraient donc explicitement s'engager pour traiter les zones de chevauchement.
Par conséquent : Ritualisez un événement Scrum de Scrum pendant lequel les représentants de l'Equipe Scrum créent un plan partagé pour découvrir et résoudre les dépendances inter-équipes et les obstacles.
Vous pouvez identifier les dépendances entre les Equipes Scrum lors de la Planification du Sprint. La Planification du Sprint porte sur deux sujets qui répondent respectivement aux questions suivantes :
- Qu'est-ce qui sera livré dans l'Incrément issu du prochain Sprint ?
- Comment réalisera-t-on le travail nécessaire pour livrer l'Incrément ?
Répondre à la première question permettra d'identifier les zones de chevauchement et les dépendances. L'Equipe de Développement choisit les PBIs à implémenter, elle sait donc aussi avec quelle autre Equipe de Développement elle devra travailler dans le Sprint à venir pour traiter les zones de chevauchement. En répondant à la deuxième question, l'Equipe de Développement impliquée planifie le travail nécessaire pour traiter les zones de chevauchement.
L'événement Scrum de Scrums a lieu régulièrement et aussi souvent que nécessaire. Lors des événements Scrum de Scrums, les participants expliquent :
- Qu'est-ce que mon équipe a fait depuis la dernière fois que nous nous sommes rencontrés et qui aide à produire un Incrément Produit Périodique ?
- De quelle aide mon équipe a-t-elle besoin pour résoudre les dépendances inter-équipes ?
- Quels sont les obstacles qu'entrevoit mon équipe avant que nous nous rencontrions à nouveau et qui nous empêche d'intégrer notre travail avec les autres Equipes de Développement.
Les membres de l'Equipe de Développement, qui travaillent réellement sur les zones de chevauchement, participent au Scrum de Scrums. Le Scrum de Scrums peut permettre de découvrir de nouvelles zones de chevauchement et ainsi permettre de résoudre les obstacles inter-équipes et les dépendances. Les participants restituent ce travail de façon transparente à leurs équipes de développement en le ramenant dans le Backlog du Sprint de leurs équipes.
Bien que le Scrum de Scrums soit un événement dédié à résoudre les dépendances inter-équipes et les obstacles, leur résolution ne doit pas être reportée au prochain événement Scrum de Scrums. Les obstacles sont traités dès qu'ils apparaissent. Les Equipes de Développement sont autorisées à s'auto-organiser pour faire leur travail et minimiser les risques de dépendance en appliquant le principe Les Dépendances D'abord. Le ScrumMaster aide à éliminer les obstacles bloquant la progression de l'Equipe de Développement et peut invoquer la Procédure d'Urgence en dernier recours.
✥ ✥ ✥
Les Equipes Scrum organisent chaque Sprint pour planifier le travail sur les zones de chevauchement et livrer un Incrément Produit Périodique. Le Scrum de Scrums permet à l'Equipe Scrum d'étendre sa Définition du Fini plus facilement. Du coup, le feedback émerge rapidement sur les problèmes de dépendance, et celles-ci peuvent être traitées de manière plus efficace.
