Les méthodes agiles en dehors de l'informatique

Vaste sujet... Qui m'intéresse (voir ce qui est écrit à droite, là) et dont j'ai déjà parlé (ou dont je parle tout le temps ?) dans ce blog.
Et puis plusieurs échanges m'ont relancé sur ce sujet : une session à Agile Innovation,  et d'autres choses dont je vous reparlerai sûrement.

D'abord, ce n'est pas l'informatique qui a "inventé" l'agilité. Les origines semblent plutôt à chercher dans l'industrie dite 'lourde' (voir Lean, Toyota & co).
Mais qu'à cela ne tienne, bouclons la boucle, retournons tout ça et voyons ce qu'il est possible d'apporter à d'autres domaines.

J'ai repris le manifeste agile et les principes. Il y a des choses qui me semblent relativement faciles à transposer et d'autres moins.
Les faciles :

- privilégier les individus et les interactions plutôt que les processus et les outils,
- privilégier la collaboration avec le client plutôt que la négociation d'un contrat,
- privilégier la réponse au changement plutôt que le suivi d'un plan,

- bâtissez le projet autour de personnes motivées. Donnez-leur l'environnement et le soutien dont elles ont besoin, et croyez en leur capacité à faire le travail,

- la méthode la plus efficace pour transmettre l'information est une conversation en face à face,
- les gens de l'art et les développeurs doivent collaborer quotidiennement au projet
- une attention continue à l'excellence technique et à la qualité de la conception améliore l'agilité,
- la simplicité - l'art de maximiser la quantité de travail à ne pas faire - est essentielle,
- les meilleures architectures, spécifications et conceptions sont issues d'équipes qui s'auto-organisent,
- à intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens,
- les processus agiles promeuvent un rythme de développement soutenable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment.

En résumé, tous les aspects humains : collaboration, confiance, communication et ceux liés à la qualité et la simplicité de ce que l'on réalise. Et ça peut s'adapter à tout, il me semble : création, construction, organisation d'événements, gestion de projets au sens large.

Les moins faciles :

- privilégier les logiciels qui fonctionnent plutôt que la documentation exhaustive,
- notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles,
- le changement est bienvenu, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client,
- livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte
- un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet,

Un peu plus compliqué, là. Car le développement logiciel a des particularités : on peut travailler de façon incrémentale et itérative, ce qui n'est pas toujours évident dans d'autres domaines. Difficile de construire un bout de maison, d'y installer une famille pour qu'elle s'en serve et d'adapter la maison ensuite, en continuant de la construire, en plus.

Ce que l'on peut tirer de ces principes, c'est qu'il faut s'attacher aux réalisations concrètes, à la confrontation avec la réalité, et accepter le changement. Ca ne veut pas dire accepter de détruire la maison et de tout recommencer, mais ne pas rejeter le changement d'office.

Voilà pour les grandes lignes. Et dans un prochain post, j'essaierai d'identifier les pratiques agiles qui sont utilisables : standup meeting, rétrospective, etc.