TagSAFe

« Agile Health Check » SQLI : animer une rétrospective SAFe à 50 personnes !

Nous avons récemment eu l’occasion de voir notre dernière création à l’épreuve d’une rétrospective dans un contexte SAFe : la cérémonie d’Inspect & Adapt (Inspect & Adapt).

Pour plus d’informations sur le Health Check Agile SQLI, nous vous invitons à suivre ce lien : http://blogagile.toulouse.sqli.com/blog/index.php/2019/08/26/un-agile-health-check-pour-accompagner-lamelioration-continue/

Cette cérémonie rassemble les équipes du Train à intervalles réguliers pour inspecter l’incrément de solution produit et leurs pratiques, dans le but d’identifier des actions d’amélioration.

 

Il y a quelques temps, nous vous présentions un retour d’expérience de l’utilisation de ce jeu dans une équipe : http://blogagile.toulouse.sqli.com/blog/index.php/2019/10/01/agile-health-check-2-formats-dateliers-au-service-de-lamelioration-continue/

Dans le contexte SAFe présenté ici, les Scrum Masters des équipes du Train avaient, pour la première fois, la responsabilité d’organiser cette cérémonie et, plus particulièrement, la rétrospective.

D’après notre expérience, la méthode d’animation la plus courante est réalisée avec le diagramme d’Ishikawa (Ishikawa Diagram) ou « arête de poisson ».

Ici, les Scrum Masters souhaitaient changer de technique d’animation. Ils ont décidé de prendre de la hauteur par rapport à SAFe et de revenir aux fondements de l’agilité en utilisant le jeu de cartes SQLI.

 

La principale difficulté a été d’organiser la session avec une cinquantaine de personnes.

Les Scrum Masters ont pris le parti de réaliser la session en plénière, au format auto-évaluation, en évaluant l’ensemble des sujets.

Format d’animation

  1. Distribution d’un jeu de cartes smileys à chaque participant​

Les sujets ont été évalués sur une échelle de satisfaction à quatre niveaux à l’aide des cartes de vote ci-dessous.

  1. Affichage numérique des cartes d’auto-évaluation

Les cartes ont été affichées l’une après l’autre. Pour chaque carte, un Scrum Master était en charge de lire le contenu à haute voix (recto et verso).

Ayant conservé les intitulés des sujets, il a été nécessaire de préciser aux participants que la notion d’« équipe » signifiait ici le Train dans son ensemble, et que la notion de « produit » signifiait l’incrément produit par l’ensemble des équipes.

  1. Vote au format Poker Planning 

Pour chaque carte présentée, le temps de réflexion a été fixé à une minute. Un Scrum Master s’est chargé de gérer le time-box. A l’issue du temps imparti, les participants votaient simultanément.

A la différence d’un Poker Planning, les Scrum Masters n’ont pas demandé aux participants d’expliquer leurs choix : il n’y a pas eu recherche de consensus.

Une fois le vote effectué, ils se sont chargés de comptabiliser le nombre de smileys de chaque couleur et de les retranscrire dans une grille de résultats préparée pour l’occasion.

  1. Analyse de la grille de résultats

Grâce à la grille, les résultats ont pu être diffusés à la fin de l’exercice.

Les participants ont choisi de travailler sur les axes les moins bien notés : ils en ont sélectionné quatre.

  1. Définition d’un plan d’action

La suite de la rétrospective a été réalisée à la façon d’un forum ouvert (Forum Ouvert). Les quatre sujets ont été affichés au mur à des endroits bien distincts. Chaque participant a pu librement circuler entre les sujets pour contribuer.

Les Scrum Masters circulaient eux aussi pour s’assurer que l’on réponde bien à l’objectif : obtenir un plan d’action concret (action d’amélioration, responsable, date butoir) pour chacun des sujets.

Un temps de restitution en plénière a été prévu pour présenter les résultats à l’ensemble du groupe, ainsi que le plan d’action et les conclusions de la rétrospective. Les Scrum Masters en ont profité pour avoir un retour sur la méthode d’animation.

Notre retour d’expérience sur ce format 

  • Prévoir 2h30 pour réaliser la rétrospective dans sa globalité (hors démo). Le temps de réflexion fixé à une minute a parfois pu être un peu long ; 30 secondes nous paraît plus adapté.
  • L’avantage de ce format est de prendre du recul par rapport aux problématiques opérationnelles et de revenir aux raisons qui nous amènent à mettre en place de l’agilité : cela permet de faire émerger des discussions auxquelles les participants n’auraient pas songé à première vue.
  • Le vote simultané permet à chacun de s’exprimer sans être influencé. Dans un contexte mêlant clients ou donneurs d’ordres et fournisseurs, il est nécessaire de s’assurer que le climat est propice à ce que chacun soit libre de donner son avis, sans quoi les résultats seront faussés.
  • Même remarque que pour la rétrospective d’équipe : les sujets de réflexion étant proposés via les cartes, cela ne laisse pas forcément l’opportunité d’aborder un point qui a particulièrement été dérangeant sur la période qui vient de s’écouler.  Une idée : conserver un espace-temps durant lequel les participants peuvent aborder un sujet qui n’est pas nécessairement mentionné sur les cartes.
  • Un inconvénient de ce format est que les notes extrêmes, même si non majoritaires, sont moyennées et donc noyées dans la masse. Une idée : le cas échéant, prévoir d’aborder le sujet avec les participants concernés pour qu’ils puissent exprimer leur point de vue.

 

Et vous, quels sont vos retours sur l’utilisation de ces cartes ? N’hésitez pas à nous les partager en commentaires.

Pourquoi SAFe marche ?

Souvent décrié mais pour autant de plus en plus utilisé, il nous semble intéressant d’expliquer nos convictions sur les éléments qui font que SAFe® est une approche pertinente pour adresser l’agilité à grande échelle dans des organisations complexes.

Avant de commencer, si vous cherchez dans cette article du SAFe Bashing ou des réponses toutes faites à  « Est-ce que SAFe est agile ou non », ni même l’apologie de SAFe en tant que solution « One size fits all » … ce n’est pas vraiment ici que vous le trouverez.

Par contre, nous allons discuter des axes qui au travers de plusieurs expériences nous permettent de dire que SAFe, ça marche !

SAFe, c’est des poupées russes

Tel le concept de fractale ou des poupées russes, SAFe s’appuie sur ce qui marche bien au niveau équipe agile et le réplique aux niveaux d’abstraction plus élevés (tels que le programme et le portefeuille).

SAFe - cadence et synchronisation

Cadence et Synchronisation

Autrement dit, l’équipe Scrum ne pense plus à son projet seulement, mais elle appartient à un système qui s’appelle l’Agile Release Train et qui a son macro backlog. Connecté à l’entreprise et ses objectifs stratégiques, cette équipe agile d’équipes agiles délivre tel un flux continu de la valeur à ses clients. Ces équipes planifient ensemble (PI planning au niveau du train SAFe), identifient leur dépendances, leurs risques et leurs objectifs, puis collaborent et se synchronisent au fur et à mesure (Scrum of Scrum), et enfin démontrent ensemble leur incrément (System Demo) puis réalisent leur inspection et adaptation (Inspect & Adapt). Ce n’est donc plus seulement une équipe qui sprinte mais un système dans son ensemble en utilisant les mêmes cérémonies que Scrum avec les mêmes objectifs mais à une échelle différente.

On retrouve aussi une illustration des poupées russes quand on regarde les personnes impliquées, 3 « rôles » au niveau équipe Scrum que vous connaissez bien, que l’on retrouve au niveau du train – RTE en tant que Super Scrum Master, Product Manager en tant que Super PO, System Architect en tant que connaissance technique du système – mais aussi au niveau de la value stream – VSE en tant que Super Super Scrum Master, Solution Manager en tant que Super Super PO, Solution Architect en tant que coordination technique de l’ensemble. En d’autres termes, aucune relation hiérarchique mais des réseaux de personnes qui ont les mêmes activités avec des granularités différentes.

Les Agile Release Trains sont donc des équipes d’équipes Agiles s’appuyant sur les mêmes caractéristiques que les équipes agiles à savoir : pluridisciplinaire, auto-organisée, 3 rôles, des rituels pour cadencer et synchroniser… seule la taille changement passant d’une équipe de 7 à une équipe d’équipes allant de 50 à 125. Les ARTs ont l’ensemble des compétences pour définir et délivrer des incréments de produit toutes les deux semaines.

Principes Lean / Agile

Difficile de ne pas parler de SAFe et du manifeste agile qui au travers de ses valeurs et principes sous-jacent restent la base fondamentale. Mais quand on parle d’agilité à l’échelle, ces 12 principes sont ils tous toujours applicables ? La grande majorité, oui.
– « Un logiciel opérationnel est la principale mesure d’avancement. » -> Pour ne citer que celui-ci reste totalement vrai et appliqué à l’échelle.
– « Les meilleures architectures, spécifications et conceptions émergent d’équipes auto-organisées. » -> Dans une organisation complexe et un SI complexe, sans orientation et vue d’ensemble, les meilleures équipes auto-organisées peuvent rencontrer des difficultés.

En mixant agile pour l’essentiel et lean pour le passage à l’échelle, SAFe en propose une déclinaison sous forme de 9 principes – fondamentaux à prendre en compte à l’échelle.

  1. Avoir une vue économique : L’ensemble des acteurs ont la responsabilité de s’assurer que l’investissement dans de nouvelles solutions fournira des avantages économiques. Il est donc important de comprendre les raisons économiques de délivrer au plus tôt et souvent la plus haute valeur. Il est aussi question de comprendre les paramètres permettant de prendre des décisions économiquement viables et cela à tout niveau de l’organisation
  2. Appliquer une pensée systémique : voir chaque groupe de personnes ou d’activités comme un système afin d’avoir une vue globale des problèmes et challenges. « le composant le plus lent décide de la vitesse de l’ensemble » Moore.
  3. Assumer la variabilité et se préserver des options : les approches traditionnelles visent à s’engager le plus tôt possible sur une unique solution technico-fonctionnelle, ici, on parle plutôt d’essayer d’avoir les données issues d’expérimentations pour faire le meilleur choix au meilleur moment.
  4. Construire progressivement avec des cycles d’apprentissage rapides et intégrés : Chaque itération aboutit à un incrément intégré du produit regroupant l’ensemble des équipes du train. Ces incréments donnent l’opportunité de d’avoir un maximum de retours des utlisateurs, permettant de pivoter régulièrement et faire décroitre le risque.
  5. Avoir des jalons basés sur l’évaluation objectif du système fonctionnel : Chaque point d’intégration de l’incrément offre l’occasion d’évaluer la solution, fréquemment et tout au long du cycle de vie du développement. Mais c’est aussi un moyen d’assurer qu’un investissement apporte suffisamment de bénéfice.
  6. Visualiser et limiter WIP, réduire les tailles des lots et gérer les longueurs de file d’attente : Les organisation s’efforcent d’atteindre un état de flux continu de livraison de valeur. Trois clés principalement issu du Lean existent pour la mise en œuvre d’un flux : 1. Visualiser et limiter la quantité de travail en cours afin de contraindre la demande à la capacité réelle, 2. Réduire la taille des lots pour faciliter un flux le plus unitaire possible dans le système et 3. Gérer les longueurs de file d’attente afin de réduire les temps d’attente pour les nouvelles fonctionnalités.
  7. Appliquer cadence et synchronisation : La notion de cadence transforme les événements imprévisibles en prévisibles et fournit un rythme de développement. La synchronisation permet de comprendre, de résoudre et d’intégrer simultanément de plusieurs équipes.
  8. Débloquer la motivation intrinsèque des équipiers : l’idéation, l’innovation et l’engagement des équipiers ne passent pas par une motivation basé sur des objectifs individuels et des récompenses associées. En travaillant sur la motivation intrinsèque, on essaye d’assurer l’autonomie, de travailler pour atteindre un but important, et de minimiser les contraintes, afin d’améliorer le bien être des équipe et aboutir à de meilleurs résultats
  9. Décentraliser la prise de décision : l’organisation nécessaire à une livraison rapide nécessite une prise de décision elle aussi rapide et décentralisée, car toute décision peut introduire un délai. La prise de décision décentralisée réduit les retards, améliore le flux de développement du produit, permet des feedbacks plus rapide et des solutions plus innovantes. Cependant, pour être réaliste certaines décisions sont stratégiques, de nature globale et ont des économies d’échelle suffisantes pour justifier la centralisation de la prise de décision.

SAFe nous propose grâce à ces principes un prisme d’analyse à base de pensée systémique, lean product development et bien sûr d’agile development pour développer l’agilité à l’échelle. 3 grands axes passionnants mais qui déjà nous donne un avant-goût de la conduite du changement qu’il va falloir réaliser pour faire admettre ces basiques.

Alors oui, ca marche !

SAFe et les agile release trains, oui, ca fonctionne ! Et la raison majeure, c’est cette capacité fractale à réutiliser les concepts qui ont fait le succès de l’agilité à l’échelle d’une équipe Scrum. Gardez bien à l’esprit qu’aucun framework qu’il soit à l’échelle ou non vous rendront Agile. Qui plus est en tant qu’Agiliste, nous devons particulièrement reconnaitre que le cadre n’est qu’un outil qui sans leadership, sans transformation organique et expérimentale et sans agent du changement sera inutile. Les points débattus ci-dessus sont des outils de cette transition que vos équipes devront prendre le temps de découvrir et expérimenter dans leur contexte.

Coach Lean/Agile. Passionné d’humain, j’ai d’abord été développeur agile et Scrum Master, puis j’ai ci-crée une startup du web. J’interviens maintenant pour plusieurs grands comptes pour remettre de l’humain au centre des organisations : depuis la découverte de l’agilité jusqu’à la transformation d’organisations complexes et de leurs cultures.
Mots-clés : Lean, Scrum, Kanban, SAFe.
Citation : « You never change things by fighting the existing reality.
To change something, build a new model that makes the existing model obsolete. » R. Buckminster Fuller