95% des entreprises indiquent compter dans leur rang au moins une équipe agile. En d’autres termes, aujourd’hui tout le monde veut être agile. C’est devenu une norme, à la fois pour l’entreprise qui doit pouvoir réagir vite et avec la bonne réponse aux conditions changeantes du marché, mais aussi pour les individus qui doivent réussir à mieux collaborer et travailler collectivement à un but commun. Si bien qu’il est même devenu compliqué d’être recruté ou de recruter sans afficher un plan de transformation agile pour l’un et une certification pour l’autre.
Pour autant, dans la plupart des situations que je rencontre, les entreprises se concentrent beaucoup plus sur le “FAIRE” agile que sur le “ÊTRE” agile, beaucoup plus sur les processus et les outils que sur l’essence même de l’agilité qui se situe dans l’état d’esprit et dans les interactions.
Nous avons parfois tendance à oublier que l’agilité est un état d’esprit et un moyen, ou plus globalement un ensemble de moyens, de pratiques qui servent un objectif. Un moyen de s’en rendre compte est d’observer les indicateurs des entreprises concernant l’agilité. Ce qui est mesuré et suivi par les entreprises est l’utilisation et l’adoption de pratiques plutôt que la performance qu’elles sont supposées apporter.
Voyez plutôt :
Je fais des daily meetings donc je suis agile
J’utilise Jira donc je suis agile
Je fais des rétrospectives donc je suis agile
J’organise des PI Planning pour aligner les dépendances entre mes équipes donc je suis agile
Je dis que je fais de l’agilité à l’échelle donc je suis agile.
L’agilité : au service de la performance avant tout
Mais au fait, si je suis agile, quel but cela sert-il ?
Ce but qui est si souvent inexistant devrait pourtant être la préoccupation première de l’entreprise ou de l’équipe.
Essayons d’utiliser les 3 cercles de Simon Sinek pour détailler dans quel but devenir agile :
le WHY c’est la performance de l’entreprise ou de l’équipe
le HOW ça peut être l’adoption de l’état d’esprit agile (qui peut être complété par d’autres choses, comme le renforcement des compétences ou l’innovation par exemple)
le WHAT ça peut être la mise en oeuvre de pratiques concrètes comme certaines méthodes agiles : Scrum, Kanban, XP… ou d’autres techniques
L’agilité n’est pas une fin en soi. Être agile, intrinsèquement, ne suffit pas. Viser une meilleure performance est nécessaire. En fonction du contexte, la performance se décline sur des axes différents comme par exemple : plus de ventes, plus de notoriété, plus de nouvelles fonctionnalités, dépasser un concurrent, moins de turnover, mais aussi plus de partage de connaissances, plus d’apprentissages, plus de nouvelles expérimentations…
Je vais être clair ici, pour moi la performance, qu’elle soit individuelle ou collective, n’est pas un gros mot. C’est même ce qui doit nous animer au quotidien. Être plus performant dans son métier ou dans son rôle, c’est tout simplement être meilleur, apprendre sans cesse, progresser. C’est une nécessité pour moi.
Mesurez des KPI sur le but, pas sur le moyen
Mes clients me demandent souvent comment nous allons mesurer l’impact de leur transformation agile, afin de prouver que cette transformation est utile. J’aime qu’on me pose cette question car, même si il n’est pas simple d’y répondre, elle dénote une bonne compréhension des enjeux autour de la transformation.
Comme je le disais, mesurer l’impact d’une transformation n’est pas simple à réaliser. Car si je peux mesurer aisément si une équipe respecte ses rituels, met à jour son Jira, délivre ce qu’elle a prévu (via le Burn-Down Chart par exemple), ce faisant je mesure le WHAT : le moyen. Je ne mesure pas l’impact. Je ne répond pas à la question.
Donc je travaille plutôt à mettre en place des indicateurs de performance qui permettent de mesurer un résultat sur le WHY : augmentation du panier moyen, du taux de repeat, du nombre d’utilisateurs actifs, du taux de disponibilité, etc… Evidemment, il n’y a pas de lien direct (ou 1 pour 1) entre le moyen (l’agilité) et le résultat (la performance), car d’autres facteurs viennent impacter le résultat (l’évolution du marché, le marketing…). Mais je préfère expliquer à mon client que la transformation agile permet de soutenir le développement de ses ventes que de lui dire que 93% de ses équipes font un daily meeting.
Comment mesurer le ROI d’une initiative agile ?
I WANT MY ROI !
Si vous êtes dans une démarche « ROIste » pur, il sera peut-être compliqué pour vous de voir l’intérêt de l’agilité.
Car l’agilité intervient dans un système global et il n’est pas possible de découper le système de sorte qu’on puisse mesurer l’impact d’un seul moyen mis en œuvre. C’est d’ailleurs un des principes fondamentaux de la pensée systémique : un système complexe ne peut pas être découpé en petits systèmes plus simples. C’est un tout.
Dès lors, le retour sur investissement se mesure dans la capacité à améliorer l’axe de performance principal de l’entreprise ou de l’équipe. S’il était difficile au départ de faire grossir sa base utilisateur, la transformation mise en œuvre aidera probablement à délivrer plus vite des fonctionnalités à plus forte valeur ajoutée. Et donc à sortir en premier LA nouvelle fonctionnalité qui va faire le buzz. C’est à ce moment que l’investissement sera rentable.
Visez la performance plutôt que l’adoption des pratiques agiles
Je suis personnellement convaincu que l’agilité est un bon moyen pour améliorer la performance d’une entreprise ou d’une équipe. Et j’expérimente mes convictions depuis une dizaine d’années maintenant. Les transformations qui réussissent sont celles qui se concentrent sur la mesure de la performance, et non pas sur le nombre de cérémonies effectuées dans le mois. Et puis, il existe de nombreux autres moyens d’améliorer sa performance, des moyens qui se découvrent par l’expérimentation et l’apprentissage.
Le 1er octobre 2019, l’équipe Transformation Agile a animé un événement dédié aux Organisations Agiles. C’était l’occasion de partager avec les participants les témoignages exceptionnels d’Emmanuel Lucas (Claranet) et de Mathieu Delobelle (veepee).
Nos intervenants ont pris le temps de partager leur vision, de présenter leur expérience, l’organisation, ainsi que les leviers et outils qu’ils ont mis en place dans leur entreprise afin que celle-ci acquière la capacité de s’adapter en permanence.
3 temps forts ont rythmé cette matinée
Les expérimentations menées chez Oxalide et la démarche d’amélioration continue mise en place chez Claranet portées par Emmanuel Lucas, Directeur de Business Unit et en charge de l’Organisation de Claranet France
Une mise en œuvre d’une organisation agile orientée produits chez veepee depuis 2 ans et demi, portée par Mathieu Delobelle, Chief Product Officer et membre du Comité Exécutif du groupe veepee
Les leviers pour faire progresser son entreprise vers une organisation apprenante et qui s’adapte au changement par Séverin Legras, Leader de l’équipe Organisation Agile.
Rupture douce 05 : les individus et les interactions d’abord !!
Rupture douce 05 : les individus et les interactions d'abord !!
Les individus et les interactions d’abord !!
Les Individus et les interactions d’abord !! Le nouveau Tome de Rupture Douce est disponible !!! 40 textes, 30+ auteurs, de nombreuses illustrations pour remettre les pendules à l’heure en matière d’agilité et de transformations agiles.
Auto-édition sur lulu.com, 15€ HT (coût de fabrication 10€ + 5€ qui seront reversés aux resto du coeur. Pour mémoire 536€ = repas pour une famille de 4 pour tout l’hiver.
Quel plaisir pour moi d’avoir fait partie de cette aventure collective, capable d’accoucher d’un livre en quelques semaines. J’ai immédiatement plongé dans le projet avec quelques pages qui proposent ma vision d’une agilité agnostique des frameworks, mais centrée sur l’humain, le (bon) sens et la recherche de simplicité. Et ça aussi, ça fonctionne « à l’échelle ».
Séverin Legras
4ème de couverture
Durant toutes ces années, l’agilité a connu de beaux succès, et encore trop d’échecs. Dans tant d’endroits, les transformations agiles sont encore asservies par une descente de processus agiles (Scrum, Kanban, Safe, etc) sur les individus. Heureusement, nous pouvons savourer des initiatives comme Agnostic Agile ou bien Heart of Agile, cultivées par des anciens de l’agilité, ceux qui ont donné naissance au Manifeste Agile en 2001.
Ce tome 05 s’inscrit dans cette mouvance : ici, les contributeurs entendent rappeler que notre manifeste précisait dès sa première valeur « les individus et les interactions plus que les processus et les outils ». Vues les confusions constatées, autant simplifier en « les individus et les interactions d’abord !! ».
Dans vos mains, vous tenez une nouvelle collection d’histoires épatantes, pour remettre les pendules à l’heure. Retours d’expériences authentiques, approches pragmatiques : vous disposerez d’un beau matériel pour espérer que les 10 prochaines années soient encore meilleures.
Avec Rhapsodies Conseil, l’intelligence collective devient une évidence…
Favoriser la créativité des individus et du collectif en faisant émerger des comportements et des pratiques bienveillantes, c’est la mission que s’est fixé le cabinet Rhapsodies Conseil pour aider les entreprises à évoluer vers l’intelligence collective.
Le management directif, autocratique et hiérarchisé, symbole d’une organisation pyramidale a-t-il fait son temps ?
Pour Rhapsodies Conseil, cabinet indépendant de conseil en management, c’est une évidence !
Claranet | Oxalide et Rhapsodies Conseil vous invitent à découvrir un retour d’expérience de transformation vers une Organisation plus Agile.
Co-construit en intelligence collective, ce modèle aligné sur la stratégie de développement prévue par Oxalide (groupe Claranet) visait à faire face à des enjeux de croissance, d’organisation, de scalabilité dans un marché ou le time-to-market est le nerf de la guerre.
La conception d’un modèle de transformation en mode agile différenciant, intégrant leur cible, leur rythme et une trajectoire adaptée, était majeure pour atteindre les résultats souhaités.
Une Organisation Produit conçue avec les équipes et les consultants de Rhapsodies Conseil qui ont eu plaisir à mener cette mission.
Comment découper les besoins au sein d’une vaste organisation de 5000 collaborateurs pour mieux échanger et créer de la valeur ?
C’est l’une des questions en filigrane de l’accompagnement que nous menons en tant que coach agiles auprès des équipes produits de vente-privée depuis 1 an. Une question posée dans le sillage d’une transformation qui voit le leader de la vente flash en Europe passer d’une organisation par technologies à une organisation par produits.
Pour comprendre l’importance de ce découpage, prenez le temps d’imaginer un gros burger composé de nombreuses couches d’ingrédients. Vous avez deux manières de vous y attaquer. La première consiste à manger chaque couche, l’une après l’autre. Autant dire que vous ne profiterez pas du vrai goût du burger. Ou bien vous pouvez croquer dans ce burger à pleines dents. Vous aurez alors en une bouchée un peu de de chaque ingrédient, ce qui vous donnera une bien meilleure appréciation de ce qu’est véritablement un burger. Et comment l’améliorer à l’avenir.
Dans une organisation, le découpage des besoins, pour rester aligné sur la création de valeur, obéit à la même logique. Encore faut-il transcrire ce principe dans la pratique. Comment les équipes de vente-privee y sont-elles parvenues ? Avec quels enseignements ? Ce sont les intéressés qui en parlent le mieux.
Chez Vente-privée, à quels signes voyons-nous qu’une équipe livre de la valeur de manière optimale ?
Quand l’équipe recourt à des pratiques qui améliorent sa connaissance produit Identifier, anticiper et réduire les risques suppose de bien connaître son produit. Ces risques ont des origines multiples : adhérences externes, complexité technique ou fonctionnelle, compétences de l’équipe, interdépendances avec les autres équipes produits et transverses… Voilà pourquoi la collaboration doit être continue.
Connaître son produit
« L’architecture micro-service que nous mettons en place peut rendre une plateforme difficile à appréhender d’un point de vue fonctionnel. Mais avec la mise en place des “3 Amigos” nous avons développé les connaissances fonctionnelles de l’équipe produit. Résultat, nous délimitons mieux les périmètres de nos composants (acquisition d’image, stockage, publication…) ce qui améliore le delivery ainsi que la qualité des nouvelles features. Au final, c’est toute l’architecture qui est mieux exploitée. »
Vincent Oostenbroek de Lange – Lead Developper du Produit Media Prod
Les “3 AMIGOS” ? Concrètement, il s’agit d’un moment d’échange entre le PO/Business analyste, le testeur et le développeur pressenti pour coder. Les participants posent des questions pour clarifier les besoins et identifier les risques. Une bonne manière de couvrir les angles morts de chaque rôle. Suivant la maturité de l’équipe produit, c’est le moment où les critères d’acceptance sont décrits.
Chez Vente-privée, à quels signes voyons-nous que les équipes développent leur connaissance du produit ?
Quand l’équipe échange en continu L’équipe discute les besoins avant qu’ils n’arrivent dans le backlog des développeurs. Pour certaines équipes produit de vente-privee, nous avons donc amélioré la phase entre le moment où les clients émettent les besoins et le moment où ils arrivent dans le backlog des développeurs. Chaque équipe produit, suivant ses spécificités, a choisi les pratiques qui conviennent le mieux à leur contexte. Sans surprise, l’atelier des “3 AMIGOS”*, gage de succès, s’est aussi imposé ici.
Échanger pour définir les critères d’acceptance
« En décrivant pour chaque user story les critères d’acceptance, nous réussissons à remplacer les exigences avec un langage clarifié en termes fonctionnels et techniques. Ainsi tous les cas de tests sont anticipés en amont, orientent les choix techniques et préviennent les risques de bugs en production. Cette façon de travailler réduit d’autant le temps de qualification puisque les cas complexes ou tordus sont largement anticipés durant la phase de conception. Ce travail collectif et collaboratif entre les QA, dev et PO offre à l’équipe produit Orderpipe un gain de temps dans la livraison en production des MVP. La prochaine étape pour nous est de rédiger les tests de manière automatisée.«
Hicham Sassi – QA du Produit Orderpipe
Chez Vente-privée, à quels signes voyons-nous que le découpage des besoins est entré dans les habitudes de travail ?
Quand l’équipe sait découper les besoins fonctionnels par la valeur L’équipe s’assure de livrer de la valeur à chaque itération. Cela commence par la priorisation du backlog par la valeur jusqu’au découpage vertical en mode MVP (Minimum Viable Product).
Prioriser par la valeur
« Il y a un adage qui dit « les intérêts des uns ne sont pas forcément ceux des autres« . Et cela s’applique très bien quand il s’agit d’un produit transverse à l’ensemble des autres produits. C’est le cas du produit Personnalisation : il offre un service qui diminue l’effort de recherche des ventes disponibles pour les membres et permet aux équipes produits vente-privee de booster leur KPI (de générer plus de valeur sur leur propre produit).
Toutefois cette synergie accroit aussi la complexité. En effet, une fonctionnalité peut détruire de la valeur business pour un produit tout en générant sur un autre (i.e le voyage peut perdre au détriment du loisir). En conséquence, il est indispensable de bien découper les besoins fonctionnels afin de tracer à la fois le flux de valeur et la complexité technique. Cela permet à l’équipe produit Personnalisation de bien définir les MVP et maximiser la valeur délivrée pour l’ensemble des produits. »
Ivan VUKIC – Product Owner du Produit Personnalisation
L’équipe sait aussi s’arrêter quand elle ne produit plus de valeur.
Expérimenter par la valeur
« Dans le cadre de nos campagnes d’acquisition, nous nous étions donnés pour objectif de booster les téléchargements de l’application vente-privee sur les stores (iOS/Android). Nous sommes partis de l’hypothèse qu’une meilleure note sur ces stores améliorait le taux de téléchargement de l’app (nombre de téléchargements rapporté au nombre d’utilisateurs qui voient la description de l’app).
Pour éprouver cette hypothèse, nous avons sorti un 1er MVP de notre feature : le fait de pousser une interface de notation à certaines populations juste après un achat, ainsi le « user » est dans une dynamique positive avec le service vente-privee. Une fois ce module en production, et après analyse, nous nous sommes rendus compte que :
– nous améliorons la note de l’app (de 2.5 à 4.5 sur iOS par ex.)
– nous n’améliorons pas le taux de téléchargement de l’app
Nous avons mis de côté les évolutions possibles de ce module (optimisation de l’affichage, exécution d’autres scénarios…) puisque que nous n’incrémentions pas le nombre de nouveaux porteurs de l’app par rapport à la valeur attendue. »
Matthieu WILLAIME – Anciennement Product Owner du Produit User-Engagement, dorénavant PO Navigation
A quels signes voyons-nous que le découpage est efficace ?
Quand l’équipe sait découper les besoins fonctionnels en réduisant la complexité Objectif : limiter les inconnues afin que les développeurs, les testeurs, les UX-UI, les data analystes et les business analystes soient confiants en leur capacité de présenter ce qu’ils ont prévu de livrer lors du sprint planning. Une fois bien compris, un besoin fonctionnel ou “Business feature” est découpé en 1, 2 ou 10 users stories ou enablers (tâches techniques, UX…). Ce qui nous donne un bon hamburger :
Découpage d’un besoin fonctionnel en hamburger
Découper les besoins fonctionnels
« Depuis la mise en place de l’agilité dans notre équipe, nous rencontrions des problématiques concernant la taille des stories. Certaines s’apparentaient davantage à des business features et nécessitaient plusieurs sprints pour être réalisées. Avec le découpage en hamburger, nous nous posons les bonnes questions afin de découper au mieux les besoins. Le retour est très positif, nous parvenons mieux à nous projeter dans le temps, avec une réelle vision du travail à fournir et sur la façon de l’adresser. »
Grégory Beer – Scrum master du Produit Media Prod
Une façon de s’assurer du bon niveau de découpage du besoin fonctionnel consiste à estimer la complexité. L’équipe se pose des questions jusqu’à l’atteinte d’une complexité assez basse des users stories et enablers (exemple : en dessous de 5 sur l’échelle de Fibonacci) afin d’identifier les risques et les inconnues. C’est un des temps d’apprentissage sur l’équipe et le produit.
Exemple d’une échelle d’estimation de la complexité
S’affranchir de l’estimation grâce à la maturité de l’équipe
« Pour l’équipe Navigation, l’estimation a été un passage obligatoire et bénéfique dans notre maîtrise de l’agilité. Parfois, au début, la facilité nous poussait à mettre une estimation élevée sans remettre en question le découpage de la tâche. Après quelques mois où nous nous sommes imposés de découper les tâches pour être en dessous d’un niveau de complexité de 8, nous nous sommes rendus compte que notre découpage devenait optimal.
Nous avons choisi de nous passer des estimations en utilisant le nombre de tâches plutôt que le nombre de points de complexité comme mesure d’avancée de sprint. »
Paul-Emmanuel Garcia – Scrum master / développeur iOS Produit Navigation
Takeaways
Peu importe les rituels et les pratiques adoptés tant qu’ils contribuent à faciliter les échanges pour mieux découper les besoins.
Ces pratiques ne sont pas une fin en soi : elles contribuent seulement à acquérir des comportements agiles, aident les équipes à gagner en confiance, à travailler ensemble pour trouver des solutions – et non pour résoudre des problèmes.
L’histoire ne s’arrête pas une fois que l’équipe sait collaborer pour créer de la valeur : il faut encore apprendre à réfléchir et à s’améliorer pour de boucler les 4 étapes du cycle du cœur de l’agilité (collaborer – délivrer – réfléchir – améliorer).
avec la participation deSylvie Moumen Coachs agiles chez vente-privee, Coachs professionnelles systémiques & Coachs Process Com certifiées
