Spécificités du travail d'une équipe Agile en SAFe par rapport à Scrum en pratique

Après la publication parmi mes amis du premier article sur Burn Down Chart, dans les commentaires, la première question posée a été : « Il serait intéressant d'en savoir plus sur votre expérience avec SAFe ». C'est pourquoi, dans cet article, je vais m'efforcer de révéler les spécificités du travail en SAFe par rapport à Scrum dans notre pratique. Je ne prétends certainement pas détenir la vérité absolue et je serai ravi de toute correction et précision de la part de collègues.

D'abord, je vais énumérer sous forme de thèses l'essentiel de ce qui distingue le travail en SAFe de SCRUM, selon moi.

• Increment en Scrum et Program Increment en SAFe
• ART - Agile Release Train
• Nombre d'équipes en interaction
• PIPE
• SOS
• PO - n'est pas propriétaire du business
• RTE
• Le cinquième sprint pour l'apprentissage
• System Demo

Increment en Scrum et Program Increment en SAFe. En réalité, ce sont des termes différents, mais il est facile de s'y perdre car personne n'utilise chez nous le terme Program Increment, tout le monde dit simplement Increment - et c'est déjà un autre terme, qui est utilisé dans SCRUM. Mais dans l'ensemble, ils sont assez similaires du point de vue du sens, selon moi. Increment en SCRUM - c'est en substance le produit actuel + les histoires planifiées pour le sprint à l'état réalisé (ayant passé la DOD de l'équipe). Program Increment - c'est l'intervalle de temps pendant lequel le train (Agile Release Train) livre une valeur incrémentale en production. En durée, chez nous c'est 4 sprints de 2 semaines pour le développement et un sprint pour l'apprentissage.

Agile Release Train - c'est une équipe d'équipes travaillant sur un même flux de création de valeur. Nous appelons cela simplement le train, mais selon le framework, il est correct de l'appeler « Solution ». Dans notre cas, cette règle n'est pas entièrement respectée et les équipes travaillent souvent sur des produits différents d'un point de vue technique, car la plupart des fonctionnalités métier sont réalisées de manière complexe et touchent plusieurs produits. C'est du point de vue technique. Mais, je suis sûr que certains considèrent tous les systèmes IT comme un seul produit de l'entreprise et, peut-être, c'est même plus correct.

Nombre d'équipes en interaction chez nous en SAFe est nettement plus grand, au total il est recommandé jusqu'à 125 personnes dans un seul train. Nous avons 3 trains et cette règle n'est pas respectée dans chacun, il y a des trains avec plus de 125 personnes. SCRUM ne décrit pas comment interagir avec les autres équipes, pour autant que je sache, contrairement à SAFe, où il y a des recommandations très claires à ce sujet. L'artefact le plus marquant, selon moi, pour cela - c'est le Program Board.

Il affiche les interdépendances entre les équipes du train et, en le discutant, se déroulent les événements hebdomadaires Scrum Of Scrums (SOS) chez nous.

Environ tous les 2,5 mois (tous les 5 sprints) a lieu l'événement PIPE - Programm Increment Planning Event. C'est lorsque toutes les équipes distribuées se réunissent dans une même salle pendant 2 jours et planifient leurs travaux pour les 2,5 mois suivants. Au cours de cet événement apparaissent des artefacts tels que le Program board, par exemple, sur lequel sont affichées toutes les dépendances des équipes entre elles pour chacun des trains, j'ai déjà montré ci-dessus à quoi il ressemble. La tâche du Scrum Master de chaque équipe lors de cet événement est de faciliter l'identification du maximum de dépendances, puis, si possible, leur suppression (au moyen du transfert de compétences oralement, par exemple, d'une équipe à une autre ou au moyen de la reprise d'une dépendance d'une équipe par une autre, afin que l'équipe puisse réaliser de manière autonome sa fonctionnalité sans dépendre de personne). En pratique, c'est ainsi que cela se passe chez nous. D'abord, les fonctionnalités sont décomposées en User Story, les User Story sont réparties sur 4 sprints. Les fonctionnalités sont placées sur le Program Board et les dépendances vis-à-vis des autres équipes sont établies. Au cours de l'événement, cela est discuté, corrigé.

SOS - Scrum Of Scrum. Cet événement a lieu une fois par semaine pour chaque train séparément. Les Scrum Masters de toutes les équipes du train se réunissent en ligne, le Program Board du train est diffusé et les statuts de toutes les dépendances et fonctionnalités des équipes du train concerné sont discutés. En substance, cet événement est nécessaire pour la synchronisation centralisée des équipes au sein du train. Quelque chose comme un standup, mais une fois par semaine et non pour l'équipe, mais pour les Scrum Masters.

PO (Propriétaire du produit) - n'est pas propriétaire du business. Il y a un Product Manager - il travaille avec les Business Owner's des directions métier correspondantes et en substance distribue les fonctionnalités aux Propriétaires du produit. Le Propriétaire du produit travaille déjà directement dans l'équipe - découpe les fonctionnalités en User Stories (dans notre cas conjointement avec l'équipe) et ne découpe pas toujours, mais nous progressons constamment dans cette direction.

RTE (Release Train Engineer - conducteur de train. Scrum Master des Scrum Masters. Anime les événements SOS de son train. Interagit avec le Product Manager au niveau des fonctionnalités. Facilite le PIPE.

Le cinquième sprint dédié à la formation - oui, contrairement à Scrum, ici un sprint entier est alloué à l'équipe à la fin de l'incrément pour la formation. En pratique, nous l'utilisons généralement en premier lieu pour suivre des formations internes, y compris sur SAFe, mais pas seulement. Nous essayons de planifier les cours privés et les meetups sur ce créneau dans la mesure du possible. Nous avons aussi des développeurs qui élargissent leur stack pendant le 5e sprint, afin de pouvoir couvrir la compétence de quelqu'un dans l'équipe (assurer un relais si nécessaire).

System Demo. À l'issue du PIPE, chaque équipe dispose d'une liste d'objectifs pour l'incrément et chacun de ces objectifs est évalué par le Business Owner du train sur une échelle de 10 points. C'est ce qu'on appelle la Business Value. Ces objectifs se divisent en objectifs principaux et étendus. Les objectifs principaux sont ceux pour lesquels l'équipe ne voit aucun risque d'atteinte. Les objectifs étendus sont ceux comportant des risques d'atteinte. Tous les objectifs sont obligatoires et le volume de travail est planifié pour tous les objectifs. Lors de la System Demo, le Business Owner accepte les résultats du travail pour l'incrément. Supposons qu'une équipe ait eu 3 objectifs principaux avec des notes de 10, 6, 8 et 2 objectifs étendus avec des notes de 10, 3. Imaginons que le Business Owner ait attribué respectivement les notes suivantes : 8, 6, 4, 2, 0. On peut maintenant calculer le pourcentage d'atteinte des objectifs : on prend comme 100 % la somme initiale des points pour les objectifs principaux, dans notre cas 10+6+8=24. Les points atteints sont calculés en tenant compte des objectifs étendus (c'est-à-dire que l'équipe a atteint 20 sur 24), donc le pourcentage d'atteinte des objectifs de l'équipe sera (20*100)/24 = 83,3 %. Un résultat normal est considéré comme une atteinte de 80 % à 100 %.

Pour tout le reste, nous travaillons selon SCRUM. Enfin, presque pour tout :) Concernant notre expérience : je peux dire que, de mon point de vue, l'évolution est évidente. En un an, les équipes ont beaucoup grandi, sont devenues auto-organisées ; certaines équipes, il est vrai, se sont effondrées, mais là aussi on observe une certaine évolution. Il reste encore de la marge pour progresser.

Commentaires de collègues de facebook

« Jénia, bonjour ! C'est super que tu écrives, bravo ! Je vais juste corriger un peu à propos des trains - ils ne se forment pas autour du produit, mais autour du flux de création de valeur. Et dans le retail, de notre point de vue SAFe, ce n'est pas un train, mais une Solution. C'est simplement pour faciliter la communication et simplifier la compréhension que nous continuons à appeler cela un train) »

– Konstantin Voronin (représentant du bureau de projet d'Ingosstrakh)

« Et puis peut-être que quelqu'un remarquera que, du point de vue SAFe, l'évaluation des objectifs a lieu à l'I&A ; (où la SD entre comme une partie, mais n'est pas directement liée à l'évaluation) et les SD elles-mêmes doivent avoir lieu à chaque sprint (après les démos des équipes). Mais nous en sommes encore loin, c'est pourquoi nous appelons consciemment tout comme c'est écrit dans ton article) »

– Konstantin Voronin (représentant du bureau de projet d'Ingosstrakh)

« Jénia, continue s'il te plaît, c'est très utile ! »

– Alexeï Ionov (Formateur certifié SAFe)