Comment aborder la transition de Scrum à SAFe

L'intégration d'équipes Scrum fonctionnelles au sein d'une entreprise représente un défi de taille, et de nombreuses tentatives échouent régulièrement. Cependant, une fois que plusieurs équipes interdépendantes collaborent sur un même produit ou une chaîne de valeur unique, une structure plus solide devient indispensable.

Il est crucial d'adopter un cadre d'évolution capable d'englober ces équipes Scrum. Cela leur fournit les processus et les règles nécessaires pour se synchroniser, s'harmoniser et éviter de s'égarer.

Il arrive fréquemment que des équipes se retrouvent isolées, c'est-à-dire des équipes Scrum autonomes travaillant à atteindre leurs objectifs individuels, sans vraiment avoir conscience de l'objectif global du programme. C'est là que le Scaled Agile Framework (SAFe) entre en jeu.

Qu'est-ce que SAFe ?

Source: scaledagileframework.com

SAFe est une approche qui introduit un cadre et des processus agiles dans des organisations autrefois hiérarchiques. Il englobe les niveaux de structure et les processus, mais plutôt que de les reconstruire, il réintroduit un second système, de manière organique, qui est familier à la plupart des acteurs existants du système d'origine.

SAFe repose sur plusieurs valeurs fondamentales.

Harmonisation

Chaque équipe Scrum doit comprendre la vision et la stratégie, ainsi que l'objectif ultime vers lequel elle contribue.
Il faut relier la stratégie entre les équipes afin de les mener vers une exécution concertée.
La communication avec les équipes doit se faire dans un langage commun et clair, facilement compréhensible.
Il est essentiel de vérifier régulièrement que les équipes comprennent les objectifs et la vision.
Les équipes doivent se concentrer sur le client, comprendre qui sont les clients et ce dont ils ont besoin. La stratégie doit être mise à jour pour refléter cela.

Transparence

Il est important de créer un environnement où chacun peut travailler de façon optimale, en toute confiance.
Les arguments et les faits doivent être communiqués ouvertement. Soyez direct et honnête, ne cachez pas d'informations cruciales aux équipes.
Les erreurs doivent être transformées en opportunités d'apprentissage. En cas d'échec, tirez-en rapidement les leçons, puis adaptez votre stratégie.
Visualisez le travail en cours afin que chacun puisse mieux le comprendre.
Assurez un accès facile aux informations nécessaires.

Respect des individus

Mettez l'accent sur la dimension humaine. Ne traitez pas les individus comme de simples ressources.
Valorisez la diversité des personnes et de leurs points de vue. Encouragez les retours honnêtes.
Favorisez le développement et l'éducation des individus grâce au coaching et au mentorat.
Comprenez que votre client est celui qui bénéficie de votre travail.
Construisez des partenariats durables, tant au sein qu'à l'extérieur des équipes.

Amélioration continue

Créez un environnement où la résolution de problèmes est une source de motivation pour les équipes.
Prenez le temps d'analyser ce qui a été fait la semaine précédente et identifiez les points à améliorer.
Considérez les faits comme la base la plus solide pour apporter des améliorations.
Prévoyez du temps et de l'espace pour l'innovation. Donnez aux équipes la liberté d'expérimenter et d'essayer différentes approches, même si elles semblent moins sûres.

SAFe introduit une couche de collaboration et de communication dans les systèmes Agile à grande échelle. Il ne remplace pas les activités des sprints des équipes Scrum individuelles, telles qu'elles sont pratiquées actuellement.

L'Agile Release Train (ART) est un élément central de SAFe. Il s'agit d'une équipe stable et pérenne, composée de plusieurs équipes Scrum (généralement jusqu'à 12), qui fournit régulièrement de nouvelles fonctionnalités incrémentales après chaque version de sprint. Ces équipes développent, livrent et prennent en charge une ou plusieurs solutions, au sein d'un flux de travail unique.

Source: scaledagileframework.com

Rôles au sein de SAFe

SAFe repose sur des individus ayant des responsabilités différentes. Le respect des rôles est un facteur clé de la réussite de la mise en œuvre du cadre. Il est donc essentiel de comprendre ces rôles et leurs objectifs.

#1. Équipe Agile

Les équipes agiles sont polyvalentes, ce qui signifie qu'elles sont capables de couvrir l'ensemble du domaine qu'elles mettent en œuvre au sein de l'équipe même. Ce sont également des entités auto-organisées qui définissent, créent, testent, déploient et publient des incréments de valeur.

Chaque équipe Agile possède les compétences nécessaires pour exécuter le périmètre sur lequel elle s'est engagée. L'équipe met en œuvre cette portée par incréments à chaque sprint, de manière prévisible. La prévisibilité est essentielle, car ce n'est qu'ainsi que l'équipe peut s'engager à atteindre des objectifs concrets dans des délais précis. La communication et la livraison sont des valeurs cruciales que l'équipe doit constamment améliorer.

L'équipe agile est un élément fondamental des sessions de planification d'incrément de programme (PI) pour créer des user stories et les planifier dans les sprints. Enfin, elle s'engage sur ses propres objectifs PI.

Le Scrum Master encadre l'équipe Agile et facilite les réunions d'équipe. Il supprime les obstacles et protège l'équipe des influences extérieures. Il participe aux réunions Scrum dans le cadre de l'ART.

Le Product Owner (PO) est un autre membre clé de l'équipe. Il est la voix du client et a une influence directe sur les user stories et leur priorisation. Il communique avec les autres PO pour définir et prioriser les user stories dans le backlog des équipes.

#2. Gestion des produits

La gestion des produits se situe au-dessus des équipes Scrum et se charge de l'harmonisation entre les équipes. Ses responsabilités incluent :

La réalisation des objectifs commerciaux en veillant à ce que les équipes de développement créent des produits et des solutions réalisables et durables.
La compréhension des besoins des clients et la garantie que les produits sont créés selon leur point de vue.
La disponibilité d'un nombre suffisant de fonctionnalités prêtes dans le backlog à tout moment.
Le soutien du flux de travail grâce aux conseils de programme et dans le backlog du programme.
La détermination de la portée de la prochaine phase du programme en accordant la priorité aux fonctionnalités créées par les équipes. La gestion des produits est finalement responsable de la définition du prochain PI.

#3. Architecte système / Ingénierie

L'équipe d'ingénierie analyse et développe le contenu défini des user stories du backlog. Elle représente l'expertise de l'équipe et ses responsabilités comprennent :

La création et la maintenance de la trajectoire architecturale pour que les nouvelles fonctionnalités puissent utiliser les outils technologiques.
La participation active à la planification progressive du programme et aux démonstrations du système à la fin de chaque incrément de programme.
La collaboration avec les équipes agiles pour mettre en œuvre de nouveaux outils d'architecture. Cela permettra aux équipes de construire de nouvelles fonctionnalités.
L'aide aux équipes agiles dans la définition de solutions et de décisions de conception de haut niveau. La proposition de solutions alternatives et de la meilleure approche pour les activités de preuve de concept au sein des équipes agiles.
La création d'une trajectoire architecturale, c'est-à-dire une définition des catalyseurs technologiques prêts à être utilisés pour des fonctionnalités définies par les équipes respectives.

#4. Propriétaires d'entreprise / parties prenantes

Il s'agit d'équipes externes aux équipes Scrum, mais elles jouent un rôle important dans le cadre SAFe à chaque étape de l'exécution.

Avant la planification PI :

La contribution aux activités de raffinement du backlog.
La participation à la planification pré-PI si nécessaire.
La garantie que les objectifs commerciaux sont compris et acceptés par les principales parties prenantes de l'ART, y compris l'ingénieur Release Train (RTE), la gestion des produits et les architectes système.

Pendant la planification PI :

La fourniture du contexte commercial et de la vision du prochain PI.
La participation à l'examen du projet de plan et l'attribution d'une valeur commerciale aux objectifs PI de l'équipe.
La participation à la revue de direction et l'aide à la résolution des problèmes qui mèneront à l'acceptation du plan final.

Après la planification PI :

La participation active au maintien de l'harmonisation des activités et du développement, alors que les priorités et la portée changent inévitablement.
L'aide à la validation de la définition des produits minimum viables (MVP) pour les Program Epics et l'orientation de la décision de pivoter ou de persévérer en fonction de la livraison du MVP.
L'assistance à la démonstration du système pour observer les progrès et fournir des commentaires.
La participation aux événements de planification de sprint et de rétrospective de sprint de l'équipe Agile, selon les besoins.
La participation à la gestion des versions, en mettant l'accent sur la portée, la qualité, les options de déploiement, les versions et les considérations du marché.

#5. Ingénieur Train de Libération (RTE)

Le RTE organise les activités des individus et des équipes au sein de l'ART. Il agit en quelque sorte comme un Scrum Master pour l'ensemble du programme. Ses principales responsabilités sont les suivantes :

La gestion et l'optimisation du flux de valeur à travers l'ART.
L'établissement et la communication des calendriers annuels des sprints et des incréments de programme (PI).
Le rôle de modérateur lors des réunions de planification PI.
L'organisation des équipes et l'aide à la création d'un résumé de leurs objectifs PI identifiés. La traduction des objectifs des équipes en objectifs globaux du Plan PI.
Le rassemblement des équipes pour communiquer et résoudre les risques et les dépendances entre elles.
La connexion de la gestion des produits, des Product Owners et d'autres parties prenantes externes pour harmoniser les stratégies.
L'orchestration des ateliers Inspecter et Adapter dans le but d'améliorer continuellement les processus et les activités existants.
L'évaluation du niveau actuel de maturité de l'adoption de la méthodologie agile au sein des équipes et la définition des actions de suivi pour l'amélioration future.

#6. Direction

La direction définit la stratégie du programme et fournit aux équipes tous les outils et le soutien nécessaires pour leur permettre de travailler. Elle définit en fin de compte le système dans lequel tout le reste fonctionne. Il est donc essentiel d'avoir une équipe de direction qui donne à l'équipe une définition claire des objectifs et des valeurs. Ses principales responsabilités sont les suivantes :

Mener par l'exemple.
Adopter un état d'esprit de croissance.
Mettre en valeur les valeurs et les principes de SAFe.
Développer les compétences des individus.
Mener le changement.
Favoriser la sécurité psychologique.

Planification des incréments de programme (PI)

La planification PI est un événement de deux à trois jours dont l'objectif est de comprendre et de s'engager dans le travail pour la prochaine phase du programme. Il peut s'agir par exemple de la période du prochain trimestre.

La gestion des produits est responsable de la priorisation des fonctionnalités identifiées lors de la planification PI. Les équipes agiles sont responsables de la planification des capacités, de la création des user stories, de l'estimation et de l'engagement envers les objectifs PI.

La planification PI est essentielle pour SAFe. Si vous ne planifiez pas les PI, cela signifie que vous n'appliquez pas réellement SAFe.

Processus PI

Source: scaledagileframework.com

La planification PI commence par la mise en commun de plusieurs éléments. Chaque axe de travail rassemble ses besoins et ses idées sur ce qu'il souhaite créer pour ses produits. Ces éléments sont ensuite utilisés comme entrées pour la planification PI :

Le top 10 des fonctionnalités à mettre en œuvre ensuite.
Le backlog ART des épopées ou des fonctionnalités prêtes à être formulées.
La vision du Product Owner.

Une discussion s'engage entre les différents axes de travail. Chacun présente sa vision et ses caractéristiques. Ils soulignent les points importants à mettre en œuvre ensuite et les ressources nécessaires pour réussir. Cela peut signifier plusieurs choses :

L'activation est assurée par d'autres flux de travail afin de leur permettre de développer les fonctionnalités.
La dépendance à l'égard d'autres flux de travail et la nécessité de donner la priorité aux commandes.
Les problèmes actuels du système qui doivent être résolus avant de pouvoir continuer.
Les défis de recrutement pour l'équipe. Plusieurs rôles clés au sein de l'équipe peuvent encore manquer pour mettre en œuvre le contenu requis par les fonctionnalités.
Les contraintes budgétaires qui empêchent votre flux de travail de réaliser la vision dans les délais impartis.
Tout autre risque, problème, hypothèse ou dépendance que l'équipe peut identifier et une discussion plus large avec le reste des équipes SAFe est nécessaire pour s'aligner sur l'objectif commun.

Déroulement de la planification PI

La planification PI elle-même est souvent divisée en plusieurs jours, généralement deux ou trois, selon l'ordre du jour suivant :

Jour 1

La présentation de l'énoncé de mission et des principaux objectifs à venir, qui constituent la vision et la stratégie globales du programme. Le leadership est responsable de cette partie et doit la communiquer clairement à l'équipe.
La mise en commun de toutes les fonctionnalités des flux de travail et leur hiérarchisation en fonction de la vision commune.
La présentation de la vision de l'architecture et la définition des principaux objectifs des exigences de développement. La mise en évidence des défis techniques et la décision collective de la résolution des obstacles au sein des équipes.

Jour 2

L'explication détaillée du processus de planification aux équipes et la description des résultats attendus une fois le PI clôturé.
La tenue des premières séances de travail en équipe pendant la planification. L'objectif de l'équipe est de créer des ébauches de plans et d'identifier les obstacles et les risques.
La présentation et l'examen par les équipes des projets de plans qu'elles ont créés devant les autres équipes, une fois la séance terminée.
L'étape suivante concerne la direction, qui examine les plans et fournit des orientations pour les initiatives de résolution de problèmes qui suivront. Des ajustements sont apportés aux plans en fonction des défis, des risques et des obstacles.

Jour 3

Le début de la journée par des ajustements de planification, conformes aux décisions prises lors de la réunion de direction de la veille.
L'élaboration des plans finaux et l'affinement des risques et des obstacles par les équipes. L'attribution d'une valeur commerciale aux objectifs de l'équipe par les propriétaires d'entreprise.
La présentation des plans finaux devant l'ensemble du public.
La discussion sur les risques restants au niveau du programme et l'application des informations sur les risques ROAM (résolus, détenus, acceptés, atténués).
Le vote des équipes sur leur confiance dans les résultats de la planification des incréments du programme.
En cas de votes trop faibles ou si la confiance globale reste faible, une planification supplémentaire est organisée.
Après l'engagement PI, le RTE prévoit une rétrospective pour que les équipes discutent de l'avancement de la planification et des points à améliorer pour le prochain tour. Le leadership indique ce qui se passera à l'avenir, en même temps que les instructions finales.

Résultat de la planification PI

Le résultat final de la planification PI est la liste des fonctionnalités dont l'achèvement est prévu selon les sprints au cours de la prochaine période PI. Toutes les dépendances connues ont un plan précis sur la manière de résoudre les problèmes et de débloquer la progression des fonctionnalités.

Les équipes s'engagent sur leurs objectifs et leur portée. Tout objectif supplémentaire ne faisant pas nécessairement partie de la liste est considéré comme un objectif non engagé. Ces problèmes peuvent être résolus si le temps et les ressources le permettent.

Les équipes documentent et suivent tous les risques du programme et disposent d'un plan précis sur la manière d'y faire face.

Les équipes enregistrent également toutes les idées rétrospectives qu'elles ont formulées lors de leur réunion rétrospective et les notent comme des leçons à retenir pour la prochaine session de planification PI.

En ce qui concerne plus précisément les équipes, certaines attentes sont claires, par exemple :

Les équipes s'engagent sur des objectifs qui ont de la valeur pour l'entreprise.
Les équipes calculent leur capacité par sprint afin de mieux estimer la faisabilité du contenu de la feuille de route.
Elles tiennent également compte de la charge réelle pour chaque sprint.
Les user stories sont intégrées aux sprints spécifiques de chaque domaine de travail, en fonction de la capacité fournie.
Les équipes votent pour leur confiance dans le plan PI et le contenu à proposer.

Conclusion

Cela peut ne pas paraître évident, même après avoir lu tout ce qui précède, mais je peux vous assurer que la transformation d'une grande organisation en SAFe est une tâche extrêmement complexe. Dans certains cas, cela peut même ressembler à une mission impossible. Même si certains de ces principes fondamentaux sont appliqués, il faut généralement de nombreuses itérations pour atteindre un état où vous pouvez affirmer avec certitude que vous êtes désormais SAFe.

Très souvent, les progrès remettent en question certains principes et règles hiérarchiques de la vieille école, qui ont la vie dure, quels que soient vos efforts. Vous pouvez avoir une planification PI approfondie et des résultats de toutes sortes, que vous pouvez même identifier en toute confiance. Mais qu'est-ce que cela signifie réellement si les équipes de travail ne fonctionnent pas selon la méthodologie agile appropriée ?

Je peux seulement dire qu'il n'y a pas de place pour les compromis. Soit vous êtes pleinement investi, avec les processus, les personnes et l'état d'esprit appropriés, soit vous échouerez si au moins un des aspects méthodologiques n'est pas respecté.

Bien sûr, avant même d'envisager la mise en œuvre de SAFe, assurez-vous de maîtriser déjà les principes et les méthodes de travail de l'équipe Agile. Pas seulement du point de vue de la direction, mais laissez les équipes voter et exprimer leur opinion honnête. Vous pourriez être surpris par les résultats.

Ensuite, consultez les ressources d'apprentissage appropriées pour la certification agile.

Cet article vous a-t-il été utile ?

Merci pour votre évaluation !