FAST est l'acronyme pour Fluid Scaling Technology, une nouvelle approche radicale d'agilité à grande échelle
Après LeSS et SAFe, voici FAST.
Un choix de nom qui se discute, comme celui du livre Accelerate!, comme celui de sprint, mais un contenu nouveau et intéressant.
Si la science est largement évoquée, les gens ne sont pas oubliés
Le livre choisi pour le klub d’octobre était donc : Lean Enterprise: How High Performance Organizations Innovate at Scale de Jez Humble, Joanne Molesky, Barry O’Reilly.
Dans l’atelier Puzzle grand Scrum dont je parlais dans mon dernier billet, il y a donc 3 équipes qui concourent à la réalisation du puzzle. Le format du jeu pousse les équipes à se caler sur le même rythme.
En 2014, j’avais essayé un jeu de simulation de Scrum, avec un puzzle ; il mettait l’accent sur l’affinage et la présentation du backlog en bacs (notion qui est expliquée dans mon livre Scrum), c’était donc le jeu des bacs.
Début 2015, j’avais expérimenté une variante pour simuler du Scrum à plusieurs équipes.
Cette variante a reçu un très bon accueil, ce qui fait que je l’ai animée de nombreuses fois. J’ai eu du mal à lui trouver un nom. Cela a d’abord été “Astérix et la grande échelle de Scrum” parce que j’utilisais le puzzle “Le village gaulois”.
Finalement c’est “Puzzle grand Scrum”, un atelier que j’ai animé une quinzaine de fois :
Pour justifier qu’une équipe Scrum doit rester de taille raisonnable et surtout stable dans le temps, j’invoque souvent Tuckman et Brooks.
Le modèle de Tuckman et la loi de Brooks.
Scrum se diffuse inexorablement dans le domaine industriel, sur des programmes ou produits impliquant plusieurs équipes. Il m’arrive de plus en plus souvent d’être appelé pour du scaling Scrum. J’interviens actuellement pour accompagner des programmes spatiaux d’envergure qui ont fait le choix du développement agile.
Ken Schwaber vient de publier le guide Nexus, son framework de Scrum à grande échelle. Un de plus ! Cela en fait trois, au moins, qui se revendiquent de l'esprit Scrum : Nexus, SSwS et LeSS
Développer un produit avec plusieurs équipes
C’est le titre du 21ème chapitre de mon livre Scrum, édition 4. Quand plusieurs équipes travaillent sur le même produit, un point délicat est la mise à l’échelle du rôle de Product Owner ainsi que l’affinage à haut niveau.
J’ai passé une bonne partie des ces dernières années à réfléchir à l’utilisation de Scrum sur des gros projets et à mettre en place ce passage à grande échelle pour des organisations.
Les enseignements que j’en ai tirés, j’ai commencé à en parler sur ce blog et ils pourraient être présentés, qui sait, dans une 4e édition de mon livre Scrum, le guide de la méthode agile la plus populaire.
Par ailleurs je viens d’animer avec succès un atelier pour simuler l’organisation de plusieurs équipes qui collaborent à un même produit.
Quand décider quelle équipe s'occupe de quelle feature ?
Le passage à grande échelle avec des features teams demande une prise de décision supplémentaire : le choix de l’équipe qui va réaliser une feature.
Comme pour les travaux d’affinage sur les stories, il est souhaitable que cela se fasse autour de conversations, mais impliquant cette fois toutes les équipes.
C’est l’objet des sessions d’affinage et d’affectation des features.
Qu'est-ce qui change dans ce tableau quand on passe à Scrum à l'échelle ?
Un tableau de features permet de montrer la décomposition du travail à faire et l’affectation aux différentes équipes dans le cadre d’un Scrum à grande échelle.
Le Large Scale Scrum ou Agilité à grande échelle, c’est un sujet ancien qui avait déjà été d’actualité en 2011. J’ai participé au mouvement : j’ai écrit le chapitre 19 de l’édition 2 de mon livre “Scrum à grande échelle” à cette époque, j’avais fait une présentation au ScrumDay 2011 et c’était aussi le thème de mes présentations aux conférences Agile tour de l’automne. Avec cette grande échelle, on avait parlé de l’Agilité des pompiers.
Je fais toujours du Scrum, certes, mais de façon différente et cela va bien au-delà
10 ans après ma transition de consultant à Scrum (oui, déjà, c’est en 2005 que j’ai mis Scrum sur ma carte de visite), je m’aperçois que mes activités sont très différentes de ce qu’elles étaient au début.
Je fais toujours du Scrum, certes, mais de façon différente et cela va bien au-delà.
Quelques exemples récents.
Le chapitre 19 de mon livre s'appelle Scrum à grande échelle. C'est un sujet délicat.
Le but du chapitre est présenté dans l’introduction :
On peut distinguer trois niveaux pour la prise en compte de l’agilité dans des organisations : projet, produits, organisation. Beaucoup d’expériences actuelles avec Scrum restent au niveau projet. Nous allons approfondir les niveaux produits et organisation. J’ai évoqué, dans le chapitre 18, Transition à Scrum, la façon dont une entreprise gérait le changement vers l’agilité. Ici, il s’agit d’aborder le changement d’échelle dans ce qu’il implique sur la mécanique de mise en œuvre de Scrum, en termes d’équipes, de backlogs et de cycle de vie.
Voici le support de la session « Expérimentation de l’Agilité pour un grand projet scientifique spatial » présentée à 3, avec Maurice Poncet (Cnes) et Laurent Meurisse au ScrumDay 2013[1].
L’objectif de la mission Euclid est de cartographier la géométrie de la matière noire et de l’énergie sombre.
Euclid est un projet, sous l’égide de l’ESA, dont les instruments et le segment sol scientifique sont réalisés par un consortium européen regroupant les principales agences spatiales nationales et laboratoires scientifiques, dont le Cnes.
Jeudi prochain le 11, au ScrumDay, je participerai à la présentation de l’expérimentation de l’Agilité pour un grand projet scientifique spatial.
Nous ferons la présentation à trois, avec Maurice Poncet, du CNES, et Laurent Meurisse. Il manquera le quatrième mousquetaire, Nicolas Deverge. Car nous faisons l’étude à trois consultants /coachs agiles.
L’objectif de la mission Euclid est de cartographier la géométrie de la matière noire et de l’énergie sombre. Euclid est un projet, sous l’égide de l’ESA, dont les instruments et le segment sol scientifique sont réalisés par un consortium européen regroupant les principales agences spatiales nationales et laboratoires scientifiques, dont le CNES. La NASA a rejoint le consortium fin 2012.
Piloter de gros projets avec Kanban, l'histoire de la police suédoise
Henrik Kniberg a publié Lean from the trenches chez The Pragmatic Programmers en fin d’année 2011. Il l’a écrit de façon itérative et a sorti plusieurs versions intermédiaires. C’est une de ces versions, le draft 0.9, que nous avons traduite.
Bien sûr, c’est avec l’accord d’Henrik :
Cette version draft est gratuite. Je l’ai rendue disponible pour ceux qui ont un budget serré et qui ne peuvent pas s’offrir le livre, ou qui souhaitent parcourir le draft pour se faire une idée générale de la portée du livre avant de l’acheter.
La question était :
3 équipes Scrum participent au développement d’un seul produit, chacune s’occupant d’un ensemble de features. Comment gérer la signification de fini ?
J’ai participé aux étapes toulousaines et bordelaises de l’Agile tour 2011.
Dans les deux villes, j’étais invité à présenter l’Agilité à grande échelle.
En tant que consultant, j’ai la chance de travailler dans des domaines variés. Après avoir accompagné Sarenza.com dans sa transition radicale et à grande échelle à Scrum[1], j’interviens sur le projet Sirius du CNES avec Thalès.
Il s’agit de développer le patrimoine de base de la dynamique du vol, sur lequel viendront se construire les futurs outils opérationnels pour les mises à poste et maintien à poste de satellites. Sirius consiste en des bibliothèques Java sur la base de OREKIT et Commons Math.
