Une journée à Agile Tour Nantes

Jeudi 27 novembre avait lieu l’Agile Tour à Nantes, une journée de découvertes, ateliers et conférences autour de l’agilité. Articulé en trois temps, le Why, le How et le What, le format de cette année permettait de combiner les conférences et ateliers traditionnels à des sessions de World Café, un temps d’échanges entre participants, permettant à tout un chacun de ne pas rester simple spectateur, mais de devenir acteur de la journée. Voici mon compte-rendu de cette journée intense.

Séance de facilitation graphique

“Facilitation graphique”, “scribing”, le sujet n’est pas de savoir bien dessiner mais d’oser prendre le feutre pour donner à voir. Les bénéfices : des réunions qui avancent, des participants qui prennent des photos, la disparition des compte-rendus fastidieux. Et aussi un nouveau plaisir au travail.

Cette session proposée par Pierrick Thibault et Romain Couturier a accueilli bien plus de monde que prévu, il a fallu la faire dans le hall plutôt que dans la salle prévue initialement. Cet atelier était également un piège : les participants y gagnaient un badge “scribe” et la responsabilité de la facilitation graphique sur les séances de World café…

Nous avons appris quelques astuces pour devenir capables de scribouiller un compte-rendu visuel pendant une réunion, et ce même si on a deux mains gauches et aucun talent artistique (un peu comme moi en fait). Les voici :

• dessiner les personnages : il suffit de faire une patate, avec des yeux et une bouche. On met ensuite les bras (au niveau du cou et pas au milieu du corps) et les jambes, la position permet ensuite d’exprimer beaucoup de choses ;
• faire des cadres : ils mettent le texte en valeur. Il est intéressant de varier les types de cadres, et nous avons appris à dessiner une bannière ;
• dessiner des flèches : elles introduisent un mouvement, relient les éléments ;
• faire des textes et des bulles : il faut écrire en majuscules d’imprimerie serrées. Pour avoir une écriture régulière, il n’y a pas de secret, il faut s’entrainer ;
• les canevas : l’organisation du dessin sur la feuille permet de montrer une ligne de temps, une idée centrale, un enchaînement… Il faut séparer les zones pour occuper l’espace d’une manière pertinente.

Pour démontrer l’intérêt de la facilitation graphique, voici l’atelier résumé en une image.

Vous pouvez également lire le compte-rendu de Pierrick Thibault.

« Sois autonome ! », histoire de paradoxe et de jeux psychologiques

Qu’est-ce qui se joue lorsqu’un manager veut donner plus d’autonomie à son équipe ?
Nous allons le découvrir dans cette session originale en trois temps sur l’autonomie et les jeux psychologiques.

Cette conférence proposée par Christophe Morin et Pierre Leray a débuté par un spectacle de théâtre, leur passion commune, mettant en scène les interactions pouvant se nouer dans la vie quotidienne, cette introduction portant sur des relations de voisinage – mais faisant écho à des situations vécues au travail.

Nous avons ensuite eu une partie plus théorique nous présentant l’analyse transactionnelle et le cycle de l’autonomie. L’analyse transactionnelle est une pratique inventée par le psychiatre Eric Berne au cours des années 50. Il s’agit d’un cadre théorique de lecture de nos comportements, qui ne correspond pas à une réalité neurologique, mais donne une lecture pratique des relations psychologiques. Pour simplifier (le support de la présentation donne beaucoup de détails et d’exemples), nous avons 3 états du moi :

• le parent : issu de notre éducation, c’est la partie de nous qui fixe les règles (normatif) et qui donne des solutions (nourricier) ;
• l’adulte : la partie de nous qui traite l’information, qui raisonne factuellement ;
• l’enfant : la part de nous qui est plus basée sur le ressenti, l’instinct. Il se divise entre l’enfant libre (créatif mais égoïste) et l’enfant adapté. Notre enfant adapté pouvant être lui-même soumis (facile à s’adapter mais victime désignée) ou rebelle (il ose dire non, mais parfois juste par principe).

Aucun de ces états n’est bon ou mauvais par lui-même, ils ont tous des aspects positifs et négatifs, ce qui est important c’est de rester équilibré entre tous ces états.

Ces états peuvent être rapprochés du triangle dramatique, le parent normatif étant dans le rôle du persécuteur, le parent nourricier dans celui du sauveur, et l’enfant adapté dans celui de la victime. On peut le transformer en triangle pédagogique en utilisant nos états du moi dans leur aspect positif : le parent normatif assure la protection, le parent nourricier donne des permissions, ce qui permet de cadrer la puissance de l’enfant libre.

L’analyse transactionnelle consiste à identifier qui parle à qui, et à éventuellement corriger le tir en sortant du rôle imposé par l’autre. Un exemple concret : je demande à un collègue de l’aide pour un problème de configuration. Si au lieu de m’expliquer comment faire, il me dit : « Laisse, je vais le faire. », il s’inscrit dans le rôle du sauveur (et moi dans celui de victime), ce qui instaure un triangle dramatique. Si je manque de confiance en moi, je vais lui répondre en acceptant, et donc en endossant ce rôle de victime. Le triangle est installé – car l’une des leçons de la séance de théâtre est que le triangle dramatique peut s’installer avec deux personnes (le sauveur devient persécuteur, puis la victime se rebelle et les rôles s’inversent). Mais je peux également m’affirmer, et au lieu de laisser l’enfant soumis répondre, donner la parole à l’adulte, qui affirmera sa volonté d’apprendre au lieu que l’on fasse à sa place. C’est un exemple concret de la responsabilité partagée dans le triangle dramatique. Attention, il ne faut pas croire que la réponse adulte est à privilégier systématiquement. En effet, une demande émotionnelle va plutôt demander une réponse émotionnelle (de compréhension et d’empathie) en premier lieu.

Nous avons retrouvé quelques principes de la Communication Non Violente : une fois que l’on a identifié qui parle en soi et chez l’autre, entre l’enfant (émotionnel), le parent (modèle) ou l’adulte (raisonnement), on doit retrouver quel est le besoin exprimé. C’est en parlant de lui que l’on pourra activer son état adulte. Une notion supplémentaire abordée a été la tolérance, non seulement vis-à-vis des réactions de l’autre, mais aussi de nos propres réactions.

Nous avons vu ensuite le cycle de l’autonomie, qui se découpe en quatre passages :

1. la dépendance : l’individu ne peut rien faire sans les autres, par exemple quand on arrive sur un projet ;
2. la contre-dépendance : l’individu se rebelle et remet systématiquement en cause les choix de ceux dont il dépend. C’est un passage indispensable vers l’inter-dépendance, il est donc préférable de ne pas aller contre quand on est manager ;
3. l’indépendance : l’individu fait tout dans son coin sans en référer à personne, il devient responsable de ses erreurs ;
4. l’inter-dépendance, ou autonomie, dans laquelle chaque membre de l’équipe travaille en partenariat avec les autres.

Il s’agit d’un cycle, il est donc possible de passer de l’interdépendance à la dépendance, par exemple en changeant de projet. Le mode de management va suivre ce cycle et se montrer successivement directif, explicatif, participatif et délégatif. Si le cycle de l’autonomie vous intéresse, surveillez le blog Ippon, un article sur le sujet est en cours de préparation, par Alban Dericbourg.

La session s’est terminé par une nouvelle séance de théâtre, dans laquelle le public votait pour la réaction qu’il désirait de la part de l’un des protagonistes, cette fois dans une situation de rapport professionnel.

J’ai beaucoup apprécié le côté dynamique de la session, très plaisant après le déjeuner, même si je n’ai pas beaucoup adhéré à l’analyse transactionnelle, peut-être à cause de son caractère irréfutable (dans le sens de Karl Popper).

Faire la conception en équipe sans architecte, non mais allô quoi ?

La conception par l’équipe est considérée comme une pratique agile. Pourtant beaucoup d’entreprises préfèrent que les choix techniques soient décidés uniquement par un architecte.
Découvrez au travers d’un REX les pièges à éviter et des astuces pour que la conception collective soit une réussite.

Ce retour d’expérience posait une question cruciale : l’architecte est-il compatible avec l’auto-organisation d’une équipe ?

Ly-Jia Goldstein nous a relaté son expérience dans ce domaine, dans un projet impliquant 30 développeurs répartis en 3 équipes utilisant la méthode Scrum. L’architecte qu’ils avaient au départ n’avait pas été remplacé, mais ils pensaient pouvoir s’en passer aisément, dans la mesure où ils suivaient toutes les bonnes pratiques : TDD, pair-programming (qui devait suffire pour la communication)… Les problèmes n’ont pas tardé à surgir : des conceptions hétéroclites, ainsi que des pertes de temps liées à l’absence de documentation, ont été mis en valeur lors des rétrospectives.

Ce qu’il y a de bien avec l’agilité, c’est justement sa capacité à changer de direction quand on constate que quelque chose ne marche pas. Au lieu d’embaucher un architecte, les équipes se sont mieux organisées par la mise en place de réunions. Pour chaque story, un “conseil de guerre” décidait de la conception, et le résultat était mis en place graphiquement sur un tableau blanc, disponible pour tous pendant toute la durée de l’itération. Les avantages constatés ont été :

• la diversité des points de vue favorisait l’émergence de solutions innovantes ;
• la vision était partagée par toute l’équipe ;
• les tableaux blancs donnaient une visibilité au client.

En ce qui concerne la documentation, le passage au BDD (Behaviour-Driven Development) a forcé à la discussion en amont entre les développeurs, les utilisateurs et les testeurs. Les traces étaient ensuite visibles sous forme de tests fonctionnels. L’approche de l’ubiquitous language du DDD (Domain-Driven Design), c’est-à-dire l’utilisation du langage de l’utilisateur dans le code, permet à ce dernier de le comprendre directement, sans passer par un développeur.

Cette expérience a apporté beaucoup d’enseignements :

• les individus et les interactions avant les processus et les outils ne signifie pas qu’il ne faut pas du tout de processus ni d’outil ;
• toute l’équipe doit être responsable et doit être capable d’accepter les erreurs pour les corriger ;
• il est nécessaire de partager la connaissance avec les membres de l’équipe non-techniques.

Cette solution peut sembler coûteuse pour l’entreprise : certes elle économise le salaire d’un architecte, mais la programmation en binôme et les réunions prennent du temps aux développeurs. Cependant, il ne faut pas perdre de vue les avantages :

• une protection contre le turn-over : si tout est connu par une seule personne, l’architecte, son départ est très problématique, alors qu’une absence ne l’est pas quand l’information est fortement distribuée ;
• participer à la prise de décision sur l’architecture est bien plus valorisant pour le développeur, c’est un moteur de motivation et d’engagement.

La difficulté à se passer d’architecte tient souvent à l’architecture des systèmes d’information, ces applications étant souvent des “usines à gaz” difficiles à maîtriser. La solution consiste à changer de modèle : délimiter des contextes fonctionnels à la place de couches. Ainsi, chaque équipe de développeur devient autonome sur un périmètre restreint. Le plus gros frein restant le manque de confiance envers les développeurs.

Comme le disait Ly-Jia, en général, les personnes ne changent pas de point de vue sur les architectes suite à sa présentation, mais celle-ci a au moins le mérite de donner un retour d’expérience concret. Voici le support de la présentation (qui ne manque pas d’humour).

Bilan de la journée

Je n’ai pas trouvé les présentations aussi passionnantes que les années précédentes, mais cela est sans doute lié au hasard de mes choix et non à une perte de qualité (peut-être aussi qu’avec les session de World Café, les orateurs manquaient de temps). Les World Café étaient la grande originalité de la journée, puisque nous étions placés au hasard, avec des inconnus, à discuter autour des questions Why, How et What et à échanger nos expériences. Ces rencontres ne manquaient pas d’intérêt, et permettaient de prendre contact avec des personnes de profils très différents, dont beaucoup dans des professions sans lien avec l’informatique. Et comme un dessin vaut mieux qu’un long discours, ci-dessous un résumé en image de deux World Café.

Le Why

Le What