A quel Agile allez-vous être mangés ?

Dans cet article, je vais essayer de dépasser l’équation Scrum = Agile et expliquer à quels besoins Agile peut répondre. Je propose donc de commencer par évoquer les problèmes auxquels Agile se propose de répondre. Je mets bien un A majuscule à Agile pour bien dire que je prends comme référence le manifeste Agile.

Incertitude

Il y a beaucoup de manières différentes de percevoir l’incertitude. Cela peut être que j’ai du mal à anticiper la suite, qu’au vu des dépendances je ne sais pas par où cela va partir et aussi que j’ai du mal à comprendre les relations de cause à effet. La définition que l’on choisit ne change finalement pas grand-chose à la conclusion, je considère que le changement est naturel et que je dois donc être en capacité de m’adapter. Les méthodes Agile sont considérées comme des méthodes adaptives à la différence du cycle en V qui est vu comme prédictif. Je vais donc m’adapter au changement plutôt que de suivre un plan. Cela veut dire que je vais faire des plans modulaires. Conséquence directe pour les maitrises d’ouvrages : Je ne spécifie pas tout en début de projet et à aucun moment je n’aurais une vision globale détaillée. Je crée bien au début une vision globale, mais je ne détaille qu’au fur et à mesure. Il s’agit d’éviter le gâchis que provoquerait une réorientation d’un projet/produit. Autre attendu, je vais apprendre à travailler avec les personnes qui m’entourent et je vais donc adapter au fur et à mesure mes méthodes de travail.

Communication

Eh, il manque une virgule à tel endroit. Pas de problème, je fais un avenant… Si vous n’avez pas vécu ce type de situation, vous avez de la chance. C’est un résumé de la complexité des différentes phases suivantes : Définir son besoin, exprimer à l’oral son besoin, exprimer à l’écrit son besoin, que la personne en face comprenne le même besoin, qu’elle exprime une solution (oral et écrit), que je comprenne ce qu’elle veut dire,… Il y a d’innombrables sources d’incompréhension dans un process de développement produit. Je peux me dire que je vais m’améliorer dans la gestion des exigences et/ou je peux me dire que cela est inévitable et qu’il vaut mieux montrer un résultat. En Agile, je vais montrer le plus vite possible le résultat final pour récupérer du feedback et ainsi valider que je fais le bon produit. Comme je ne suis pas magicien, je ne vais pas juste faire plus vite ce que je fais déjà en cycle en V. Je vais devoir découper ma solution pour être capable de montrer mon produit final par bout. Point très important, je découpe bien mon expérience utilisateur finale et cela n’est ni un découpage technique, ni un découpage du problème.

Engagement

Dans une approche prédictive comme le cycle en V, je vais construire ce qui a été prévu. Dans les environnements peu volatiles, c’est efficace. Quand ce n’est pas le cas, j’ai un risque très fort pour ne pas dire quasi certain de développer un produit qui n’est plus le bon. Les conditions de marché ont pu changer, la connaissance des utilisateurs n’est plus la même,… En tant qu’équipe de développement, je ne vais pas m’engager sur une solution finale (un contrat) mais plus sur du travail collaboratif pour arriver à la meilleure solution. Pour paraphraser Peter Drucker, rien n’est plus inutile que de faire efficacement ce qu’il ne faudrait pas faire du tout. L’engagement de l’équipe est plus sur la capacité à produire que sur le produit final. Il est normal que le périmètre fonctionnel change en cours de route.

Culture

Par culture, je ne suis pas en train de parler musique ou peinture, mais bien des habitudes de comportement au sein d’une équipe, une organisation,… Quel est le problème ? Plus une organisation est éclatée sur différentes localités, cultures, fuseau horaire,… et plus la communication est compliquée. Je peux me dire qu’en documentant bien mon process de développement, tous ces problèmes disparaitront naturellement. La réponse Agile est plus de se dire que les interactions entre les individus permettront de résoudre les problèmes et de passer outre les difficultés. Il s’agit donc de favoriser les échanges par des interactions directes fréquentes. La configuration Agile standard est donc de la colocalisation.