FAST, c’est un framework d’Agilité à l’échelle proposé par Ron Quartel, coach Agile (entre autres) basé à Seattle et qui a eu l’occasion de développer cet outil à l’occasion de l’une de ses missions. L’objectif était de pousser à l’extrême la notion d’auto-organisation et de fluidité d’équipe (comprenez, les personnes ne font pas partie d’une équipe en particulier mais se réorganisent en permanence). Résultat, une vingtaine de pages pour décrire le fonctionnement d’une organisation plus ou moins étendue (jusque 150 personnes) avec des unités temporelles de 2 jours. Comment ça peut marcher ? On vous en dit plus tout de suite !
FAST, c’est-à-dire ?
Pour parler de FAST, il faut conjuguer Open Space Technology et Open Allocation. Comprenez, pour l’un, qu’il s’agit de laisser les personnes décider sur quoi il est préférable de travailler, dans un environnement colocalisé, et pour l’autre, qu’il s’agit de laisser les personnes s’auto-organiser sur la meilleure façon de travailler ensemble. Ces deux critères sont à la base de ce framework, combinée avec le découpage et l’animation du (des) produit(s). Celui-ci se rapproche d’un Story Mapping classique permettant de prioriser le travail à faire et de diffuser la vision produit.
Ces éléments vont donc permettre d’animer des cycles de valeur (et non pas des itérations) de 2 jours, dans lesquelles on trouve une seule réunion qui termine le cycle en cours et ouvre le suivant, en faisant à la fois le bilan du travail réalisé et en re-mélangeant le travail à faire.
Le diagramme suivant résume en quelques images le fonctionnement d’un cycle FAST (source twitter @FSTAgile) :
OK, mais comment en savoir plus ?
Ce qu’il y a d’intéressant avec FAST, c’est que le framework est tout jeune (imaginez découvrir Scrum alors qu’il sort tout juste des cartons de Ken Schwaber et Jeff Sutherland), et encore dans sa phase de consolidation. Vous retrouverez le guide sur le site officiel, mais avant de vous plonger dedans, le Case Study est une étape fortement recommandée. Cet article raconte comment FAST est venu au monde, dans le cadre d’une mission au sein d’une mutuelle Américaine. Le processus, les difficultés rencontrées et leur gestion, permet de mieux comprendre le contenu du guide. Surtout, si vous souhaitez en savoir plus et contribuer, un Slack est ouvert aux personnes que le sujet intéresserait. N’hésitez pas à contacter Ekité pour obtenir un lien d’invitation.
Et si on en discutait directement avec le fondateur ?
Ron Quartel le créateur de FAST
L’avantage des outils qui se structurent, c’est que les personnes qui en sont à l’origine sont généralement disponibles pour en parler. Nous avons donc pu obtenir un rendez vous en visio avec Ron Quartel, le fondateur de FAST. En direct de Seattle où il était 6h du matin pour lui, nous avons pu faire connaissance, échanger et poser les questions que nous avions. Ron est quelqu’un de très curieux et accessible, on sent la volonté de contribuer au développement de l’agilité en apportant cette méthode issue de sa propre expérimentation et non la volonté de vendre un framework.
Fast est encore au stade de recherche et d’expérimentation, James Shore (auteur de « The art of Agile Development ») mène en ce moment des tests de FAST sur son projet. Plusieurs fois au cours de l’entretien Ron nous a répondu : « Il faudrait tester », loin de penser avoir toutes les réponses il nous propose d’apporter notre pierre à l’édifice en expérimentant nous-même et en contribuant. Il nous a même invité à proposer nos idées pour le nommage de certains détails qui pourraient être déceptifs (l’étape du Show & Tell notamment, à ne pas imaginer comme étant une Démo Scrum mais comme un passage en revue rapide).
Ron a insisté sur la notion de « bulle d’autonomie » : il est nécessaire d’avoir suffisamment de marge de manœuvre pour pouvoir mettre FAST en place. Il faut également un management qui laisse de l’espace et qui autorise l’expérimentation. Son seul regret sur son expérimentation est le changement de management qui a mis fin à cette aventure. Il nous a parlé de « TEAL management » qui est le dernier stade d’évolution d’une organisation qui s’approche de l’auto-gouvernance d’après Frédéric Laloux (dans Reinventing Organizations : Vers des communautés de travail inspirées).
La gouvernance de l’équipe
Nous avons aussi pu parler de l’importance de lancer cette approche accompagné de personnes volontaires et motivées par ce mode de fonctionnement, tout le monde n’est pas demandeur de plus d’autonomie et cela peut être un frein au lancement de FAST. Dans la dimension humaine toujours il a plusieurs fois insisté sur l’importance de très vite se mettre d’accord sur la notion de « Tribe Agreement » (comment les décisions seront prises ensemble et comment les conflits seront résolus ) pour avancer sereinement vers la suite.
Certaines de nos questions touchaient à l’autonomie et aux problèmes qui auraient pu en découler, nous étions curieux par exemple de savoir si les tâches de run n’étaient pas délaissées, si les tests et les release se faisaient également en bonne harmonie. Le problème ne s’est jamais présenté sur son projet, l’expérimentation de Fast avait justement démarré parce que plusieurs produits étaient gérés en parallèle par son équipe et qu’il ne voulait pas « punir » les plus anciens développeurs en les faisant travailler sur la partie Legacy. En affichant tout sur la Product Map toutes les tâches sont identifiées (même les tests ou les release apparaissent, il n’y a pas de tâche implicite) et l’équipe se les répartit en bonne intelligence sans besoin d’assignation de la part du Product Manager. La notion de responsabilité collective est plusieurs fois revenue.
L’ajout de règles de fonctionnement supplémentaires se fait quand et si nécessaire, Ron a pris l’exemple de la partie Run qui a été affichée à part sur un kanban par son équipe pour plus de visibilité.
Et nous, qu’est-ce qu’on en pense ?
Sur le papier cette approche FAST basée sur l’Open Space Technology semble prometteuse. La mise en place est simple, le travail à accomplir est visible de tous et l’auto organisation permet à chacun de travailler sur les sujets qui l’intéressent sur des cycles très courts.
Les prérequis nécessaires à son bon fonctionnement ne sont néanmoins pas anodins : un management qui accepte de jouer le jeu et des personnes volontaires en quête d’autonomies sont nécessaires pour un essai transformé.
Nous n’avons pas encore pu expérimenter ce framework, faute de contexte adéquat pour le mettre en place, néanmoins nous aimerions avoir l’occasion de le faire à l’avenir.
