Quatre valeurs, pas quatre règles
Le Manifeste Agile, publié en 2001, tient en quatre préférences : les personnes et leurs échanges plutôt que les processus et les outils, un produit qui fonctionne plutôt qu'une documentation exhaustive, la collaboration avec le client plutôt que la négociation de contrat, l'adaptation au changement plutôt que le suivi d'un plan. Le texte précise que les éléments de droite ont aussi leur valeur. Il ne dit pas « pas de plan » ni « pas de documentation » : il dit ce qui passe en premier quand il faut arbitrer.
Dix ans plus tard, un numéro spécial du Journal of Systems and Software faisait le point sur la recherche et cherchait encore à expliquer pourquoi ces pratiques fonctionnent, plutôt qu'à seulement les décrire (Dingsøyr et al., 2012). Autrement dit, l'agilité est un ensemble de pratiques qui ont fait leurs preuves sur le terrain, et la théorie arrive après.
Ce que ça change dans le travail de tous les jours
Le travail devient visible
Impossible d'ajuster ce qu'on ne voit pas. Le premier geste d'une équipe qui devient agile consiste souvent à poser toutes ses tâches sur un tableau partagé, quitte à découvrir que dix choses sont « en cours » pour trois personnes.
Le cycle devient court
Au lieu de planifier douze mois, on se donne une ou deux semaines, un objectif et une démonstration à la fin. C'est le principe de base de la méthode Scrum, mais on peut l'appliquer sans en adopter tout le cadre.
La mesure reste simple
À la fin d'un cycle, deux ou trois chiffres suffisent : ce qui est terminé, ce qui est bloqué, ce qui a glissé. Le but est d'en discuter, pas de noter l'équipe.
Démarrer cette semaine avec une équipe de cinq
- Lundi : chacun liste ses tâches en cours et à venir, sans filtre. On les pose sur un tableau commun.
- On choisit une durée de cycle (une semaine pour commencer) et un objectif unique, réaliste.
- Chaque jour, cinq à quinze minutes : qu'est-ce qui avance, qu'est-ce qui bloque.
- Vendredi : trente minutes pour montrer ce qui est vraiment terminé, puis dire à voix haute ce qu'on change la semaine suivante.
Si l'objectif n'est pas atteint au bout de deux cycles, on s'interroge d'abord sur la taille des tâches et l'estimation avant de chercher une autre méthode.
Sources
- Beck, K. et al. (2001). Manifeste pour le développement Agile de logiciels. agilemanifesto.org
- Dingsøyr, T., Nerur, S., Balijepally, V., & Moe, N. B. (2012). A decade of agile methodologies: Towards explaining agile software development. Journal of Systems and Software, 85(6), 1213-1221. doi:10.1016/j.jss.2012.02.033