Explorer les 4 valeurs du Manifeste Agile

Lorsque je commence à apprendre de nouvelles choses, j’aime revenir à la source et découvrir d’où elle vient.

Lorsque l’on examine l’histoire du mouvement Agile, toutes les sources pointent vers le Manifeste Agile, datant de 2001.

Le début

À cette époque, une nouvelle méthodologie de gestion de projet, connue sous le nom de programmation XP, était à la mode dans le développement de logiciels. D’autres méthodologies, appelées “méthodes légères”, faisaient également leur apparition.

17 leaders actifs impliqués dans ces communautés ont décidé de se réunir à Snowbird Utah du 11 au 13 février 2001 pour discuter de ce qui était commun ou de ce qui était différent entre toutes ces méthodes dans le domaine du développement logiciel. C’est de là qu’a émergé le manifeste agile, une déclaration de 4 valeurs qui capturent les idées centrales que tous les participants ont partagées pendant la réunion.

Le mouvement agile était né.

Les 4 valeurs agiles

Chaque valeur a la même construction syntaxique : “déclaration A plus que déclaration B”.

Cette construction acte la nécessité de rétablir un nouvel équilibre entre les deux états. Il ne s’agit pas d’un déni complet de l’affirmation B, ni d’une suprématie absolue de l’affirmation A. Cela veut dire que nous devrions envisager d’accorder plus d’importance à l’affirmation A qu’à l’affirmation B.

Dans cet esprit, les voici :

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

Lorsqu’il s’agit de travailler, nous nous cachons souvent derrière nos processus de gestion et nos outils.

Nous oublions souvent que les processus et les outils ne fonctionnent pas seuls et qu’il y a en fait des personnes qui font encore une grande partie du travail.

Le travail consiste donc à faire interagir des personnes entre elles pour accomplir certaines tâches.

À la fin des années 90, ces interactions étaient vraiment procédurales en raison de la segmentation et de la spécialisation du travail. Les collaborateurs des grandes organisations travaillaient souvent en silos et étaient déconnectés des clients qu’ils servaient. Les employés étaient principalement considérés comme des ressources précieuses.

Pour surmonter ces problèmes de communication, les méthodologies agiles reposent sur des cycles fréquents d’inspection et d’adaptation, sur la confiance et le respect entre les parties prenantes et sur la transparence des données, des actions et des décisions.

Être agile, c’est se recentrer sur les personnes et la façon dont elles travaillent ensemble. Si vous vous trompez, les processus et les outils ne vous seront d’aucune utilité.

Des logiciels opérationnels plus qu’une documentation exhaustive

Dans l’approche typique en cascade, les clients sont audités pour rédiger un document d’exigences. Ensuite, le produit est construit tout en donnant plus de documents aux clients sur l’état de la production. Puis, le produit est testé et si les tests sont réussis, il est livré aux clients.

Le problème est qu’après les entretiens initiaux avec le client, les modifications des exigences sont à peine gérées pendant le processus de production et doivent attendre la fin du cycle de construction et de test.

Ainsi, beaucoup d’efforts sont gaspillés sur des produits livrables qui ne répondent pas aux besoins des clients.

Selon les méthodes agiles, il est préférable de livrer des logiciels fonctionnels à intervalles réguliers plutôt que des documents sur l’état de la production. Cela signifie que vous devez diviser le produit final en petits morceaux de logiciel fonctionnel dont vous pouvez faire la démonstration à votre client.

De cette façon, il est plus probable que vous économisiez du temps et des efforts en travaillant sur des produits livrables utiles, et que vous obteniez des clients plus heureux.

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

En lien avec l’affirmation précédente, le fait d’impliquer les clients tout au long du processus de conception et de production, et non pas uniquement lors de la négociation du contrat, contribue à la production de produits qui ont du sens.

Un contrat ne remplace pas la communication.

Le Manifeste Agile reconnaît que les entreprises qui réussissent écoutent attentivement leurs clients à tout moment du processus de développement et sont capables de s’adapter aux changements.

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

Avoir un plan c’est bien, pouvoir le changer c’est mieux.

Les processus ont tendance à rigidifier l’organisation, ce qui la rend incapable de s’adapter à des situations telles qu’un client qui change d’avis.

Les méthodes agiles affirment que nous devons accueillir le changement, au lieu de le combattre.

La plupart des méthodes agiles mettent en place une production itérative et incrémentale, pour donner une place aux retours d’expérience et en tirer des enseignements.

Être agile

Nous avons tendance à rigidifier tous nos comportements et processus afin de nous sentir plus en sécurité face à l’incertitude.

Ce comportement nous fait perdre beaucoup d’efforts et de temps lorsque les choses ne se déroulent pas comme prévu.

De plus, les membres de l’équipe se sentent mal à l’aise de produire un travail inutile et les clients n’obtiennent pas ce qu’ils ont demandé.

Le Manifeste Agile vise à ramener l’adaptabilité et la flexibilité sur la table.

Ces deux notions favorisent la communication et la collaboration entre les parties prenantes, l’amélioration continue de l’entreprise et des personnes, et la production itérative et incrémentale sur laquelle on demande régulièrement un retour d’information.

C’est un point sur lequel nous sommes profondément d’accord ici à Kantree et nous essayons de le mettre en oeuvre dans notre travail et nos produits.

Lectures utiles sur le sujet

Martin Fowler sur l’origine du Manifeste Agile : Martin était l’un des 17 qui ont rédigé le manifeste. Il a partagé avec nous l’histoire de cet événement.

Jeff Sutherland sur les principes et valeurs agiles : Jeff, auteur de la méthodologie Scrum, revient sur les valeurs agiles et les explique avec son travail sur Scrum.