Passez à l'agilité à l'échelle

Découvrez les caractéristiques du framework SAFe

Carte d’identité du framework

SAFe ajoute une couche méthodologique appelée Program au-dessus de vos équipes agiles. C’est dans cette couche que chaque rôle, chaque cérémonie et chaque livrable Scrum trouvent leur correspondance à l’échelle.

Rôles agiles à l’échelle

Release Train Engineer

Votre Release Train Engineer (RTE) est un “Super Scrum Master”, garant de l’alignement méthodologique et organisationnel de vos équipes.

Il facilite vos cérémonies de niveau Program et veille au bon fonctionnement du train.

Product Management

Votre Product Management, composé d’une ou plusieurs personnes, est un “Super Product Owner”, garant de l’alignement business/fonctionnel de vos équipes.

Il est orienté client, porte la vision stratégique du métier, et priorise les évolutions fonctionnelles.

System Architect

Votre System Architect, composé d’une ou plusieurs personnes, est un “Super Développeur”, garant de l’alignement technique de vos équipes.

Il porte les principes d’architecture et les évolutions techniques.

System Team

Son but est que vos équipes puissent se concentrer totalement sur la production de valeur métier, sans être pénalisées par des tâches manuelles ou des problèmes d’environnements.

Cérémonies agiles à l’échelle

L’horizon de planification préconisé par SAFe est un incrément composé de 5 itérations de 2 semaines, soit 10 semaines. On peut le représenter grâce à l'illustration ci-dessous :

Je vous propose de nous pencher davantage sur les différentes cérémonies.

Scrum of Scrums

Chaque semaine, votre Release Train Engineer rassemble les Scrum Masters pour :

• partager de manière transparente l’avancement des équipes ;

• coordonner les dépendances entre les équipes ;

• lever les obstacles et suivre les risques ;

• aligner les Scrum Masters sur des pratiques agiles.

PO Sync

Chaque semaine, votre Product Management rassemble les Product Owners pour :

• partager l’avancement des équipes concernant les objectifs métiers ;

• assurer une cohérence fonctionnelle de la solution ;

• effectuer des arbitrages fonctionnels ;

• donner de la visibilité sur les fonctionnalités prévues pour le prochain incrément.

System Demo

La System Demo est l’occasion pour vos équipes de montrer une solution intégrée afin de collecter les retours métiers, et de s’adapter en conséquence. Elle a lieu à chaque fin d’itération. La System Demo de l’itération 5 est l’occasion de convier un panel élargi des membres du business, pour montrer le fruit du travail de tout l’incrément.

Rétro Train

L’incrément se termine par une rétro train organisée par votre Release Train Engineer, où tout le monde est convié pour identifier ce qui s’est bien passé et mal passé pendant l’incrément, et s’améliorer collectivement pour l’incrément suivant.

Innovation and planning

L’itération 5, appelée Innovation and Planning, est une itération particulière, dans laquelle il ne faut pas planifier de travaux. Elle permet à vos équipes de :

Program Increment Planning (PI Planning)

SAFe propose un agenda type pour votre Program Increment Planning. Vous pouvez modifier les horaires et la durée des créneaux, l’essentiel étant de respecter les différentes étapes à réaliser, et l’ordre de ces étapes.

Pas de panique, je vous explique tout en détail. 😉

• La première demi-journée est entièrement dédiée à l’alignement de vos équipes :

  • le contexte business présenté par votre sponsor et les objectifs métiers présentés par votre Product Management alignent vos équipes d’un point de vue business/fonctionnel ;

  • l'architecture et les principes sont présentés par votre System Architect pour aligner vos équipes d’un point de vue technique ;

  • le contexte planning permet à votre Release Train Engineer de rappeler les objectifs de ces 2 jours, et d’aligner vos équipes d’un point de vue méthodologique.

• Les deuxième et troisième demi-journées sont des team breakouts, c’est-à-dire des travaux d’équipes pour :

  • planifier les itérations ;

  • rencontrer les autres équipes pour gérer les dépendances ;

  • échanger avec le Product Management sur la compréhension du besoin ;

  • échanger avec le System Architect sur les points techniques.

• Entre les deux team breakouts, une revue managériale permet de prendre des décisions et de faire les ajustements nécessaires.

• La dernière demi-journée sert à valider l’ensemble des travaux :

  • une présentation par chaque équipe de sa planification ;

  • une gestion globale des risques pour identifier des porteurs qui établiront des plans d’action pour les minimiser ;

  • un vote de confiance, exprimé par tous par une note entre 0 et 5, pour mesurer si l’engagement collectif est atteignable. Si la moyenne des votes est inférieure à 3, un team breakout supplémentaire est effectué pour revoir les plans, et sécuriser ainsi l’engagement collectif ;

  • une rétrospective de fin d’évènement pour améliorer le prochain Program Increment Planning.

Pendant les team breakouts, vos équipes coconstruisent :

• Un Program Board unique qui montre les fonctionnalités que vos équipes prévoient de terminer dans chaque itération, ainsi que les dépendances entre les fonctionnalités.

• Un Team Board par équipe qui montre les travaux prévus et les risques identifiés pour chacune de vos équipes, dans chacune des itérations.

Mettez en place le framework SAFe

Points forts

• La puissance du Program Increment Planning favorise la richesse des échanges.

• L’horizon de planification à un incrément, qui permet une bonne gestion des dépendances entre les équipes.

• Une System Team au service des autres équipes, responsable d’automatiser l’intégration et le déploiement continus.

• SAFe propose un cadre méthodologique pour délivrer des solutions qui nécessitent plusieurs trains.

• SAFe propose également une gestion agile et lean du portefeuille d’entreprise.

Points de vigilance

• La mise à l’échelle de tous les concepts Scrum représente un coût d’implémentation important. Ce framework doit donc être réservé uniquement à des périmètres qui en ont le besoin.

• SAFe est un framework complexe qui nécessite les formations adaptées avant de se lancer.

• Le soutien d’un sponsor est important pour composer un train avec l’ensemble des personnes permettant de livrer en toute autonomie de la valeur aux clients.

• L’horizon de planification à 10 semaines peut être un frein pour un périmètre nécessitant de pivoter plus fréquemment.

• Le temps consacré à l’innovation dans le sprint 5 sert trop souvent à terminer les itérations précédentes.

• Les Product Owners peuvent ressentir une perte de responsabilités lors du passage à SAFe, car ils perdent leur orientation client pour prendre une orientation uniquement équipe.

À vous de jouer !

Faites évoluer votre dispositif

Fortes de 4 mois d’agilité à l’échelle avec le framework LeSS, les équipes UX-Booking ont fait le constat qu’elles ont beaucoup de dépendances avec les équipes Fidélio. Toutes ces équipes ont donc décidé de se regrouper au sein d’un même dispositif de 6 équipes au total.

• Quel framework allez-vous préconiser pour ce dispositif, et pourquoi ?

Organisez le Program Increment Planning

Le premier Program Increment Planning a été planifié, mais le Release Train Engineer n’a pas encore été recruté ! Dans l’attente de ce recrutement, c’est à vous de prendre en charge l’organisation de cet événement important.

• Définissez la liste des actions à effectuer pour préparer l’évènement.

Réajustez votre dispositif

Un an plus tard, votre dispositif subit une très forte réduction budgétaire. Il ne reste plus que 3 équipes, avec un niveau de dépendance moyen. Vous décidez malgré tout de ne pas changer de framework.

• Quels sont les éléments de SAFe qui risquent de ne plus faire sens ?

Corrigé

Vous pouvez consulter le corrigé pour vérifier votre travail.

En résumé

• SAFe introduit la notion de train pour définir un dispositif composé de 50 à 125 personnes, c’est-à-dire 5 à 12 équipes agiles. Un train est autonome pour délivrer de la valeur aux clients.

• L’horizon de planification préconisé par SAFe est l’incrément, soit 10 semaines.

• À chaque début d’incrément, un Program Increment Planning constitue l’événement phare du framework, car il rassemble tous les membres du train pendant 2 jours.

• D’un point de vue méthodologique, SAFe porte à l’échelle tous les éléments de Scrum, ce qui induit un coût d’implémentation élevé.

Vous maîtrisez désormais 3 frameworks bien différents, qui vont vous permettre de répondre à la diversité de vos périmètres. Il vous reste à renforcer la cohésion entre vos équipes grâce à des pratiques issues du modèle Spotify.