Mise à l'échelle agile : meilleures pratiques SAFe pour les Scrum Masters

Cet article est la deuxième partie de la série de mise à l'échelle Agile de Toptal, conçue pour guider les chefs de projet dans leurs efforts d'expansion d'équipe. Lisez le premier article, "5 cadres de mise à l'échelle agiles comparés : lequel devez-vous utiliser ?" pour un aperçu détaillé des options les plus populaires.

Au fur et à mesure que les produits grandissent et deviennent plus complexes, les équipes qui les produisent aussi. Lorsqu'il est temps de passer à l'échelle, de nombreuses entreprises passent de Scrum au Scaled Agile Framework (SAFe), un système qui est mis en œuvre au niveau de l'entreprise et permet aux entreprises de gérer plusieurs produits complexes qui nécessitent des équipes d'équipes pour se développer.

Un Scrum master évoluant dans un cadre SAFe entrera dans un environnement à la fois familier et nouveau. Les artefacts, les rôles et les cérémonies sont basés sur Scrum. Mais opérer à une échelle supérieure s'accompagne de responsabilités supplémentaires, en particulier pour les Scrum masters qui choisissent d'évoluer vers le rôle d'ingénieur de train de lancement (RTE), une trajectoire courante. Le RTE agit en tant que Scrum master de l'ensemble du train de versions. Au lieu de diriger une équipe Scrum de 9 à 11 personnes, les RTE deviennent des leaders-serviteurs d'équipes d'équipes qui chevauchent plusieurs départements, et ils organisent des événements de plus grande taille et portée.

Les bases : de Scrum à SAFe

SAFe permet à une entreprise d'appliquer des approches, des valeurs et des principes Agile à plusieurs équipes. L'« équipe d'équipes » qui en résulte est connue sous le nom de train de lancement agile (ART). Les équipes individuelles continuent d'employer un Scrum master pour faire des affaires comme d'habitude, tandis que le rôle de Scrum-master sur un ART est assuré par un RTE. Le RTE applique les mécanismes généraux et la gouvernance de Scrum, mais au niveau de l'organisation et non de l'équipe. D'autres rôles et artefacts Scrum traditionnels au niveau de l'équipe changent également en conséquence. Par exemple, le « product owner » ART devient chef de produit ; un « product backlog » devient le backlog du programme ; un « backlog de sprint » est un backlog d'itération ; et "l'incrément de produit" est maintenant l'incrément de programme (PI).

Il existe quatre configurations de SAFe (Essential, Large Solution, Portfolio et Full) et celle que vous utilisez dépend de la mesure dans laquelle votre entreprise adopte le cadre. Les configurations permettent une mise en œuvre à plusieurs niveaux, allant de plusieurs équipes travaillant ensemble à l'intégration complète du portefeuille et à l'agilité commerciale à l'échelle de l'entreprise. Mais à tous les niveaux, l'objectif reste de faire évoluer les pratiques Agile et Scrum, et non de les remplacer.

Scrum Master en SAFe

Les maîtres Scrum travaillant dans un cadre SAFe au niveau de l'équipe constateront que leurs tâches ne sont pas significativement différentes. Il restera un leader-serviteur pour une équipe Agile, responsable de l'encadrement et de l'éducation, de l'élimination des obstacles et de la promotion d'un environnement où les membres de l'équipe se sentent en sécurité pour faire de leur mieux et s'améliorer continuellement.

Cependant, il y aura de nouvelles responsabilités. Un maître Scrum SAFe soutient le RTE dans l'événement de planification PI et dans l'exécution du programme, et représente son équipe dans les réunions de synchronisation ART. Lorsqu'il y a des obstacles qui dépassent la capacité de l'équipe à supprimer, le Scrum master les fait remonter au RTE.

Un Scrum master qui décide de devenir un RTE constatera que son rôle s'accompagne de bien plus de considérations. L'ART peut inclure des équipes qui sont nouvelles pour vous ou pour Agile, comme l'analyse commerciale, le matériel ou la conformité. Et parce que les configurations supérieures de SAFe incluent des opérations de programme ou de portefeuille, la direction sera directement et régulièrement impliquée d'une manière qu'elle ne serait pas dans Scrum, en s'assurant que tout est aligné sur les objectifs au niveau de l'entreprise et/ou du portefeuille.

Le RTE est chargé de lever les entraves qui dépassent les capacités d'une seule équipe. Ils communiquent avec les parties prenantes et favorisent l'amélioration continue au niveau de l'ART. Le RTE coache non seulement les équipes mais aussi les responsables de ces équipes, aidant tous les niveaux de l'ART à évoluer vers l'auto-organisation et l'autogestion.

Événements SAFe

Tout comme un Scrum master facilite les événements au niveau de l'équipe, un RTE facilite les événements au niveau de l'ART - la planification PI, la synchronisation ART, la démonstration du système, et l'inspection et l'adaptation. En tant que RTE, vous vous engagerez avec une plus grande variété de parties prenantes que vous ne l'étiez en tant que Scrum Master et gérerez plusieurs équipes aux intérêts concurrents. Il y a de plus en plus de participants à chaque événement, et vous devez aligner les priorités et obtenir l'adhésion aux initiatives bien à l'avance.

Planification IP

L'événement de planification PI est une cérémonie essentielle pour SAFe, une gigantesque session de deux jours pour aligner les objectifs de toutes les équipes au sein de l'ART pour les huit à 12 prochaines semaines en créant le plan PI. C'est comme un événement de planification de sprint, mais il s'étend sur plusieurs sprints dans plusieurs équipes.

Contributions

• Vision d'entreprise
• Liste des 10 à 15 principales fonctionnalités à implémenter
• Détails sur la capacité de chaque équipe

Les sorties

• PI plan (un plan de livraison pour les cinq à six prochains sprints)
• Objectifs PI
• Liste des risques potentiels

Conseils généraux pour l'événement PI Planning

• Obtenir l'adhésion des parties prenantes. Avant la réunion, les RTE doivent établir qui sont les principales parties prenantes et partager leurs contributions avec le groupe.
• Alignez les priorités. Avant la session, planifiez une réunion d'une journée avec l'équipe de gestion des produits pour convenir d'une vue d'ensemble des fonctionnalités à fournir, ainsi que des priorités futures. Il y aura beaucoup à régler lors de l'événement, comme les risques et les dépendances, et il est bon d'avoir un accord directionnel de base en place.
• Répéter! Le PI planning est un événement énorme. Il n'est peut-être pas utile de passer deux jours complets à répéter, mais une session de deux à quatre heures avec les chefs d'équipe de l'ART qui crée une expérience aussi proche que possible aidera énormément. Créez une version simplifiée de l'agenda de l'événement et partagez-la avant la répétition afin que la pratique puisse commencer à partir d'un endroit bien informé.
• Soyez prêt pour le fluage de la mission. L'objectif de la planification PI est de fournir un plan à long terme dans un laps de temps relativement court. Parfois, les gens voudront entrer dans les détails de tout, ce qui n'est pas le but de l'événement. Expliquez cela aux chefs d'équipe lors de la répétition et de la séance ; rappelez aux équipes que l'objectif est de fournir des plans de haut niveau et de créer un alignement, et non de planifier chaque minute des trois prochains mois.
• Préparer les informations sur la capacité de l'équipe. Demandez à vos Scrum masters de fournir des calculs de capacité pour les huit à 12 prochaines semaines. Attendez-vous à des réactions négatives ou à des questions ; par exemple, un Scrum master peut ne pas savoir précisément combien d'absences son équipe aura au cours des deux prochains mois. Dans de tels cas, demandez des estimations et soyez flexible lorsque vous répondez aux limites de capacité pendant l'IP lui-même.
• Partagez le programme de planification PI. Distribuez le programme au moins deux semaines avant l'événement et soyez prêt à répondre à de nombreuses questions. Il y aura de nombreux participants, et si SAFe est nouveau pour vous et votre entreprise, il est probablement aussi nouveau pour de nombreux autres membres de l'équipe. D'après mon expérience, dès le deuxième ou le troisième événement de planification PI, la pression sur les animateurs devient beaucoup moins intense à mesure que les équipes se familiarisent avec l'événement et savent à quoi s'attendre.
• Présence de gestion sécurisée. Il est souvent difficile pour les managers ou les cadres supérieurs d'assister à un événement de deux jours, mais la présence de la direction est indispensable pour garantir un alignement de haut niveau. Confirmez leur présence au moins deux semaines avant la planification de l'IP et organisez le soutien dont ils auront besoin. Il en va de même pour les propriétaires d'entreprise, qui doivent approuver les objectifs PI.

Synchronisation ART

L'événement ART sync est une réunion hebdomadaire où le RTE peut avoir un aperçu des progrès des équipes et identifier les risques et les blocages du programme. Bien qu'il ne s'agisse en aucun cas de la seule occasion pour un RTE d'évaluer les obstacles et de déterminer s'ils nécessitent une escalade, il s'agit d'un événement important qui fournit un lieu régulier pour que ces questions soient soulevées.

Contributions

• Progrès des équipes
• Journal des obstacles
• Le PI plan (pour identifier tout écart majeur entre le plan et l'avancement réel)

Les sorties

• Escalades (si nécessaire)
• Décisions concernant toute modification du plan PI

Conseils généraux pour l'événement ART Sync

• Encouragez une communication régulière. Étant donné que l'ART Sync est hebdomadaire, au lieu d'être quotidien comme les stand-ups Scrum, le RTE doit indiquer clairement que les équipes peuvent soulever des problèmes urgents immédiatement et ne doivent pas attendre la prochaine synchronisation ART.
• Soyez prêt avec des données. Demandez aux maîtres Scrum et aux propriétaires de produits d'apporter des mesures de progression quantifiables, telles que le burndown ou le flux cumulé, afin d'avoir une conversation éclairée sur les progrès.
• Allez au-delà d'un examen de statut hebdomadaire. La synchronisation ART est censée être un événement où les priorités sont alignées et les problèmes sont résolus, pas un simple enregistrement.

Démo du système

La démonstration du système est destinée à présenter l'ensemble du travail créé lors d'une itération précédente. Lors de cet événement, le chef de produit et son équipe montrent aux propriétaires d'entreprise et aux autres parties prenantes les progrès intégrés de l'ART dans sa forme actuelle.

Saisir

• L'état actuel du travail basé sur les résultats de tous les membres de l'équipe Agile au cours de l'itération précédente

Les sorties

• Retour d'expérience sur l'aptitude à l'emploi du système
• Modifications du backlog (si nécessaire)

Conseils généraux pour l'événement de démonstration du système

• Répéter! Consacrez 30 à 45 minutes toutes les deux semaines à travailler avec les présentateurs pour définir leurs segments.
• Abandonnez les diapositives. Présenter le travail intégré réel. Si vous travaillez sur un produit logiciel, demandez aux présentateurs de montrer aux parties prenantes un incrément de produit fonctionnel plutôt qu'un jeu de diapositives. Si possible, faites la démonstration de votre produit dans un environnement de mise en scène. Vous voulez que la démo ressemble exactement à l'expérience de l'utilisateur final. Si vous n'êtes pas en mesure de présenter un système intégré toutes les deux semaines, examinez votre pipeline de livraison et réfléchissez avec les équipes sur la manière dont vous pouvez adopter la culture CI/CD et DevOps.
• Concentrez-vous sur la valeur commerciale. Votre présentation s'adresse aux propriétaires d'entreprise et aux parties prenantes ; partager ce qui est le plus important pour eux.
• Gardez la rétroaction ciblée. Les commentaires des parties prenantes que vous recevrez seront importants, mais cet événement n'est pas le moment de modifier radicalement la vision ou la feuille de route du produit. Soyez prêt à rediriger la conversation vers des commentaires de haut niveau que les équipes pourront transformer en éléments d'action ultérieurement.
• Soyez bref. Les parties prenantes sont des personnes occupées ; une réunion de 45 à 60 minutes se traduira par une participation plus fréquente et plus engagée.
• Prévoyez du temps pour les questions et réponses. Soyez transparent dans vos réponses. Souvenez-vous que parfois « je ne sais pas, mais nous pouvons trouver » est la meilleure réponse.

Inspecter et adapter

L'inspecter et adapter est une méga-rétrospective qui se déroule à la fin d'un PI. La séance est divisée en trois parties,

• La démo du système PI : une vitrine pour l'ensemble de la sortie intégrée du PI. Il est similaire à la démo du système principal, mais au lieu d'une itération, cet événement présente le travail intégré sur l'ensemble de l'IP.
• Mesures quantitatives et qualitatives : une opportunité pour RTE de présenter les métriques recueillies au cours du PI. Ces mesures incluent (mais ne sont pas limitées à) la vélocité de l'équipe, les user stories acceptées, la couverture des tests unitaires ou les défauts ouverts.
• Atelier rétrospectif et de résolution de problèmes : une occasion pour les participants de revenir sur l'IP, de réfléchir à ce qui a fonctionné et ce qui n'a pas fonctionné, d'identifier les problèmes systématiques et de proposer des moyens de les résoudre.

Contributions

• Progrès des équipes
• L'état actuel du travail intégré de l'ART, y compris tous les résultats de l'incrément de programme

Production

• Liste des améliorations potentielles

Conseils généraux pour l'événement Inspecter et adapter

• Prévenez les propriétaires d'entreprise à l'avance. Fournir un préavis d'au moins deux semaines avant l'événement. Rencontrez tous les chefs de produit et propriétaires d'entreprise présents avant la session pour vous aligner sur la présentation des résultats qualitatifs.
• S'assurer de la présence des principaux intervenants. Leur présence est plus importante lors de la démonstration du système PI lorsque vous présentez le travail de l'équipe et l'évolution du produit. De nombreux conseils pour la démonstration système régulière s'appliquent ici : répétez à l'avance, évitez les diapositives de présentation et présentez les livrables réels.
• Évitez les reproches. Tout au long de la session, assurez-vous que personne ne se sente menacé par les données présentées ou les problèmes identifiés dans la rétrospective. Certaines équipes peuvent se sentir jalouses ou sur la défensive si les chiffres d'une autre équipe sont plus élevés, ou se sentir pointées du doigt si un problème vient de leur équipe. Adoptez une culture d'équipe complète pour anticiper de tels problèmes.
• Concentrez-vous sur les problèmes systématiques. Essayez de ne pas accorder trop d'attention aux problèmes sporadiques, donnez à votre équipe l'espace dont elle a besoin pour réfléchir et laissez libre cours à l'imagination pour les solutions proposées.
• Créer des propositions actionnables. À la fin de l'événement, vous devriez avoir des éléments de backlog à mettre en œuvre par les équipes. Identifier les problèmes ne sert à rien si vous ne prenez pas les mesures nécessaires pour les résoudre.

Le tableau ci-dessous compare les événements SAFe avec leurs équivalents Scrum et décrit la fréquence et l'exécution des cérémonies au niveau de l'entreprise :

Intensification et mise à l'échelle

La transition de Scrum à SAFe peut être intimidante. Opérer à une échelle supérieure présentera toujours de nouveaux défis et de nouvelles façons de penser, même les pratiques les plus familières. Si vous choisissez de devenir RTE, vous constaterez que le poste dépend surtout des compétences que vous possédez déjà. Un RTE est un agent de changement et un leader-serviteur, tout comme un Scrum master, et le travail vous donne la possibilité d'exercer ce rôle au niveau de l'entreprise, en élevant vos compétences aux côtés de vos produits.