Dans mes précédentes publications, j’ai régulièrement évoqué SAFe. Tout d’abord en faisant une conférence « Panorama des frameworks Agile à l’échelle » à Agile en Seine 2021 disponible en vidéo puis un article « Pourquoi adopter le framework SAFe et pas un autre ?« qui donne de nombreuses raisons de choisir le framework SAFe plutôt qu’un autre.

Pour me faire ma propre opinion, j’ai moi-même déployé SAFe dans un grand programme, 4 trains et un niveau solution, dont j’ai partagé un compte rendu lors d’une Conférence chez Orange « Retour d’expérience en vidéo : 18 mois d’un programme Agile avec 500 collaborateurs« .

Pourquoi ce questionnement en titre de cet article ? Parce qu’il y a débat ! SAFe représentait jusqu’alors un bon tiers des déploiements d’Agilité à l’échelle. SAFe a son lot de détracteurs qui voient un framework contraire aux principes Agile car trop codifié, trop formaté avec trop de rôles silotés ou une machine à dollars avec ses formations de 2 jours minimum obligatoires pour tous et un questionnaire de passage de la certification avec des questions ambigües. C’est vrai ! Mais SAFe a également son lot de promoteurs qui voient en lui un processus efficace et adapté aux grandes organisations avec des objectifs clairs attendus à court terme (dans le trimestre) permettant de mesurer un avancement réel. Et puis il y a les équipes qui, lorsqu’elles pratiquent SAFe, l’apprécient,  ne le remettent pas en cause et ne veulent pas revenir en arrière.

Impossible de concilier les uns et les autres qui basent leurs expériences sur ce qu’ils ont vécu. Il y a certes de grands succès mais aussi nombre de déploiements Agiles, qu’ils soient SAFe ou pas,  bancales et/ou incomplets limitant l’efficacité de ce qu’ils devraient obtenir.

Le marché a toujours raison. Il ne faut jamais l’oublier. En 2022, une bascule s’est opérée : SAFe représente dorénavant plus de 50% des frameworks Agile utilisés. Et ce n’est pas anodin. Passer la barre des 50% signifie qu’il n’y a plus débat !

Selon le 16ème rapport annuel de l’état de l’art du déploiement Agile publié par Digital.ai fin 2022, le framework SAFe est adopté dans 53% des cas (37% en 2021), devant son challenger Scrum@Scale / Scrum of Scrums qui est adopté dans 28% des cas (9% en 2021) et plus adapté dans les situations impliquant moins de 50 collaborateurs. Les autres frameworks sont beaucoup moins déployés. « Some other framework » n’est plus qu’à 8% alors qu’il représentait 19% en 2021 sous l’appellation « Don’t know », ce qui correspond aux frameworks maison.

Cela conforte ce que je disais dans mon article « Pourquoi adopter le framework SAFe et pas un autre ?« . Si votre projet / programme implique :

• plus de 50 personnes, préférez SAFe
• Entre 10 et 50 personnes, préférez Scrum at Scale, plus léger que SAFe
• moins de 10 personnes, choisissez Scrum

Ainsi, les 28% de Scrum at Scale correspondent très probablement à des projets à l’échelle de moins de 50 personnes.

Ce qui est important de noter, c’est que cette montée de SAFe et dans une moindre mesure de Scrum at Scale se fait au détriment des frameworks maison. Cela veut dire que la question d’utiliser un framework du marché plus qu’une invention maison est maintenant au cœur de la stratégie des entreprises. Le bricolage ou les POC ne sont plus de mise. Les entreprises s’industrialisent autour de l’Agile. Même si l’adaptation au contexte de l’entreprise reste clé pour son adoption.

Les autres frameworks, bien que toujours utilisés, représentent une part non significative du marché (moins de 8%).

Comme je le disais en titre : en 2023, il n’y a plus débat !

Je suis pratiquant de l’Agilité à l’échelle depuis 10 ans et SPC depuis l’année dernière. SPC est le diplôme donné par SAFe à ceux qui sont en mesure de déployer SAFe en entreprise. Je publie une série d’articles concernant SAFe en ayant à la fois le bagage théorique et la pratique de longue date. Le contenu reste mon avis personnel, donc discutable, mais avisé.

Il existe de nombreux frameworks Agile. SAFe ou Scaled Agile Framework est aujourd’hui le plus populaire. Effet de mode ou vrai évolution ? Faut-il adopter ce framework ou se tourner vers un autre ? La réponse est OUI ! SAFe est LE framework à adopter et cet article va vous expliquer pourquoi. Mais attention, SAFe n’est pas adapté à tous les contextes. Explications…

Lire la suite

Le nouveau Scrum Guide attire toute les convoitises comme le nouveau catalogue Ikea (c’est à dire pour les personnes qui s’intéressent au sujet), sauf qu’il ne sort pas chaque année ce qui en fait un événement.

Ce qu’il en ressort, c’est moins de pages, donc moins de contenu. Je comptais comme en 2017 faire un article de synthèse sur ce guide, mais comme à chaque fois, d’autres coachs sont plus rapides que moi. Alors plutôt que de refaire une nième analyse, je vous redirige directement vers l’analyse qui me parait la plus riche, celle de Bruno Margueritat, « Scrum Guide 2020« .

Pour ceux qui préfèrent le guide complet de 13 pages pour se faire une opinion, il est disponible en français et en anglais sur le site officiel.

J’aurais aimé être l’auteur de cet article. Mais je me suis fait doubler par Nicolas Lochet et je lui en suis reconnaissant parce que son analyse est juste et, je trouve, pas trop partisane. Je remercie aussi le collègue qui m’a fourni cette analyse d’expert très intéressante : « Peut-on aimer SAFe quand on est agiliste ? »

Pour résumer très simplement les choses et inclure les personnes larguées par le sujet, SAFe est une proposition de cadre pour pratiquer de l’agilité dans des contextes où il y a plus de 50 personnes qui travaillent ensemble et pouvant aller jusqu’à l’échelle de l’entreprise complète.

Les détracteurs de SAFe pensent que ce n’est pas Agile car trop structuré, laissant entendre que l’agilité, c’est la déstructuration à l’extrême. En fait, même Scrum, qui est fait pour une équipe de 10 personnes est très structuré. C’est ensuite ce que l’on en fait qui est efficace ou brouillon.

Mais quand on commence à travailler dans un eco-système impliquant plus de 50 personnes, SAFe devient une grande aide car il apporte des réponses aux très nombreuses problématiques que l’on se pose lorsqu’on déploie de l’agilité. Et quand on regarde les propositions « concurrentes », LeSS, DAD, Nexus, Scrum@Scale, pour ne citer qu’eux, et bien les réponses n’y sont souvent pas, sauf pour les plus simples qui sont finalement assez proches de ce que propose SAFe.

Les détracteurs répondent alors que SAFe est trop complexe. Mais qui a dit qu’il fallait tout prendre de SAFe ? On regarde la boite à outils, on prend ce qui nous intéresse, et si on constate un dysfonctionnement, on re-regarde la boite à outils pour voir si on n’a pas oublié quelque chose d’important, c’est tout.

Je fais partie de ceux qui ont déployé un framework alternatif venant d’un cabinet de consulting. Dans les grandes lignes, c’était aligné avec SAFe, mais dit différemment. Et puis, il y avait des zones d’ombres… Pour les combler, il ne restait qu’un moyen : se retourner vers ce que SAFe propose.

Le grand défaut de SAFe, c’est la machine commerciale qui est derrière. On doit suivre les formations comme ça et pas autrement. Il faut renouveler sa licence chaque année. On n’a pas le droit de former si on n’est pas SPC et qu’on n’a pas sa licence à jour. On paye pour chaque personne formée. Les slides n’ont pas le droit d’être diffusés tant que la formation n’est pas donnée et payée. Tout cet aspect est horrible et peut justifier à lui seul de dire qu’on ne fait pas du SAFe mais quelque chose qui y ressemble. C’est vrai.

Mais au bout du bout, le truc qu’on ferait qui y ressemble, finalement, il y ressemble beaucoup… ou alors ça ne fonctionne pas.

En attendant, lisez le long article de Nicolas Lochet : « Peut-on aimer SAFe quand on est agiliste ?« 

2016 aura été pour moi une année exceptionnelle ! Un feu d’artifice de bonnes choses !

C’est certainement l’année où j’ai le plus progressé dans ma carrière. C’est l’année de l’Agilité à l’échelle. L’année où mes coachings sont tous devenus plus gros (30 personnes et plus). L’année où ce que je n’osais pas faire n’est plus une difficulté pour moi. J’ai pris énormément de risques et cela a payé. Même si je n’ai pas été parfait sur tous les points.

En 2016, j’ai fait une moisson très riche de formations reçues, pour la plupart certifiantes, toutes dans la même thématique :

• Lean Engineering, Thales
• Certifié SAFe Agilist (SA) – Scaled Agile Framework
• Certifié coach Agile niveau 1 et 2 (ICP-ATF & ICP-ACC) – ICAgile
• Certifié Entreprise Agile – Unow

En 2016, j’ai donné 2 conférences ambitieuses (slides et vidéos disponibles derrière les liens) qui ont été le fil rouge de mon activité de l’année :

• Le contrat Agile, ce n’est pas si simple que ça, à Agile France en juin 2016
• Qu’est-ce qu’une Entreprise Agile ?, à Agile Tour Paris, Aix-Marseille et Sophia Antipolis en novembre et décembre 2016

En 2016, j’ai travaillé en interne dans ma société sur des sujets de fond importants :

• Rédaction d’un contrat Agile acceptable pour l’entreprise conjointement avec le service juridique
• Construction d’un workshop Agile d’une journée pour l’ingénierie système (le cœur de métier de mon entreprise)
• Réflexions avancées sur la transposition de l’Agile dans un contexte d’ingénierie système
• Début des travaux sur l’Entreprise Agile

En 2016, j’ai du innover dans mes coachings.

Par exemple, l’un de mes commanditaires m’a dit avant de démarrer, « on veut faire de l’Agile, mais pas du Scrum ». A ma question « Pourquoi ? », il n’a pas su me répondre. Je suis entré en immersion dans le projet, de plus de 30 personnes, avec cet énoncé, pour finalement… ne jamais évoquer Scrum. Je les ai aidé à mettre en place des outils issus de Lean pour partager une vision et se synchroniser, à s’organiser pour avoir des rôles clairs de Product Owner et d’équipiers, et j’ai introduit en douceur le sprint planning, le daily meeting, la démo et la rétrospective. Mais on ne fait pas de Scrum 😉

Dans un autre coaching, mon commanditaire m’a appelé pour résoudre son petit problème, dans un contexte de plus de 30 personnes : « On a tout essayé, on n’arrive pas à anticiper et gérer nos dépendances entre plusieurs équipes ». J’ai introduit le Release day, inspiré de SAFe, avec un regroupement fonctionnel inter-équipes plutôt que par équipe. Cela n’a pas tout résolu, mais l’équipe en redemande. Elle a maintenant une vision claire à minimum trois mois. J’ai également introduit la notion de cellule PO, composée du PO, des proxy PO et des architectes logiciels, afin de préparer ce Release day et d’anticiper le futur.

En 2016, je n’ai donné que cinq formations Agiles de trois jours, dont une en anglais à Bucarest en Roumanie avec 39 personnes (épique !), ayant consacré mon énergie sur d’autres formations spécifiques d’une seule journée. Cette formation, à destination des développeurs, leur permet de mettre le pied à l’étrier sur l’Agilité et Scrum. Elle est composée à 50% d’ateliers et de jeux. En tant que formateur, quand je donne peu de formations, je suis frustré et j’ai envie de tout donner lorsqu’il y en a une. Et j’ai visiblement tout donné au vu d’une appréciation reçue qui m’a particulièrement marquée : « Très bon animateur qui transcende la formation grâce à ses valeurs humaines ».

Et annexement, cette nouvelle année a aussi été l’année de l’arrivée de mon second enfant. Une année très riche ! Et vous ?

Il est temps maintenant de parler de 2017, une année très prometteuse, dans la continuité de 2016.

Cycle en V, Kanban, Scrum, etc… des méthodes différentes pour réaliser la même chose : un produit ! Mais comment comprendre les avantages et les inconvénients de chaque méthode en 2 heures ? Avec des Legos bien sur ! Le Lean Lego game est un jeu qui permet d’expérimenter les différentes méthodes et comprendre rapidement leurs différences.

J’ai eu la chance de découvrir ce jeu lors du meetup « Jeux en Kanban … retenter votre chance » du French Kanban User Group le 17 juin 2014. Oui, j’avoue, je suis en retard pour le compte rendu. L’animateur du jeu était Yannick Quenec’­hdu. Ce jeu n’est pas tout jeune puisqu’il a été joué la première fois en 2008, à Buenos Aires en Argentine. Il est la création de Danilo Sato. A partir de son site, vous avez la possibilité de le contacter pour obtenir un set d’animation du jeu. Il y a également des slides qui présentent le jeu. Le principe du jeu est également décrit sur le site Lean Simulations.

En résumé, nous devons dérouler le même jeu par équipes de 8 personnes. Deux équipes fonctionnent en parallèle soit 16 personnes en tout. Dans le premier déroulé, nous pratiquons le cycle en V. Notre production est limitée et le stock est énorme. Le stock, c’est de l’argent. Il va donc en déduction de nos recettes. Bilan : avec le cycle en V, nous perdons de l’argent. Ensuite, nous testons respectivement Scrum, Kanban puis Lean. Et à chaque fois, on s’améliore. Le but du jeu était de fabriquer le plus de petites maisons comme sur la photo ci-dessous.

En utilisant le même temps, avec le cycle en V, nous avons pu construire 3 maisons alors qu’avec la meilleur des méthodes, nous avons pulvérisé tous les records, de mémoire 34 mais je n’en suis pas certain. Yannick lui-même n’y croyait pas ! Ce jeu est un excellent outil éducatif et j’espère pouvoir l’animer personnellement très prochainement !

Au vu des slides trouvé sur le site de l’auteur, je pense que Yannick a un peu adapté le jeu pour passer les messages qu’il souhaitait. J’ai trouvé cela très efficace.

Pascal Jussac, coach Agile à Thales, donc un de mes collègues, a proposé d’animer le jeu Lego4Scrum, un jeu en licence Creative common dont le site officiel est lego4scrum.com, lors du meetup du 17 décembre 2014 organisé par AgileDojo chez Agilbee. Nous utilisons ce jeu le 3ème jour de la formation Scrum que nous animons à Thales après avoir expliqué de fond en comble ce qu’est l’agilité, Scrum, XP et consorts. Notre version est remaniée par rapport à l’original. C’est la cerise sur le gâteau qui clôture en beauté notre formation par une mise en pratique complète de Scrum, excepté le daily meeting. Les groupes sont de 12 personnes, parfois 14 ou 15, jamais plus.

C’est en voyant qu’il y avait 50 inscrits qu’il m’a demandé un coup de main que je me suis empressé d’accepter. Nous sommes arrivés non pas avec une boite de Legos, mais deux. Pour la première fois, nous allions construire non pas une ville, mais une agglomération de deux villes : la ville écolo, avec beaucoup de verdure et la ville futuriste, avec des véhicules à roues carrées (j’avais oublié d’apporter mes roues).

Environ 25 personnes sont venues et les retours ont été enthousiastes. Certains participants débutaient en Agile et ont donc appris à vitesse grand V. D’autres avaient déjà joué à ce jeu par le passé et on trouvé notre animation beaucoup plus riche et punchy que ce qu’ils avaient vécu. Merci à tous d’avoir participé à ce dernier meetup de l’année !

Pour en savoir plus, allez sur la page du Meetup d’Agile Dojo, « Lego & Scrum Kata : Expliquer Scrum avec des Legos (Lego4Scrum) » où vous pourrez lire tous les commentaires des participants et voir les 100 photos qui ont été prises durant la soirée.

À l’occasion de la première rencontre organisée lundi 3 décembre 2012 par l’association Agile .Net dans les locaux de Microsoft, j’ai eu la chance de rencontrer pour la première fois Jeff Sutherland, le fondateur de la méthodologie Scrum. L’occasion pour lui de faire le point sur la situation de Scrum dans le monde et plus particulièrement aux États-Unis. Qu’a-t-il dit ? Compte-rendu.

Lire la suite

Grace à French Scrum User Group, j’ai participé à mon premier meetup, un scrum breakfast sur l’agilité chez Google animé par Petra Cross, une employée de Google San Francisco qui a travaillé sur des projets d’envergure, notamment Gmail. Google pratique très largement l’agilité et Petra vient nous expliquer comment. Il est intéressant de voir le nombre de points communs avec nos usages en France, mais aussi quelques différences. Compte-rendu.

Lire la suite

Une vidéo un peu décalée et en anglais mais qui résume parfaitement le rôle du Scrum Master dans la méthode Agile Scrum.

De plus, j’ai découvert que Youtube sous-titrait les vidéos basé sur l’écoute de la piste audio. Ça marche un peu… Ça permet surtout de voir comment les non anglophones comprennent les anglophones.

Merci Hamdi pour cette trouvaille.