FAST
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.
Je réfléchis actuellement à la partie 5 de mon livre Scrum édition 6. Les premières parties portent sur :
- l’équipe et son écosystème,
- les boucles de feedback,
- le prélude,
- les rites du sprint.
La 5e et dernière partie devrait s’appeler :
Coopérations
Pour préparer cette partie je lis et je réfléchis pour savoir ce que je garde de l’édition 5. Parmi mes lectures, il y a l’édition 2 du livre de James Shore, The Art of Agile, qui était à l’affiche du klub de lecture Agile Toulouse du 20 avril. Toujours en version provisoire, James Shore vient de publier le chapitre Scaling Agility1.
C’est toujours pertinent. Et en plus, il y présente un truc dont je n’avais pas encore entendu parler :
FAST, acronyme pour Fluid Scaling Technology
Ah, et le A entre le F et le S ? Pour Agile ? Non, bien que le sous-titre de FAST soit :
Agile for the Age of Disruption
Je viens le lire la version 2.1 de juin du guide FAST. C’est — disons — radical (ce qui nous plait beaucoup, à Anthony, Jean-Pascal et moi). Comme le dit James Shore, c’est tout neuf mais très prometteur.
FAST est basé sur les concepts de Forum Ouvert (Open Space Technology) et d’auto-organisation (Open Allocation). Cette dernière se situe à un niveau différent de celui de l’équipe Scrum, s’adressant à un groupe (appelé tribu) dont la taille peut allègrement dépasser une dizaine.
L’idée clé est celle d’équipes dynamiques : la tribu est stable, mais à l’intérieur les équipes se constituent lors de la place de marché (d’où la référence au Forum Ouvert).
Nous avions abordé le sujet Dynamic Reteaming au klub de lecture l’an dernier.
La radicalité de FAST tient surtout dans son cycle de valeur (value cycle). Ce n’est pas une boite de temps et c’est bien plus court qu’un sprint. Les auteurs suggèrent une durée de deux jours pour démarrer.
En ce qui concerne les rites, c’est simple : il n’y en a qu’un2, à chaque fin de cycle de valeur (tous les deux jours !). Il inclut trois étapes :
- l’équivalent de la démo (pour toutes les équipes de la tribu),
- le lancement du nouveau cycle avec ajustement de la vision (car oui, il y a une vision portée par le directeur de produit 3,
- la création et l’ouverture de la place de marché, au cours de laquelle les équipes se reforment, chacun se positionnant sur un sujet proposé par le directeur de produit ou émergent lors de ce forum ouvert.
C’est donc extrêmement léger ; à part le directeur de produit (en gros l’équivalent du PO unique), on a un steward (pour le dire vite un SM dynamique) pour chaque équipe de la tribu.
L’allocation dynamique étend la notion de fourmillement (ou butinage, swarming en anglais, au niveau de la tribu), avec éventuellement un steward par fonctionnalité (feature steward).
Dans l’édition 5, mon chapitre sur l’agilité à l’échelle s’appuyait sur LeSS. Il se pourrait bien que j’ajoute une partie sur FAST, qui est tout à fait dans l’esprit de l’édition 6.
Tout à la fin, vous trouverez une critique bien argumentée au sujet de SAFe. ↩︎
Et la rétrospective ? FAST n’est pas prescriptif sur le sujet de l’amélioration. Dans l’article qui raconte l’expérience à l’origine de FAST, elle est évoquée à un rythme mensuel et se déroule aussi sur le principe du forum ouvert. ↩︎
Product Director, ça me rappelle l’article de Brian Marick qui décidément était pertinent. ↩︎