Mythe et légende de l’agilité : être agile permet de produire plus vite ?

Nous voulons être agile pour produire plus vite”.

N’avez-vous jamais entendu cette phrase ? Il m’est arrivé plusieurs fois de l’entendre chez mes clients. Certains veulent devenir agile dans le but d’augmenter la productivité de leurs équipes, de raccourcir les délais de production. Peut-on attendre ce gain d’une transformation agile ? Je vous propose dans cet article d’étudier cette question et d’essayer d’y répondre grâce à mes expériences et mon vécu en entreprise.

Produire plus vite grâce à l’agilité, mythe ou réalité ?

Que nous dit le manifeste agile?

Le manifest agile, créé en 2001, est la base de l’agilité, il se compose de 4 valeurs et 12 principes. Que nous disent ces valeurs et ces principes concernant la performance des équipes ? Y a-t-il des éléments nous permettant d’espérer un gain en productivité ? Sinon, quels gains espèrent-on de l’agilité ?

Parmi les 4 valeurs, j’ai choisi de sélectionner la deuxième, “Des logiciels opérationnels plus qu’une documentation exhaustive”, et la quatrième, “L’adaptation au changement plus que le suivi d’un plan”. Ces valeurs, alors que les 2 autres parlent de collaboration, donc de moyen, mettent en avant les buts premiers de l’agilité, produire de la valeur et s’adapter. Nous n’avons donc pour l’instant aucune mention à la vitesse de production de l’équipe.

Allons un peu plus loin dans notre analyse et regardons les principes. Les 2 premiers principes semblent aller dans le même sens.

  • “Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée”. Dans ce principe, le terme “rapidement” est à interpréter comme étant “au plus tôt” et non “au plus vite”. En effet, le terme original anglais utilisé est bien “early”. Le fond de ce principe est donc d’apporter de la valeur au plus tôt et non de produire plus rapidement.
  • “Accueillez positivement les changements de besoins, même tard dans le projet. Les processus Agiles exploitent le changement pour donner un avantage compétitif au client”. Nous retrouvons ici les notions d’adaptation, ainsi que la notion de valeur ajoutée. Avec les moyens et le temps à notre disposition, nous exploitons le changement afin de produire le maximum de valeur.

Pour le moment, je vais m’arrêter à ces valeurs et principes pour mon analyse. Les autres concernent la collaboration, la qualité, la motivation, l’amélioration.

En résumé, l’agilité a pour objectif principal l’adaptation et l’apport de valeur dans un monde changeant et complexe. Cela peut même induire des retours en arrière et réduire la performance et la productivité au profit de plus de valeur.

Peut-on produire plus vite grâce à l’agilité ?

J’ai pu observer au moins 2 phénomènes qui peuvent amener à penser que l’agilité permet de produire plus vite.

Le premier a un rapport direct avec les attendus de l’agilité, c’est à dire maximiser la valeur produite. Nous privilégions la production d’éléments à forte valeur ajoutée et à coût réduit. On va donc avoir une forte production de valeur dans un temps relativement “court”. Il arrive même que des projets s’arrêtent avant d’avoir tout produit car la valeur produite est suffisante. Nous avons produit moins et terminé au plus tôt, car le produit répond aux attentes du marché. Bien que la productivité de l’équipe ne soit pas plus élevée, nous pouvons avoir cette sensation.

Le deuxième phénomène possible est la réelle amélioration des performances grâce à des pratiques agiles.

Etudions deux principes supplémentaires du manifeste : “La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle” et “À intervalles réguliers, l’équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence”.

Si notre organisation met en place ces principe, c’est à dire de l’amélioration continue, il est possible de gagner en performance. Le fait de prendre le temps de réfléchir et de s’améliorer peut aider une organisation à réduire le gaspillage ou améliorer la qualité de son travail.

Attention cependant à l’interprétation et aux résultats attendus dans ces derniers principes. J’ai pris la liberté de les écarter de ma première sélection de principe car il s’agit de pratique pouvant aider à produire plus vite, mais il ne s’agit que de résultats possibles ! Il est même possible de perdre en vitesse de production au profit de la qualité. Il ne s’agit donc pas d’un attendu ni même d’une certitude mais bien d’une conséquence possible.

 

En conclusion, il est possible de gagner en performance, voire de finir un projet plus rapidement, grâce à l’agilité. Cependant, ça n’est pas le but recherché, ni même une conséquence certaine, l’objectif est bien de produire un maximum de valeur ajoutée et de s’adapter.

 

Le rôle du PO est de gérer le backlog et c’est tout !

Aujourd’hui il y a beaucoup de discussions autour du rôle de product owner (PO); sur ses objectifs mais aussi sur ses outils, notamment le backlog. Il est souvent vu comme réducteur de résumer le travail du PO à la tenue du backlog. Il m’est même arrivé de voir des PO refuser cette tâche et l’attribuer au rôle ajouté de proxy PO (PPO).

Et si je vous disais que le seul et unique objectif du PO est de gérer le backlog ? Mais cela n’a rien de réducteur au contraire. C’est pour clarifier cette pensée que je me propose d’établir une liste non exhaustive du travail qu’il y a derrière « gérer un backlog ».

 

 

Comprendre le besoin

D’abord soyons clair, le backlog est une liste de besoins, et non de solutions. Afin d’apporter de la valeur au produit il est important d’avoir une pensée orientée besoins.

Pour y arriver, dès les premiers instants de la construction du backlog et tout au long de sa durée de vie, le PO doit travailler étroitement avec les futurs utilisateurs et les parties prenantes du projet (sponsors, experts, management…)  Selon le nombre de parties prenantes, il faut également réussir à aligner les contraintes et les besoins pour construire un produit cohérent.

Il s’agit déjà là d’une tâche très compliquée puisque nous avons tendance à réfléchir à des solutions et non des besoins. Et pourtant, le PO n’est pas au bout de ses peines puisque remplir le backlog de besoins n’est que le premier pas.

 

Imaginer une solution

Le PO a besoin de  travailler avec l’équipe de réalisation pour imaginer la meilleure solution possible afin de répondre au besoin de l’utilisateur. C’est-à-dire une solution fonctionnelle qui va apporter de la valeur à l’utilisateur sans dégrader le reste du produit.

Encore une fois, le PO doit aligner les différentes contraintes afin de permettre au produit de correspondre à la vision générale tout en gardant une bonne conception (visuelle, ergonomique et technique).

Le besoin et sa solution doivent être suffisamment explicites et clairs pour que tous les acteurs parlent le même langage et que le produit réalisé corresponde bien à ce qui a été travaillé.

 

Maximiser la valeur ajoutée/apportée

Ne l’oublions pas, l’un des objectifs du product owner est de maximiser la valeur produite, c’est-à-dire le retour sur investissement. Pour cela il a encore 2 missions.

Le PO doit prioriser le backlog de produit suivant divers critères. Cela peut nécessiter de travailler avec les parties prenantes ainsi que l’équipe de réalisation pour comprendre la valeur réelle apportée par la réponse au besoin, ainsi que la difficulté de réalisation de la solution proposée. Au delà de la valeur vécue par l’utilisateur, il y a là la notion de retour sur investissement qui entre en jeu. Dans certains cas les solutions peuvent être revues et dégradées afin de répondre au mieux et au plus vite au besoin.  

Suivre et monitorer l’avancement du produit

Enfin, une dernière tâche souvent attribuée au PO, et qui peut nécessiter une bonne tenue du backlog, est le monitoring sur l’avancement du produit. Il est donc souvent nécessaire d’ajouter des données aux items de backlog et d’avoir une avance suffisamment confortable pour voir arriver les problématiques. Il faut donc effectuer toutes ces tâches avec un peu d’anticipation pour pouvoir s’assurer que la direction que prend le produit est la bonne.

Il est également nécessaire de découper les besoins finement afin de réduire la marge d’erreur et d’assurer un apport de valeur à chaque itération, quelque soit sa durée.

 

Conclusion

Pour « seulement » remplir le backlog, le PO doit donc :

  • aligner les différents acteurs,
  • comprendre les besoins,
  • les découper,
  • imaginer une solution fonctionnelle,
  • et le tout avec une avance permettant de suivre la vision du produit.

Bien entendu aucune de ces tâches ne se fait en une fois et nécessite de nombreux aller-retour et dialogue avec les différentes parties.

Alors, pensez-vous toujours que gérer le backlog soit un travail simple à déléguer à d’autres ? Est-ce réducteur de penser qu’il s’agit de la priorité du PO ?

 

Marc Bougeret