Scrum à l'échelle : Modèles et ressources

Un modèle est une pratique ou un processus qui a été observé pour répondre à un ensemble spécifique de défis dans un contexte défini. Les modèles ont émergé parce que scrum est prescriptif sur les objectifs de chaque partie du cadre, mais ne dit pas grand-chose sur la façon d'atteindre ces objectifs. Ainsi, au fil des ans, des pratiques communes sont apparues pour aider les équipes à atteindre ces objectifs face à des obstacles connus. À l'instar d'une pièce tirée du livre de jeu d'une équipe sportive, les modèles aident les équipes à réagir au changement et à préparer le terrain pour la réussite.

Il existe de nombreux modèles bien documentés au niveau de l'équipe, et une bibliothèque faisant autorité peut être consultée ici. Notre objectif est de créer une bibliothèque publique de modèles de mise à l'échelle afin que la communauté puisse apprendre d'elle-même.

Vous trouverez ci-dessous un exemple de modèle. L'objectif d'un modèle est de décrire la pratique avec juste assez de détails pour que toute personne familière avec le cadre et les concepts soit en mesure de la mettre en œuvre. 

Module : Priorité au carnet de commandes

Nom du modèle : Caractéristiques, Composants, Équipes

Modèle : 

La hiérarchisation des carnets de commandes se fait en cascade, depuis le carnet de commandes d'un produit unique jusqu'aux carnets de commandes de plusieurs composants et, enfin, aux carnets de commandes de chaque équipe.

Le carnet de commandes de haut niveau est géré et hiérarchisé par un seul chef Product Owner. Il comprend, au niveau des fonctionnalités et des éléments, le carnet de commandes pour au moins la prochaine version. Le carnet de commandes du produit est affiné toutes les deux semaines lors d'une réunion d'affinage avec tous les propriétaires de produits composants. Les sessions d'affinage se concentrent sur la préparation de deux sprints de backlog. Le chef Product Owner organise également des réunions régulières de méta-scrum avec les parties prenantes de l'organisation afin d'aligner et de rendre visible la hiérarchisation du carnet de commandes. Tous les retours d'information sur les produits passent par le chef Product Owner, qui les répercute ensuite dans la hiérarchisation du carnet de commandes et dans la communication lors des réunions d'affinage.

Le backlog de produit de haut niveau est classé par composant du produit (à quelle partie du produit cette fonctionnalité sera-t-elle ajoutée ?) pour créer des backlogs au niveau des composants. Les backlogs des composants sont détenus et classés par ordre de priorité par un seul propriétaire de produit de composant, qui est souvent aussi un propriétaire de produit principal au niveau de l'équipe. Chaque backlog de composant est affiné chaque semaine par les responsables de produit des équipes qui travaillent sur le composant. Ces sessions d'affinage se concentrent sur la décomposition des fonctionnalités en histoires de la taille d'un sprint, et sur la hiérarchisation de ces histoires avec les éléments de recherche et de dette technique identifiés par les équipes pour les backlogs au niveau de l'équipe.

Les backlogs au niveau des composants sont ensuite divisés par les équipes pour créer leurs backlogs de sprint. Ces backlogs de sprint contiennent au moins suffisamment de travail pour les deux sprints suivants sur une base continue.

Contexte:

Facteurs clés : Innovation, amélioration de la rapidité de livraison, amélioration de l'expérience client

L'organisation est leader sur le marché et cherche à garder une longueur d'avance sur la concurrence. L'entreprise fabrique de nombreux produits, mais ce modèle concerne l'un d'entre eux, qui est un produit de bureau hérité qui est en train d'être adapté à un modèle de Software as a Service (logiciel en tant que service). Les mises à jour ont lieu une fois par an et ont toujours été perturbantes pour les clients en raison du grand nombre de nouvelles fonctionnalités contenues dans chaque version.

Réussites :

Il fournit un certain degré de vision centralisée avec le CPO comme principal point de contrôle, tout en répondant au changement et en tirant parti des connaissances et de l'autonomie au niveau de l'équipe par l'intermédiaire d'une équipe de propriétaires de produits. Elle a permis aux équipes de gérer les dépendances et de produire un produit plus intégré. Cette approche couvre l'établissement des priorités, la décomposition et la planification dans le cadre d'une cadence de réunions régulières.

Défis : 

Ce schéma exige des efforts supplémentaires pour maintenir la cadence des réunions de perfectionnement et des méta-scrums, ainsi qu'une discipline pour assurer le suivi des perfectionnements et coordonner les dépendances entre les composants. Le chef Product Owner a une charge de travail particulièrement lourde : il doit jongler avec les méta-scrums, tous les retours d'information sur les produits et les perfectionnements hebdomadaires avec les responsables des produits des composants et de l'équipe.

L'industrie: Logiciels

Taille de l'organisation: 7,000

Le formulaire ci-dessous vous guidera tout au long du processus de soumission. Référez-vous à l'exemple de patron ci-dessus et gardez à l'esprit que l'objectif est de fournir suffisamment de détails pour que toute personne lisant votre patron soit en mesure de l'appliquer. N'oubliez pas que les défis et les réussites de votre modèle sont tout aussi importants.

Une fois soumis, votre modèle sera téléchargé dans la bibliothèque publique de modèles. Votre nom et votre adresse électronique sont nécessaires pour que nous puissions assurer le suivi des soumissions et vous aider à affiner votre modèle. Les informations de contact soumises dans ce formulaire ne seront jamais partagées avec le public et ne seront utilisées que pour vous contacter au sujet des patrons de mise à l'échelle.