Le ballet et l'agilité

J'ai regardé un peu par hasard ce matin en déjeunant un documentaire sur l'expérience d'un groupe de jeunes Berlinois pour monter un spectacle de danse sur le Sacre du printemps de Stravinski accompagnés par le philharmonique de Berlin. Le documentaire couvre tout le projet, des répétitions et jusqu'à la représentation, et montre toutes les difficultés qu'il rencontre.

En particulier, il y a au bout d'un moment un fossé qui se creuse entre 5 ou 6 des élèves qui se débrouillent bien et le reste des élèves qui freinent la progression. La danse est une activité difficile. C'est fatiguant et parfois douloureux. C'est ennuyeux quand il faut recommencer des dizaines de fois le même enchaînement jusqu'à ce que tout le groupe le mémorise et le réalise en rythme avec la musique et en coordination avec les autres dans ses déplacements. Et au delà de ça, c'est un art. Il faut que les danseurs expriment l'argument du ballet. Et le thème du Sacre du printemps n'est pas facile. C'est un rituel pour le retour du printemps qui se termine par le sacrifice d'un élu pour que le printemps revienne. Donc des sentiments probablement assez perturbants.

En première approche le problème semble être imputable à ceux qui sont à la traîne. Ils ont leurs raisons : ils n'aiment pas la musique classique, ils n'ont aucune idée de ce que signifie faire des efforts, ils se contentent de faire le job parce qu'ils estiment que c'est suffisant. Certains sans forcément le reconnaître ont peur d'échouer et préfèrent échouer parce qu'ils n'ont pas fait ce qu'il faut qu'en ayant fait le maximum.

Le chorégraphe britannique Royston Maldoom dans son approche pédagogique se montre très exigeant. Il leur explique qu'il pense qu'ils peuvent faire mieux (alors que l'encadrement local pense qu'ils sont à leur maximum). Il exprime aussi la frustration que ressentent ceux qui ont déjà compris à devoir refaire encore à cause de ceux qui ne sont pas concentrés. Je ne suis pas sûre que cela ait eu beaucoup d'effet puisqu'ils envisagent quelques temps plus tard de déplacer les meilleurs dans un autre groupe pour qu'ils puissent avancer à leur rythme. Mais il fallait qu'il le fasse pour être cohérent avec lui même.

Ce qui est assez amusant, c'est que lorsqu'ils sont interrogés individuellement, Royston Maldoom le chorégraphe et Simon Rattle le chef d'orchestre reconnaissent que ce sont eux qui sont différents. Qu'ils ont une exigence d'aller toujours plus haut et de ne pas se contenter d'atteindre l'objectif qu'ils ne peuvent partager qu'avec très peu de gens. C'est un discours de passionné plus que d'artiste d'ailleurs. Les élèves qui sortent du lot énoncent aussi cette différence d'une manière moins rationalisée. Ils ont rencontré une personnalité, une activité, une perspective qui leur a donné la motivation de se dépasser.

Finalement le spectacle a lieu. Probablement pas aussi parfait que ce qu'il aurait pu être, mais le but de l'expérience était plus je pense de faire vivre quelque chose à ceux qui ont su en profiter. Certains de ceux qui n'aiment pas la musique classique ont trouvé que certains passages du Sacre du printemps étaient intéressants à sampler. D'autres ont pris confiance en leur capacité à réussir quelque chose.

Alors pourquoi ce grand détour par la danse, alors qu'en gros je parle plutôt d'informatique ?

Parce qu'il y a une similitude avec ce qui se passe dans les projets informatiques, surtout lorsque l'on aborde de nouvelles technologies. On ne se rend pas toujours compte que les techniques que nous maîtrisons ne sont pas forcément maîtrisées par les gens avec qui nous travaillons et que cela a un coût pour eux de les acquérir, voire parfois de reconnaître qu'ils ne les maîtrisent pas. Cela entraîne souvent une certaine frustration chez nous parce qu'on voudrait que ça aille plus vite, qu'ils adoptent ce qu'on leur présente comme la meilleure solution. Pire encore que leur manque de maîtrise, ça ne les passionne pas plus que ça.

Ce documentaire m'a amenée à repenser à des discutions que nous avons eu cette semaine, en particulier avec Eric Le Merdy et Etienne Charignon à propos d'une question posée initialement par Eric sur les stratégies que l'on peut adopter pour amener les gens aux pratiques Agile : est il indispensable de commencer en respectant strictement tous les préceptes ou peut on amener les gens à l'Agile plus souplement par l'exemple ?

Comme le fait remarque Etienne, la première démarche relève encore souvent du projet pilote. On plonge le client en immersion dans un projet géré 100% SCRUM et on leur dit qu'on sait qu'ils peuvent le faire. Cela s'apparente à l'expérience de réalisation d'un spectacle avec des professionnels. L'avantage de ce processus est de permettre une évaluation rationnelle et scientifique d'un ROI. Encore faut-il que les gens suivent. Comme dans l'expérience de ballet plus haut il est probable que certains adhèreront sans réserve et d'autres pas. Je doute que l'on puisse maintenir des pratiques Agiles sur la seule base d'un ROI. L'implication demandée est trop forte pour que le processus fonctionne de manière imposée. C'est probablement pour cela qu'Etienne constate des retours-arrière vers des projets "pâte à modeler". Tout le monde n'a pas vu la lumière mais certaines pratiques ont plu.

D'un autre côté, la méthode souple revient à introduire par l'exemple certaines de bonnes pratiques comme faire des tests unitaires, ou du TDD. Mais est que ça revient à avoir un mode de pensée Agile ? Probablement pas. C'est un peu comme aller en cours de danse 1h par semaine. On fait quelques assouplissements et on se sent plus en forme, allez, on mange bio comme la prof de danse parce que ça à l'air de lui réussir. Mais je doute que l'on comprenne de cette manière ce que représente la préparation d'un spectacle de danse et l'accomplissement de le délivrer en public. C'est face à la difficulté que l'on comprend vraiment les enjeux d'une pratique.

ça n'est pas inutile pour autant. D'abord, faire un peu de sport ça n'est pas si mal. Ensuite, je crois que les technologies se diffusent beaucoup de manière virale. J'ai vu émerger Java, le Web, UML, XML, J2EE. Aucune de ces technologie n'a été adoptée facilement au départ parce qu'elles étaient rationnellement meilleures comme on peut le penser maintenant. Elles ont été portées par des gens passionnés, qui y ont compris les avantages, on expliqué encore et encore, on fait découvrir ces technologies alors qu'ils étaient venus pour tout autre chose. La passion des gens est communicative même si on ne partage pas toujours tous les arguments présentés. Au bout d'un moment, la nouveauté fait partie du paysage, elle ne fait plus peur et on peut poser le problème du choix plus rationnellement.

Je ne vois pas d'opposition entre les deux stratégies. C'est plus une question de timing. La méthode souple amènera certains au grand saut dans un pilote, et voire plus si affinité. Dans le pire des cas, elle facilitera les choses pour plus tard en ayant appris certaines pratiques nécessaires dans un projet Agile ce qui facilitera les pilotes. Il faut juste être conscient que le saupoudrage de pratiques Agile n'est pas un projet Agile, c'est seulement une distribution d'échantillons. C'est peut être difficile à faire comprendre aux gens avec qui on travaille et qui sont tentés par la mode Agile.

Etienne pense que pour la stratégie en douceur, il faudra de la persévérance et de la pugnacité. A mon avis, il en faudra pour les deux stratégies de toute manière. Et peut être encore plus pour transformer les projets "pâte à modeler" en projets vraiment Agile. Ce qui compte c'est de rester passionnés et à l'écoute.

J'avais prévu au départ quelque chose plus lié à la musique suite à d'autres discussions. ça sera pour une autre fois.

La photo Modern Dance est de Kevin Eddy