Études de cas SAFe : notes de transformation sur le terrain

Cet article est la troisiè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. Assurez-vous de lire la première partie, "5 cadres de mise à l'échelle agiles comparés : lequel devez-vous utiliser ?" et la deuxième partie, "Agile Scaling: SAFe Best Practices for Scrum Masters".

L'agilité est pratiquée d'une manière ou d'une autre par 94 % des entreprises, selon le 15e rapport annuel sur l'état de l' agilité. Mais la recherche suggère également que 90 % des organisations ont du mal à mettre en œuvre Agile à l'échelle de l'entreprise. En règle générale, c'est le travail des coachs Agiles, des Scrum Masters et d'autres professionnels de la gestion de projet de diriger et d'organiser ces efforts. Souvent, ils travaillent avec des équipes ou des départements résistants au changement, dans une culture d'entreprise difficile à appréhender.

Dans cette table ronde, trois chefs de projet Toptal évoquent les enjeux de la conduite des transformations Agiles. Parce que leurs solutions sont compatibles avec le Scaled Agile Framework (SAFe), nous avons également parlé avec Dean Leffingwell, créateur de SAFe. Leurs idées collectives illustrent la nécessité pour les praticiens SAFe de préparer une vision claire de ce qu'est l'agilité et un plan de leadership qui peut rallier les équipes récalcitrantes.

Parler SAFe avec le créateur du framework

SAFe, un framework formalisé par Scaled Agile, ne date que de 2014. Mais pour Leffingwell, le travail a commencé lorsqu'il a rencontré pour la première fois des équipes Agiles au début des années 2000. En tant que méthodologiste du développement logiciel, il a été impressionné par les résultats des pratiques Agiles sur les équipes de développement, et il a immédiatement commencé à explorer comment l'état d'esprit pouvait être appliqué à l'ensemble d'une entreprise. Si une équipe Agile pouvait produire des résultats, que pourrait produire une équipe d'équipes Agile alignées ? Comment les pratiques Agile pourraient-elles être utilisées pour des projets de transformation à grande échelle dans des entreprises nationales ou internationales ? Comme le dit Leffingwell, « J'adore le développement de logiciels. J'aime Agile. Je le veux juste grand .

Au cours des années qui ont suivi, les entreprises ont reconnu les avantages de SAFe, notamment des livraisons plus courtes, une meilleure qualité des produits, une plus grande efficacité et des employés plus engagés. En 2021, plus d'un tiers des organisations dans le monde utilisaient SAFe, et parmi ses aspects les plus importants figurent les processus partagés et le langage unifié qu'il fournit. Par exemple, si une équipe pense qu'un sprint dure deux semaines et qu'une autre pense qu'il dure 30 jours, cela crée ce que Leffingwell décrit comme un « problème de la tour de Babel ». Il est difficile pour les équipes de discuter des fonctionnalités à ajouter si elles ne peuvent même pas s'entendre sur ce que signifie « fonctionnalité ». "Vous [avez besoin] de personnes travaillant de manière commune si vous voulez créer de grandes solutions", dit-il. "Il n'y a pas un terme dans notre industrie qui ne soit pas surchargé, comme 'itération' ou 'sprint' ou 'backlog'. Ce n'est pas utile si vous essayez de travailler au-delà des frontières de l'équipe et de la région.

Histoires de réussite agiles

Amener tout le monde dans une entreprise à adopter une manière unifiée de parler et de faire le travail est une tâche ardue, même lorsqu'il y a une énorme urgence de changement. Dans les sociétés établies, cela peut être plus difficile. Leffingwell précise : « Vous regardez les plus grandes entreprises du monde qui gagnent beaucoup d'argent et se portent incroyablement bien et sont en concurrence – et elles doivent changer. Eh bien, la question pour eux est pourquoi devraient-ils? Les chefs de projet Toptal présentés ici ont chacun rencontré des questions comme celle-ci au cours de leurs propres activités de mise à l'échelle, et chacun a trouvé sa propre façon de travailler à travers ses transformations Agile à l'aide de SAFe.

Démontrer la valeur

Alvaro Villena, chef de projet Toptal à Santiago, au Chili, a récemment achevé une transition SAFe pour un portefeuille développant une plate-forme interentreprises. « La première étape de ma transition a été la tenue d'un atelier sur la chaîne de valeur », dit-il. En termes simples, un atelier de flux de valeur est une réunion de lancement pour identifier l'ensemble du processus métier, du concept à la livraison, ainsi que toutes les étapes, les utilisateurs, les systèmes et les points faibles intermédiaires.

Faire participer des représentants de toute l'entreprise à l'atelier a aidé Villena à comprendre la culture de l'entreprise et quels seraient ses obstacles. "Avant de mettre en place l'atelier, il y avait une structure dans laquelle une entreprise avait son équipe, une autre avait son équipe et l'entreprise suivante avait sa propre équipe - les trois ne se parlaient pas."

Villena a découvert que même si toutes les équipes partageaient des problèmes similaires, il n'y avait pas de collaboration sur les solutions. Par exemple, bien que toutes les entreprises du portefeuille expédient des produits, une seule avait développé un système de suivi. Il n'y avait aucune raison pour qu'ils ne puissent pas tous l'utiliser, sauf que personne n'avait partagé les connaissances. Une fois que l'atelier les a fait parler, les connaissances ont commencé à circuler entre les équipes, les entreprises et les propriétaires de produits. « Ce genre de conversation était vraiment, vraiment puissant pour le programme. C'était un bon point de départ », dit Villena. Lorsque DevOps, la conception et le produit savent tous ce que font les autres équipes, ils voient qu'il existe des solutions dans l'entreprise qu'ils peuvent utiliser. « Ils commencent à demander : 'Comment puis-je avoir ça ?' Et c'est là que vous intervenez et dites : "Suivez ce processus".

"Personne ne veut de changement tant qu'il ne sait pas pourquoi. Donc, vous commencez par un pourquoi et vous leur donnez un avenir meilleur. Dean Leffingwell, créateur de SAFe

Leffingwell sait que les équipes sont parfois résistantes. "Personne ne veut de changement tant qu'il ne sait pas pourquoi", a-t-il déclaré à Toptal. "Donc, vous commencez par un pourquoi et vous leur donnez un avenir meilleur." Donner aux équipes un aperçu de leur efficacité potentielle est un puissant outil de leadership du changement.

Même lorsque tout le monde est enthousiaste à bord, vous devez toujours vous attendre à des départs difficiles. Les équipes habituées au développement Waterfall traditionnel et aux grandes versions, par exemple, peuvent avoir du mal à passer à un processus de développement plus itératif et agile, même si elles en voient la valeur. "La première augmentation de programme que nous avons faite a été une sorte de désastre pour les équipes", explique Villena. « Et nous savions que ce serait le cas ; nous avons dit au client de s'attendre à ce que les trois premiers mois soient difficiles. Pour compenser cela, il a intégré une itération unique d'une semaine à la fin du premier incrément de programme (PI) au cours de laquelle les équipes pouvaient évaluer leurs progrès. Il a organisé un sprint consacré uniquement aux améliorations de processus et aux évaluations qui iraient au-delà de l'inspection et de l'adaptation habituelles. Il a trouvé utile d'appliquer un état d'esprit Agile non seulement au produit mais aussi à la transition de l'entreprise, en prenant le temps de prendre du recul, de voir ce qui a fonctionné et ce qui n'a pas fonctionné, et de s'adapter en conséquence.

Créer de petites victoires

Il est important d'être préparé aux obstacles inattendus dans votre adoption de SAFe. Il y a quelques années, le chef de projet Toptal, Miroslav Anicin à Belgrade, en Serbie, effectuait la transition d'une entreprise de télécommunications vers SAFe. L'entreprise avait externalisé l'ensemble de son développement logiciel. L'intégration d'une équipe hors site n'était pas une tâche particulièrement onéreuse - les problèmes impliqués étaient principalement logistiques. Mais l'effort a créé des défis imprévus dans la transition de l'entreprise elle-même. « Je cherchais les compétences dont nous avons besoin dans le train de lancement », dit-il. "Et toutes les personnes parmi lesquelles j'ai dû choisir appartenaient au marketing, au juridique, aux produits, à la finance - sans aucun état d'esprit Agile ni même aucune expérience en Agile."

Il est devenu évident que la direction n'avait aucune expérience dans la gestion d'équipes Agiles. La prise de décision distribuée oblige les gestionnaires à renoncer à un certain contrôle, un fait auquel les dirigeants peuvent rechigner s'ils ne sont pas expérimentés avec les cadres Agile. Pour résoudre ce problème, Anicin a dû s'entraîner de bas en haut et de haut en bas, en entraînant les dirigeants avec leurs équipes.

Une telle évolution vers une prise de décision plus décentralisée nécessite « de changer la façon de travailler du commandement et du contrôle, en passant par le leadership des serviteurs, vers cette culture d'apprentissage et d'Agile habilitante, et la capacité de tolérer les erreurs », déclare Leffingwell.

Anicin a commencé le processus de mise à l'échelle progressivement - avec de petits projets Agile réalisés au sein d'équipes individuelles, et non dans un cadre SAFe - afin que les équipes individuelles puissent développer une expérience pratique. Ces projets devaient être non essentiels et suffisamment petits pour que l'entreprise ne soit pas lésée si quelque chose tournait mal du premier coup, mais suffisamment utiles pour montrer à l'équipe ce qui pouvait être accompli avec l'approche. Par exemple, l'équipe marketing a créé une campagne de marketing interne, au cours de laquelle Anicin leur a enseigné les bases de Scrum. Semblables à l'atelier de Villena, ces petits projets démontrent la valeur d'Agile en termes réels, afin que les membres de l'équipe et la direction puissent voir les avantages des versions courtes et de l'amélioration continue avant la transition à grande échelle.

Répondre aux besoins de vos équipes

Lorsqu'Imane Marouane, chef de projet Toptal basée à Paris, a dirigé la transformation d'une grande institution financière multinationale, elle est entrée dans un environnement chaotique où les équipes individuelles produisaient un travail solide mais ne partageaient aucune vision à l'échelle de l'entreprise. « Chaque équipe avait sa propre priorité. Chaque chef de produit voulait que son produit soit livré en premier.

La solution de SAFe à ce problème peut être trouvée dans le modèle WSJF (Weighted Shortest Job First). WSJF fournit une norme pour hiérarchiser le travail afin que, lorsqu'il est temps de décider quelle devrait être la prochaine tâche, la première étape n'implique pas de conflits sur la façon de classer l'importance. Dans un système Agile basé sur les flux, vous n'avez pas à vous soucier de tout livrer en même temps car, comme le dit Leffingwell, « la chose la plus importante est le travail à faire ensuite. Et c'est une question à laquelle il est beaucoup plus facile de répondre que quel est le travail le plus précieux. SAFe fournit un moyen de résoudre les dépendances entre les équipes - l'ordre des tâches est essentiel pour ce résultat.

Le chemin de Marouane vers la résolution des dépendances est devenu incertain : "Après deux sprints, avant la première inspection et adaptation, nous avons remarqué que certaines équipes ne suivaient pas notre plan PI." Les dépendances qui étaient définies dans le PI plan n'étaient pas suivies, donc le travail d'une équipe n'a pas pu commencer car la contribution d'une autre équipe n'était pas prête.

« Comme il s'agissait de la première itération et que les équipes n'étaient pas habituées à ce genre de travail, nous avons décidé de mettre en place une cérémonie supplémentaire, une réunion hebdomadaire pour discuter de l'avancement des dépendances », explique Marouane. "Une personne de chaque équipe est venue faire le point sur l'avancement de ses contributions." De cette façon, si l'équipe A disait qu'elle n'était pas en mesure de livrer, l'équipe B pouvait le savoir à l'avance et planifier en conséquence, au lieu d'attendre des contributions qui n'allaient pas se concrétiser au début de leur sprint.

Leffingwell prêche la prudence lors de ces types d'ajustements à SAFe : « SAFe est un système de responsabilités. … Vous pouvez l'adapter, mais vous devez être très prudent. Bien que le cadre soit conçu pour être adaptable, les changements ont tendance à être intégrés s'ils ne sont pas réévalués. La configuration Essential SAFe existe pour s'assurer que toute modification répond aux critères de base.

La cérémonie supplémentaire de Marouane a été incluse à nouveau dans le deuxième PI, et par le troisième, elle avait été progressivement supprimée. Les équipes n'avaient rien à signaler qui n'ait déjà été communiqué. Un peu de flexibilité supplémentaire a permis à Marouane de remettre les équipes sur une voie de processus plus traditionnelle. Elle a constaté que la transition elle-même nécessitait un état d'esprit Agile pour tirer le meilleur parti des équipes de l'institution financière. Et surtout, le changement qu'elle a apporté, grâce à son engagement envers l'amélioration continue, a finalement servi les principes Lean-Agile qui sont à la base d'Essential SAFe. Sa solution a donné à l'entreprise la vision unifiée qui lui manquait et a permis aux équipes de travailler ensemble vers les mêmes priorités.

Adaptez-vous pour l'avenir

Tout cadre fonctionnant à grande échelle s'accompagnera de défis. Le nombre de pièces mobiles et d'intérêts concurrents est immense. Mais les bénéfices sont tout aussi importants, et une transition bien exécutée donnera aux équipes les outils dont elles ont besoin pour travailler vers des objectifs communs. Les obstacles auxquels vous serez confrontés dans une mise en œuvre à si grande échelle seront imprévisibles, et un état d'esprit Agile a aidé Villena, Anicin et Marouane à s'adapter à des défis inattendus. Après tout, c'est à cela que sert la livraison continue : donner à votre processus les outils nécessaires pour s'adapter à l'imprévu.

Scaled Agile s'adapte également aux nouvelles technologies et aux normes de l'industrie en évolution, en introduisant de nouveaux outils et capacités si nécessaire. Tout le monde doit rester agile et se préparer à l'inattendu. "Nous n'avons pas de boule de cristal", déclare Leffingwell. "Nous courons juste vite, menons dur et suivons dur - et écrivons aussi vite que possible."