La production vs les effets

Il n’est pas rare d’entendre des membres d’équipes dirent : “On a fait 90 points pendant ce sprint. C’est super! Beau travail!” ou “Mon équipe est capable de faire 150 points/sprint”. Bon score me direz-vous. Pourquoi pas. Mais qu’en est-il des effets qui découlent de ce travail fourni. Quels sont les fruits récoltés à l’issu de cette moisson de points? Plutôt que de se targuer d’un tel score, est-ce que l’équipe a aussi pris le temps de mesurer la satisfaction client produite par leurs derniers efforts? Beaucoup de questions qui restent malheureusement trop souvent en suspens ou qui entraînent des réponses négatives.

L’objectif de cet article va être de montrer la différence entre la poursuite de la performance liée à la productivité versus la recherche de l’obtention de résultats tangibles et exploitables pour la suite de la vie d’un produit.

Différence entre l’output et l’outcome

L’output est la quantité du travail fourni par un individu ou une machine tandis que l’outcome représente les effets qui découlent d’une action ou d’un évènement. Autrement dit, la production d’une équipe se mesure par exemple au travers de sa vélocité ou du nombre de tickets terminés (throughput) alors que le résultat réside dans la manière dont l’utilisateur va réagir vis-à-vis d’une nouvelle fonctionnalité ou d’un changement.

On comprend donc qu’il va être très facile de monitorer la production d’une équipe mais nettement plus compliqué et coûteux de suivre son outcome à mesure que le produit évolue. C’est sûrement une des raisons pour lesquelles les entreprises se concentrent sur la production. En effet, l’analyse des résultats va demander énormément d’analyse souvent opérée par plusieurs personnes ou plusieurs équipes. Divers outils devront être utilisés comme l’analyse des chiffres liés au trafic, l’interview des utilisateurs ou la création d’enquêtes de satisfaction. Il est également plus difficile de définir les effets attendus par rapport à sa cible. Par exemple, est-ce que l’augmentation du temps passé sur la page Panier est un bon effet ou plutôt un indicateur d’un défaut discret?

Donc, en résumé, les métriques de production restent superficielles alors que l’analyse des effets représente la chair du fruit sous la coque épaisse qui montre si oui ou non de la valeur a été générée.

Utiliser les artefacts comme il se doit

Tout le monde connait le framework Scrum aujourd’hui. Je ne vous apprends rien en vous disant que le dernier Scrum Guide en date indique qu’il existe 3 artefacts : le Product Backlog, le Sprint Backlog et l’Incrément. En général, jusqu’ici tout va bien. C’est plus tard que ça se corse en général. Ces artefacts fonctionnent chacun autour d’un axe sur lequel l’équipe doit s’engager. En effet, le Product Backlog doit vivre grâce au Product Goal. Le Sprint Backlog vit grâce au Sprint Goal. Et l’Incrément doit vivre grâce à la Definition of Done qui sera le gage de qualité minimum requis pour délivrer le travail.

Sachant ça, on se rend compte que ces engagements sont trop souvent délaissés au profit de l’output avant tout. On rencontre beaucoup d’équipe qui multiplie les Scrumbuts en se disant : “On a pas besoin de Product Goal, on sait quoi faire pour terminer le projet”. En l’occurrence, un bon Product Owner se doit de veiller au grain pour définir un Product Goal auquel l’équipe devra se concentrer tout au long du projet et qui est également diffusé sans équivoque à toutes les parties prenantes en toute transparence.

Bien que l’utilisation, même sommaire, des artefacts demeure un point positif dans la vie des Scrum Team puisqu’ils permettent au moins de diffuser de l’information en toute transparence, ce déficit d’objectif engendre tout de même un travail superficiel qui pousse les organisations à ne mesurer que la productivité. Si les artefacts étaient utilisés comme il se doit, c’est-à-dire des objectifs et des critères de qualité diffusés avec transparence aux intéressés, les compagnies et les équipes pourraient se lancer plus facilement en quête de résultats et d’effets apportés aux utilisateurs.

En d’autres termes, il vaut mieux éviter d’exprimer un Sprint Goal de cette façon : “Faire le bloc de produits similaires” mais plutôt essayer : “Augmenter le montant du panier moyen”. Le premier exemple est un objectif par la production tandis que le second est un objectif exprimé par l’effet attendu. Ce dernier permettra d’analyser si oui ou non le Sprint est couronné de succès après avoir analysé les KPI correspondants. Cette analyse constitue l’Inspection qui doit nécessairement conduire à une Adaptation.

Le piège du waterfall

Les points faibles du Command and Control ne sont plus à démontrer. Ce mode de management archaïque, encore très ancré dans de nombreuses entreprises, force les managers à se concentrer quasi exclusivement sur la productivité superficielle des équipes, puisque les aspects apport de sens et accompagnement des collaborateurs sont réduits à leur strict minimum. C’est la raison pour laquelle, la plupart du temps, quand l’agilité vient d’être mise en place, seule les métriques de production sont exploitées pour déterminer l’efficacité d’une équipe voire pour comparer des équipes entre elles.

Une approche très réductrice de Scrum ou de l’agilité dans son ensemble. En effet, ces frameworks ou stratégies permettent de se concentrer sur la recherche de création de valeur auprès de ses clients et utilisateurs plutôt que de se concentrer sur la recherche du respect du scope,du budget ou de la deadline.

Il apparait donc évident que la productivité ne devient qu’un paramètre secondaire dans l’équation. Ici, il va être plus important de chercher à comprendre si la cible trouve le produit utile. L’utilisateur ne se préoccupe pas de savoir si l’équipe qui a fabriqué le produit qu’il a entre les mains a une vélocité de 36 points sur un sprint de 2 semaines mais plutôt si ce produit répond à ses attentes et règle ses problèmes.

Pour éviter de tomber dans le piège du waterfall classique, le management devra :

  • Diffuser la vision de l’entreprise en toute transparence
  • Alimenter les équipes au niveau du climat business
  • Augmenter la confiance et donner plus de pouvoir au Product Owner pour que les équipes responsables d’un produit définissent des Objectifs Produit orientés outcome au fil du temps

Les effets sont supérieurs à la production

Produire de nouveaux changements sur son produit c’est bien mais en tirer des effets bénéfiques pour les utilisateurs c’est mieux. Il est facile de manipuler la vélocité à sa guise. Par exemple, si l’équipe passe son temps à déplacer un bloc de texte ou à modifier la couleur de fond d’une zone. Très peu de valeur sera générée bien que des choses soient produites.

Comme le sauteur en longueur en athlétisme, il est préférable de prendre le temps de reculer un peu, prendre un peu d’élan pour mieux sauter. Cela permettra de se nourrir des informations qui circulent et de bien préparer les prochains objectifs. Bien que cette prise d’élan soit une prise de risque non négligeable puisqu’il pourra mordre plus facilement que s’il avait sauté directement de la planche. Cela fait parti du jeu. C’est pour ça qu’il adapte sa distance de prise d’élan après chaque tentative grâce à l’inspection et l’analyse de son saut.

Avoir le Courage de travailler sur des sujets difficiles. Prendre le temps de fixer des objectifs pertinents qui servent avant tout le client. Puis, quand la modification est délivrée, Inspecter ce qui s’est passé et s’Adapter en conséquence, par le pivot ou la persévérance, pour s’améliorer constamment. Tout ceci constitue l’essence la méthode.

Vous avez aimé cet article ? Partagez-le !

Author:
Développeur Front-end et Scrum Master certifié