Il est bien loin, le temps où le profil du développeur informatique type était celui d'un introverti absolu, dont l'angle de vision était juste nécessaire pour parcourir la largeur de ses écrans, et son mode de communication privilégié l'e-mail et accessoirement le post-it.
J'ai assisté jeudi soir (13/1/11) à une rencontre consacrée à "La phase exploratoire, élément facilitateur dans la réussite d'un projet Agile" dans le cadre des forums Grafotech de l'association GRANIT.
Je craignais de ne pas comprendre grand chose au milieu de ces experts techniques, mais mon intuition me disait qu'il y avait là des expériences de collaboration intéressantes. Malgré un exposé dans un dialecte de prime abord très étrange, je n'ai pas été déçu. J'ai même vraiment apprécié :
- la façon « agile » de travailler au cœur des projets,
- les types de collaborations informelles qui se développent "dans la cité"
Mais ceci soulève aussi quelques questions sur les possibilités d'inclusion de ceux qui ne seraient pas à 100% dans ces dynamiques relationnelles somme toute exigeantes...
La collaboration dans les projets « Agiles »
Première leçon : Au lieu de foncer tête baissée, que ce soit en ordre dispersé ou bien dans une discipline militaire, dans « ce qu'il y a à faire », en imaginant que quelqu'un a déjà tout compris et spécifié le résultat attendu, nous devons reconnaître que tout nouveau « produit » (ou projet) se construit plus intelligemment et avec un meilleur rapport résultat / coût en organisant un processus d'interaction permanent avec toutes les parties prenantes, sur des phases itératives nombreuses et aux résultats explicites et démontrables. Ce qui implique un processus d'interaction d'autant plus riche au sein même de l'équipe en charge du projet.
Seconde leçon : Cette interaction ne s'improvise pas, et puisqu'elle est fréquente (quotidienne au sein de l'équipe, hebdomadaire avec l'environnement) elle doit être efficace, donc « scénarisée » (revues de sprints, cérémonies,...), outillée (backlogs, charts et scrumboards...), avec une transparence totale vis à vis des « clients » du projet. Ne froncez pas les sourcils, les "gros mots" qui précèdent correspondent dans la réalité à des documents ou supports conçus pour être plus lisibles que certains cahiers des charges.
On entre peut-être dans un monde qui rappelle la culture des jeux de rôle (ce n'est sans doute pas une coïncidence), et justement les rôles, responsabilités et moyens sont explicites, avec une forte dimension de solidarité et d'aventure collective pour aller le plus loin possible, un épisode à la fois.
J'y ai retrouvé l'esprit du codéveloppement professionnel en entendant qu'il s'agissait d'une méthode « non prescriptive, ni directive, et qui demande donc beaucoup de rigueur ».
Troisième leçon, cœur de l'exposé du jour : Pour gagner du temps, et aboutir à un résultat plus satisfaisant, il est indispensable de prendre le temps de préparer tous les « rouages » du dispositif. Là encore avec une grande rigueur pour permettre cette fameuse « agilité » ensuite. Définir comment on va travailler, les rôles, le vocabulaire, la façon de valider les étapes successives... et surtout les interactions multiples et fortement « ciblées » (fréquence, forme, contenu, résultats).
C'est d'autant plus indispensable que l'équipe de développement est en interaction fréquente avec le système client, et que toutes les modalités de communication sont mobilisées : la parole (centrale), les tableaux de bord (coconstruits pour avoir du sens pour tous), la démonstration même des résultats de chaque étape, testés et validés. Cette phase préparatoire construit l'intercompréhension qui rend les échanges futurs constructifs et efficaces. Dans l'équipe et avec l'environnement.
Ce blog n'est pas le lieu où reprendre le descriptif de cette phase préparatoire, exposée en détail lors de la rencontre GRANIT. Je renvoie le lecteur aux sources plus qualifiées (voir en fin de billet)
Si je me suis senti autant « chez moi » en entendant cet exposé, même sans compétence sur les technologies du développement informatique, c'est sans doute parce que les méthodes agiles, et SCRUM en particulier, revendiquent un héritage des travaux de Nonaka et Takeuchi, spécialistes et promoteurs des "entreprises et équipes apprenantes".
La collaboration entre développeurs dans la cité
L'ouverture d'esprit et le goût d'échanger de ces professionnels (assez jeunes pour la plupart) se retrouve aussi dans leurs pratiques sociales : si les sociologues ont déjà remarqué que les frontières entre vie professionnelle et personnelle étaient peu marquées dans la « génération Y », leur implication dans de nombreuses réunions informelles et ouvertes d'échanges de pratiques témoigne de leur conviction que le progrès est plus rapide s'il est collectif.
J'en veux pour preuve le programme de La Cantine Numérique Rennaise
Ils apprennent ensemble, n'hésitent pas à faire part de leurs difficultés et erreurs, afin de maîtriser plus vite des outils, méthodes qui changent en permanence. On y retrouve l'acceptation du risque de la transparence, probablement plus perçu comme une condition positive de l'apprentissage que comme un risque. Car sur des projets où la cohérence et la cohésion collective sont les conditions de réussite, ils ont déjà compris que le risque réel était plutôt dans le « chacun pour soi », meilleure façon d'être rapidement dépassé, dans tous les sens du terme.
Un « bémol » à mon enthousiasme initial
Cette façon de travailler "agile" est clairement transposable dans d'autres types de projets, en tout ou partie, mais pas dans tous les projets. Les ambitions, les rythmes, les modalités de négociation des objectifs individuels et collectifs font partie de la culture d'une entreprise. Mettre en place même localement des méthodes de travail aussi structurantes dans un contexte préexistant ressemble fortement à une greffe, avec les risques de rejet, d'incompatibilité quasi biologique.
Tout comme il était caricatural de croire tous les informaticiens incapables de communiquer, il serait dangereux d'imaginer que tous les managers et collaborateurs peuvent s'adapter à une méthode qui implique des interactions permanentes, un travail sous le regard continu des autres membres de l'équipe, des représentants des clients, et des modes de reporting en temps réel. Ce « temps réel » est depuis longtemps reconnu comme l'un des facteurs majeurs de stress professionnel.
Pour "remonter" de la production à l'innovation, voire à l'invention (nous y reviendrons dans un autre billet), certaines tâches nécessitent plus de 8 heures de calme, d'essais-erreurs, d'imagination, et ne peuvent être évaluées au jour le jour ; et certaines personnes apportent une meilleure contribution à la valeur ajoutée à moyen terme si on n'essaie pas d'inclure leur activité dans un carcan trop "contrôlant". Par exemple, le client / utilisateur qui copilote le processus agile n'est pas le mieux placé pour proposer des innovations de rupture, si ses soucis à court terme ("le nez sur le guidon") prennent le pas sur la vision à long terme (le regard sur l'horizon).
Je recommanderais donc des essais de tolérance, au sens biologique et systémique, pour éviter les rejets et les déperditions d'énergie. Bref, du dialogue, encore du dialogue, toujours du dialogue, et selon des modalités qui n'imposent pas de normes de comportement. C'est à cette condition que l'on peut identifier précisément quand, pour quoi et pour qui de telles normes deviennent ensuite utiles, acceptables et acceptées. Et que l'on identifie quels contributeurs et projets tenir à l'abri de ces normes qui stériliseraient leur apport spécifique.
Pour en savoir plus
- Le forum Grafotech « Agile »organisateur de cette rencontre.
- Le « manifeste agile », qui montre clairement en une page la cohérence entre l'esprit et la méthode.
- Une explication un peu plus approfondie par un « coach agile », Thierry Cros
- et pour faire écho à mes propres billets sur le coaching, un autre article de Thierry Cros, sur le Coaching humaniste comparé au rôle d'un consultant
- Pour se familiariser sans douleur avec le vocabulaire un peu « spécial » de SCRUM
- Et puis pour devenir encore plus savant, la fiche Wikipedia sur Scrum
Comme d'habitude, vos commentaires sont bienvenus.
Aucun commentaire:
Enregistrer un commentaire