Analyser et comprendre les rôles dans Scrum à l’échelle (Scrum of Scrums) / Scaled Structure
Commençons par quelques éléments de base
Qu’est-ce que Scrum : un cadre de travail dans lequel les personnes peuvent résoudre des problèmes complexes qui nécessitent une adaptation, tout en produisant et livrant avec créativité des produits viables de la plus grande valeur possible.
Le guide Scrum est l’ensemble minimal des fonctionnalités qui permettent l’inspection et l’adaptabilité via une transparence radicale qui conduit à l’innovation, la satisfaction des clients, la performance, et la joie au sein de l’équipe de développement (production).
Scrum@Scale : un cadre de travail dans lequel les équipes Scrum, opérant en réseau et travaillant en cohérence avec le guide Scrum, peuvent répondre à des problèmes complexes qui nécessitent une adaptation, tout en livrant avec créativité des produits de la plus grande valeur possible.
Note : le terme produit fait référence aux matériels, aux logiciels, aux solutions intégrées complexes, aux processus, aux services, etc… dépendamment du domaine dans lequel opèrent les équipes Scrum.
Scrum@Scale est :
- Léger – une bureaucratie minimale viable
- Simple à comprendre – ne consiste qu’en des équipes Scrum
- Difficile à maîtriser – requiert l’implémentation d’un nouveau model opérationnel.
Scrum@Scale est un cadre de travail pour passer Scrum à l’échelle. Il simplifie radicalement le passage à l’échelle de Scrum en utilisant Scrum.
Dans Scrum, une attention particulière est portée pour séparer la responsabilité entre le « quoi » et le « comment ». La même attention est portée dans Scrum@Scale, si bien que la juridiction et la responsabilité sont expressément comprises dans le but d’éliminer les conflits organisationnels inutiles qui empêchent l’atteinte d’une productivité optimale.
Scrum@Scale est un ensemble de composants qui permettent aux organisations de personnaliser leurs transformations, à la fois, la stratégie et l’implémentation de cette transformation. Il leurs donne la capacité de se concentrer sur les efforts de changement priorisés, de manière incrémentale, dans les domaines qui ont le plus de valeur pour elles ; ou qui sont le plus en besoin de changement et, de progresser vers d’autres domaines ensuite.
Structure à l’échelle : Scrum de Scrums / Scaled Structure : the Scrum of Scrums
Un ensemble d’équipes Scrum qui travaillent en coordination dans le but de délivrer de la valeur aux clients comprend une équipe appelée Scrum of Scrums (SoS). Cette équipe est responsable de la livraison à la fin de chaque sprint d’un incrément de produit potentiellement utilisable et totalement intégré, en provenance des équipes participantes. Un SoS fonctionne comme une équipe de livraisons (Release Team) et doit être capable de délivrer directement de la valeur au client.
Un Scrum of Scrums (SoS) travaille comme une équipe Scrum avec une version à l’échelle des rôles, des événements, des artefacts. Considérant la nature à l’échelle d’un SOS, quelques éléments additionnels doivent être pris en compte.
SoS Roles
Un Scrum of Scrums doit avoir toutes les compétences nécessaires pour livrer un incrément de produit totalement intégré et utilisable à la fin de chaque sprint et faciliter la coordination entre les équipes lorsque cela est nécessaire. (Cela peut exiger des architectes expérimentés, des analystes qualité, des membres de l’équipe propriétaire du produit, et d’autres compétences opérationnelles.)
Équipe Propriétaire de Produit (Product Owner Team)
Pour chaque SoS, il y a un groupe associé de propriétaires de produit appelés l’équipe propriétaire de produit (Product Owner Team) qui aligne les priorités des équipes avec le backlog unique de l’entreprise de sorte à pouvoir coordonner chaque backlog d’équipe Scrum et construire en alignement (en respect) avec les parties prenantes.
Le propriétaire de produit (PO : Product Owner) d’une équipe est responsable de la composition et de la priorisation du backlog de son équipe et peut récupérer des éléments du backlog partagé du SoS pour les intégrer dans le backlog de son équipe, ou bien générer des éléments de backlog indépendants.
Les principales fonctions de l’Équipe Propriétaire de Produit (Product Owner Team) sont :
- créer une vision globale du produit et la rendre visible pour l’organisation.
- Construire un alignement avec les parties prenantes clés pour garantir le support pour l’implémentation du backlog.
- Générer un backlog unique et priorisé, assurant la non duplicité du travail.
- S’assurer que les blocages et les dettes techniques sont proprement priorisées dans le backlog.
- Créer une définition du travail livrable (« Definition of Done ») minimale et uniforme qui s’applique à toutes les équipes.
- Résoudre les dépendances qui jaillissent entre les équipes.
- Générer un plan de livraison (Release Plan) coordonné et prévoir au-delà du plan de livraison actuel (souvent appelé Roadmap)
- Décider sur et monitorer les métriques qui donnent une vision précise du produit et du marché.
Les équipes de propriétaires de produits, tout comme les ensembles SoSs, fonctionnent comme des équipes Scrum. De ce fait, elles ont besoin d’une personne travaillant comme Scrum Master qui maintient l’équipe sur le droit chemin. Elles ont aussi besoin d’une unique personne responsable de la coordination de la génération d’un unique backlog pour toutes les équipes au sein du Scrum de Scrums. Cette personne est désignée comme Chef Propriétaire de Produit (Chief Product Owner).
Chief Product Owner (CPO)
Le Chef Propriétaire de Produit (CPO) coordonne les priorités entre les autres propriétaires de produits (PO) qui travaillent avec les équipes individuelles. Il aligne les priorités du backlog avec les parties prenantes et les besoins des clients. Le CPO peut être un PO d’une des équipes ou une personne spécialement dédiée à ce rôle. Les responsabilités du CPO sont les mêmes que celles d’un propriétaire de produit (PO) au sein d’une équipe, mais, à l’échelle, le CPO est responsable de :
- définir une vision stratégique pour l’ensemble du SoS
- créer un backlog unique et priorisé de la valeur à délivrer par toutes les équipes.
- Note : ces items sont généralement de gros Items de Backlog de Produit (Items Product Backlog) qui auront besoin d’un raffinement et d’une décomposition par les POs d’équipe.
- travailler étroitement avec le Scrum de Scrums Master associés (voir la définition de leur rôle ci-dessous) de sorte que le plan de livraison que l’Equipe Propriétaire de Produit génère soit déployable de manière efficiente.
- Monitorer les feedbacks produits des clients, aussi bien que les feedbacks produits provenant du SoS, et ajuster le backlog en conséquence.
- Au niveau exécutif / niveau méta, conduire l’événement MetaScrum où l’ensemble du Backlog Produit (Product backlog) est présenté et un alignement est trouvé avec les parties prenantes.
Scrum of Scrums Master (SoSM)
Le Scrum Master du Scrum de Scrums est appelé le Scrum de Scrum Master (SoSM : Scrum of Scrum Master). Le SoSM est responsable de la livraison de l’effort joint des équipes et doit :
- Rendre les avancements visibles
- Rendre le backlog des obstacles visibles au niveau de l’organisation
- Enlever les obstacles que les équipes ne peuvent enlever elles-mêmes.
- Faciliter la priorisation des obstacles, avec une attention particulière aux dépendances transversales entre les équipes et à la distribution du backlog.
- Améliorer l’efficacité du scrum de scrums
- Travailler étroitement avec l’équipe de propriétaires de produit pour déployer un incrément de produit potentiellement livrable au moins une fois par sprint.
- Coordonner les déploiements des équipes avec les plans de livraison des propriétaires de produit.
si vous avez un « Scrum of Scrums » qui ne dispose pas des compétences pour satisfaire aux exigences ci-dessus, alors il ne s’agit probablement pas d’un véritable Scrum of Scrums.
KENMEUGNE Romuald - Coach Agile et Formateur Officiellement Accrédité
Derniers articles parKENMEUGNE Romuald - Coach Agile et Formateur Officiellement Accrédité (voir tous)
- OFFRE D’EMPLOI : Développeur Windev (H/F) - 22 décembre 2023
- Implémenter UX et Scrum ensemble et passer sa certification PSU - 26 juillet 2023
- Relation entre Définition of Done et nombre de Product backlog Items à prendre pour le sprint - 20 juillet 2023
Laisser un commentaire