La boite à outils du Product Owner pour assurer son rôle : les fondamentaux du user story mapping 

Product Owner et User Story Mapping : les fondamentaux pour assurer son rôle

Le rôle du Product Owner est particulièrement ardu. Pour simplifier, ce rôle est celui d’un hub. Il centralise et opère un mix optimisé d’entrants de niveaux et natures très différents. 
 
Pour n’en citer que quelques-uns, mentionnons des entrants de deux types : 

  • Les nombreux horizons temporels : l’ici et maintenant (le sprint courant et celui à venir) ; le lointain point d’arrivée (une version de produit suffisamment riche pour traduire la vision, et être délivrée) ; l’entre-deux (les différentes échéances entre ces deux repères).
  • Les différents enjeux : à côté des évidents enjeux métier, qui peuvent déjà être variés et parfois antagonistes, des enjeux de nature techniques doivent être pris en compte afin d’assurer que le produit soit disponible à un niveau de qualité compatible avec les objectifs Produit (par exemple la sécurité, la performance, etc). Et un bon Product Onwer ne perd, bien sûr, jamais le fil des enjeux stratégiques irriguant les enjeux Produit. 

C’est pour cette raison que les activités qu’un Product Owner mène simultanément, sont variées. Elles nécessitent une formation solide pour mener ce rôle à bien  : celui qui a à la fois « les mains dans le cambouis » avec des activités de recette, doit aussi ajuster les différents niveaux de planification. Et également donner aux parties prenantes une vision haute des choix stratégique Produit. 

Alors comment faire en tant que Product Owner ?

Au vu des expériences d’accompagnement de démarche agile, une première réponse s’impose. C’est la formation du Product Owner et son coaching pour le soutenir dans la bonne appropriation du rôle.  

Mais, cet équipement intellectuel indispensable ne suffit pas car la complexité et le volume d’informations à gérer est telle qu’elle nécessite des outils facilitant son activité. 

Une difficulté centrale est de faire coexister la bonne gestion du niveau global, stratégique et macro du Produit (ou la macro-définition et sa macro-planification), et le niveau opérationnel (ou la définition fine et la planification envisagée de chacun des sprints). Typiquement, le Product Backlog centralise les thèmes, épics et user stories. Il est un excellent outil de planification opérationnelle mais il ne permet pas de suffisamment rendre compte de la structuration Produit.  

Une image qui traduit bien cette expérience que vit le Product Owner : la logique fonctionnelle du Product Backlog, avec laquelle il a réfléchi et décliné la vision, va se trouver brouillée par la prolifération des user stories et leur répartition dans les différents sprints.  
Si l’on représente par les feuilles d’un arbre chacune des US, cela équivaut à balayer toutes ces feuilles et les mettre en vrac dans un grand sac. La logique Produit, qui était lisible et claire jusqu’alors tout en suivant du regard les branches principales puis secondaires, n’apparait plus. 

Un outil sera particulièrement utile alors pour répondre à ce besoin de croiser la cohérence fonctionnelle et la planification : le Story Mapping.  

Les fondamentaux du user story mapping

L’idée ici n’est pas de faire une démonstration exhaustive de l’usage d’un story mapping. Néanmoins, il est essentiel de comprendre les fondamentaux de la réalisation de ce dernier afin de vous permettre de l’initier. 

Les fondamentaux du user story mapping en 8 étapes : 

  1. Cadrer le produit : définir la vision, c’est le “pourquoi” du produit, ses objectifs.
  1. Créer un ou des personas : c’est définir le “qui”, soit des utilisateurs pour lesquels on créé le produit. 
  1. Construire la colonne vertébrale de votre histoire : décrire l’ensemble du parcours utilisateur et les activités s’y rattachant.
  1. Identifier et regrouper les activités : définir des thèmes communs basés sur les éléments identifiés lors de l’étape précédente.
  1. Décomposer les thèmes en epics, puis en User Stories. L’intérêt d’atteindre une granularité de type User Stories a pour avantage (entre autres) de pouvoir les réaliser dans un délai court, et, apporter une valeur utilisateur tangible. 
  1. Analyser les potentiels écarts : revoir l’ensemble du user story mapping avec des regards croisés. Cela permet l’identification des éléments manquants (parcours utilisateur, taille/complexité des User Stories, difficultés utilisateurs, etc…).
  1. Hiérarchiser les User Stories : à l’aide d’outils de priorisation de type MoSCoW. Il s’agit ici de prioriser à la verticale les User Stories sous chaque thème. Du plus important en haut, au moins important en bas.
  1. Répartir les User Stories en itérations ou versions. C’est définir de façon horizontale l’ensemble des User Stories qui constitueront vos prochaines itérations ou versions. Cette première version peut être constituer le MVP (Minimum Viable Product). 

Pour plus d’informations

Vous pouvez prendre le temps de découvrir les articles de Jeff Patton. Ainsi que son ouvrage majeur sur le sujet « User Story mapping. Visualisez vos user stories pour développer le bon produit » 

Le story mapping, livre de Jeff Patton

En résumé, la complexité des activités du Product Owner nécessite un outil puissant de recontextualisation sur lequel s’appuyer à toutes les étapes du projet. Le story mapping est un outil de vision, de stratégie, de priorisation puisant. À ce titre, il est assurément complémentaire du Backlog de Produit qui lui a vocation essentielle à ordonnancer la planification opérationnelle. 

Partager cet article :

L’agilité, une voie royale pour améliorer la qualité de vie au travail ?

image de deux collaborateurs illustration
Deux collaborateurs agiles qui travaillent ensemble dans une bonne qualité de vie au travail.

Comment améliorer la qualité de vie au travail ? L’agilité peut-elle être une réponse pour améliorer la QVT (qualité de vie au travail) ?

La qualité de vie au travail (QVT) est un concept apparu dans le prolongement de courants de pensée. Elle met en lumière les limites du taylorisme : notamment la démotivation, le sentiment d’aliénation. Et par ricochet, leurs impacts négatifs sur la qualité et la productivité.

Les origines de l’agilité sont également en réaction à l’héritage tayloriste. Dès les années 1950, William Edwards Deming ouvre une voie à contre courant du taylorisme dominant. Le professeur Deming met en lumière des concepts tels que l’autogestion et le positionnement du leader au service des équipes. Il traite aussi des problématiques concernant l’esprit d’équipe, la valorisation de relations basées sur la confiance, l’apprentissage et l’amélioration continue. Il s’agit de mettre les employés en capacité d’agir, de s’améliorer et d’être fiers de leur travail.

Toyota : un exemple des pratiques Lean dans l’entreprise

Cette pensée novatrice inspire à cette même période les pratiques Toyota. En 1990, Jones et Womack reconceptualisent ces pratiques, en rupture avec le taylorisme, sous l’appellation Lean.

Ces pratiques Toyota et leur conceptualisation Lean vont finalement se développer dans la production logicielle. De nombreux experts expérimentent des modes de gestion de projet alternatifs. Cela leur permet de déjouer les excès de la division du travail et de la prédiction, hérités de la pensée tayloriste.

En 2001, 17 experts en développement informatique formalisent les valeurs et principes qui leur sont communs : c’est le Manifeste Agile. Il donnera une véritable visibilité à ces alternatives. Elles sont aujourd’hui massivement en voie d’adoption dans la production logicielle. Plus ou moins bien, mais ça, c’est une autre histoire…

L’origine de l’agilité et de la qualité de vie au travail reposent donc sur un socle commun. Pourtant, on les aborde sous des angles et avec des finalités tout à fait distincts. L’enjeu initial de la qualité de vie au travail est celui de la santé et du bien-être au travail. L’enjeu de l’approche agile (et du Lean) est celui de l’efficacité de la production et de son adéquation avec le besoin.

La cohésion d'équipe et la collaboration, gage de qualité de vie au travail.

Prendre soin de l’humain, c’est bon pour l’entreprise ?

Pour autant, ces motivations initiales distinctes débouchent sur un même fondement sous-jacent. Le potentiel humain d’une entreprise est un capital précieux à préserver et à bonifier.

Ainsi, prendre soin de ce potentiel confère de nombreux avantages concurrentiels.

D’une part, cela permet une gestion plus efficace, notamment par l’implication et la fidélisation des salariés et par les améliorations opérationnelles susceptibles d’en résulter (qualité, réduction de gaspillage, etc). D’autre part, la valorisation du facteur humain crée des conditions favorables à l’innovation. C’est-à-dire un écosystème humain et organisationnel au sein de l’entreprise qui lui est propice.

On pourrait là légitimement vouloir faire le procès des démarches Lean et Agile qui prennent soin du salarié à des fins d’efficience. La démarche ne serait-elle pas entachée par cette vile motivation capitalistique ? Et donc susceptible de ne pas être réellement vertueuse pour l’humain ?

Les démarches Lean et Agile, un réel atout pour l’entreprise ?

Si Toyota avait eu les moyens de faire du fordisme, peut-être aurait-il pu appliquer ce modèle qui dominait alors. Mais l’entreprise a finalement inventé une nouvelle voie. Quoi qu’il en soit, lorsque la contrainte oblige à innover, il arrive que, sur ce chemin créé par l’innovation, de nouveaux éléments apparaissent. Ces découvertes transforment l’expérience et les motivations initiales.

Pour réfléchir in concreto, prenons une organisation lambda, qui connaît des difficultés qui se manifestent de manière diverse. Par exemple, cela pourrait être des problèmes de production (réactivité, qualité, volume), des tensions internes entre services ou entre métiers, des lignes managériales. Tout cela renforce la pression pour atteindre des résultats.

Je prends les paris (avec un risque bien faible) que la qualité de vie au travail est dégradée. Et que, sans traitement adapté, l’ensemble de ces symptômes va s’aggraver dans une spirale systémique. C’est ce qu’on appelle familièrement le « cercle vicieux ».

Au-delà des premiers impacts sur le psychisme et le bien-être au travail, l’évolution future prévisible de cette organisation sera une dégradation économique. Puis elle sera certainement financière (et avec très peu de chance de pouvoir innover pour se sortir de cette spirale descendante).

Prendre soin de l'humain au travers de l'agilité : une réponse pour améliorer la qualité de vie au travail ?

Alors, quelles seraient les perspectives de redressement à un stade encore précoce ?

Je vous propose d’imaginer le scénario A (*1). Une démarche sérieuse d’amélioration de la qualité de vie au travail est mise en place. Des dérives et dysfonctionnements organisationnels, relationnels, managériaux seront identifiés comme des vecteurs ou des causes de dégradation de la qualité de vie au travail. La raison d’être de l’organisation est de créer de la valeur pour ses clients ou utilisateurs. Il existe un lien fréquent entre « se sentir bien au travail » et avoir les moyens de « faire du bon travail ». Autrement dit, de créer de la valeur. Je fais l’hypothèse que la convergence entre qualité de vie au travail et efficacité se vérifie au niveau de chaque organisation (*1). Il peut évidemment exister un antagonisme difficilement réductible sur des postes spécifiques. Par exemple, nous pouvons illustrer cela avec des postes dédiés à gérer l’insatisfaction tel qu’un service de réclamation. Il sera dans ce cas plus difficile d’atteindre un niveau de qualité de vie au travail en rapport avec la qualité du traitement des réclamations.

Prenons maintenant le scénario B. Une démarche sérieuse d’agilisation est mise en place. Les mêmes dérives et dysfonctionnements organisationnels, relationnels, managériaux seront encore plus rapidement traités. Car la démarche vise en premier lieu la mise en place des conditions d’efficacité opérationnelle. L’amélioration des conditions d’épanouissement au travail en sera une conséquence mécanique. Par exemple, avec la mise en place de rituels agiles, qui donnent des repères. Mais aussi avec l’approche orientée solution, l’apprentissage et l’amélioration continue qui redonnent confiance et sérénité. Ou encore avec la possibilité réelle d’agir et d’autonomie pour chacun, qui redonne les degrés de liberté indispensables pour le bien-être comme pour l’efficacité.

Est-il alors possible de dire que les démarches de la qualité de vie au travail et l’agilité sont équivalentes en termes de résultat ?

Ce serait réducteur, car la qualité de vie au travail couvre de manière directe bien d’autres enjeux (santé au travail, égalité, etc.). Enjeux que l’agilité pourrait au mieux adresser par un effet de ricochet hypothétique.

En revanche, zoomons sur la seule dimension de la qualité de vie au travail relative au bien-être lié au travail (et à ses conditions organisationnelles plus ou moins épanouissantes). La question de la comparaison a alors davantage de sens. 

Les outils de remédiation aux dysfonctionnements de l’organisation peuvent être très divers. Rien n’empêcherait un bon praticien QVT, qui maîtrise par ailleurs l’agilité, de mobiliser les pratiques agiles pour une démarche QVT. Toutefois, l’agilité est encore beaucoup associée au monde informatique. Il n’est pas certain que les praticiens de la qualité de vie au travail maîtrisent suffisamment les outils agiles.
Avec des outils différents, les résultats dans un contexte donné peuvent s’incarner sous des formes spécifiques difficiles à comparer. La question reste donc ouverte aux retours d’expérience des praticiens de la qualité de vie au travail.

Alors, l’agilité est-elle un bon moyen de mettre en place une démarche de qualité de vie au travail ?

L’expérience d’accompagnement agile le confirme toujours et en tout contexte. Une bonne démarche agile est d’abord une démarche qui redonne aux équipes opérationnelles la place qu’elles méritent de tenir dans la contribution à la création de valeur. Cette revalorisation de l’équipe, par l’autonomie et la confiance, est un marqueur fort. Cela indique qu’une démarche agile est en bonne voie pour réussir. Et cela consolide la poursuite de la démarche grâce à cette « énergie positive » créée au sein de l’organisation.

De mon point de vue d’agiliste, j’ai rencontré des situations et des enjeux très différents. Un des premiers chantiers, et souvent le premier, est de remettre en condition opérationnelle des équipes qui ont été « cassées ». Puis il faut recréer les conditions de la confiance, de l’espoir même. Cela passe d’abord par du processus opérationnel. Il apporte rapidement des bénéfices secondaires vertueux, tels que retrouver la capacité de produire, d’agir, d’exprimer une pensée critique, d’être entendu. Et cela permet d’améliorer la production. Tout cela donne aux individus et aux équipes un réel pouvoir et une fierté professionnelle.

Aussi, sans avoir les grilles de lecture de la qualité de vie au travail, il me semble que les agilistes sérieusement engagés pour accompagner leur client apportent une contribution majeure sur certains composants de la qualité de vie au travail. Pour une entreprise donnée, ces composants peuvent être centraux.

La complémentarité entre l’agilité et la qualité de vie au travail

La démarche QVT présente quant à elle l’avantage d’adresser l’intégralité des composants de la qualité de vie au travail. Nombre d’entre eux ne sont pas directement couverts par une démarche agile. Comme par exemple l’égalité professionnelle, les conditions sanitaires ou encore la gestion des carrières. 

Il est donc plus pertinent d’articuler ces deux approches en complémentarité, selon les besoins et les difficultés d’une entreprise donnée. Et ce, afin de maximiser les bénéfices de ces démarches.

Cette complémentarité peut être renforcée par l’interaction entre elles, jusqu’à des services symbiotiques. Par exemple, une démarche agile peut “ouvrir la voie” et remettre en état opérationnel un service de production. Cela donne l’appui nécessaire à une démarche de qualité de vie au travail qui adresse des difficultés dans la gestion des carrières et la formation. Ou inversement, selon le besoin spécifique de l’entreprise !

Mais les motivations « business » de l’agilité n’entachent-elles pas les préoccupations de la qualité de vie au travail ?

Au-delà de l’association forte entre la qualité de vie au travail et le dynamisme économique d’une organisation, la belle histoire (qui se finit bien) de cette entreprise lambda illustre que ce qui compte, ce n’est pas tant d’où on part, mais où l’on va. Ainsi que la qualité du cheminement.

Une entreprise pourrait lancer une démarche agile avec une compréhension faible du rôle central du « facteur humain ». Si elle est suffisamment bien guidée et capable d’évoluer, elle pourra arriver à d’excellents résultats. Ceux-ci s’expriment autant sur des bénéfices d’épanouissement au travail que sur des gains d’efficience et d’innovation.

A l’inverse, une entreprise qui lance une démarche agile pour des raisons plus « vertueuses* » peut échouer si courage et clairvoyance lui font défaut en chemin.

*Compréhension des enjeux de la qualité de vie au travail, volonté de transformation réelle, etc.

L’expérience nous montre que ce qui fait la différence in fine, c’est, tout comme au sein de l’entreprise, la qualité de l’engagement de ceux et celles qui accompagnent une démarche de transformation d’entreprise.

(1) N’étant pas une spécialiste en qualité de vie au travail, j’invite les experts du domaine à apporter leur regard critique sur ces hypothèses de pensée.

Partager cet article :

Dette technique : illustration chez un éditeur de logiciels 

agile-dette-technique-éditeur-logiciels
Agile - Dette technique chez un éditeur de logiciels

Cet article donne une illustration du mode urgence chez un éditeur logiciel. L’une de ses conséquences les plus frappantes est la création accélérée de la dette technique.

Prenons un éditeur de solutions numériques : son existence dépend totalement de la monétisation de son produit logiciel. C’est justement pour cela qu’il est probable qu’à un moment, il glisse sur la pente savonneuse qui le fait sombrer dans l’enfer.


Il suffit d’un évènement déclencheur pour faire basculer cet éditeur. Par exemple, ce sera la perte d’une ressource critique (départ du développeur qui avait tout en tête). Cela pourra être liée à un rôle critique (un CTO défaillant). Ou encore, une brusque surcharge de travail se présentera (une grosse opportunité commerciale nécessite rapidement un module additionnel). En réalité, l’évènement déclencheur est une simple mèche qui déclenche le potentiel ravageur de dysfonctionnements importants non traités. Par exemple, dans le cas du départ d’une ressource critique, on se retrouvera avec une documentation insuffisante et une absence de gestion de la ressource rare.

Parfois, il s’agit simplement d’un cumul de micro-dysfonctionnements au fil des années, sans même nécessiter un évènement déclencheur.

Toujours est-il qu’à un moment, quelqu’un dit à l’équipe développeurs : « il faut se débrouiller pour que ça sorte pour telle date ». Et c’est là le début des ennuis.

Généralement, devant une pression forte de délai, les développeurs identifient des raccourcis et réalisent des aménagements temporaires, en coordonnant plus ou moins leurs choix.

Quand les urgences deviennent une dette technique

A côté de possibles raccourcis par rapport aux bonnes pratiques de développement logiciel, la qualité de la conception sera aussi dégradée. Pourquoi ? Pour la simple raison qu’une bonne conception nécessite du temps, de l’intelligence collective, et de la maturation. Et lorsque ce temps n’est pas disponible, la conception est de moindre qualité. Cela limitera par exemple l’évolutivité du logiciel.

Il s’agit donc d’effets purement mécaniques. Les développeurs ne souhaitent pas “mal travailler”, mais ils n’ont simplement pas le temps de “bien travailler”. Cela concerne notamment la production de code suffisamment modulaire, bien documenté et qui respecte les bonnes pratiques de gestion de configuration, de codage, etc.

Et le plus souvent, les libertés par rapport aux bonnes pratiques de développement ont été prises. Même si les équipes projettent sincèrement de remettre au propre le code, dès que l’urgence sera passée.

Ce qui advient rarement dans les faits.

Plusieurs phénomènes empêcheront cette remise au carré. Par exemple, d’autres urgences arriveront. Et la capacité réelle de produire sera probablement devenue inférieure à sa capacité théorique (car diminuée par les effets de dysfonctionnements non traités).

Parmi les dysfonctionnements non traités, il y a notamment la dette technique. Si elle n’est pas soldée, elle va en effet commencer à « coûter » cher en intérêts.

Le code « legacy »

Ce processus relève en effet de la descente aux enfers. Chaque pas supplémentaire vers les tréfonds enrichit le cercle vicieux avec de nouveaux dysfonctionnements.

Dès lors que cette dette technique dépasse un niveau significatif, elle va en effet influer sur la capacité de production et la qualité du produit. C’est un facteur de constitution accélérée de ce qui est appelé un code “legacy”.

En résumé, un code legacy résulte du “désordre” inhérent à tout codage de nouvelles fonctionnalités (sans pression spécifique de délai) si on ne fait rien pour vérifier et nettoyer au fur et à mesure. Cela est comparable à l’utilisation d’un lieu de vie. On le garde propre et rangé par de petits gestes au cours des différents usages. Il serait évidemment vite en désordre et sale sans cette attention. 

La transformation de la base de code en un code legacy va subir un effet d’accélération incontrôlé avec une pression spécifique de délai, avec la multiplication de petites dettes techniques. Cette accumulation de dégradations crée un phénomène si massif que l’on parle de “dette technique’. C’est-à-dire que cela devient un paramètre à part entière qui impacte désormais la vie du produit logiciel.

Comment reconnaître le code « legacy » ?

Ce code legacy se reconnait facilement par la difficulté à utiliser ce code et à le maintenir en condition opérationnelle. L’application insuffisante de bonnes pratiques de développement et d’entretien l’ont rendu de moins en moins compréhensible. Les développeurs n’ont plus les moyens de relier le code et le comportement applicatif réel. Parfois, cette corruption profonde dépasse le champ du développement. Il touche tout le système d’information. Par exemple, plus personne ne sait ce qu’était le comportement applicatif attendu dans certaines situations. Ou à quel besoin correspondait tel comportement applicatif attendu.

La caractéristique majeure d’un code legacy est son imprédictibilité. Les développeurs n’ont plus les moyens d’estimer le temps que prendra une intervention sur le code. Généralement, le couplage fort entre les composants internes combiné au manque de clarté du code fait de n’importe quelle intervention mineure une potentielle aventure de plusieurs jours ou semaines. Un langage permissif va par exemple permettre de créer des objets aberrants ou invisibles. Un bouton Windev peut ainsi abriter du code, qui est de facto caché.

La conséquence de la dette technique sur les équipes

Il n’y a ainsi plus de lien entre la complexité fonctionnelle et la complexité du code (et du travail associé).

Cette équipe de développement est alors en incapacité de donner des estimations fiables. Elle ne peut plus respecter sa propre planification, voire même proposer une planification.

Le tableau final est une équipe de développement démotivée, voire épuisée. Elle compose au mieux avec un code legacy qu’elle peine à faire évoluer et à maintenir en condition opérationnelle. Et pour cause : à chaque mise en production d’un correctif logiciel, « les murs tremblent ». La survenue d’effets de bords surprenants, d’anomalies majeures ou critiques, et une explosion des appels client en sont la conséquence.

Le reste de l’entreprise considère généralement l’équipe de développement comme incompétente. En particulier les instances client (centre d’appel…), qui subissent les effets de l’insatisfaction client. Et la direction produit (ou métiers) qui subit la difficulté de faire évoluer le produit.

Pour résumer, l’équipe de développement est prise en otage par une dette technique devenue incontrôlable. Elle est accusée par le reste de l’entreprise d’incompétence crasse ou de mauvaise volonté.

Pourtant la cause des limitations subies par l’entreprise est bien d’ordre technique. Elle ne relève pas de responsabilité actuelle de l’équipe de développement. Celle-ci fait du mieux qu’elle peut le plus souvent, dans une situation où elle n’a pas de pouvoir d’action en l’état.

Alors que faire pour contrer le phénomène de dette technique ? 

A côté d’une stratégie spécifique pour traiter la dette technique (le symptôme, devenu une cause d’inefficience) et chercher à retrouver une capacité réelle de production, il faudra aussi traiter la cause originelle à l’origine de ce glissement dans un mode urgence qui a créé de la dette technique.

Ainsi il y aura ainsi deux types d’approche (et deux expertises spécialisées) à mobiliser. Une approche technique de résolution de situation de dette. Et une compétence organisationnelle plus large, qui inclut l’organisation processus comme managériale.

Cette remédiation organisationnelle est l’objet de notre article : « Comment l’agilité peut aider à se libérer de la tyrannie du mode urgence ».

Comment l’agilité peut aider à se libérer de la tyrannie du mode urgence ?

confluence-digital-data-agile-smartview
agilité et mode d'urgence dans les entreprises : comment y remédier ?

Au milieu des organisations d’entreprise et des différents niveaux de dysfonctionnement que nous rencontrons comme coachs-formateurs, lors de formations ou d’interventions, il existe un sujet de plus en plus présent dans de nombreuses organisations. 

Ce puissant dénominateur commun occupe une place centrale dans le panel statistique que je considère ici. Celui-ci est constitué de divers participants croisés au fil de plus de dix années de formations dispensées chez Smartview.  

Il s’agit de ce que l’on appelle « le mode urgence ». Nous verrons ensuite comment l’agilité peut aider à se libérer de la tyrannie du mode urgence.

Le « mode urgence », quésako ? 

Il s’agit d’un mode de fonctionnement en urgence, non justifié par une urgence objective. Et qui est devenu un mode nominal. 

Pour être tout à fait clair, définissons d’abord ce qu’est une urgence. 

Une urgence objective relève à la fois de l’imprévisible et de l’important. Un accident cardiaque et une grosse opportunité business ont trois caractéristiques communes. C’est-à-dire, un évènement déclencheur soudain et/ou aléatoire, la nécessité objective d’une action/décision rapide, et des enjeux importants, voire critiques. 

Or, il arrive de plus en plus souvent de voir la gestion des affaires quotidiennes traitées comme le seraient de vraies urgences. Outre une possible réduction du temps de traitement, ce « mode urgence » amènera du stress, de la désorganisation, une moindre maitrise de la qualité en découlant. Cet hypothétique gain de temps immédiat risque de coûter de futurs ralentissements. 

Intéressons-nous un instant aux spécialistes de l’urgence, par exemple les pompiers ou les réanimateurs. Ils sont rompus à une bonne gestion de l’urgence, et ont des modes d’organisation adaptés à ce contexte particulier. 
 
Imaginons une ligne de partage entre les métiers de l’urgence et les autres métiers. Il est intéressant de noter que le « mode urgence » prend en réalité le pire des deux mondes

  • L’urgence, prise dans l’univers de l’urgence réelle (mais sans les ressources d’organisation adaptées pour la gérer) ; 
  • Les modes d’organisation ne relevant pas de l’urgence. 

Comment se manifeste le mode urgence ? 

En entreprise, ce « mode urgence » se manifeste par le constat des opérationnels de « ne pas avoir le temps de traiter tous les sujets », ou « ne plus avoir le temps de bien les traiter ». 

Factuellement, cela peut se traduire à plusieurs niveaux. Typiquement, on retrouvera le plus souvent : 

  • En termes de processus : des temps d’attentes excessifs de traitement, et beaucoup de travail « stocké », qui est en attente ; 
  • En termes de résultats : des « loupés » ou un niveau de qualité déficient, de l’insatisfaction client, et à terme une perte de clients ou des pénalités ; 
  • Et sur le plan social : des personnels démotivés, voire épuisés, avec davantage de turn-over (ou d’accidents du travail, d’arrêts-maladies…). 

Au-delà de ces symptômes, l’accumulation de problèmes finira au bout d’un moment par être telle que la situation paraît tout à fait inextricable

À l’arrivée, il semble qu’il n’existe aucune solution devant ces dysfonctionnements qui s’alimentent les uns les autres. Dans un autre article, nous verrons une illustration de ce mode urgence chez un éditeur logiciel. Le corolaire existe en dehors du développement logiciel avec la dette organisationnelle. 

Y a-t-il un remède simple au mode urgence ? 

Oui.  

Devant cet embrouillamini de problèmes, on pourrait être tenté de penser que non. Alors que la solution est facile à trouver, et si l’organisation s’en donne le courage, elle est accessible et praticable. 

Les causes du mode urgence résultent en effet d’un mécanisme simple. C’est l’existence d’un écart significatif et stable entre le niveau de ressources et le niveau de charge de travail

Le remède ne peut porter que sur deux axes. 

L’axe de solution le plus évident est d’augmenter le niveau de ressources. Pourtant, cet axe de solution devant plutôt être recherché dans un second temps. C’est-à-dire une fois l’autre axe correctif exploré, s’il s’avère que c’est le seul moyen permettant de retrouver un fonctionnement efficace. 

L’autre axe de solution est de diminuer la charge de travail. Ce qui est généralement difficile ou impossible en l’état pour les opérationnels. 

Au niveau des équipes opérationnelles, la seule marge de manœuvre potentielle est celle des améliorations processus significatives. Selon les contextes, il y aura là un gisement plus ou moins important. 

S’il n’y a pas de gains significatifs à attendre d’améliorations processus, comment l’équipe opérationnelle pourrait-elle réduire sa propre charge ? 

Le seul moyen de réduire une charge est… de la réduire. Cela nécessite d’accepter de renoncer : par exemple, renoncer à lancer autant de projets que l’on voudrait sur une période donnée. 

Cette renonciation implique une décision managériale, découlant d’arbitrages entre les enjeux stratégiques de l’organisation. 

Gageons que si l’organisation rencontre ce genre de problème, c’est justement du fait de sa difficulté à décider et à renoncer. C’est là que l’agilité amène des ressources utiles pour débloquer cette situation. 

Les ressources agiles 

Le premier niveau d’action est le niveau stratégique. Cette priorisation va se réaliser en s’appuyant sur des outils typiques des projets agiles. Ces outils permettent de clarifier la vision, d’aiguiser et de faciliter la priorisation de haut niveau. 

Le story mapping

Prenons l’exemple du story mapping stratégique et des outils de priorisation. Ils permettront par exemple de visualiser les hiérarchies entre différents produits et leurs horizons temporels respectifs de réalisation. 

Ces outils de clarification au niveau de la direction de l’organisation sont aussi des outils de communication opérationnelle efficace. Ils sont extrêmement performants. Ils sont visuels et réduits au minimum : ils montrent l’essentiel, et le lien avec la vision et les priorités stratégiques. 

Ainsi, le story mapping stratégique permet de donner une direction claire et réaliste au reste de l’organisation. 
 
L’organisation va ensuite décliner ces priorités stratégiques. Le responsable d’un produit (un Product Owner dans un contexte Scrum) va réaliser son propre story mapping produit

Dans la mesure où un story mapping est une représentation visuelle, le processus de cascade entre ces différents niveaux de planification (ici, les niveaux portfolio et produit) est extrêmement efficient. 

Le story mapping donne une direction claire, et facilite les arbitrages. Cela aide à sortir du mode urgence car l’organisation arrête de fonctionner en surcharge permanente. Elle a les moyens de se focaliser sur les objectifs les plus importants pour créer de la valeur.  

Cette simplification et cette focalisation vont apporter de l’efficacité. 

Autres outils agiles

D’autres outils agiles seront utiles pour les mêmes raisons, tels les outils reposant sur le feedback ou l’approche centrée utilisateur. 

Ces outils ne peuvent donner leur pleine efficacité qu’avec une compréhension pleine des valeurs portées par l’agilité. 

Cette culture agile repose sur le courage au sein de l’organisation. Le courage (1) renvoie ici à la capacité des différents composants de l’organisation à autoriser la remise en cause du statu quo. Il permet des changements de cap salutaires et à tirer les leçons du passé et du présent. 

Il s’agit alors de développer la capacité de l’organisation à accepter l’erreur pour la dépasser, à autoriser la réversibilité, à développer une culture du questionnement radical de la création de valeur. 

Ces outils sont utiles, sinon indispensables, pour lutter contre l’entropie naturelle des organisations. Mais aussi pour le tirer meilleur parti des ressources. Ce sont des vecteurs puissants d’une culture d’entreprise permettant l’innovation. 

En conclusion

Ainsi, un mode de fonctionnement du type “mode urgence” ne résulte pas de situations d’urgence. Il résulte d’un manque de clarification des priorités et de mécanismes efficients de choix. Le mode urgence ne va jamais régler le problème de surcharge. Il va créer de nouveaux problèmes qui vont “endetter” l’organisation jusqu’à réduire sa marge d’action. 
 
À un certain stade, il devient difficile de comprendre comment l’organisation en est arrivée là. Les soi-disant urgences du moment sont incriminées. En fait, c’est la défaillance de processus clés de l’organisation qui est la cause première. Il est vrai que ces pseudo-urgences ont généré de nouveaux dysfonctionnements. Elles ont créé de la dette (technique, organisationnelle). Tout est si embrouillé que les analyses causales tendent à ressembler à la question de l’antériorité de la poule ou de l’œuf. 

À ce stade, une farandole de fausses bonnes idées devrait se succéder afin d’améliorer la situation. Généralement, elles créent de nouveaux problèmes ou apportent de la confusion. Le meilleur exemple est une démarche de réduction des coûts (cost-killing). Cela peut avoir son utilité dans certains contextes, mais sera nuisible dans un contexte de ce type. 

Dans la mesure où les solutions sont simples, il n’est pas exclu que l’organisation arrive à un moment à trouver le courage de résoudre les vraies sources des problèmes, à trouver le courage de changer certains processus sous-jacents viciés, et à retrouver le chemin qui la ramènera vers la création de valeur (2)

(1) Le courage est une valeur de Scrum. 

(2) Ce qui ressemble à un conte de fée existe dans la vraie vie ! Nous rencontrons régulièrement des clients que nous accompagnons dans cette transition. 

Besoin d’aide pour remédier à cela ? 

Si les situations décrites ici vous paraissent familières, ce n’est pas un hasard. Ce sont des situations que nous rencontrons assez communément chez nos clients. 

Le cursus de Product Manager que nous délivrerons cette année en partenariat avec Montpellier Business School est justement là pour cette raison. L’objectif est d’aider à comprendre et corriger certains de ces problèmes, via la mise en œuvre d’une vraie stratégie produit, outillée et supportée par des Product Managers bien formés. Ce cursus est inscrit au Registre National des Certifications Professionnelles (RNCP) et est donc éligible à l’utilisation de votre Compte Professionnel de Formation (CPF). 

Nous organisons un webinaire mardi 8 mars pour échanger avec vous à ce sujet et répondre à vos questions. Pour en savoir plus sur cet événement et vous inscrire, c’est par ici :

Mesurer l’agilité : le mot de la fin

Mesurer-lagilité-vision

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

Vous souvenez-vous de Paul* ? 

Au début de notre saga de sept articles, Paul, directeur de projet de la société Scholesoft*, était pris en tenaille entre la volonté de sa direction de mesurer l’agilité de ses équipes, de son organisation, et son manque de connaissance de ce qu’est l’agilité, et donc ce que cela impliquerait de la mesurer. 

Ensuite, il s’est posé de nombreuses questions autour de la perception de cette mesure dans ses équipes. Comment cela sera-t-il reçu ? Comment évacuer l’idée de la sensation de « flicage » autour de la mise en place de ce type de démarche ? 

Il y a eu ensuite toute l’incompréhension autour de la mise en place d’une énorme machine à gaz. Les dizaines d’indicateurs vides de sens qui lui étaient demandés, ainsi qu’à ses équipes, deux fois par jour. Ce que cela a généré en termes de perte de temps, de mauvaise compétition entre les équipes. 

Mais tout cela, c’est du passé. 

Aujourd’hui, Scholesoft a réussi à mettre en place d’une démarche de mesure de l’agilité de l’organisation. Celle-ci apporte satisfaction, que ce soit au niveau des équipes, du management intermédiaire ou de la direction de l’entreprise. Il a fallu tomber dans les pièges que nous vous avons relatés avant de se relever. 

Dans une approche empirique, l’expérimentation et l’erreur font partie du jeu. Vous allez donc forcément découvrir les obstacles et les résoudre au fur et à mesure que vous avancerez.  

Mais si vous voulez éviter de tomber dans TOUS les pièges, voici quelques conseils que nous pouvons vous donner. Ils sont à mettre en application à différentes étapes de votre parcours. 

*Paul et Scholesoft sont purement fictifs. 

Clarifier la vision 

Avant de se lancer dans une démarche de mesure de l’agilité, il est essentiel de rappeler à toutes et tous ce qu’est l’agilité. Et pourquoi nous devrions chercher à devenir plus agiles. Nous en parlons longuement dans l’article 1

Si le concept d’agilité n’est pas clair pour vous, sachez qu’une session de sensibilisation d’une journée peut déjà suffire à entraîner dans son sillage les parties prenantes et la direction de l’organisation. Des sessions supplémentaires, plus adaptées à certains métiers, peuvent suivre.  

Image par athree23 de Pixabay 

La démarche vers plus d’agilité est une démarche de conduite du changement. Elle prend du temps, il y aura des obstacles sur la route, et l’atteinte de vos objectifs n’est pas garantie. Et comme dans toute démarche de conduite du changement, pour arriver à maximiser vos chances de réussite, fédérer vos collaborateurs autour de cette démarche ne peut que vous aider. 

Nous conseillons ainsi à la direction de clairement communiquer sur la démarche qui se met en œuvre. Quelle est la vision de la destination à atteindre ? Sous quelle échéance souhaite-t-on avoir quels résultats ? Quels sont les changements qui devront s’opérer pour y arriver, qu’ils soient opérationnels, organisationnels ou autres ? Communiquer clairement et régulièrement, par tous les moyens disponibles, est essentiel. 

Dédramatiser la notion de mesure 

Comme nous l’avons évoqué ensemble dans l’article 2, la mesure est pourtant une étape indispensable à l’amélioration dans une approche empirique. Pour pouvoir s’adapter, il est essentiel de pouvoir constater les résultats de nos expérimentations précédentes. Cela, afin de savoir si on a fait mieux ou pas. Puis de savoir à quel niveau placer notre curseur vis-à-vis de nos attentes. 

C’est là qu’il est important d’être transparents, de parler de ce qu’on ambitionne de mesurer, de pourquoi nous souhaitons le mesurer, et d’embarquer tout le monde dans cette démarche de réflexion et de construction. Il n’est pas nécessaire d’infantiliser les équipes . Évitons de retomber dans un modèle où les décideurs ne font que décider, et où les exécutants ne font qu’exécuter. La communication est clé, une nouvelle fois. 

Image par Gerd Altmann de Pixabay 

Dans une démarche agile, et vous l’avez vu avec les indicateurs que nous avons proposés, il est rarement utile d’effectuer des mesures individuelles. Ce qui nous intéresse, c’est la production de valeur, l’atteinte d’un certain niveau de qualité, de prédictibilité… autant de points qui sont liés à un travail collectif. Clarifier le fait que les mesures réalisées seront collectives, et pas individuelles, aide à faire retomber la pression inhérente à ce type d’exercice, et à faire progresser tout le monde dans le même sens. 

Quoi qu’il arrive, afin d’éviter les situations conflictuelles qui ne feraient que ralentir la marche en avant de l’organisation, rattacher des indicateurs individuels mesurables à l’obtention d’une prime, d’une augmentation ou tout autre facteur de motivation extrinsèque devrait être proscrit. Nous avons tous vécu la situation dans laquelle Yvan refusait d’aider Nadia, parce que le temps passé à cela l’empêcherait d’atteindre ses propres objectifs. Clarifier le fait que les objectifs ne seront pas contradictoires entre les équipes promeut la collaboration. 

Choisir les bons indicateurs 

Nous en avons parlé précédemment. Il n’est pas utile de mesurer 72 indicateurs, 12 fois par jour, pour obtenir des données intéressantes et qui nous aideront à nous améliorer. 

Définissez un nombre limité d’indicateurs, une fréquence de mise à jour, et un processus de décision qui doit s’appliquer en fonction de la tendance observée. Les indicateurs que nous avons présentés dans l’article 5 et l’article 6 peuvent être une base de départ. Mais il y en a évidemment d’autres. 

mesurer l'agilité - indicateurs- 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). 

Si vous ne mesurez rien aujourd’hui de façon vraiment disciplinée, mesurer même un ou deux indicateurs de façon régulière sera un progrès. Et vous pourrez toujours compléter votre arsenal par la suite. 

Evitez au maximum tout ce qui est « vanity metrics », dont nous avons parlé dans l’article 3. Ne mesurez pas pour « avoir l’air bons », mais mesurez pour savoir sur quoi vous pouvez vous améliorer. 

Faire preuve de discipline 

Comment parvenir à tirer quelque chose de ses mesures si nous les réalisons quand bon nous semble, sans stratégie ? C’est très peu probable que le temps passé à mesurer produise alors un retour sur investissement. 

Mettre à disposition les bons outils pour aider à réaliser nos mesures est alors un atout non négligeable. Le fait de réduire au maximum le temps passé par les collaborateurs à mesurer, que ce soit par la mise en place d’interfaces adaptées ou même l’automatisation de la production d’un certain nombre d’indicateurs, leur permettra de ne plus voir cela comme une activité rébarbative qui empiète sur leur temps de création de valeur. Si la mesure est moins perçue comme une contrainte, il est alors plus facile de s’y astreindre de façon régulière. 

Photo de Brett Jordan sur Unsplash 

Au-delà de cela, il est important de refaire passer les bons messages quant à l’importance des mesures : à quoi vont-elles nous servir ? pourquoi faisons-nous ces mesures à cette fréquence ? C’est quelque chose que nous avons déjà évoqué précédemment. Ne partez pas du principe que les choses ont déjà été dites une fois, et que cela suffit. La répétition des informations est une composante importante dans tout apprentissage. 

Il faut savoir faire preuve de ténacité vis-à-vis des équipes qui ne jouent pas le jeu, quelle que soit la raison. Pourquoi ne mesurez-vous pas tel indicateur ? Que vous manque-t-il, que ce soit en termes de données, en termes d’outils, en termes de connaissance ? Sans tomber immédiatement dans le jugement, du style « Ils ne mesurent pas cet indicateur parce que cela les ennuie. ». Il est bien de rappeler pourquoi ces indicateurs sont importants pour nous améliorer ensemble. Et de suivre d’un peu plus près les équipes qui peinent à s’astreindre à cet exercice. Tout cela est fondamental pour avoir des données de qualité qui nous aideront à prendre les bonnes décisions au bon moment. 

Faire preuve de solidarité 

Il n’est pas facile pour tout le monde de faire toute la lumière sur la performance de ses équipes. Cela peut être perçu comme un exercice de comparaison dont nous nous passerions bien, vis-à-vis d’autres personnes. Et nous sommes désireux de ne pas être perçus comme les « vilains petits canards ». 

C’est là qu’une culture d’organisation générative sera prépondérante dans notre capacité à vous améliorer. Si les équipes moins agiles, avec une vélocité qui décroît, un taux d’anomalies qui monte, des livraisons qui s’étiolent, sont affichées sur le « mur de la honte » sous les yeux de collaborateurs qui ricanent, ne vous attendez pas à ce que votre démarche de mesure dure dans le temps. 

Image par Sasin Tipchai de Pixabay 

La mesure est essentielle pour s’améliorer, car elle nous permet de nous situer. Savoir que notre performance est insuffisante sur tel ou tel indicateur devrait justement générer un élan de solidarité du reste de l’organisation pour nous aider à atteindre notre objectif. C’est là justement que l’attribution de primes basées sur des objectifs trop individuels risque de nous gêner. 

Gardons à l’esprit que, dans une approche systémique, l’optimisation du système passe par l’optimisation de tous ses composants, ainsi que des connexions entre les composants. Avoir 60% des équipes qui performent correctement et le reste qui est en grande difficulté n’est pas une réponse dans le cadre d’une démarche d’amélioration globale. 

Il est donc de bon ton de valoriser les démarches d’entraide entre les équipes et les départements. Mais aussi de valoriser le savoir-être de ses collaborateurs dans ce genre de situations. À l’inverse, sachez mettre le doigt sur, et recadrer, les comportements pathologiques, afin de faire passer le message que ce genre de choses n’est pas toléré dans un environnement comme le vôtre.  

En synthèse : mesurer l’agilité

Clarifier la vision 

  • Sensibilisez / formez les acteurs de l’organisation 
  • Communiquer sur la démarche de changement 

Dédramatiser la notion de mesure 

  • Embarquer tout le monde dans la démarche de réflexion et de construction
  • Clarifier le fait que les mesures seront collectives 
  • Clarifier le fait que les objectifs ne seront pas contradictoires entre les équipes 

Choisir les bons indicateurs 

  • Définissez un nombre limité d’indicateurs pertinents et une fréquence de mise à jour 
  • Définissez le processus de décision qui doit s’appliquer 

Faire preuve de discipline 

  • Mettre à disposition les bons outils 
  • Refaire passer les bons messages en permanence 
  • Faire preuve de ténacité envers les équipes ne jouant pas le jeu 

Faire preuve de solidarité 

  • Valoriser les démarches d’entraide et de collaboration 
  • Recadrer les comportements pathologiques 

C’est la fin de notre série sur la mesure de l’agilité !

Merci pour votre fidélité ! 

Si vous voulez être mis au courant de nos prochains articles, restons connectés ! Et si vous souhaitez en savoir plus sur nos capacités de formation et d’accompagnement de votre organisation, consultez la page de notre expertise agile et contactez-nous ! 

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.

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.

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.

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.

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.