10 ans après sa parution, le Manifeste Agile n'a pas pris une ride. En réponse aux méthodologies de la fin du XXe siècle qui reléguaient le développement à une activité de simple traduction des spécifications fonctionnelles en langage machine, le mouvement Agile a replacé les équipes de développement au centre de la chaîne de valeur des projets logiciels.

Pour ceux qui connaissent mal, essayons de rapidement capturer quelques points clés essentiels des méthodes Agiles, sans paraphraser le manifeste :

• Efforcez vous de faire simple,
• Décrivez vos intentions à l'aide de tests, codez jusqu'à obtention de la barre verte, puis refactorez votre code,
• Privilégiez autant que possible une conception émergente au fur et à mesure des nouvelles fonctionnalités,
• Au lieu de vous projeter à l'avance sur l'élaboration d'un grandiose paquebot qui (pensez vous) répondra à tous les problèmes, communiquez fréquemment avec votre client pour bien comprendre ses besoins et ses priorités, et vérifier la justesse de ce que vous avez fait.

Le mouvement Agile représente un progrès indéniable, qui a su insuffler un nouvel élan dans les communautés de développeurs, et surtout aidé à répondre mieux aux vrais attentes du client.

XP par exemple, propose un système de 5 valeurs (Simplicité, Communication, Feedback, Courage, Respect) déclinées en principes, puis en pratiques. Ce système a longtemps constitué pour moi une essentielle source d'inspiration pour des propositions d'amélioration de notre travail en équipe.

Nous commençons à avoir un certain recul maintenant sur les méthodes Agiles, et force est de constater que nous sommes encore loin des résultats espérés : l'écrasante majorité des projets de développement informatique (en tout cas dans mon expérience) vieillissent encore rapidement et mal, après une première période d'euphorie.

Pourquoi?

Pour expliquer ces résultats décevants, certains tiendront des discours dogmatiques, tels que :

• les itérations sont trop longues / trop courtes,
• nous ne faisons pas du Kanban,
• nous ne faisons pas du “Vrai XP”, du “Vrai Scrum”, du “Vrai Lean”…

Quelques-uns accuseront “Les Autres”, par quelques attaques du genre :

• c'est la faute du client : il ne joue pas le jeu, ne cherche pas à comprendre notre façon de travailler,
• l'équipe voisine (opérations, experts métiers, …) refuse de prendre ses responsabilités,
• le management ne nous laisse pas faire.

D'autres estimeront que la cause profonde se trouve du coté d'un manque d'organisation et/ou d'unité dans l'équipe :

• nous ne sommes pas une équipe “auto-organisée”,
• l'équipe n'est pas motivée (ou pas de façon uniforme),
• nous ne faisons pas assez de sessions “team-building”,
• nous ne mangeons/sortons/jouons pas suffisamment ensemble.

Enfin, un dernier groupe préfèrera des explications d'ordre purement technique, du type :

• nous ne prenons pas soin de la qualité du code chaque jour, chaque tâche,
• l'équipe manque de compétence,
• nous n'avons jamais réfléchi à une vision technique d'ensemble,
• la couverture des tests est insuffisante.

Ne trouvez vous pas que ces 4 familles de postures apparaissent fréquemment lors des séances de rétrospective? A chaque fois, une ou deux explications remporte(nt) l'adhésion du groupe, des actions correctives sont décidées, puis tout le monde se remet au travail… jusqu'à ce qu'on se rende compte (au bout d'un certain temps, plus au moins long), que nous n'avons le plus souvent rien obtenu de très satisfaisant! Pourquoi? Parce que l'équipe ne s'est souvent jamais sérieusement posé la question fondamentale : “avons nous un vrai objectif commun sur ce projet?”

Cette dernière année fut pour moi exceptionnellement riche en expériences de toutes sortes… mais mon apprentissage le plus fondamental semble déconcertant de simplicité, a posteriori : la meilleure chance de réussir tout projet est de commencer par définir ensemble, de façon claire et explicite, son succès.

Comment?

Tout simplement en posant la question aux bénéficiaires, ceux auxquels le projet est destiné! (généralement désignés comme “les clients”)
Par exemple dans notre cas, où nous faisons ce que certains appellent de la “maintenance évolutive”, nous identifions 2 clients : le premier est responsable du build (notre PO pour les évolutions), et le second s'intéresse à la qualité de service de l'ensemble de la solution (dont nous ne sommes qu'un maillon). Nous leur avons donc posé la question suivante :
Afin pour nous de mieux comprendre votre perspective, pouvez vous nous décrire les conditions pour lesquelles vous direz, dans un an, “je suis content, vous avez été bons”?

Si le client n'est pas bien identifié, ou si la réponse ne convient pas à une partie de l'équipe, il faut alors reculer d'un pas et se poser ensemble (équipe et management) une question encore plus fondamentale, comme : dans quel but ce projet et cette équipe existent-ils aujourd'hui? Que cherchons nous à accomplir ensemble?

C'est un message fort que nous cherchons ici, une vision tenant sur au maximum 3 ou 4 phrases courtes. Il ne faut donc pas hésiter à itérer plusieurs fois jusqu'à obtenir une vision à la fois claire et partagée par tous.

Pourquoi?

La réponse à cette question de base constitue la vraie direction à suivre de l'équipe :

• pour aligner l'attention de tous, tous les jours, sur un objectif commun,
• pour guider une authentique amélioration continue, en se posant les bonnes questions,
• pour nous éviter d'entamer des discussions de comptoir interminables et stériles en rétrospectives, notamment dans les périodes difficiles, de doute.

Evidemment, tout ne se résout pas magiquement par cette réponse : nous venons juste d'atteindre la situation à partir de laquelle nous pouvons enfin démarrer quelque chose de sérieux, vraiment ensemble.