Ne me parlez pas d'indicateur Agile !
il y a 3 ans par JeanLestang

Le management est la plupart du temps convaincu par des enjeux business et des logiques de ROI souvent à court terme mais pas seulement heureusement, tout dépend des entreprises et des managers. Les bénéfices peuvent bien sûr être quantifiés souvent à MT mais aussi être plus qualitatifs dans un premier temps et jouer sur la réputation d'une marque puis sur le bouche à oreille, puis sur les ventes.
Ensuite, tout dépend du marché, B2B ou B2C, des cibles, des cycles de vente, produit, service....Pour moi pas de réponse générique mais des convictions et beaucoup d'empathie vis à vis des clients bien sûr mais des équipes aussi. Une démarche permettant d'identifier les facteurs explicatifs, les points d'amélioration et de doter des moyens de piloter à travers d'outils et d'indicateurs et de les regarder dans l'absolu mais surtout en terme d'évolution, de progrès.
Nous avons engagé il y a quelques mois une démarche pour accompagner une PME proposant des services d'intégration de logiciels. Au départ, ils nous ont demandé si on savait traiter un problème de satisfaction client à travers des indicateurs et un baromètre avec l'ambition d'en faire aussi un levier commercial. Nous avons proposé de les accompagner en mode collaboratif en impliquant leurs équipes et leur clients pour co-construire ensemble la solution. L'objectif, mesurer, piloter, mais surtout impliquer les équipes dans cette démarche pour la pérenniser plus la mise en place de 2 indicateurs majeurs, un sur la satisfaction composé d'un agrégat d'indicateurs, un second sur le climat du projet mesuré en miroir entre équipe interne et équipe client. Pour moi la satisfaction des clients passe aussi par la satisfaction des équipes qui assurent le service rendu.
L'ambition pour moi ne se résume pas à mesurer, piloter voire à corriger mais aussi à transformer les comportements dans la durée.

J'ai plusieurs fois constaté la même chose... il y a encore (en particulier dans les grandes entreprises) des programmes de transformation agile qui sont gérés avant tout comme un programme et pas comme une transformation agile.

J'ai une solution intermédiaire à proposer: demander à chacune des équipes agiles de s'auto-évaluer. Prendre ces auto-évaluations comme indicateurs. C'est un peu une pierre, deux coups:
1. pour celles et ceux qui croient en les indicateurs, ca fait l'affaire, certains ne verront pas le changement. Ceux qui le voient, on peut les prendre à part et tenter de leur expliquer le véritable but, qui est :
2. pour les équipes elles-mêmes, on les aide à fonctionner sur un mode d'apprentissage, d'amélioration par la mesure. On va aider les rétrospectives. Et parmi les critères, on peut y mettre la satisfaction client qui va servir surtout au product owner, mais aussi d'autres critères plus techniques ou organisationnels (par exemple s'inspirer des 12 principes du manifeste agile) qui vont servir à l'équipe pour s'améliorer. Car c'est en améliorant le "comment" on travaille qu'on peut aussi améliorer les résultats du pourquoi ;-)

Les difficultés:
- bien sur, les valeurs de ces mesures doivent être prises de manière relative, propre à chaque équipe (comme la vélocité). On est dans le subjectif, le travail de l'équipe sur elle-même. Et pour éviter les réactions "mais pourquoi cette équipe est deux fois meilleure que cette autre ?", le coach peut aider les équipes à "harmoniser un peu" leurs auto-évaluations.
- c'est un casse-tête en cas de sous-traitance pour comparer les fournisseurs entre-eux... le seul critère véritablement valable dans ce cas, c'est effectivement le pourquoi, la satisfaction des clients ou utilisateurs finaux. Dans la mesure où certains critères essentiels (definition of done, une livraison à chaque itération, etc) sont respectés.
- il y a aura toujours des experts maquilleurs qui voudront tirer parti de "bons" indicateurs, même si la réalité est différente. Mieux vaut chercher à les éviter plutot que les combattre...

Un dernier conseil: éviter les points de fonction qui visent à objectiver, calibrer la mesure (mon opinion: utopique!) alors qu'on veut qu'elle soit relative (voire subjective)...

Ca m'amène à conclure sur "comment mesurer la satisfaction client ?": je pense qu'il est suffisant de mesurer *souvent* les *variations* de satisfaction client pour bien piloter son produit. Pour cela, pas besoin de calibrer, d'étalonner. Et quand cette mesure ne permet pas de décider, il est temps d'avoir une vraie conversation avec quelques clients pour avoir leur feedback. Et si vraiment ca ne marche toujours pas, remettre sa vision en question !

Bonjour,

Selon ce que j 'ai pu voir, le management a souvent besoin d'avoir une vision de ce qui se passe sans nécessairement avoir besoin des détails, donc proposer un point régulier ou un slide reprenant les faits marquants et le suivi des calendrier et charges peut être suffisant. Pour ma part, cela fonctionne très bien. Le management sait ce qui se passe, connait les difficultés et peut anticiper sur des escalades (ou des crises)
Sur la mesure réelle de la satisfaction client, c'est plus ambigu et on se retrouve vite dans les travers du "Good enough" ou du 80 / 20: on est dans les clous de ce qu'on peut accepter, budgétairement faire mieux n'est pas rentable. Donc difficile de mesurer... même avec une enquête de satisfaction. Personnellement, je mesure de façon un peu macro ce sujet par mon temps consacrer au traitement des plaintes et autres réclamations. Quand je n'ai que consacre qu'une journée à répondre aux escalades, je pense que la satisfaction "client" est bonne.
En espérant répondre à ta question

Le NPS, Net Promoter Score, pour peu que tu aies une vitrine internet, est un excellent moyen de sonder la satisfaction de tes clients.

Notez que dans mon cas les « clients » sont majoritairement des clients internes : l'informatique propose des solutions à un domaine métier.

Selon moi, les indicateurs doivent créer la confiance dans le processus Agile. Le management (et le contrôle de gestion) cherche à suivre ses engagements budgétaires. Or dans une vraie démarche Agile, on s'engage sur des moyens, pas sur une cible définie dans tous ses détails à l'avance. Si cela fonctionne, on construira peut-être un produit différent de ce que l'on avait envisagé, parce que c'est ce qui convient au client maintenant.

Pour ceux que cela intéresse, une (longue) vidéo inspirante qui propose de parler d'investissements en terme de risque, et de gérer un portefeuille de petits projets, que l'on engagera dès que l'on a de la disponibilité de réalisation. Cela permet même de tenter des projets innovants et risqués, qui pourraient être rapidement abandonnés en cas d'échec (principe du "fail fast").
"Annual Budgeting and Agile IT: How to keep agile from getting compromised when it goes corporate?"
www.youtube.com/watch?v=80DfKrImhhU

3 pages du blog de l'orateur, Ross Petit :
- Part I, Why the CFO isn't Impressed With Agile?
www.rosspettit.com/2011/07/annual-budgeting-and...
- Part II: Why Agile gets Compromised When It Gets to Corporate?
www.rosspettit.com/2011/09/annual-budgeting-and...
- Part III: Operational Predictability versus Financial Rationality
www.rosspettit.com/2011/10/annual-budgeting-and...

Quant à eux, quels sont les indicateurs qu'ils souhaitent ? Peut être y en a-t-il des pertinents ?

Quoiqu'il en soit, tout va dépendre de la typologie de services/produits et donc de clients... On ne mesure par une masse de clients où l'on est dans la vente en volume de produits/services ou bien des relations "personnalisées" où les produits/services s'étendent sur des durées plus longues avec une relations permanente avec le client.

Je dirai que l'agilité doit permettre à un flux de continuer de s'écouler pour produire tout en maintenant la qualité de la production. Donc les KPI seraient pour moi la mesure du débit de ce(s) flux et deux mesures qualitatives : l'une sur le contrôle qualité interne du produit en bout de chaine et l'autre par un contrôle qualité externe basé sur le feedback client. (et j'inclus dans ces flux la réactivité face à une demande client).