Dorénavant, je publie mes articles sur mon blog nilslesieur.fr
Quelques notes, issues de la traduction que j’ai réalisée, avec l’aide des coaches benext, pour préparer le meetup Beyond Scrum Mastering du 2 juin 2020, pour aider les participants à suivre, pour relire a posteriori, au calme…
La traduction complète est disponible sur le blog d’agilefluency.org et sur le blog de Martin Fowler (rubrique traductions). Un grand merci à Diana Larsen.
Un peu d’histoire
James Shore et Diana Larsen ont conçu le modèle Agile Fluency à partir de leurs observations personnelles et de leur expérience terrain. Ils ont décrit le modèle en collaboration avec d’autres leaders de la communauté agile. Martin Fowler, qui a été l’un des premiers à soutenir le modèle, a publié leur article fondateur en 2012.
Depuis la fin des années 90, ils ont dirigé et aidé des équipes à faire la transition vers du développement agile. Pendant ce temps, le mouvement Agile est passé d’une passion centrée sur le programmeur, faite d’enthousiastes, d’innovateurs à un monstre qui s’est emparé du monde du logiciel. Malgré cette ferveur — ou peut-être à cause de cela — les approches agiles n’atteignent pas toujours ce que les gens en attendent.
Au cours de ces années, ils ont appris sur ce qu’il faut pour réussir avec l’agilité et pourquoi tant d’organisations ne voient pas les résultats qu’elles attendent. Et donc, en 2012, ils formalisent ces apprentissages sous le nom du modéle Agile Fluency.
Pourquoi l’utiliser ?
- Pour comprendre à quels avantages vous pouvez attendre de la part de votre équipe, de vos équipes agiles
- Ou pour comprendre quels investissements doivent être faits pour obtenir ces avantages
- Ou pour savoir où regarder lorsque vos équipes n’offrent pas les avantages dont vous avez besoin.
Le modèle en 2 mots
Le modèle est décrit 4 lieux distincts (pas des étapes ou des buts à atteindre, la distinction est importante et sera abordée plus bas) que les équipes, organisations peuvent traverser. Chaque lieu apporte des avantages spécifiques :
- Les équipes qui se concentrent, s’alignent sur la valeur métier produisent de la valeur métier. Ce sont les équipes Alignement (Focus Value).
- Les équipes qui se concentrent sur la livraison respectent la cadence du marché. Ce sont les équipes Livraison (Deliver value).
- Les équipes qui se concentrent sur l’optimisation de la valeur métier livrée sont en tête de leur marché : les équipes Optimisation (optimise value).
- Les équipes qui comprennent réellement qu’elles appartiennent à une organisation plus grande, rendent leurs organisations plus fortes : les équipes Renforcement (optimise system).
Chaque lieu dépend d’un ensemble de compétences agiles, de comportements observables qui conduit aux avantages du lieu. Dans le cadre de ce modèle, il est important de s’intéresser à la maîtrise, à la capacité de suivre une habitude à tout moment, même sous pression.
Ces lieux ne sont pas des buts à atteindre : il ne faut absolument être dans le lieu Renforcement. Chacun de ses lieux apporte son lot d’avantages, nécessite des investissements spécifiques, peut-être n’avez pas besoin de tel avantage ou n’avez pas envie de faire tel investissement.
Notion d’aisance
Aux lieux, rapidement aperçus ci-dessus et décrits plus finement ci-dessous, sont associés des pratiques, des compétences. Ce modèle insiste sur la notion d’aisance, de maîtrise.
Cette aisance provient d’un investissement voulu dans l’apprentissage par la pratique. Il faudra du temps (parfois beaucoup) pour l’atteindre. Elle se fera par à-coups, l’apprentissage ne sera pas linéaire, ni séquentiel, parfois l’équipe reculera. Atteindre l’aisance peut être frustrant parfois.
Le soutien de l’organisation est un facteur important dans l’atteinte de l’aisance, elle doit apporter son soutien.
Alignement (l’agile fondamental, Focus value)
Présentation rapide
Les équipes Alignement en maîtrise (ce dernier mot est important) forment une équipe solidaire avec des objectifs communs : elles pensent et planifient en fonction de bénéfices que leurs sponsors, clients et utilisateurs verront dans leur logiciel. Cela contraste avec les équipes qui commencent tout juste leur parcours agile (qui ne sont pas en maîtrise), qui ont tendance à raisonner autour de pures considérations techniques, telles que les couches logicielles, et qui travaillent souvent comme contributeurs individuels avec des tâches assignées individuellement.
=>Scrum, Kanban, management visuel, rétrospectives, backlog, timebox, charte d’équipe, feedback des pairs, sécurité psychologique
Quels bénéfices pouvez-vous attendre de ce lieu ?
La transparence est accrue : une démo au moins une fois par mois pour communiquer sur les travaux récents, récolter des retours et réajuster si besoin.
Le focus sur la valeur est réel, quotidien, il est accompagné d’une réflexion régulière sur les habitudes, l’organisation du travail.
L’équipe est de plus en plus alignée : les malentendus se réduisent, les délais entre les membres de l’équipe aussi.
Quelles compétences l’équipe doit-elle acquérir ?
Répondre aux besoins métiers, les comprendre, les montrer (par morceaux) régulièrement
Travailler efficacement et réellement en équipe. Cette organisation est acceptée de l’équipe, des sponsors, du management
Travailler en ayant conscience des interactions entre mode de fonctionnement et résultats et continuer à améliorer l’organisation de l’équipe.
Quels sont les investissements à faire ?
- Choisir des membres d’équipe compétents et ayant la volonté de travailler ensemble à 100% à leur équipe, les accompagner et les former aux compétences de ce lieu.
- Un espace de travail partagé, dédié et axé sur la productivité.
- La disponibilité de la personne ayant l’expertise sur les priorités métier et la valeur client.
- Former des managers à créer un environnement favorisant le travail d’équipe et à gérer le système de travail plutôt que les contributions individuelles
Livraison (l’agile durable, Deliver value)
Présentation rapide
Les équipes qui maîtrisent ce lieu ne se concentrent pas seulement sur la valeur métier, elles la livrent aussi souvent que leur marché l’accepte. Elles sont capables de livrer ET de livrer quand elles le désirent.
Pour livrer souvent, quand l’équipe le désire, cela suppose peu de défauts (sinon vous pouvez sans doute d’ores et déjà planifier les réunions de crise post release) et une gestion autonome de la livraison. C’est le lieu de la technique du modèle, ici on va retrouver des pratiques issues de l’Xtrem Programming, du mouvement DevOps par exemple.
=> Livraison et déploiement continus, refactoring continu, TDD, BDD, pair-programming, mob-programming, …
Quels bénéfices pouvez-vous attendre de ce lieu ?
Les défauts sont détectés tôt, leur nombre peu élevé permet une livraison régulière. L’équipe peut fournir des prévisions de livraison à l’organisation.
Le taux peu élevé de bugs fournit du temps à l’équipe pour réfléchir à des améliorations (versus temps de corrections de bugs). La dette technique, elle aussi, est faible, les changements sont plus faciles, plus courts, moins coûteux.
Peu de défaut, peu de dette, l’équipe vit mieux. La fidélisation et la productivité sont renforcées.
Quelles compétences l’équipe doit-elle acquérir ?
Tous les développements réalisés peuvent aller en production, ils sont livrés dans un environnement identique à la prod une fois par jour (par le PO c’est encore mieux).
Le code appartient à tout le monde ! Il n’est pas seulement accessible dans Git ou autre par tout le monde, non. Tous les membres d’équipe peuvent modifier n’importe quel bout de code sans le hurlement ou la moue de tel ou tel développeur : La responsabilité est collective.
L’excellence technique ! Des livraisons en production rapides, automatisées ou quasi, pas (ou presque plus) de tests manuels. La qualité du code s’améliore sans cesse.
Quels sont les investissements à faire ?
- Ce lieu est synoyme de beaucoup (beaucoup) de nouvelles techniques, pratiques ; les membres de l’équipe vont sans doute devoir se former au détriment, pendant un temps, de la productivité (et oui). Un coach, formateur sur ces techniques sera sans doute nécessaire.
- L’équipe devra intégrer des compétences des équipes qualification et infra.
- Proposer une formation sur les pratiques agiles pour les profils techniques.
Optimisation (les promesses de l’agile, Optimise value)
Présentation rapide
Les équipes Alignement et Livraison sont capables de livrer, les équipes Livraison, le font quand elles veulent. Les équipes Optimisation en maîtrise livrent ce qui fait sens pour le marché et quand cela fait sens.
C’est souvent ici que l’on va expérimenter des techniques axées sur le produit => lean startup, design thinking, user story mapping, impact mapping, …
Quels bénéfices pouvez-vous attendre de ce lieu ?
Ces équipes savent où elles se positionnent sur le marché, sont capables de dire vers où elles vont aller et pivoter si il le faut.
L’équipe est “armée” sur le plan produit et peut prendre des décisions produit pertinentes. Ces livraisons font sens et lui permettent d’apprendre encore et toujours.
Expertise produit au sein de l’équipe : les décisions peuvent être rapides. Cette expertise conduit aussi à une confiance avec son organisation.
Quelles compétences l’équipe doit-elle acquérir ?
Les roadmap produit se fait en fonction d’impacts métier. Les livraisons s’établissent en fonction du marché.
L’équipe est autonome, vraiment. Elle est reponsable de ces livraisons, de sa roadmap produit du début à la fin. Cela ne se fait pas sans le reste de l’organisation évidemment. L’organisation s’assure que l’équipe peut être autonome.
Tout à l’heure, c’était excellence technique, là c’est excellence produit : compréhension du marché toujours accrue, tests, pivot, …
Quels sont les investissements à faire ?
Evidemment, une équipe dédiée, c’est déjà précisé plus haut, c’est toujours le cas, ici : c’est la base.
Elle comprend des experts métiers présents et disponibles. Une peut-être plusieurs.
Le management doit être accompagné, l’autonomie de l’équipe peut être difficile à vivre, à appréhender pour les managers. Ils devront par exemple la juger sur les impacts métiers et non sur les plannings.
Autonomie ! Budget, roadmap, résultats… toujours dans le cadre de l’entreprise.
Renforcement (le futur de l’agile, Optimise system)
Présentation rapide
Des équipes Optimisation en maîtrise optimisent le produit, des équipes Renforcement en maîtrise aident, également, la structure à s’organiser, à se renforcer… à devenir plus efficace.
Diana et James appellent ce lieu le futur de l’agile, les exemples sont peu nombreux. On peut penser à des structures type entreprises libérées (Zappos, FAVI, Gore, Chronoflex…) : compréhension de son rôle au sein de l’entreprise, diffusion des compétences délibérées, différents types de fonctionnement (choisi, conscient) au sein de l’entreprise.
=> Cynefin, réunions en mode forum ouvert (open space agility), sociocratie, holacratie, équipes auto-constituées…
Quels bénéfices pouvez-vous attendre de ce lieu ?
Des problèmes cross équipes sont résolus, les goulots d’étranglements aussi.
Des travaux inter-équipes pour optimiser ou aider .
La diffusion aligne les équipes et nourrit la recherche d’excellence.
Pour finir
Ceci est un modèle, le résultat d’observations, il ne doit pas être un carcan, une route avec des points de passage obligatoires. Comme beaucoup d’outils, il est là pour vous aider.
Utilisez le pour générer des conversations. Sur l’apprentissage des compétences. Sur les investissements à faire. Sur ce que souhaite la structure, …
Et vous trouverez, j’en suis sûr, d’autres idées, d’autres pistes pour l’exploiter.
Ces notes sont issues de la traduction que j’ai réalisée, avec l’aide des coaches benext, pour préparer le meetup Beyond Scrum Mastering du 2 juin 2020, pour aider les participants à suivre, pour relire a posteriori, au calme…
La traduction complète est disponible sur le blog d’agilefluency.org. Un grand merci à Diana Larsen.
Dorénavant, je publie mes articles sur mon blog nilslesieur.fr
