Agile ? Bien sûr ! Mais… qu'est-ce que c'est ?

Le manifeste

Le Manifeste Agile existe depuis plus de 20 ans et reste l’un des sujets les plus discutés dans l’industrie du logiciel. Il y a un consensus sur le fait que l’Agile peut être bénéfique, et en même temps le nombre de personnes qui s’en plaignent semble toujours croître. Le sujet peut être très polarisant : certains vantent ses mérites, d’autres lui attribuent tous les maux de l’industrie. Alors, quelle est vraiment la définition de l’Agile ?

Les individus et leurs interactions plus que les processus et les outils

Des logiciels opérationnels plus qu’une documentation exhaustive

La collaboration avec les clients plus que la négociation contractuelle

L’adaptation au changement plus que le suivi d’un plan

— agilemanifesto.org

La difficulté ne vient pas de la définition elle-même ; elle vient du fait qu’elle définit des valeurs, un état d’esprit, et non des actions. Par exemple, la plupart des gens s’accorderont à dire qu’un logiciel qui fonctionne a plus de valeur qu’une documentation exhaustive. Mais est-ce que cela signifie qu’on peut se passer de toute documentation ? Bien sûr que non. Alors, quand choisit-on de ne pas documenter ? Qui décide ? Sur quelle base ? Eh bien, ça dépend. Comme toujours. Ce qu’il faut retenir, c’est qu’on devrait se poser la question avant de documenter quoi que ce soit : est-ce que cette documentation va apporter de la valeur ? La réponse changera d’un projet à l’autre, et être Agile ne donne pas la réponse — cela nous rappelle simplement qu’il faut se la poser.

La même logique s’applique aux quatre valeurs. Personne n’a jamais dit qu’il fallait abandonner la documentation, les outils, les contrats ou la planification. Le manifeste n’a jamais eu pour but de nier ces valeurs. Il nous rappelle simplement toutes les valeurs qui comptent, afin que nous puissions faire un choix conscient et toujours investir nos ressources vers nos véritables objectifs. La conscience du choix compte plus que le choix lui-même ; ce n’est pas un dogme.

Scrum n’est pas Agile

Scrum est devenu le framework le plus utilisé pour le développement Agile, au point d’y être presque systématiquement associé. Si une entreprise a des Sprints, un Product Owner, fait des démos régulières — est-elle Agile simplement parce qu’elle suit certaines méthodes Scrum ? Eh bien, ça dépend. Scrum est un cadre de travail : il rend possible, mais ne garantit rien.

On peut travailler à distance ou sur site, avoir de grandes ou de petites équipes, préférer les prestataires ou les salariés, se réunir quotidiennement ou non, faire de nombreux choix… Aucun d’entre eux ne nous dira si nous valorisons les logiciels opérationnels plus que la documentation exhaustive. Aucun n’est par nature Agile ou non. Au mieux, ils peuvent faciliter l’application de certaines valeurs Agile.

Scrum est un framework, une façon d’organiser le travail, la collaboration entre équipes, de manière à rendre l’agilité possible. Scrum ne garantit pas qu’on devienne Agile. Scrum ne valorise pas en lui-même les logiciels opérationnels plus que la documentation — il fournit seulement les outils pour organiser le travail. C’est à nous de faire les choix. C’est à nous d’être Agile.

Si une entreprise définit une forme de time boxing pour les tâches et l’appelle « Sprint », ou si elle reformule toutes ses tâches sous la forme « en tant que… je veux… afin de… », ou si elle laisse les business analysts ajouter des fonctionnalités à tout moment dans une liste — est-ce Agile ? Ce pourrait très bien être de la publicité mensongère : on sait qu’on devrait être Agile, mais on ne veut pas le faire, alors on utilise des mots à la mode pour s’en tirer.

À l’inverse, certaines entreprises appliquent le framework Scrum à la lettre, ont même des Scrum Masters et des Scrum Coaches pour s’assurer que le framework est religieusement respecté. Alors, si l’on suit chaque petite étape du framework, on doit forcément être Agile, n’est-ce pas ? Comme toujours, ça dépend. Se concentrer trop sur le comment, c’est oublier le pourquoi.

Et le pourquoi, c’est évidemment parce qu’on veut faire un meilleur produit !

Un meilleur produit ? Bien sûr ! Mais… qu’est-ce que cela signifie ?

Tout d’abord, j’aimerais essayer de définir ce qu’est un produit et ce que « meilleur » signifie. Je pense qu’il existe toujours une perspective dans laquelle un produit peut être vu comme quelque chose construit par une entreprise pour apporter de la valeur à un client. L’entreprise a payé pour construire le produit, et elle s’attend à ce que le client la paie en retour, de préférence davantage.

J’aimerais noter ici que le client et l’utilisateur ne sont pas toujours la même personne.

• B2B : par exemple, les agents d’un centre d’appels (utilisateurs) peuvent utiliser un logiciel de centre d’appels (produit), mais ils n’en sont pas les clients. Les clients sont les propriétaires du centre d’appels, et dans cette définition, ils utilisent le produit en le donnant à leurs employés pour améliorer leur service.
• B2C avec produit gratuit ? Non, B2B : si l’on considère Google Maps, qui nous donne un accès gratuit à sa plateforme, nous ne sommes pas clients, nous sommes utilisateurs, et le fait que nous utilisions la plateforme permet à Google de vendre de la publicité à leurs vrais clients. De ce point de vue, il y a toujours un produit et des clients ; les utilisateurs font simplement partie du produit.
• Interne : le client peut aussi être l’entreprise elle-même. Par exemple, si le département IT construit un logiciel de facturation pour le département Finance, il y aura un coût dans le département IT, et le « paiement » sera le coût évité dans le département Finance grâce au logiciel automatisé.

Cette définition d’un produit est extrêmement simpliste, mais elle suffit à définir ce qu’est un meilleur produit. Un meilleur produit est un produit qui apporte plus de valeur au client d’une manière qui augmente le paiement que l’on peut en obtenir.

Alors, qu’est-ce que l’Agile ?

La réponse courte, c’est que l’Agile est un état d’esprit qui aide à faire de meilleurs produits, sous certaines conditions.

Certains produits sont clairement définis dès le départ. Parfois il est même exigé que tout soit défini avant de commencer à construire. Par exemple, on ne peut pas poser une brique d’une maison avant d’avoir obtenu l’approbation du plan complet par les autorités. Dans la plupart des industries très réglementées, les mêmes principes s’appliquent. Dans ces cas-là, être agile n’est pas vraiment nécessaire, c’est même parfois interdit, et l’on peut utiliser d’autres frameworks comme le waterfall si l’on peut prendre toutes les décisions pour améliorer la valeur du produit avant de le construire.

Dans l’industrie du logiciel, il arrive assez souvent que le produit ne soit pas clairement défini au début. À la place d’un produit défini, il y a souvent une forme de vision, ou un besoin qui doit être adressé. Nous savons pourquoi nous voulons le produit, mais nous ne savons pas exactement quoi, et encore moins comment le construire. C’est là qu’un état d’esprit Agile aidera à construire un meilleur produit.

Avoir un état d’esprit Agile, c’est :

• Reconnaître qu’il faudra peut-être explorer plusieurs pistes avant de trouver celle qui apportera le plus de valeur
• Admettre qu’on ne sait peut-être pas tout ce qu’on a besoin de savoir au départ, et qu’il faut donc concevoir en même temps qu’on construit
• S’appuyer sur la Continuous Discovery (comme dans « Continuous Discovery Habits » de Teresa Torres)
• Se rappeler à chaque étape que notre objectif est d’apporter de la valeur au client, et que cette valeur, du point de vue du client, sera toujours la seule mesure du succès

Il semble évident que pour obtenir le meilleur produit possible, il faut trouver un moyen de découvrir ce qu’il faut construire et d’évaluer si l’on a construit quelque chose d’utile. Il semble évident qu’il faut collaborer avec le client si l’on veut répondre à ses besoins. Il semble évident qu’il faut s’adapter au changement si l’on ne peut pas tout planifier depuis le début. La plupart des valeurs et principes Agile relèvent du bon sens, et pourtant ils sont très difficiles à appliquer.

Être Agile, c’est se rappeler le pourquoi à chaque étape. Parce que garder la vue d’ensemble est difficile, utiliser le bon sens est difficile, être constant est difficile. Être Agile est difficile. Suivre un guide, c’est plus facile. Alors, on suit ce qu’on croit être la recette de l’Agile : Scrum. Comme vous pouvez le deviner maintenant, je pense que cela peut être dangereux, parce que Scrum n’est qu’un outil. Le premier principe Agile nous enseigne de « valoriser les individus et les interactions plus que les processus et les outils ». Je propose qu’on commence par faire exactement cela.