Voici une nouvelle démonstration quasi-mathématique prouvant qu’avec  :

• une équipe motivée organise un événement : merci à toute l’équipe, et croyez-moi pour l’avoir constaté, ils se sont pliés en quatre pour nous
• un ensemble d’orateurs, de facilitateurs, et de coachs de qualité relèvent le challenge : merci pour votre générosité
• des participants de tous niveaux s’investissent : merci pour la richesse des échanges qui ont eu lieu
• et les moyens de le faire : merci aux sponsors

on abouti à une nouvelle édition parfaitement réussie d’un événement régionalement majeure autour de l’Agilité. Comme Bastien GALLAY (@bastien_gallay) nous l’introduit en pré-ouverture, cette édition se déroule sur 2 jours, avec une seconde journée destinée d’une part à des passionnés, d’autre part à des participants (éventuellement tout aussi passionnés) qui n’auraient pas pu se libérer un jour travaillé. Là, en le plaçant un samedi férié en pleines vacances scolaires, ils auraient eu beaucoup de mal à faire mieux !

Cette année, c’est Gojko ADZIC (@gojkoadzic/http://gojko.net) qui c’est frotté avec brio à cet exercice. Exercice qui a fait l’objet d’un « enregistrement graphique » en live par Romain COUTURIER (@romaincouturier). Pour ce qui est de l’enregistrement vidéo, il y a eu une retransmission en directe. J’espère pouvoir mettre à jour ce post assez vite avec un lien.

Nous profitons donc d’une réflexion poussée sur la flexibilité et ses enjeux pour des sociétés qui sont demandeuses et pourtant tellement frileuse.

Voici quelques points retenus :

• Les sociétés recherchent la compétitivité mais les responsables recherche à avoir des listes de tâches/actions/chantiers finies dès le début.
• Le temps moyen entre la validation business et la livraison est en moyenne 1,5 ans.
• Un scope flexible est dangereux si vous n’avez pas de vision d’ensemble
• « Allez chercher du feedback et apprenez de vos échecs » (Tim Hartford)
• Une roadmap devrait être comme un GPS :

Capable de s’adapter en cas de changement de direction Capable de nous avertir rapidement en cas de sortie d’itinéraire et capable de nous réorienter dessus Capable d’estimer rapidement l’impact d’une sortie d’itinéraire (il est parfois moins coûteux de faire un petit demi-tour)

• Il faut savoir planifier le fait d’apprendre (assimilé à la variation)
• De bonnes user stories devraient être des OPTIONS pour expérimenter des changements de comportement SANS faire MOURIR l’entreprise
• Une user story doit proposer un objectif mesurable
• Il vaut mieux réagir rapidement à un imprévu que de tenter de planifier l’imprévisible
• Le premier PO (Product Owner) selon lui était le roi de Suède. En 1626, il commanda des navires rapides pour étendre son royaume à l’ensemble de l’Europe. Pour autant, il changeait régulièrement de consignes durant le chantier entre « ils doivent être plus rapides » et « ils doivent avoir plus de canons ». Ce chantier aurait pu ressembler à un succès puisque ces navires lui ont été livrés dans les coûts et délais attendus. Pour autant, ces changements effectués sans vision simple, partagée et globale de l’objectif ont aboutis à leur naufrage en 1628 suite au déséquilibre dû au poids des trop nombreux canons.
• De grandes choses arrivent lorsque les gens savent POURQUOI ils réalisent une tâche ou un travail et qu’ils ont un feedback rapide sur ce travail.

Il nous a même offert une édition numérique du dernier ouvrage qu’il ait coécrit avec David Evans : Fifty Quick Ideas to Improve your User Stories. Merci Gojko.

Alexis MONVILLE (@alexismonville) nous livre un retour sur la gestion d’une équipe un peu particulière : L’équipe de développement d’openstack (http://www.openstack.org/). Près de 1500 développeurs au cœur d’une communauté de plus de 4500 individus, le tout réparti à travers le monde.

Comment synchroniser autant de personnes ? Principalement par le rythme. En ce qui les concerne, il s’agit d’un rythme retenu d’une release tous les 6 mois. Le contenu n’est pas figé, la date oui. Ces 6 mois sont découpés ainsi :

1. un Design Summit (j’y reviens vite)
2. quelques milestones
3. une (ou quelques) release candidate
4. une release

et on recommence !

Comment aligner autant de personnes ? En agilité, on colocalise les individus. Ici, ce n’est pas facile. Plusieurs fuseaux horaires, plusieurs langues, plusieurs cultures, un territoire … étendu. Pour autant, ce n’est pas impossible. Il s’agit donc de ce qui est réalisé lors du Design Summit. Nous sommes bien en train de relever qu’ils ont mis les moyens de leurs ambitions. Tous les 6 mois, 4500 participants se retrouvent en un même lieu pour définir le contenu de la prochaine release.

Voici les 2 axes principaux que j’ai retenu. En fait, Alexis s’est aussi attardé sur la modularité, la gestion des branches (d’ailleurs, la gestion d’une branche unique de production est assez intéressante – à l’opposé de ce que je pratique pour le moment), la cooptation par consensus mou, l’enregistrement de tous les échanges pour gérer la prise e connaissance asynchrone de l’ensemble des intéressés, etc. Pour autant, je n’ai pas dit que j’étais impartial, et il ne s’agit ici que de mon point de vue. Les aspects rythme et socialisation/alignement sont ceux qui m’ont le plus impressionné.

J’ai tenté d’assister à la présentation d’Antoine VERNOIS (@avernois). Le manque de place ma invité à me réorienter sur une autre option. La prochaine fois, il faudra que je sois plus véloce.

Quoi qu’il en soit, ma réorientation fût bien inspirée.

En sortant de mon échec à assister à la présentation d’Antoine, j’ai eu le plaisir de constater que le calendrier des coachs n’était pas plein.

J’ai déjà écrit tout le bien que je pense de la coaching clinique dont j’ai découvert le principe au ScrumDay 2014. Dès que le planning a été affiché, j’ai donc réservé une place pour 14h00.

Comme je m’en suis vu offert l’opportunité, j’ai immédiatement saisie l’occasion de profiter d’un second passages à la coaching clinique (un premier en fait en plus de celui planifié à 14h00). Évidemment, je ne dévoilerai ici ni les sujets, ni leur traitement. Je me contenterais de reprendre le principe que Fabrice AIMETTI (@fabriceaimetti) orchestre de main de maître :

Il s’agit donc d’un ensemble de coachs qui se mettent à disposition gratuitement pour échanger et orienter vis-à-vis d’un sujet précis en 15 minutes. Il suffit de s’inscrire en donnant un prénom, un sujet, et une heure souhaitée.

Pour avoir échangé sur le sujet avec un certain nombre de participants, il apparaît que certains n’ont juste pas « osé » s’inscrire. Si je n’ai qu’une suggestion à faire, c’est « profitez-en si l’occasion se représente »

Croyez-moi, il est impressionnant de voir combien c’est enrichissant.

Sans en dévoiler plus, je me contente de remercier Olivier PATOU (opatou) et Cécile AURET (CecileAuret) pour tout ce que nous avons partagé.

Bruno HICKEL nous livre un retour d’expérience sur la reconception d’une application recentrée sur la concertation des experts du métier (des utilisateurs finaux chez les clients). Un travail qui a abouti à une simplification des écrans pour les rendre intuitifs.

Le leitmotiv de cette refonte : la simplicité des écrans doit les rendre évident à utiliser.Finalement, est-ce vraiment sous cet angle que nous appréhendons nos évolutions ? Merci Bruno, cela raisonne encore dans ma tête.

Mathilde LEMEE (@MathildeLemee) nous livre quelques clefs pour appréhender la notion de tests exploratoires.

J’en retiens quelques éléments (de façon partiale évidement) :

• les tests exploratoires marchent très bien avec des débutants qui n’ont pas encore le prisme à travers laquelle nous utilisons une application que nous connaissons.
• les personnes expérimentées seront en quête d’éléments basée sur leur expérience.
• ces tests doivent être cadrés pour les borner dans le temps.

Explore (target)with (resources)to dicover (info)

• un test trop spécifique se doit d’être automatisé
• identifier les zones pour lesquelles le développeur ne sait pas comment l’application va réagir.
• jeu du cauchemars : demander à l’équipe d’imaginer qu’au matin, son produit fait la une des journaux. (J’aime beaucoup l’idée)
• 1 test qui passe au vert n’est pas suffisant pour une mise en production (explorer les montées en charge, etc).

Isabel MONVILLE (@isabelmonville) et Fadhila BRAHIMI (@FBrahimi) nous offrent une keynote de clôture de haute volée.

Je suis conscient que ce que je rapporte des divers conférences est une trahison quant à la richesse des contenus que je ne restitue pas (et je m’en excuse), mais je pense que cette prestation en est le plus bel exemple. Je vais donc me limiter aux notions qui sont à ma portée :

• nous avons tous un cadre de référence
• ce cadre est constitué de notre culture, nos croyances, notre éducation, etc
• chacun de ces éléments sont l’objet de filtres que nous appliquons à notre perception des choses
• chaque filtre peut être à l’origine de tension lorsqu’il ne s’accorde pas (voire même qu’il s’oppose) à ceux d’un interlocuteur
• il n’existe pas de bonne façon d’aborder ces tensionsPour autant, Isabel et Fadhila nous propose une « méthode » dite « ESIE » :

Ecoute activeÉcouter sans interrompre, observer l’autre en accueillant ce que va dire l’autre SortirAdopter de nouvelles façons de penser.Développer l’art de l’hypothèse (si vous n’avez pas 3 ou 5 hypothèses, vous êtes dans l’immobilisme) InterrogerPrendre une position META : s’extraire de la situation (à froid), prendre du recul, s’interroger soi-même sur ses propres valeurs bafouée (ou celle de l’autre). Oser poser des questions. ExprimerExprimer un ressenti (utilisation du JE) : J’ai l’impression que …Ramener à ce que l’on perçoit nous-même.

• voici une petite vidéo illustrant une différence de cadre : https://www.youtube.com/watch?v=AfiINIrFMRM

• et une petite illustration invitant respecter le cadre de « l’autre » :

Ajoutons là dessus une mise en scène illustrant la différence de cadres de référence entre 2 amies de longue date exerçant la même profession (Isabel et Fadhila sont toutes deux coach) mais à l’aide de référentiels différents (l’Analyse Transactionnelle pour Isabel, et la Systémique pour Fadhila), nous avons eu le droit à une keynote aussi riche qu’agréable.

C’est une tradition, l’Agile Tour se termine généralement dans un pub bordelais. Cette année n’y a pas dérogé.

Voici donc le moment le plus informel de la conférence, dont la richesse des échanges est inestimable. J’ai pris beaucoup de plaisir à échanger avec de nombreux participants, et ce casse-croûte partagé avec Irène DOAN (@idetido) et Christophe THIBAUT (@ToF_) fût une conférence à part entière.

Bref, les enseignements de cette journée ont fini pour moi à une heure bien tardive.

Christophe THIBAUT (@ToF_) nous fait partager 25 ans d’expérience dans le développement logiciel.

Il nous interpelle très vite sur une question : Dans quelle autre industrie peut-on livrer quelque chose qui n’a pas été revue par au moins une autre personne ? Relisez cette phrase et réfléchissez bien. Prenez le temps d’être honnête (vous êtes seul), et pouvez-vous garantir que tout ce que vous avez poussé en production ait été revu par un pair ? Dit comme ça, je dois admettre que j’aurais beaucoup de mal avec l’idée que les ingénieurs et techniciens qui ont élaborés et construit ma voiture n’aient jamais montrés leur travail à qui que ce soit (disons par excès de confiance en eux, ou parce qu’ils estimaient ne pas avoir à en prendre le temps). C’est bien là l’une des grandes incohérences de notre métier. La revue n’est que trop rare.

Il refait évidemment mouche lorsqu’il nous rapporte des remarques du type : « Je n’ai pas testé parce que j’avais sous-estimé la complexité ». Si vous n’avez pas le poil qui hérisse, c’est que vous êtes totalement inconscient. Si vous n’y avez jamais été confronté, c’est que vous ne bossez pas depuis bien longtemps (voire pas encore).

Il nous offre aussi une petite recette simple pour planter un projet :

1. assumer des estimations non-réalistes
2. prendre des raccourcis sur la qualité
3. alerter qu’une fois qu’il est trop tard

INRATABLE !

Il embraye ensuite sur quelques « cercles vicieux ». Celui de la pression est mon préféré. En gros, en général, la baisse de qualité des résultats implique une hausse de la pression portée sur l’équipe. Cette hausse va amener à réduire le temps investi sur la qualité (???), donc va limiter l’application de pratiques qui avaient pour vocation d’augmenter la qualité des résultats (???). Bref : que du rationnel évidemment !

Celui sur les corrections en urgence au dépend de l’amélioration de la qualité a aussi fait écho à du vécu.

Quelques conseils pour sortir de ces cercles :

1. inverser la courbe de la rache
2. maintenez la maintenabilitéune dévelopeur qui dit « faut tout casser », c’est que le problème fait parti de la solution
3. créez un flot continu de petites victoires
4. créer un environnement permettant d’apprendre en équipe
5. observer vos pratiques sur le terrain
6. les briques de base

A retenir : Les projets grandioses ne sont qu’un enchaînement de tâches laborieuses (dans lesquelles il faut trouver du fun)

Pour mettre en place les pratiques de base :

• Test (unitaire .. ou pas) de développeurs
• le TDD (Test Driven Development) : Métaphore du vélo : à vélo, on va plus vite qu’à pied. Le tout, c’est d’apprendre à en faire.Les développeur du projet Appolo faisaient déjà du TDD (mais pas sous ce nom)
• Revue de codeEviter les bugs avant qu’ils n’apparaissentPermettre aux nouveaux d’apprendre sans avoir à poser la questionAvoir un standardApprendre à se parler du code
• Pair programmingEn 2 semaines de binômage, toute l’équipe connait tout le code du projet.
• Clean feedbackSéparer ce que j’observer, comment je l’interprète, puis ce que cela j’en ressentEx : « On constate que cela fait 3 fois que tu change les priorités, on pense que c’est préjudiciable, qu’est-ce que tu en penses ? »

Côté chiffres : Mettre en place une « culture de la qualité » prend 3 à 5 ans

Enfin, je finis par une citation de Christophe qui me plait beaucoup : « Il n’y a rien de plus gratifiant qu’une équipe qui reprend la main sur son code legacy à coup de tests. »

Romain COUTURIER (@romaincouturier) nous a invité à … prendre les feutres. En ce qui me concerne, j’avais prévu d’assister à cet atelier dans le but de comprendre à qui s’adressait les sketchs. Mais je suis arrivé dans l’atelier motivé par Romain à travers le pitch « Tu sauras dessiner en 1 minute ». Osé n’est-ce pas ?

Et bien force est de constater que j’ai pu suivre l’exercice. C’est remarquable. Evidemment, je suis aussi sorti de l’atelier avec mes éléments de réponse. Les sketchs s’adressent donc uniquement aux personnes présentes lors de son établissement. Ils servent alors :

• d’alignement entre les participantsL’illustration représente une reformulation des idées évoquées, permettant de lever d’éventuels quiproquos
• de support de mémoire collectiveMême les éléments apparemment insignifiants du sketch servent de supports mémoriels

Pour ce qui est de l’atelier, il est articulé autour d’une facilitation graphique live menée par Romain au fil du débriefing de notre premier exercice. Autant dire qu’en sortant de l’atelier, nous ne sommes pas en mesure d’en faire autant. Mais pour ceux qui peuvent en avoir l’occasion, il assure une formation de 2 j sur Bordeaux début décembre (http://ayeba.fr/formation-facilitation-graphique/).

Puisque Evernote (pourtant mon outil préféré) ma joué un sale tour (2 en fait sur le WE … ça commence à faire beaucoup), je reprends ma note tronquée. Evidemment, je n’ai plus en tête mon premier jet .

Je me suis déjà étendu lors de mon retour sur le ScrumDay 2014 sur le bien que je pense du format « Open Space ». Cette édition menée avec talent par Alexis MONVILLE (@alexismonville) n’échappe pas à ce sentiment. Une richesse d’offre n’égalant que la richesse des échanges qu’elle génère. Et je ne vous parle même pas de l’énergie qu’il en ressort. L’Open Space est un phénomène !

Suite à une conversation de déjeuner avec Charlotte (@chalou33), j’ai été amené à proposer un sujet sur … les rétrospectives (original de ma part !). Plus précisément, « Divers formats de rétrospectives ». Une réflexion collective autour des risques de certaines pratiques, et ayant fait émergé quelques idées d’autres pratiques très intéressantes. Je les garde sous le coude pour de futures expérimentations.

Pour la seconde session, je me suis orienté vers une session traitant de la remotivation d’une équipe déjà agile. Un ensemble d’échanges des plus intéressant avec une leçon en bon et due forme d’Isabel (@isabelmonville) sur les 6 modes de structuration du temps tirés de l’analyse transactionnelle. J’ai adoré. Je vous les livre tels quels (avec uniquement mes propres repères mémoriels). Si vous voulez en savoir plus … cherchez un peu . Il y a donc 6 modes parmi lesquels nous passons tous chaque jour :

1. Le rituel (politesses de socialisation)
2. Le passe-temps (échanges sans engagements)
3. L’activité (activité collective)
4. Le retrait (besoin d’isolation)
5. Les jeux psychologiques (inconscients mais nocifs)
6. L’intimité (partage en 2 personnes proches)

Je vais simplement rebondir sur mon intro : lorsque nous réunissons les bonnes conditions, nous obtenons quelque chose de qualité. Cette édition ne fait pas exception. Je renouvelle mes remerciements et même si me lever un samedi matin a représenté un réel effort pour moi, j’estime avoir pleinement rentabilisé mon effort.