Agile Fluency

Charles Pépin : “Un modèle est exemplaire et inspirant parce qu’il est inimitable”.

Court rappel sur ce qu’est “Agile Fluency”

Agile Fluency est un modèle permettant à une équipe de se situer dans une grille de 4 zones ou lieux plus ou moins favorables selon son contexte, afin d’envisager plus clairement l’évolution de ses pratiques en fonction de ses intentions et des moyens qu’elle est prête à accorder à cette évolution. Ainsi, un niveau n’est pas considéré meilleur ou pire qu’un autre dans l’absolu. La dynamique de progrès est à analyser, penser, organiser de façon contextuelle, comme souvent, et par introspection. Une équipe peut décider de rester dans un même lieu et continuer à se développer, ou vouloir en changer pour en tirer d’autres bénéfices.

La source

• Le schéma simplifié des 4 états d’Agile Fluency

• La proposition de valeur des auteurs

James Shore et Diana Larsen ont créé le modèle à partir de leurs observations et expériences personnelles. Martin Fowler a donné du crédit à cette initiative dans un article en 2012.

En 2014, les auteurs ont créé Agile Fluency Project, qui est une offre de formation et de consulting à destination des coachs, consultants, agents du changement pour aider à mettre en pratique le modèle. Les informations sur le site laissent entrevoir des approfondissements sur la théorie du changement et surtout sur la mise en pratique, plus actionnable du modèle.

Le Modèle Agile Fluency est une marque déposée. Un document explicatif d’une vingtaine de pages, actualisé en 2018, est disponible gratuitement et sans inscription en ligne. La licence CC permet à chacun d’en faire bon usage en citant la source.

La grille

Niveau	Objectif	Pratiques	Prérequis	Antipattern
FOCALISATION	Se focaliser sur ce qui a le plus de valeur	Scrum Product Owner: Priorisation par la valeur, Kanban: Limiter le TAF et flux tiré	Communication avec les parties prenantes	Dire oui à tout, manque de feedback
LIVRAISON	Accélérer les boucles de feedback en commençant par diminuer la part d’incertitude relevant de la technique par de l’automatisation	Rétrospective d’amélioration du processus de développement et de l’équipe pour lever les obstacles, Définition de Fini, DevOps, Kanban Flux: Diminution des gaspillages/anomalies, One Piece Flow	Un cadre de travail sécurisant défini pour l’équipe de façon suffisamment durable, le temps d’une saison	Livrer alors que ce n’est pas fini, engagement sur la vélocité, pas droit à l’erreur
OPTIMISATION	Prendre de meilleures décisions au bon moment	Etre à l’écoute des parties prenantes et adapter la solution en continue par la coopération, Lean Startup, Innovation frugale	Transparence Partage d’intérêts communs et synchronisation avec les parties prenantes, du mou/du jeu pour la créativité	séparation entre décideurs/réalisateurs avec des allers-Retours dans les décisions, occupation à 100%
RENFORCEMENT	des composantes et des liens dans l’organisation	Sociocratie, Holacratie, Organisation apprenante, Essaimage des pratiques	Volonté de changement de culture managériale, organisationnelle	Changer pour changer … Changer localement au détriment d’une valeur globale pour les parties prenantes

L’utilisation par la communauté

Claude Aubry et Pablo Pernot ont vu très tôt l’intérêt du modèle. J’ai pu le découvrir à l’occasion d’un raid agile en 2016 dans les Cévennes. A cette époque, on entendait beaucoup parler du “modèle Spotify”, de Squads, Tribes et autres Chapters pour restructurer l’entreprise. Mais c’était oublier le parcours de construction unique de Spotify qui a conduit à l’invention et mise au point de nombreuses pratiques, de façon purement empirique et contextuelle. Aujourd’hui, beaucoup ont compris les dangers de transposer des modes de fonctionnement complexes d’une entreprise à l’autre. Il ne suffit pas d’extraire ce que l’on croit comprendre de bonnes pratiques et de demander leur application, pour apprécier une quelconque amélioration.

Aussi, Claude et Pablo l’ont proposé sous la forme d’un atelier qui part du référentiel de chacun, constitué de l’ensemble des pratiques agiles que l’on connaissait, en les classant selon 2 axes :

• l’axe des niveaux d’agile Fluency
• l’axe de maîtrise

La version traduite en français et expliquée par Claude Aubry dans cet article

Si certains d’entre vous sont allés plus loin, ont trouvé des compléments ou des utilisations différentes, n’hésitez pas à m’en faire part. Ecrivez-moi.

Retour d’expérience pratique et interprétation personnelle

Dans mes accompagnements, j’utilise ce modèle principalement en phase d’observation, en complément d’autres modèles (*), pour répondre à quelques questions factuelles sur des choses visibles ou que l’on peut entendre:

• les pratiques ou habitudes de l’équipe => ce qu’elle fait
• les accomplissements ou résultats => ce qu’elle obtient
• les intentions et injonctions sur ce qu’il convient de faire ou ne pas faire => pourquoi elle fait ce qu’elle fait, et comment elle le fait

Le recueil de ces informations permet de dessiner un profil actuel et un profil rêvé de l’équipe, avec des compétences acquises, en cours d’acquisition ou que l’on souhaite acquérir. Ce qui est intéressant c’est qu’il y a rarement de consensus sur l’un ou l’autre des profils du moins au début des discussions. Sur le lieu actuel, certains “optimistes” s’imaginent plus performants qu’ils ne sont en réalité au regard des faits. D’autres au contraire ne voient que ce qui ne va pas, et peuvent penser ne pas mériter encore leur place dans la zone la moins ambitieuse de la grille.

Question pratique: Comment s’effectue le recueil et la consolidation des informations ?

Au choix: Interview de chacun des acteurs / Sondage en ligne / Atelier collaboratif

L’alignement de l’ensemble de ces perspectives, comportements et objectifs conforte la situation de l’équipe sur tel ou tel niveau de la grille. Dans l’éventail des pratiques agiles ou d’autres propres au domaine

Les capacités de l’équipe peuvent donner quelques signes sur l’adhésion aux valeurs et principes agiles. La grille peut donc éclairer la situation de l’équipe, révéler les comportements plus

En général, un premier entretien mené avec le client manager d’équipe, dirigeant avec un support minimal, permet de: 1- clarifier la situation, le sens de l’organisation et la cohérence des forces en présence 2- clarifier l’objectif et la demande d’accompagnement

C’est à ce moment que j’imagine la suite, et la pertinence du modèle à présenter et à renseigner avec l’équipe.

L’intérêt du modèle est d’être suffisamment simple pour permettre à l’entreprise de rapidement se situer, et de pressentir les efforts nécessaires à ses ambitions.

Exemple de questionnement:

Si l’expression “être agile” est employée par le client, je pose souvent la question: “Que veut dire être agile pour vous, dans votre contexte ?”

Que cherchez-vous à accomplir de vraiment important et qui présente un enjeu actuellement, ou plus tard pour votre organisation ?

Références

• Agile Fluency Project, avec un ebook téléchargeable
• La scierie à pratiques (jeu inventé par Pablo à l’occasion d’une discussion informelle à un Agile Open Sud aux Angles (66). Souvenir, souvenir…, qui s’articule bien avec Agile Fluency)
• Spotify et ses plus de 50 pratiques
• Philomag
• Le modèle de Bruce Wayne Tuckman (FORMING-STORMING-NORMING-PERFORMING-ADJOURNING)
• Reinventing Organizations et Entreprises libérées