Mesurer l’agilité : que mesurer ? Quel indicateur agile ? (2)

Mesurer-lagilité-Indicateurs-agiles-Évolution-du-nombre-danomalies-remontées

Tous les articles de notre série “Mesurer l’agilité” :

Précédemment, dans la mesure de l’agilité…

Que peut-on mesurer pour se rendre compte de notre capacité à être plus agiles ? Et à quoi cela va-t-il nous servir ?

Dans le précédent article, nous avons parlé de trois indicateurs agiles : l’évolution de la valeur ajoutée perçue par les utilisateurs, l’évolution du temps de cycle et l’évolution du temps de traversée.

En voici trois supplémentaires.

#4 indicateur agile : L’évolution du nombre d’anomalies remontées

Visualiser l’évolution du nombre d’anomalies remontées peut nous aider à comprendre si le travail que nous fournissons en tant qu’équipe, programme ou organisation est conforme au niveau de qualité que nous souhaitons pour nos utilisateurs.

Que prendre en compte dans cet indicateur agile? Uniquement les anomalies remontées par les utilisateurs en production ? Également celles détectées par l’équipe, dont le Product Owner, lors de ses vérifications avant livraison ? Ou par la plateforme d’intégration continue, si du code vérolé a été poussé sans vérification préalable ? Il y a plusieurs écoles, à vous de voir où vous souhaitez placer le curseur.

Un code ou un processus n’est jamais dépourvu à 100% d’anomalies. Même les langages sur lesquels nos programmes sont basés sont en constante amélioration, pour des raisons de fonctionnalités ou de performances. L’introduction de nouveau code signifie l’introduction potentielle de nouvelles anomalies.

La question à se poser est : à quel point sommes-nous capables d’en produire le moins possible dans la durée, de façon à continuer à satisfaire nos utilisateurs et à ce que notre dette technique n’explose pas dans le temps ?

Mesurer l'agilité avec un indicateur agile : L’évolution du nombre d’anomalies remontées

Pourquoi le mesurer ?

Une augmentation dans le temps de la quantité d’anomalies remontées peut induire une diminution de la qualité de notre production, ce qui nous fait perdre en agilité (moins bonne capacité à répondre au besoin utilisateur par exemple). Il est alors nécessaire de comprendre les causes racines de cette évolution. Puis, il est nécessaire de mettre en place les actions correctives adéquates.

Comment le mesurer ?

Cela pourrait être une mesure, une fois par période (semaine, mois, trimestre…), du nombre d’anomalies remontées sur cette dernière, et le traçage d’un graphique comme celui ci-dessus.

Comment l’améliorer ?

L’automatisation d’un certain nombre de tests (unitaires, d’intégration, fonctionnels…) peut permettre d’identifier le plus tôt possible les anomalies, et donc de les corriger avant qu’elles ne viennent perturber les utilisateurs.

#5 indicateur agile : L’évolution du taux de couverture du code

La couverture du code, dans une approche logicielle, est le pourcentage du code source du produit qui est exécuté par vos tests automatisés. Supposons que vous ayez 1000 lignes de code dans votre produit. Vos tests sont automatisés. Une fois exécutés, ils éprouvent 700 lignes de ce même code (laissant donc planer un doute sur le bon fonctionnement des 300 autres). Votre couverture du code sera de 70%.

Il s’agit d’un indicateur agile plus technique que les précédents. Mais même celui-ci pourrait être éventuellement adapté à des équipes non techniques. Comment ? On mesurera par exemple la proportion d’étapes dans un processus qui disposent de procédures de vérifications associées. Dans notre équipe RH : a-t-on bien une liste de contrôle pour l’étape de qualification ? Et pour l’étape d’entretien avec le candidat ?

L’évolution du taux de couverture du code - indicateur agile à mesurer

Il s’agit également d’un indicateur agile peut-être plus controversé que les précédents, car plus facile à “truquer”. Pour améliorer le score, il suffit de rajouter des tests inutiles. Cela permet alors d’augmenter le score. Au lieu de réellement le faire de façon rationnelle dans une optique de réduction du nombre de cas non testés.

Mais si j’en parle, c’est que de façon très concrète, au sein des organisations de tailles diverses que j’ai accompagnées, j’ai vu un vrai lien entre la couverture du code et la capacité d’une équipe à être agile, à partir du moment où les tests sont rédigés en bonne intelligence, pour une bonne raison, et dans un ordre et une quantité pertinents.

Pourquoi le mesurer ?

Une meilleure couverture du code, c’est normalement une capacité accrue à détecter les anomalies dans le code. Et donc une réactivité accrue pour les corriger avant même que le code en défaut n’ait été poussé jusqu’au dépôt. C’est aussi, à terme, un temps moindre passé à retester toujours les mêmes procédures. Et donc un temps plus important passé à créer de la valeur nouvelle pour les utilisateurs. Une équipe agile devrait donc viser une amélioration de son taux de couverture du code jusqu’à un certain point, et un maintien à long terme de ce taux à un niveau qu’ils jugent satisfaisant.

Comment le mesurer ?

Le taux de couverture du code est mesuré par des outils dédiés, qui varient généralement en fonction de la technologie sur laquelle est basée votre produit.

Comment l’améliorer ?

Il n’y a pas de magie : si le taux de couverture paraît insuffisant, il faut sans doute passer plus de temps à implémenter les tests couvrant votre code, et donc généralement moins de temps à développer de nouvelles fonctionnalités. C’est un juste équilibre à trouver. Vous n’avez sans doute pas besoin de viser une couverture de 100%. En revanche, il faut faire en sorte de prioriser l’implémentation des tests pour les pans les plus critiques du produit, et faire en sorte que le taux de couverture augmente ou reste stable dans le temps. En effet, au fur et à mesure que vous développerez de nouvelles fonctionnalités, le nombre de lignes de code devrait augmenter : si le taux de couverture diminue, c’est peut-être le signe qu’il n’y a pas de tests implémentés pour ces nouvelles fonctionnalités, ce qui est un problème.

#6 Indicateur agile : L’évolution de la satisfaction des utilisateurs et des collaborateurs

L’agilité, c’est notamment la régularité et l’amélioration continue. Et contrairement l’interprétation que certains peuvent faire de certains termes, comme le fameux “sprint” de Scrum, adopter une approche agile n’est pas synonyme d’aller le plus vite possible. Mais garder un rythme soutenable dans le temps, idéalement “indéfiniment” si l’on se réfère aux principes agiles (n°8).

À ce titre, il est important de prendre régulièrement “la température” des humains qui nous accompagnent dans cette démarche. Il y a les utilisateurs d’une part. Mais il y a aussi les personnes qui travaillent pour ces utilisateurs : les développeurs, testeurs, graphistes, facilitateurs, Product Owners, managers, etc. Et cela reste évidemment vrai dans une démarche qui n’a rien à voir avec du développement logiciel.

Pourquoi le mesurer ?

Une diminution dans le temps de cette satisfaction est le signal que quelque chose ne va pas dans notre façon de fonctionner. Cela permet alors de prendre des mesures avant que la situation ne se dégrade trop, jusqu’à arriver parfois à un point de non-retour (syndrome d’épuisement professionnel, démissions…).

Comment le mesurer ?

Il y a, là aussi, plusieurs pistes. Le modèle du Squad Health Check, popularisé par Henrik Kniberg, permet aux membres des équipes de s’exprimer collectivement sur un certain nombre de points et de donner leur satisfaction sur chacun. Le calendrier Niko Niko du Management 3.0 est peut-être moins intéressant de ce point de vue. Il est cependant plus rapide à mettre en œuvre. Pour ce qui est de la satisfaction des utilisateurs, un sondage simple avec une note, comme par exemple le Net Promoter Score (NPS), permet déjà d’avoir un résultat.

Indicateur agile à suivre : L’évolution de la satisfaction des utilisateurs et des collaborateurs

Comment l’améliorer ?

Il n’y a pas de magie : si le score ne vous paraît pas suffisamment bon, il faut écouter les retours qui ont été faits et se remonter les manches pour les mettre en application. C’est justement là qu’un exercice comme le Squad Health Check, plus collectif et basé sur l’échange, va être plus intéressant qu’un Niko Niko. Attention : écouter et ne pas agir ne suffit pas.

L’évolution, signe de la direction prise

Les six indicateurs agiles qui vous ont été présentés dans cet article et le précédent ont tous été présentés comme “l’évolution de quelque chose” (temps de traversée, nombre d’anomalies, etc.). Pourquoi ?

Un nombre, pris hors de son contexte, peut vouloir tout ou rien dire. Dans une approche d’amélioration, ce qui devrait nous intéresser est plutôt de savoir à quel point nous sommes capables de progresser dans la bonne direction, en agissant afin de permettre la diminution de la valeur de certains indicateurs, et l’augmentation de la valeur de certains autres.

Si vous avez une satisfaction utilisateurs de 7 / 10, cela peut être une note acceptable. Si, sur les douze mois précédents, la satisfaction moyenne de vos utilisateurs était de 5 / 10, alors bravo, vous avez bien progressé et il faut continuer dans cette voie. Mais si cette même moyenne sur les douze derniers mois était de 9,7 / 10, qu’a-t-il bien pu se passer depuis ? Et que devrions-nous changer pour endiguer cette dégringolade ?

Vous êtes peut-être lancés dans une démarche produit ou service qui durera un, deux, cinq, dix ans. Ne soyez pas trop impatient. Ne faites pas confiance aux chiffres tels quels. Cherchez à vous améliorer dans une direction plutôt que vers un objectif bien précis. Visualiser l’évolution des indicateurs est ce qui vous permettra de prendre la bonne décision au bon moment. Vous ajouterez un contexte bienvenu que le chiffre seul ne donne pas.

La suite et fin au prochain épisode

Comment les choses ont-elles évolué chez Scholesoft, l’entreprise de Paul ? Quels résultats ont été obtenus ? Restez connectés pour être mis au courant des prochains articles sur le sujet.

Partager cet article :

Mesurer l’agilité : que mesurer ? Les indicateurs agiles (1)

mesurer l'agilité - indicateurs- courbe de valeur ajoutée cumulée au fil du temps

Tous les articles de notre série “Mesurer l’agilité” :

Précédemment, dans la mesure de l’agilité…

Nous avons parlé de ce que signifie “mesurer l’agilité”, en nous basant sur une définition de ce que pouvait être l’agilité, qui était :

Une caractéristique propre à un individu, une équipe ou une organisation, qui est capable de s’adapter aux changements de son environnement, via :

  • La livraison la plus régulière et fréquente possible de valeur, en fonction des attentes évolutives de ses utilisateurs et de son écosystème ;
  • Un état d’esprit exemplaire favorisant la collaboration, l’autonomie et l’auto-organisation ;
  • La recherche constante de la qualité et de l’amélioration dans ses activités et ses interactions.

Nous avons expliqué pourquoi il n’y a pas de raison de percevoir la mesure de l’agilité comme quelque chose de négatif ou d’antinomique avec les valeurs agiles. Cela peut nous aider à nous situer par rapport à une cible que nous nous fixons vis-à-vis de notre capacité à délivrer plus de valeur, collaborer, faire un travail de qualité… donc à nous améliorer.

Nous avons aussi parlé des pièges à éviter lorsque nous mettons en œuvre ce genre de pratiques. Par exemple : mesurer sans savoir pourquoi, céder à la tentation de tout vouloir contrôler, mettre en compétition les individus ou équipes entre eux… entre autres.

Ceci posé, que pouvons-nous mesurer, quels indicateurs agiles suivre et à quoi cela va-t-il nous servir ?

Indicateur d’agilité #1 : L’évolution de la valeur ajoutée perçue par les utilisateurs

Peter Drucker* aurait dit un jour que “rien n’est plus inutile que de produire efficacement quelque chose qui n’aurait pas dû être fait du tout”.

* Peter Drucker est un professeur en management américain (1909-2005) relativement connu. Il est décrit comme “le père du management moderne”.

Plus tard, nous mesurerons notre capacité à délivrer régulièrement de nouvelles solutions, de façon qualitative d’un point de vue de notre code. Mais cela nous permettra-t-il de savoir si nous répondons réellement aux besoins de nos utilisateurs ? Non. Pourtant, c’est essentiel.

mesurer l'agilité - indicateurs agiles - courbe de valeur ajoutée cumulée au fil du temps
Capture d’écran de la vidéo “Agile Product Ownership in a nutshell” de Henrik Kniberg (ici en VOST).

Le graphique ci-dessus montre l’évolution classique d’une courbe de valeur ajoutée cumulée au fil du temps.

Au démarrage, nous allons avoir tendance à travailler sur des sujets indispensables au bon démarrage de notre produit, parfois moins riches en valeur pour les utilisateurs, tout en tâchant d’apporter malgré tout quelques fonctionnalités porteuses de valeur.

Après quelques semaines, nous devrions normalement travailler sur des sujets bien identifiés comme les plus importants pour nos utilisateurs.

Et au fil du temps, alors que nous avons traité les sujets les plus importants, ceux qui restent devraient, normalement, apporter une valeur ajoutée plus faible.

Pourquoi mesurer cet indicateur agile ?

C’est une mesure qui va permettre de savoir si nous allons, ou pas, dans la bonne direction vis-à-vis de ce qui paraît important aux personnes pour lesquelles nous travaillons. Des utilisateurs satisfaits, ce sont des utilisateurs qui vous seront fidèles, qui n’iront pas voir chez la concurrence. Ou qui iront voir pour d’autres raisons (comme le prix). Mais qui reviendront un jour si lesdits concurrents ne sont pas capables de se placer à leur niveau en comprenant leurs attentes.

Comment la mesurer ?

Il y a plusieurs possibilités. Cela peut être, par exemple, attribuer une valeur à chaque demande, avec l’aide d’un panel d’utilisateurs. Et comptabiliser chaque mois la valeur totale qui a été atteinte. Cela peut être également le fait de convier régulièrement les utilisateurs clés à une revue de produit. Et leur demander de noter ce qu’ils ont vu, du point de vue de la valeur ajoutée (beaucoup de valeur = une meilleure note). Il y sans aucun doute d’autres façons de faire.

Comment l’améliorer ?

Une valeur ajoutée perçue par les utilisateurs qui diminue au fil du temps peut être symptôme de plusieurs choses. Cela peut être parce que l’équipe a passé plus de temps à travailler sur des sujets à faible valeur ajoutée perçue. Par exemple, des sujets techniques : optimisation, correction d’anomalies… D’où l’intérêt de lisser ce type de sujets dans le temps autant que possible. Cela peut aussi être dû à une mauvaise compréhension des besoins. Que cela soit dans leur formulation, leur priorisation ou la réponse apportée. Ce qui devrait inciter l’équipe à collaborer de façon plus étroite avec ses parties prenantes.

Indicateur d’agilité #2 : L’évolution du temps de cycle

Qu’est-ce que le temps de cycle ? C’est la durée qui s’écoule entre le moment où nous commençons à travailler sur un sujet et le moment auquel il est considéré terminé.

Dans le cadre d’une démarche de développement logiciel, c’est généralement le délai qui s’écoule entre le moment où l’équipe commence à travailler sur un développement et sa mise à disposition sur l’environnement de production.

Dans le cadre d’une démarche d’un processus métier, non-IT, c’est le même raisonnement. Prenons l’exemple d’un département RH qui s’occupe de traiter des candidatures. Le temps de cycle pourrait être la durée écoulée entre le moment où le dossier du candidat commence à être examiné et la réponse définitive donnée au candidat.

Indicateurs de mesure agile - temps de cycle
Le temps de cycle est la durée qui s’écoule entre le début du travail sur une demande et sa finalisation.

Il s’agit d’une durée : il s’exprime donc généralement en jours ou en heures. On peut tout à fait considérer le temps de cycle de chaque demande de façon indépendante. Mais il est plus intéressant de visualiser le temps de cycle moyen d’une équipe, voire d’un type de demandes. Cela permet de visualiser comment il évolue au fil du temps.

Pourquoi le mesurer ?

Un meilleur temps de cycle aide à obtenir un meilleur temps de traversée (voir ci-dessous).

Comment le mesurer ?

Pour chaque demande, il suffit de noter la date de début du travail sur le besoin exprimé. Puis de noter la date de mise à disposition à l’utilisateur, et de faire la différence entre les deux.

Comment l’améliorer ?

Pour cela, on peut réduire plusieurs choses :

  • les délais dans la prise de décision,
  • les délais dus aux blocages dans le processus de travail,
  • les allers-retours inutiles.

C’est un premier axe qui permet d’obtenir de sérieux gains, car la demande va plus rapidement aller à son terme. C’est une des raisons pour lesquelles l’auto-organisation et l’autonomie des équipes et la composition d’équipes cross-fonctionnelles sont mises en avant dans les approches agiles : pour assurer une meilleure réactivité.

Automatiser un certain nombre d’opérations chronophages, telles que les tests, aide également. Cela permet un gain de temps et diminue le risque d’erreurs.

Indicateur d’agilité #3 : L’évolution du temps de traversée

Le temps de traversée (que vous connaissez peut-être dans sa version anglaise, “lead time”) est, de la façon la plus générique possible, la durée qui s’écoule entre le début d’un processus et sa complétion.

Dans le cadre d’une démarche de développement logiciel, c’est généralement le délai qui s’écoule entre l’expression d’un besoin par un utilisateur et sa mise à disposition sur l’environnement de production. Et si nous reprenons notre département RH, quel serait le temps de traversée ? Cela pourrait être la durée écoulée entre la réception de la candidature et la réponse définitive donnée au candidat.

Indicateurs agiles - le temps de traversée
La mesure du temps de traversée débute dès le moment où la demande arrive dans notre backlog, même si nous ne travaillons pas encore dessus.

Le temps de cycle est donc inclus dans le temps de traversée. Un temps de cycle plus court aidera à obtenir un temps de traversée plus court. Le temps de traversée se compose, en plus, de la durée qui s’écoule pendant laquelle la demande est dans une file d’attente. C’est-à-dire, attendant son traitement, mais qui n’est pas traitée. D’où l’intérêt, pour plus de réactivité, d’être également capables de réduire la longueur de cette file d’attente.

Pourquoi le mesurer ?

Un meilleur temps de traversée signifie une réponse plus rapide à un besoin exprimé par un utilisateur. Cela suppose donc une capacité à livrer plus régulièrement de la valeur, ce qui était un des axes de notre définition de l’agilité vue précédemment.

Comment le mesurer ?

Pour chaque demande, il suffit de noter la date de l’expression du besoin par l’utilisateur à l’équipe. Puis de noter la date de mise à disposition à l’utilisateur. Enfin, il suffit de faire la différence entre les deux.

Comment l’améliorer ?

Pour améliorer le temps de traversée, il est important d’améliorer le temps de cycle (voir ci-dessus). Il faut aussi arriver à réduire la durée pendant laquelle la demande reste à l’état de demande exprimée, mais sur laquelle aucun travail n’a encore été entrepris. Pour cela, réduire la longueur de la file d’attente (le backlog) est une possibilité. Cela permet de rejeter les idées qui ne sont pas suffisamment porteuses de valeur pour se concentrer sur l’essentiel.

La suite au prochain épisode

Nous aborderons trois indicateurs agiles supplémentaires dans notre prochain article. Restez connectés pour être mis au courant des prochains articles sur le sujet.

Partager cet article :

Mesurer l’agilité : quels pièges éviter ? (2)

Mesurer-lagilité-les-pièges

Tous les articles de notre série “Mesurer l’agilité” :

Précédemment, dans la mesure de l’agilité…

Paul pensait y voir un peu plus clair. Il avait compris ce que signifie “mesurer l’agilité” de ses équipes ou de son organisation. Il avait également compris comment faire passer le message, en interne. La mesure fait partie du processus d’apprentissage et d’amélioration auquel ses équipes pouvaient prétendre. Puis, il s’était renseigné sur différents indicateurs qui pouvaient être mesurés facilement par ses équipes. Chacun ayant une vraie utilité quant au message qu’ils faisaient passer.

C’était il y a trois mois. Depuis, dire que tout ne s’est pas passé comme prévu relève de l’euphémisme. Entre COKARD, KILLMI, primes à la performance et marquage à la culotte, les raisons de s’inquiéter sont nombreuses.

Pour retrouver la première partie de cet article, c’est par ici ! Avec les trois premiers pièges mis en avant :

  • Mesurer sans savoir pourquoi
  • Confondre transparence et flicage
  • Mettre les équipes en compétition entre elles

Passons à la suite…

#1 Piège mesure agile : Mesurer trop souvent ou pas assez souvent

C’est un véritable enjeu dans toute démarche de mesure. À quelle fréquence devrait-on surveiller nos indicateurs, et prendre des décisions en conséquence ? Il n’y a pas une unique bonne réponse à cette question. Tout va dépendre de votre contexte, de votre situation actuelle, de l’indicateur que l’on mesure. Et aussi de votre ambition à vous améliorer plus ou moins rapidement.

Dans l’entreprise de Paul, il y a un COKARD une fois par semaine et un outil demandeur de nouvelles données quotidiennes. Cela oblige les équipes à alimenter en données et à surveiller en permanence l’ensemble des indicateurs qu’elles ont à leur disposition. Non pas pour les aider à prendre des décisions étayées, mais simplement parce que leur direction le leur demande. Ce n’est sans doute pas la meilleure chose à faire.

On peut comparer cela à l’utilisation d’un pèse-personne. Allez-vous vous peser toutes les six heures pour vérifier la masse que vous avez perdue, ou prise, dans le dernier quart de journée ? Allez-vous vous peser une fois par an ? La plupart des personnes utilisant un pèse-personne sont très probablement entre ces deux extrêmes. Et d’autres n’utiliseront peut-être jamais un pèse-personne. Tout simplement parce qu’elles sont satisfaites de leur apparence physique et qu’elles n’en ont jamais eu besoin à ce jour.

Les pièges à éviter -  mesure agile
Allez, on y retourne dans dix minutes !
Photo by i yunmai on Unsplash

Ne pas utiliser un indicateur est d’ailleurs toujours une possibilité ! Supposons que vous ayez une équipe qui soit aux anges, une ambiance excellente, le bon équilibre de sérieux et de folie. Allez-vous chercher à mesurer de façon hebdomadaire un indicateur de satisfaction de l’équipe ? À vous de décider, mais souvenez-vous que toute mesure que vous réaliserez demandera du temps à toutes les personnes concernées, et que sans réelle action à entreprendre derrière, c’est potentiellement du temps gaspillé.

#2 Piège mesure agile : Mesurer de façon trop précise

La visualisation et l’analyse d’un indicateur sont supposées aider à prendre des décisions étayées en connaissance de cause. La question qui se pose légitimement est de savoir à quel point nous avons besoin d’être précis pour pouvoir prendre une décision.

Reprenons l’analogie du pèse-personne. Supposons que mon poids de forme est de 75 kg. Si je pèse plus que ce poids, je vais (peut-être) décider de limiter ma consommation d’aliments gras ou sucrés. Ou je vais décider de faire plus de sport. Mon pèse-personne m’indique que mon poids actuel est de 77,1 kg. Aurais-je pris une décision différente s’il m’avait indiqué 77,14 kg, ou 77,137 kg ?

C’est exactement la même chose avec les indicateurs que suivent Paul et ses équipes. Combien de demandes ont été traitées sur une période donnée ? Quel est le reste à faire de l’équipe ce matin ? Nous avons besoin d’avoir une vision assez précise de la situation. Cependant, nous ne sommes pas en train d’envoyer un satellite en orbite.

Les pièges de la mesure de l'agilité : mesurer de façon trop précise

Deux membres de l’équipe de Paul cherchent à extraire la vélocité du dernier sprint avec huit décimales
Photo by Science in HD on Unsplash

Ce n’est pas pour rien que beaucoup de choses que nous faisons dans une approche agile, comme les estimations ou la planification, restent très macroscopiques, imprécises. De nombreuses équipes, organisations, se sont évertuées pendant des années à réaliser des estimations et des suivis à l’heure près, à l’euro près.

Et pour quel résultat ? Pas forcément un résultat plus reluisant que dans des équipes qui se passent aujourd’hui de cette précision inutile.

Gardez à l’esprit que si nous passons une heure par semaine à calculer un indicateur quotidiennement de façon imprécise, et que cela nous demande à l’inverse quatre heures par semaine de le calculer de façon précise (car au-delà du calcul, il y a aussi le travail demandé aux collaborateurs pour consolider l’indicateur : saisie de données notamment), les trois heures de différence entre les deux modes de calcul sont “perdues”. Cela en vaut-il vraiment la chandelle ? Ce n’est pas toujours le cas.

#3 Piège mesure agile : PDCA vs PDSA

Nous avons parlé dans le précédent article de la roue de Deming, le fameux PDCA : Plan – Do – Check – Act. La vérité est que Deming n’a pas inventé le PDCA, comme l’indique le site de son institut (et notamment l’excellent document qui est référencé à la fin de l’article en question et que je vous conseille).

William Edwards Deming, inspiré par son collègue Walter Shewhart, un statisticien américain, et de son cycle de Shewhart, est à l’origine de la roue de Deming. C’est une approche empirique consistant à designer un produit, le construire, le vendre et évaluer à travers des études de marché et des tests en conditions réelles ce qu’en pensent les utilisateurs. Ce sont des exécutifs de l’industrie japonaise qui l’auraient ensuite transformé en PDCA au début des années 1950. Tandis que Deming essayait de se dégager de la paternité du PDCA au début des années 1990 en introduisant le PDSA, pour Plan – Do – Study – Act.

Mesure de l'agilité : les pièges - Plan - Do - Check - Act

Le PDSA se différencie du PDCA par l’introduction de l’étape “Study” à la place de “Check”
Extrait de “Circling Back” par Ronald D. Moen et Clifford L. Norman

La différence peut paraître ténue, mais elle est suffisamment importante pour que Deming l’ait faite. En français, to check signifie vérifier, s’assurer de quelque chose, contrôler, tester, inspecter, alors que to study signifie étudier, analyser, travailler.

Il y a potentiellement un monde d’écart entre ces deux termes et entre les postures qu’elle peut supposer ou légitimer plus ou moins maladroitement. Il y a potentiellement un monde d’écart entre consolider des indicateurs pour les vérifier, les inspecter, les contrôler, et consolider des indicateurs pour les étudier, les analyser.

Et comme dans l’entreprise de Paul, il est très facile de traverser la ligne blanche pour se retrouver dans une situation où l’atteinte des indicateurs devient le nerf de la guerre. Où il devient l’objectif, indépendamment des actions qui sont décidées par les personnes sur le terrain et mises en œuvre pour participer à l’amélioration continue de l’organisation et de ses produits et services.

Pour aller plus loin : les douze principes de la mesure

Le Management 3.0 pourrait être défini comme un état d’esprit, combiné à une collection de jeux, outils et pratiques, pour aider tout travailleur à gérer l’organisation. C’est un mouvement qui a le vent en poupe depuis le début des années 2010 et la parution du livre de Jurgen Appelo “Management 3.0: Leading Agile Developers, Developing Agile Leaders”. Au-delà du nom, qui peut prêter à sourire, le Management 3.0 partage un certain nombre de pratiques qui sont intéressantes à connaître.

Voici une traduction approximative des “douze règles de la mesure” telles que proposées par le Management 3.0 :

  • Mesurer pour une raison
  • Rétrécir la part d’inconnu (tout n’est pas mesurable, mais on peut toujours essayer de trouver des indices qui nous permettent de comprendre une situation)
  • Chercher à s’améliorer
  • Ravir toutes les parties prenantes (pas juste une seule, quelle qu’elle soit)
  • Ne pas faire confiance aux chiffres (qui peuvent être truqués, garder un certain scepticisme au moment de l’analyse)
  • Fixer des cibles imprécises (plus comme une direction qu’un réel objectif à atteindre)
  • Garder la possession de vos indicateurs (VOUS mesurez pour VOUS)
  • Ne pas rattacher les indicateurs à des récompenses
  • Promouvoir les valeurs et la transparence (évite le désir de truquer le système)
  • Visualiser et humaniser (pour aider et inciter tout le monde à interagir avec les indicateurs)
  • Mesurer tôt et souvent (afin de ne pas laisser les problèmes s’aggraver sans contrôle)
  • Essayer autre chose (changer d’indicateurs de temps en temps pour une perspective différente)
Les 12 principes de la mesure de l'agilité

Les douze règles de la mesure en version originale
Image issue de management30.com

Ces principes ne sont peut-être pas parfaits. Cependant, ils sont un point de départ aussi acceptable qu’un autre. Et cela a le mérite d’encadrer le processus de mesure d’indicateurs d’un état d’esprit raisonnable et cohérent.

La suite au prochain épisode

Quels indicateurs mesurer ? Restez connectés pour être mis au courant des prochains articles sur le sujet.

Partager cet article :

Mesurer l’agilité : quels pièges éviter ? (1)

Mesurer-lagilité-indicateurs-et-tableaux-de-bord

Tous les articles de notre série “Mesurer l’agilité” :

Paul pensait y voir un peu plus clair. Il avait compris ce que signifie “mesurer l’agilité” de ses équipes ou de son organisation. De plus, il avait également compris comment faire passer le message, en interne : la mesure fait partie du processus d’apprentissage et d’amélioration auquel ses équipes pouvaient prétendre. Enfin, il s’était renseigné sur différents indicateurs qui pouvaient être mesurés facilement par ses équipes. Chacun ayant une vraie utilité quant au message qu’ils faisaient passer.

C’était il y a trois mois. Depuis, dire que tout ne s’est pas passé comme prévu relève de l’euphémisme.

Genèse d’un désastre

Paul a commencé par présenter au comité de direction de l’entreprise certains indicateurs. Ce sont ceux qu’il a prévu de demander à chaque équipe de partager. Alex, le directeur, était aux anges. A tel point qu’il a demandé d’autres indicateurs, au niveau de l’entreprise, du programme, de chaque équipe, de chaque individu dans chaque équipe. De six indicateurs par équipe, nous sommes arrivés à un dashboard de vingt indicateurs à différents niveaux de granularité, certains portant sur la performance individuelle.

Un nouvel outil a vu le jour, le KILLMI. Deux fois par jour, les membres des équipes doivent se connecter au KPI Instantiator for a Lean Learning Mission-based Industry. Il y saisissent une quantité non négligeable de données qui va permettre de préparer le COKARD. Vélocité, reste à faire, temps passé sur chaque demande, marge brute… C’est un outil génial : en seulement deux heures par jour, les équipes arrivent à gagner trente minutes de préparation hebdomadaire au COKARD, et ont la garantie d’arriver avec des indicateurs justes.

Le COKARD, ou Comité Opérationnel des KPI Agiles Rationnalisés pour la Direction, parlons-en justement. Il a été mis en place pour que chaque équipe puisse partager ses indicateurs devant le comité de direction de l’entreprise. Il a désormais lieu une fois par semaine et dure quatre heures, le temps que tout le monde ait pu partager et justifier sa progression (ou non-progression). Le responsable de chaque équipe a l’obligation de participer à cette réunion.

Mesurer l'agilité : les pièges
La mise en place du KILLMI et du COKARD a permis d’améliorer de 17,872% la circulation de l’eau dans les responsables d’équipe
Photo by Hans Reniers on Unsplash

Les indicateurs présentés pendant le COKARD sont minutieusement étudiés pendant la session. Les chiffres qui présentent un écart de plus de 5% avec les estimations initiales ou les engagements pris sont débattus en séance. Le responsable de l’équipe justifie les valeurs présentées.

Au terme de chaque COKARD, un podium des équipes performantes de l’entreprise est affiché sur tous les écrans dans l’entreprise. Il est ensuite envoyé par email à chaque collaborateur de l’entreprise, ainsi qu’aux actionnaires. Tout membre d’une équipe qui garde sa place sur le podium pendant plus de deux semaines consécutives a droit à une prime équivalant à 5% de son salaire, et jusqu’à 15% pour le manager de cette équipe.

“C’était il y a seulement trois mois…”, se dit Paul alors qu’il jette un œil pensif à la lettre de démission qu’il a imprimée il y a une semaine et qu’il ne s’est toujours pas décidé à envoyer.

Qu’est-ce qui a bien pu aller de travers à ce point ? Dans quels pièges Paul et son organisation ont-ils pu tomber ?

Mesurer l’agilité sans savoir pourquoi

Nous en parlions dans le précédent article : mesurer l’agilité d’une équipe ou d’une organisation n’est pas quelque chose qui devrait choquer. Être agile, c’est délivrer de la valeur de façon régulière. C’est se donner la capacité de s’adapter. Mais c’est aussi pouvoir réagir à un imprévu, tout en gardant en tête que nous sommes des êtres humains. Car le bien-être de nos équipes et la satisfaction de nos utilisateurs sont toutes les deux cruciales à la réussite de nos activités.

Or, si nous réalisons des mesures régulières afin d’avoir une référence utilisable pour nous améliorer, il est indispensable de les réaliser pour des bonnes raisons et de les analyser avec le bon prisme. Autrement, les choses peuvent tout à fait déraper très rapidement. Je ne serais pas étonné si vous me disiez que la situation de Paul, décrite juste au-dessus, vous paraît tristement familière.
De nombreuses équipes ou entreprises mesurent aujourd’hui des indicateurs qu’elles n’utilisent même pas. Elles composent de jolis tableaux de bord dans Jira, PowerBI ou Microsoft Excel. Mais elles sont incapables de prendre une décision argumentée qui leur permettra d’améliorer leur mode de fonctionnement et leurs résultats par la suite.

Mesurer l'agilité - indicateurs et tableaux de bord
La règle n°1 dans la construction de tout tableau de bord : plus il y a d’indicateurs, mieux c’est
Photo by Arie Wubben on Unsplash

C’est le syndrome du “on m’a demandé de”. En l’occurrence, dans l’entreprise de Paul, le grand patron Alex veut voir des indicateurs. On produit donc des indicateurs, et en masse s’il vous plaît, pour montrer que “nous ne sommes pas des rigolos”. Pourquoi ? Pourquoi ceux-ci ? Aucune idée.

Et le fait qu’Alex ait demandé tellement plus d’indicateurs que ce que Paul avait proposé initialement est également le symptôme d’un autre problème, auquel nous arrivons. Car une fois qu’on se rappelle du POURQUOI de la mesure, cela doit aussi nous aiguiller sur le QUI et sur le QUOI. Nous parlerons du QUOI (quels indicateurs) dans un prochain article.

Confondre transparence et flicage

En attendant, QUI va choisir les mesures à réaliser ? QUI va être responsable de la mise en place de ces mesures ? QUI va être concerné par les valeurs des indicateurs et leur évolution ? Enfin, QUI y aura accès, tout simplement ?

Si une équipe met en place certains indicateurs à son niveau, c’est pour améliorer son propre mode de fonctionnement. À ce titre, c’est à l’équipe de décider quels indicateurs suivre. C’est à elle de prendre collectivement la responsabilité de les suivre. C’est à elle de décider des actions permettant d’améliorer son mode de fonctionnement lorsqu’un des indicateurs indiquera à une diminution de la qualité, de la réactivité, de la satisfaction utilisateurs…

Cela doit éviter le retour à une politique du “command & control”, au marquage à la culotte dès qu’un indicateur paraît dévier de sa trajectoire idéale. Si une chose telle que le COKARD existe pour vérifier de façon détaillée les indicateurs de chaque équipe, c’est sans doute parce que l’entreprise de Paul n’a pas compris, en premier lieu, qu’une équipe agile était une équipe responsabilisée, auto-organisée et libre de choisir sa façon d’agir pour accomplir un objectif bien plus large.

Agilité et mesure - confondre transparence et flicage
La patrouille s’apprête à arrêter un manager qui n’a pas partagé la vélocité de son équipe sur KILLMI depuis 72 heures
Photo by Jason Hafso on Unsplash

Une équipe agile ne devrait pas non plus cacher jalousement ses indicateurs, il n’y a rien de confidentiel là-dedans. Mais c’est évidemment ce qui peut arriver quand elle a l’impression de perdre le contrôle de sa propre démarche d’amélioration au détriment d’une volonté de briller, ou de dénigrer, à des fins politiques.

Dans tous les cas, une équipe agile devrait être responsable de sa démarche de mesure : que mesure-t-on ? pourquoi ? quelles décisions cela nous permet-il de prendre, et avec qui on partage cette démarche ?

Mettre les équipes en compétition entre elles

Quand on commence à comparer les équipes les unes par rapport aux autres, d’autant plus quand il s’agit d’être le plus haut possible dans un classement et même de toucher une prime en fonction de son résultat, peut-on encore réellement s’attendre à ce qu’il y ait de l’entraide, de la bienveillance, de la transparence, du transfert de compétences entre les différents groupes ? Tous ces éléments qui doivent permettre de tirer toute l’organisation vers le haut, et pas juste un petit groupe de personnes qui veulent tirer leur épingle du jeu ?

C’est aussi là qu’on voit la mise en exergue de ce qu’on appelle les vanity metrics, qu’on pourrait traduire en français de façon approximative en métriques de vanité. Ces indicateurs ne sont pas toujours dénués de tout intérêt. Mais ils ne sont pas forcément les plus intéressants à suivre. Pourtant, on va s’attacher à les mettre en avant parce qu’ils sont ceux qui nous permettent de paraître plus performants.

C’est un peu comme si une équipe support se targuait d’une augmentation du nombre de tickets traités d’une année sur l’autre. À côté, une autre équipe support arrive à faire gagner ses utilisateurs en autonomie, diminuant ainsi la fréquence de ses interventions. L’équipe qui traite 1000 tickets performe-t-elle mieux que celle qui en traite 500 ? À vous de me dire.

C’est aussi là qu’on voit apparaître certains réflexes, comme le fait de “truquer” certains indicateurs, non pas en essayant réellement de s’améliorer, mais en déclenchant des actions simplement destinées à gonfler les indicateurs : n’appeler que les clients dont on connaît déjà le niveau de satisfaction pour notre enquête annuelle, implémenter des dizaines de tests automatisés vides de sens au lieu de se concentrer sur les pans les plus critiques de notre application, livrer un package tous les jours, même sans modification réelle, pour donner l’impression qu’on livre plus souvent…

Piège mesure agilité - mettre les équipes en concurrence entre elles
Greg, tu peux me gonfler encore un peu cet indicateur avant le COKARD de demain ?
Photo by Will O on Unsplash 

Et bien sûr, c’est aussi là qu’on voit des managers qui vont mettre une pression insensée sur leurs équipes, dans l’optique de terminer au sommet du Mont Olympe. Cela peut être évident, cela peut être sournois, mais dans tous les cas, c’est aussi là qu’on se retrouve avec des équipes qui tirent la langue, des syndromes d’épuisement professionnel (burnout), et la fin du rythme soutenable qui nous permet de produire un travail de réelle qualité dans de bonnes conditions.

Les équipes ne devraient jamais être mises en compétition les unes avec les autres, comparées entre elles. Une équipe ne devrait jamais se comparer qu’à elle-même. Charge à chaque équipe de savoir quelle est son ambition, jusqu’où elle est désireuse d’aller dans l’amélioration de ses indicateurs.

Mesurer l’agilité : la suite au prochain épisode

Les trois premiers pièges abordés dans cet article :

  • Mesurer sans savoir pourquoi
  • Confondre transparence et flicage
  • Mettre les équipes en compétition entre elles

Quels autres pièges éviter lorsque l’on mesure des indicateurs liés à l’agilité de nos équipes ? Quels indicateurs mesurer ? Restez connectés pour connaître les prochains articles sur le sujet.

Partager cet article :

Mesurer l’agilité, une bonne idée ?

Mesurer-lagilité

Tous les articles de notre série “Mesurer l’agilité” :

Paul comprend un peu mieux ce que veut dire “mesurer l’agilité”. Mais une autre réflexion vient désormais hanter son esprit : comment va être perçu le fait qu’il cherche à obtenir des mesures pour un certain nombre d’indicateurs autour de l’agilité ?

Et cela lui fait un peu peur. Paul est manager de trois équipes, chacune étant composée de six à huit personnes. Et même si ce sont des personnes sympathiques, il faut admettre qu’elles ont l’air d’évoluer dans un monde un peu à part, à parler d’auto-organisation, de management horizontal, à faire des rôtis en pleine réunion ou à se réunir autour d’une étoile de mer deux fois par mois.

Imaginez la stupeur de Paul lorsqu’il a surpris son équipe en rétrospective
Image par StockSnap de Pixabay

Car comme nous le précisions dans notre précédent article, Paul dispose déjà d’un tableau de bord avec des indicateurs assez classiques. Mais alors qu’il est autonome pour les mesurer, en ayant accès aux estimations réalisées en début de projet, aux temps imputés par chacun, au reste à faire de chaque tâche, il va désormais devoir s’appuyer sur les personnes de son équipe pour être capable de mesurer ces nouvelles valeurs.

Paul craint que ses équipes perçoivent comme du flicage de nouveaux indicateurs du niveau d’agilité, et que cela génère des réactions hostiles. Comment présenter cela avec sérénité, et comment va-t-il être reçu ?

La mesure, étape indispensable à l’amélioration ?

Qui dit agilité, dit amélioration continue. Amélioration de nos pratiques, de nos postures, et idéalement, de nos résultats. Et comment réellement percevoir une amélioration si on ne compare pas un “avant” avec un “après” ?

C’était peut-être l’avis d’un certain William Edwards Deming, statisticien, auteur, professeur et ingénieur américain du 20ᵉ siècle, lorsqu’il a présenté au Japon la fameuse roue qui porte désormais son nom, la roue de Deming, aussi connue sous le nom de cycle de Shewhart : le PDCA, pour Plan – Do – Check – Act.

PDCA ne veut pas dire “Please Don’t Change Anything”
Image par Karn Bulsuk issue de Wikipédia sous licence CC BY 4.0

Dans un modèle cyclique, itératif, empirique, l’objectif est de prévoir un minimum de choses, de les mettre en application, de vérifier le résultat et d’agir en conséquence pour améliorer les choses en vue du prochain cycle. C’est une approche radicalement différente de l’approche séquentielle, type cycle en V, dans laquelle nous prévoyons tout dès le départ, puis nous exécutons le plan.

L’étape “Check” a une importance cruciale, et nous pourrions mettre derrière ce mot la capacité d’un individu, d’une équipe, d’une organisation, à adopter un point de vue rétrospectif, pourquoi pas en comparant l’état actuel avec la cible que nous cherchons à atteindre. Si cette cible est tangible, mesurable, alors notre positionnement actuel devrait pouvoir l’être également.

Nous reviendrons sur la précision de l’appellation “Check” dans un prochain article.

La mesure dans les approches agiles

Dans la même veine, les trois piliers de Scrum ne sont-ils pas la transparence, l’inspection et l’adaptation ? Inspection qui pourrait tout à fait consister en la mesure d’un certain nombre d’indicateurs sur lesquels nous sommes transparents, et en leur comparaison avec notre cible, afin de vérifier que nous allons dans la bonne direction, et de pouvoir nous adapter.

D’autres approches telles que Kanban pour l’IT font aussi la part belle aux indicateurs. Temps de traversée, temps de cycle, cartes de contrôle… autant d’informations qui doivent nous permettre, en tant qu’équipe, de donner de la visibilité, de limiter la variabilité de notre processus… et de nous adapter si les indicateurs ne sont pas suffisamment “bons”.

Un diagramme de flux cumulés aide rapidement à visualiser l’évolution de nos indicateurs, et donc de la situation de l’équipe, dans une approche agile
Image issue des supports de formation SmartView

La notion de vélocité que la plupart des équipes Scrum utilisent et que Martin Fowler, co-auteur du livre Planning Extreme Programming avec Kent Beck, créateur de XP, présente comme étant une pratique issue d’Extreme Programming, est également une mesure.

En bref, être agile, cela ne signifie pas faire les choses “à l’arrache” ou sans prêter attention de façon régulière au résultat de notre travail et à notre performance. L’inattention aux résultats est d’ailleurs un des dysfonctionnements majeurs d’une équipe tels que les a décrits l’auteur américain Patrick Lencioni dans son livre The Five Dysfunctions of a Team.

De tout temps, les équipes agiles ont mesuré un certain nombre d’indicateurs, pas par vanité, pas pour faire plaisir à un manager, mais dans une optique d’amélioration de leurs pratiques, processus et postures.

Mesurer l’agilité, une bonne idée ?

En ce sens, cela ne devrait choquer personne que l’on cherche à mesurer un certain nombre d’indicateurs au niveau d’une équipe ou d’une organisation. Pour être performante, une personne, une équipe, une organisation, devrait se fixer un minimum d’objectifs et être capable de les atteindre, en vérifiant régulièrement (par exemple via la mesure) si elle est sur le bon chemin.

C’est malheureusement ce qui manque cruellement aux initiatives de type cycle en V aujourd’hui : cette capacité à lever la tête du guidon pendant quelques minutes pour se poser la question de ce qui marche bien, ce qui marche moins bien, et comment améliorer ce qui doit l’être.

Non, nous avons un plan pensé en amont, que nous “déroulons” pendant des mois, indépendamment des indicateurs que nous mesurons, car si nous commençons à les regarder de trop près, nous pourrions être tentés de poser le stylo pour corriger notre trajectoire… ce qui remettrait en question l’intégralité du plan. Toute ressemblance avec des faits réels (survenant en ce moment-même) est évidemment fortuite !

Le compteur indique 270 km/h, mais pas besoin de ralentir, on gère !
Image par PublicDomainPictures sur Pixabay

Le fait de vouloir mesurer un certain nombre d’indicateurs ne devrait donc pas gêner les équipes de Paul… si tant est que Paul et ses équipes réalisent ces mesures pour de bonnes raisons, et que les résultats sont analysés avec le bon prisme. Ce sera le thème du troisième article de notre série.

La suite au prochain épisode

Dans quels pièges ne pas tomber ? Quels indicateurs mesurer ? Restez connectés pour être mis au courant des prochains articles sur le sujet.

Partager cet article :

Mesurer l’agilité : qu’est-ce que cela signifie ?

offre-agile-coaching-formation-smartview

Tous les articles de notre série “Mesurer l’agilité” :

Paul est embêté

Paul* est un directeur de projet dans une société qui produit des logiciels, Scholesoft*. Depuis peu, Scholesoft essaie de changer de mode de fonctionnement. Ils ont suivi des formations autour des pratiques et approches agiles, et appliquent un certain nombre de choses dans leur quotidien.

L’objectif, pour Scholesoft, est d’arriver à délivrer plus régulièrement de nouvelles fonctionnalités, produire des logiciels de qualité, et trouver le bon équilibre entre la satisfaction des utilisateurs et un rythme de travail soutenable pour tout le monde.

Avant de passer à un mode de fonctionnement agile, Paul avait des tableaux de bord avec des indicateurs qu’il suivait : nombre de jours hommes consommés, suivi du budget, respect pour chaque fonctionnalité de l’estimation réalisée en amont, nombre d’anomalies par statut et criticité… Cela lui permettait d’avoir une certaine vision sur ses projets et de prendre des décisions en fonction de ces indicateurs.

Les tableaux de bord pour mesurer l'agilité ?
Voilà une vue à faire frissonner de plaisir tout directeur de projet.
Image de Wiko Bausoftware GmbH sous licence CC-BY-SA 4.0

Mais Paul est embêté.

Lors du dernier comité de pilotage, Alex*, le grand patron, a indiqué qu’il faudrait faire évoluer la batterie d’indicateurs suivie au niveau de chaque projet pour y intégrer des “indicateurs d’agilité”. Pour Paul, l’agilité, c’est encore nouveau. Franchement, y a-t-il vraiment besoin de faire évoluer les indicateurs actuels, qui remontent des informations intéressantes ? Quels indicateurs suivre ? Mais avant toute chose, ça veut dire quoi, des “indicateurs d’agilité” ?

Mesurer l’agilité nécessite de savoir ce qu’est l’agilité

Pour mesurer l’agilité, il serait déjà intéressant de s’intéresser à la définition de l’agilité. C’est la moindre des choses pour savoir ce qu’on va mesurer. Et sur ce premier point, tout le monde n’est déjà pas d’accord. Pour certains, l’agilité, ce sont des méthodes de travail. Pour d’autres, c’est une philosophie. Mais comment mesurer des méthodes de travail ? Comment mesurer une philosophie ?

Vous avez peut-être déjà entendu parler du Manifeste pour le développement agile de logiciels, qui pose les bases de la philosophie agile, avec quatre valeurs fondamentales et douze principes qui le sont tout autant. Cet écrit, rédigé par dix-sept signataires en 2001, fait office de pierre angulaire pour le mouvement agile. Cependant, il reste très théorique : par exemple, nous valorisons les individus et les interactions plus que les processus et les outils.

Lorsque je dispense des formations, la première étape est d’essayer de faire comprendre aux apprenants ce qu’est l’agilité, et pourquoi être agile est important. Être agile, car ce qui compte, c’est bien le résultat final : a-t-on réussi à délivrer plus régulièrement ? Plus souvent ? Un livrable de meilleure qualité ?

Peut-on mesurer l'agilité ? Et comment ?
Lui ne fait pas d’Agile, mais il est agile. Ou allez lui dire le contraire.
Image de StockSnap sur Pixabay

C’est ce genre de choses qui définiront si l’initiative agile que nous avons essayé de lancer a réellement porté ses fruits. Ce n’est pas tant ce qu’on a mis en place pour y arriver : du Scrum ? Du Kanban ? Des pratiques Extreme Programming ?

Être agile, une caractéristique ?

Être agile, finalement, on peut le voir comme une caractéristique d’une organisation, d’une équipe, d’un système, d’un individu. Il y a peu, alors que j’accompagnais une entreprise montpelliéraine, j’essayais de le définir de cette façon :

Une caractéristique propre à un individu, une équipe ou une organisation, qui est capable de s’adapter aux changements de son environnement, via :

  • La livraison la plus régulière et fréquente possible de valeur, en fonction des attentes évolutives de ses utilisateurs et de son écosystème ;
  • Un état d’esprit exemplaire favorisant la collaboration, l’autonomie et l’auto-organisation ;
  • La recherche constante de la qualité et de l’amélioration dans ses activités et ses interactions.

Vous me direz que cette définition n’est sans doute pas parfaite. Mais il n’y a pas UNE définition parfaite de l’agilité. Cette définition ne me paraît en tout cas pas décorrélée des valeurs et principes du mouvement agile.

Une caractéristique, donc ? Comme être grand ou petit, être aimable ou désagréable, être brun ou roux ? Cela peut s’entendre. Et comme pour celles-ci, il faut bien comprendre que l’agilité n’est pas un “flag” à deux états (agile / pas agile).

Boolean isAgile = true;

J’entends parfois des personnes, des équipes, des organisations dire qu’elles sont “full Agile” : qu’est-ce que cela peut bien signifier ? Qui peut se targuer, aujourd’hui, d’être arrivé au niveau maximum de l’agilité ? Qui sait, d’ailleurs, ce qu’est le niveau maximum de l’agilité ? Est-ce que cela veut au moins dire quelque chose ?

Qu'est-ce que signifie être "full agile" ?
Paul attend avec impatience de pouvoir poster sur LinkedIn qu’il est “full agile”.

La démarche vers plus d’agilité est une démarche progressive. Le point de départ est notre état actuel. Le point d’arrivée est… à définir. Comme lorsqu’on prépare un marathon : il y a celles et ceux qui ambitionneront de le courir en deux heures, d’autres en quatre heures, d’autres voudront juste le terminer.

Pour cela, il faut comprendre ce qu’est l’agilité : nous en avons parlé. Puis, pour chacun des axes que nous avons évoqués (livraison de valeur, recherche de la qualité…), nous pouvons essayer de réaliser des mesures de façon indépendante et en tirer des enseignements. Cela pourrait être une façon de “mesurer l’agilité”.

Quelle est notre fréquence de livraison ? Notre taux de retours sur livraisons ? Notre score de satisfaction utilisateur ? C’est le point de départ. Qu’est-ce qui nous paraîtrait un résultat acceptable sur chacun de ces indicateurs ? Cela peut être le point d’arrivée.

Nos indicateurs nous apportent alors ce qu’ils sont censés nous apporter : une compréhension de l’actuel, qui nous permet de prendre des décisions pour l’avenir.

Mesurer l’agilité : la suite au prochain épisode

Mesurer l’agilité, est-ce une bonne idée, ou est-ce antinomique avec les valeurs et principes agiles ? Dans quels pièges ne pas tomber ? Quels indicateurs mesurer ? Restez connectés pour être mis au courant des prochains articles sur le sujet.

*Paul, Alex et Scholesoft sont purement fictifs.

Partager cet article :

Pixel4Scrum : les nouveautés de juillet pour le Lego4Scrum 100% numérique

pixel4scrum-lego4scrum-numérique-1
pixel4scrum-lego4scrum numérique

Le Pixel4Scrum, c’est une version complètement numérique du Lego4Scrum, un jeu permettant de découvrir Scrum en quelques heures dans un atelier ludique (serious game). Si vous voulez en savoir plus, je vous conseille de lire cet article de notre blog, publié en début d’année.

Une nouvelle version du Pixel4Scrum a été partagée cet été, avec quelques adaptations que voici. Vous pouvez toujours retrouver le plateau de jeu et les instructions dans le répertoire Google Drive que voici.

Trouver Pixel4Scrum

Le plateau de jeu disponible en version allégée + au format Mural

Le plateau de jeu du Pixel4Scrum devient disponible en deux versions :

  • la version complète (originale) ;
  • une nouvelle version allégée, qui ne contient plus que les zones de construction (environnements de développement et ville).
Plateau de jeu Pixel4Scrum

Pourquoi une version allégée ?

Certaines des actions à réaliser dans le plateau de jeu ne sont pas très pratiques dans l’outil Google Sheets. Je pense notamment à la planification ou à la mise à jour régulière du management visuel. Il fallait couper-coller bien précisément certaines cases dans certains onglets, les déplacer au bon endroit dans un autre onglet, etc.

De plus, avec le retour au présentiel, certaines équipes pourraient être tentées de réaliser la construction en pixels, mais le reste (backlog, planification, management visuel, rétrospective) en dehors de l’outil (par exemple, sur des tableaux physiques).

Vous avez donc maintenant trois choix :

  • utiliser la version complète du plateau de jeu Pixel4Scrum pour continuer à tout centraliser dans un même outil ;
  • choisir la version allégée du plateau de jeu Pixel4Scrum et réaliser un certain nombre d’actions sur des tableaux physiques ;
  • jouer avec la version allégée du plateau de jeu Pixel4Scrum et réaliser un certain nombre d’actions sur des tableaux blancs collaboratifs numériques (ex : Klaxoon, Miro, Mural…).

Pour les personnes qui feront le troisième choix, vous pouvez utiliser l’outil de votre choix bien entendu, cela vous regarde. Sachez en revanche que pour les utilisateurs de Mural, vous avez un template Mural disponible ici que vous pouvez dupliquer dans votre espace et utiliser très rapidement.

Utiliser et jouer à Pixel4Scrum

Les autres modifications apportées à Pixel4Scrum

Vous pouvez retrouver les autres améliorations apportées au jeu dans le document PDF disponible ici, dans les notes de version tout à la fin du document.

Très rapidement :

  • les revues de sprint sont désormais présentées à une (ou plusieurs) parties prenantes, pour essayer de ne pas créer de confusion dans l’esprit des participants qui avaient l’habitude de présenter à Mme/M. le Maire leurs réalisations en fin de sprint ;
  • les équipes ne sont plus tenues de construire chacune dans sa zone de construction (colonne). Elles peuvent construire à l’endroit qui leur paraît le plus adéquat, ce qui augmente leur créativité ;
  • le document de règles a été légèrement raccourci pour aller plus à l’essentiel. La version courte (supposée tenir en 1 h 30 environ) est désormais présentée dans les variantes pour ne pas alourdir le document de base.

Contactez-nous !

Chez SmartView, nous animons ce jeu dans certaines sessions de formation ou dans des séminaires sur mesure. Et c’est toujours un bon moment partagé entre les joueurs et nous !

Et le jeu reste à disposition de toutes les personnes qui souhaitent l’utiliser ou le modifier, même dans le cadre d’une utilisation commerciale (équivalent licence Creative Commons CC BY 4.0). Il est très probable qu’il évolue dans le futur, en fonction des feedbacks que nous recevrons et que nous vous invitons, dans le même esprit, à partager avec le plus grand nombre.

Nous espérons vous voir très bientôt pour partager ce moment avec vous !

Partager cet article :

Pixel4Scrum, un Lego4Scrum sans Lego et 100% numérique

pixel-for-scrum-SmartView-adapté-de-Lego4Scrum
pixel-for-scrum-SmartView-adapté-de-Lego4Scrum

La crise sanitaire mondiale a changé nos habitudes. Nous avions l’habitude de nous retrouver tous ensemble, nous devons désormais garder nos distances. Nous autres, formateurs, avions l’habitude de rencontrer “de visu” les personnes que nous formions, de pouvoir partager avec elles des moments interactifs, des ateliers et des jeux comme Lego4Scrum. Il a fallu nous adapter afin que cela reste d’actualité.

Un jeu plutôt connu dans le monde de l’agilité est le Lego4Scrum. Vous trouverez de nombreuses explications à ce sujet sur le site dédié à cet atelier. L’objectif : construire une ville en Lego selon une approche empirique, itérative, en l’occurrence selon les règles du framework Scrum. Et donc, généralement, découvrir ce qu’est Scrum et quel en est le fonctionnement. Le tout, en passant un bon moment, car c’est amusant !

Il peut se jouer avec une ou plusieurs équipes et jusqu’à plusieurs dizaines de personnes. Orientées vers un objectif commun (les équipes collaborent, elles ne se concurrencent pas), et au fur à mesure que les équipes construisent, elles utilisent les feedbacks de la personne qui a exprimé ses besoins pour s’adapter.

Comment jouer au Lego4Scrum sans Lego…

… et sans contact humain ? C’est la question qui s’est posée dès le début du premier confinement. Nous avons donc fait le choix de rendre le plateau de jeu numérique. Le concept de construction de ville en équipes selon une approche Scrum reste d’actualité : ce sont les outils qui changent.

Le Pixel4Scrum part de cette intention. Il permet de découvrir, en deux à trois heures, le mode de fonctionnement Scrum dans un exercice pratique grandeur nature. Le tout, en utilisant une zone de travail partagée (Google Sheets en l’occurrence, avec les petites cases qui font office de pixels à colorier) plutôt que des feuilles de paperboard et des Lego.

Il n’y a pas d’autre outil à utiliser pour une partie. Vous n’avez pas de compte à créer sur une quelconque plateforme, pas besoin de jongler entre différents outils. Presque tout le monde dans les publics que j’ai vus participer à ce jeu avait déjà utilisé Excel, pour faire tout et son contraire (mon collègue Damien vous en parlera mieux que moi ici). On essaie de faire en sorte que la prise en main soit aussi rapide que possible, pour se concentrer sur l’essentiel : comprendre une démarche empirique, en l’occurrence Scrum.

J’ai envie d’animer un Pixel4Scrum, comment ça se passe ?

Le plateau de jeu et les instructions détaillées pour animer une partie sont disponibles sur un répertoire Google Drive en lecture seule (pour éviter les modifications involontaires). Vous pouvez dupliquer cela dans un répertoire Google Drive de votre choix et le modifier à votre guise.

Le jeu est mis à disposition de toutes les personnes qui souhaitent l’utiliser ou le modifier, même dans le cadre d’une utilisation commerciale (équivalent licence Creative Commons CC BY 4.0). Il est très probable qu’il évolue dans le futur, en fonction des feedbacks que nous recevrons et que nous vous invitons, dans le même esprit, à partager avec le plus grand nombre.

Si vous souhaitez animer une partie, je vous conseille de lire le document complet qui explique les rôles, ce qui est attendu de chaque participant.e, les leçons à retirer de l’exercice… avant de vous lancer.

Vous trouverez aussi à cet emplacement, sur le blog de l’association Agile Montpellier, l’enregistrement d’un Meetup dans lequel nous avons joué à ce jeu (environ une vingtaine de personnes).

Si vous souhaitez participer en tant que joueur.se pour découvrir Scrum, c’est un jeu qui devient vraiment intéressant à partir de 4 joueurs (hors animateur), donc je vous conseille de former un groupe pour commencer, et éventuellement de nous contacter si vous souhaitez animer ce jeu dans votre contexte. Essayez, dans ce cas, de ne pas lire le document que je mentionne ci-dessus, afin de garder un minimum d’effet de surprise le jour J !

Contactez-nous !

Chez SmartView, nous animons ce jeu dans les sessions de formation “Agilité, comprendre la démarche” (sur trois jours) qui correspondent au premier niveau d’acculturation à ce qu’est l’agilité et aux différentes façons de fonctionner dans l’objectif de devenir plus agiles. Et c’est toujours un bon moment partagé entre les joueurs et nous !

Comme précisé au-dessus, nous pouvons également l’animer dans des sessions dédiées (ex : séminaires d’entreprise).

Nous espérons vous voir très bientôt pour partager ce moment avec vous !

Partager cet article :

Mettre en avant les valeurs de l’agilité

c'est quoi l'agilité ?

J’aimerais croire à un futur dans lequel les personnes vont plus s’attarder sur les valeurs, sur l’état d’esprit qui est nécessaire pour aller vers l’agilité plutôt que sur quelque chose de très froid et presque politisé.

Elie Théocari

C’est quoi l’agilité ?

c'est quoi l'agilité ?

C’est un sujet très vaste. L’agilité, c’est la capacité à s’ajuster, à changer, à pouvoir répondre aux changements de la société en général et également aux attentes des personnes pour lesquelles on construit les produits. Dans le cadre du développement logiciel, l’agilité c’est d’abord un mouvement qui met l’accent sur cela. Ce mouvement incite à construire un produit avec des livraisons régulières et de la valeur. Il est important de livrer un maximum de valeur et de qualité à nos utilisateurs. Il est tout aussi important de les mettre au centre de ce qu’on construit. Et de le faire avec des individus qui sont passionnés, motivés, et contents de faire ce qu’ils font. Donc l’agilité c’est d’abord un mouvement, un état d’esprit. Cela a ensuite été décliné en un certain nombre de principes et de méthodes.

Si vous ne savez pas ce qu’est l’agilité, c’est d’abord les individus et les interactions plus que les processus et les outils. C’est l’adaptation au changement plus que le suivi d’un plan. C’est la collaboration avec les clients plus que la négociation contractuelle. Et enfin, c’est un logiciel opérationnel plus qu’une documentation exhaustive. C’est ce qu’on appelle le manifeste agile, les 4 valeurs de l’agilité, qui animent aujourd’hui ce qu’on retrouve derrière l’agilité. 

Aujourd’hui il y a déjà des personnes, des organisations qui sont moins agiles mais qui tendent à l’être de plus en plus. Il y en d’autres qui le sont également mais qui n’avaient pas forcément mis un mot derrière ça.

Existe-t-il plusieurs agilités ?

En termes de valeurs et d’état d’esprit, je ne pense pas. Je pense qu’il y un certain nombre de concepts forts derrière l’agilité. C’est également le respect des personnes, que ce soit les utilisateurs ou les personnes qui construisent le produit. On parle également du fait de construire quelque chose de façon itérative, incrémentale sur une base régulière. Cet état d’esprit, il faut qu’il soit présent.

Ce n’est pas uniquement le fait d’avoir des sprints ou d’accrocher des post-its sur un mur qui va nous l’apporter. Aujourd’hui, on entend beaucoup parler d’agilité. On a l’impression que c’est un peu une mode, presqu’un argument politique, de dire : « nous, on est agiles, donc on est meilleurs ». Comme aujourd’hui il y a beaucoup d’entreprises qui disent, « nous on cherche un DevOps ». Ce sont en fait des termes qui sont beaucoup plus larges que ce pourquoi ils sont utilisés à ce jour. 

Le projet SmartView, mesure de l’agilité ?

projet smartview-mesurer la transformation agile dans l'entreprise

De plus en plus d’entreprises souhaitent un accompagnement autour de l’agilité. Le projet de mesure de transformation agile intervient dans ce contexte. Et l’agilité, ce n’est pas juste les pratiques mais également l’état d’esprit qu’il y a derrière. Nous intervenons auprès de ces entreprises pour les aider et les sensibiliser. On leur explique en quoi ça consiste et quels vont être les impacts sur leur mode de fonctionnement. Cela avant même de commencer à dire « on va mettre en place du Scrum ou du Kanban ». On n’est pas dans la prescription. On est là uniquement pour faire en sorte qu’elles fassent les meilleurs choix possibles.

Ainsi, une démarche de transformation agile, c’est une démarche de conduite du changement comme une autre. Je suis persuadé qu’il faut savoir se positionner, savoir où on est et vers quoi on ambitionne d’aller. Savoir où on est, c’est comme lorsqu’on utilise un GPS. Il va nous dire « vous êtes à cet endroit » sur la carte. Et savoir concrètement où on se trouve par rapport à notre ambition, c’est également un des enjeux de ce projet de mesure de la transformation agile.

Nous ne sommes pas en train de parler de mesurer par rapport à un concurrent ou à une entreprise. Ni par rapport à un état de l’art qui paraît assez indéfinissable. On est vraiment en train de mesurer ce qu’on est capable de faire aujourd’hui. Qu’est-ce qu’on est capable d’accomplir par rapport à certains indicateurs ? Par rapport à là où on veut aller ? C’est ça, le projet de mesure de transformation agile.

Le futur de l’agilité ?

Le futur de l’agilité aujourd’hui ? J’aimerais croire à un futur où les personnes vont plus s’attarder sur les valeurs, sur l’état d’esprit qui est nécessaire pour aller vers ce type d’approche plutôt que sur quelque chose de très froid et presque politisé. Ce n’est pas « on est agile parce que le fait d’être agile, ça va nous permettre d’attirer des investisseurs, ou parce que ça va nous permettre d’attirer des candidats ». Ça ne doit pas non plus permettre à un patron de division de montrer qu’il a le dessus sur les autres.

On est agile parce qu’aujourd’hui on cherche à construire une société qui est plus tournée vers l’humain, qui est plus tournée vers les autres. Que ce soit les personnes qui consomment nos produits ou que ce soit les personnes qui construisent les produits elles-mêmes.

Un conseil pour les investisseurs ?

Si je devais donner un conseil à un investisseur qui cherche à investir dans des entreprises agiles ? C’est déjà de bien se documenter sur ce qu’est l’agilité. À quoi le voit-on ? L’agilité, c’est un état d’esprit, des valeurs, des principes avant tout. Donc l’objectif est d’investir dans les entreprises qui ont vraiment cela dans leur ADN. Ce n’est pas le fait d’avoir mis en place des sprints, d’avoir un Scrum Master, etc. C’est le fait de se dire « je fais confiance à cette entreprise qui démontre des valeurs qui sont alignées avec ce que je recherche pour la société de demain ». 

Des pièges à éviter ?

équipe agile smartview

S’il y a des pièges à éviter dans le cadre de ce projet, c’est de faire porter le discours uniquement autour de l’indicateur en lui-même. Il y a des choses qu’on pourra mesurer pour permettre à une équipe, à une organisation de savoir où elle en est et vers quoi elle veut aller. On peut parler par exemple du lead time. C’est le délai entre le moment où une demande est émise et le moment où elle est mise à disposition des utilisateurs. Ce sont des choses qu’on peut très facilement compiler via la base de données qu’on va ressortir d’un outil comme Jira par exemple.

Par contre, il y d’autres indicateurs qui me paraissent également très importants. Parmi ceux-là, il y a la satisfaction des utilisateurs et la satisfaction des équipes qui construisent le produit. Un autre point qui me paraît important, c’est qu’il ne faut pas que cela devienne un outil de reporting pour les managers ou pour les dirigeants. Il faut que cela soit vraiment une démarche que l’équipe s’approprie. L’équipe souhaite progresser, souhaite être dans une démarche d’amélioration continue. On n’est pas en train de se dire qu’il y a un manager qui va venir regarder des résultats et dire à l’équipe : « Ça, ce n’est pas bien, vous avez une mauvaise note », etc.

Le but n’est pas de mettre une note à des gens, à des équipes. Le but, c’est vraiment que l’équipe puisse se dire : « d’accord, là on a telle information, on sait qu’on a besoin à chaque fois de 6 mois pour mettre une fonctionnalité en production ». Cela me paraît-il bien ? Veut-on s’améliorer ? Est-ce qu’on peut s’améliorer ? Et c’est sur cette base-là que SmartView sera là pour vous accompagner. 

Interview de notre coach agile, Elie Théocari, réalisée en octobre 2020.

Partager cet article :

Mesurer la transformation agile dans l’entreprise

mesurer la transformation agile dans l'entreprise

SmartView lance un projet pour mesurer la transformation agile dans l’entreprise. L’objectif est de tirer le meilleur des hommes, des méthodes et des outils. Côté outils, l’équipe SmartView s’est concentrée sur leurs cœurs de métier : Agile, Atlassian, Microsoft et Business Intelligence.

Les trois associés de SmartView, Christophe Monnier, Stéphane Génin et Yassine Zakaria, nous parlent de leur vision concernant la transformation de l’entreprise.

Nous avons retranscrit ici plusieurs passages. Retrouvez le lien vers l’intégrale de l’interview (12 minutes) à la fin de l’article.

mesurer la transformation agile dans l'entreprise
Yassine Zakaria, Christophe Monnier et Stéphane Génin – associés SmartView

Mesurer l’agilité dans l’entreprise, qu’est-ce que ça veut dire ?

C’est avant tout s’intéresser au fonctionnement de l’entreprise, et surtout aux femmes et aux hommes qui la font vivre. C’est se poser la question de la capacité de l’entreprise à changer de cap, à réagir, à s’adapter à un nouveau marché ou à une nouvelle concurrence. Enfin, c’est être capable de s’adapter en temps réel à un nouveau contexte.

L’outil et l’agilité

Beaucoup d’entreprises pensent que c’est l’outil qui va leur permettre de devenir agile. Chez SmartView, nous pensons que le plus important dans une entreprise, ce sont les femmes et les hommes qui la composent. Ensuite viennent les méthodes et en dernier, les outils. L’outil permet ainsi de donner des informations qui seront une base d’échange et donc d’amélioration pour les équipes. Cela permet également de mesurer cette amélioration et donc de voir si les équipes sont dans la bonne direction.

Sur le terrain, beaucoup de gens se disent aujourd’hui agiles. Pourtant, quand on creuse, on se rend compte que ce n’est pas toujours le cas. Il faut faire attention aussi au terme « outil ». L’outil, et la mesure qu’il permet, n’est pas là pour sanctionner une équipe. L’outil ou les outils doivent être utilisés avant tout pour préconiser un certain nombre d’axes d’amélioration pour l’équipe et l’entreprise. Quel est donc le but de mesurer l’agilité ? Tout simplement de développer de très bons produits de qualité.

Mesurer la transformation agile – un projet qui nous tient à cœur

Ce projet de « mesurer l’agilité » est une réflexion menée depuis quelques temps par SmartView. L’objectif est de mettre en synergie les expertises, compétences, méthodes et outils avec lesquels nous travaillons. Le but n’est pas de sortir un outil qui donne uniquement des indicateurs. Un outil mal utilisé, cela pourrait se traduire par des résultats qui ne montrent pas la réalité de ce qu’il se passe dans l’entreprise.

L’idée que nous nous faisons d’un « outil », c’est qu’il puisse nous donner une sorte de graduation sur un certain nombre d’aspects de l’agilité, et surtout sur la production de la valeur de l’entreprise. Ainsi, à l’aide de diagnostics et d’entretiens, il nous sera possible de préconiser un certain nombre d’axes d’amélioration sur différents points : l’équipe, le management, les métiers, la priorisation des sujets, la rapidité des livraison, etc. Ces axes doivent permettre à l’équipe agile de les mettre en pratique sur le terrain pour pouvoir optimiser petit à petit leurs produits et leur activité.

Ce qu’en disent nos associés…

« Ce projet, qui s’articule sur le fond sur les valeurs fortes de SmartView (Fierté, Initiative, Honnêteté et Solidarité), c’est avant tout une aventure qu’on a envie de partager avec nos clients et nos équipes. » Stéphane Génin

« Ce travail autour de l’agilité nous permet de réunir toutes nos forces et toutes nos compétences et cela nous conforte dans la mission et les objectifs en commun que nous avons chez SmartView. » Christophe Monnier

« Sincèrement, c’est un projet qui remporte l’adhésion de nos équipes. Chacun montre de l’enthousiasme, que ce soit dans les équipes Atlassian, Microsoft, BI et, bien entendu, agile. Tout le monde est motivé par ce projet ! » Yassine Zakaria

Interview réalisée durant l’été 2020 dans les locaux de SmartView à Montpellier.

Partager cet article :