Carnet de route : Agile Tour Bruxelles 2013 (2/2)

Lunch break

En gagnant en taille, l’Agile Tour Bruxelles gagne en standing ! Fini les sandwiches, bienvenue au buffet commerce équitable ! La qualité est au rendez-vous, mais l’attente est un petit peu longue. Difficile de d’être parfait en la matière.

atbru13-06lunch02

De mon côté, je ne tiens pas réellement la forme. On sert aussi du potage en Belgique et je trouve en l’occurrence que c’est une très bonne idée. Surtout quand, comme ici, il est excellent.

atbru13-06lunch04

Bref, l’ambiance est au beau fixe. On est bientôt d’attaque pour la seconde mi-temps !

atbru13-06lunch03

Joanne Ho : Agile methodologies for research

Scrum nous enseigne que l’agilité s’applique bien au domaine des projets complexes, mais n’est pas conçue pour les domaines “chaotiques”. J’ai toujours (à tord ou à raison) classé la recherche dans cette catégorie. Joanne Ho nous donne l’occasion d’en savoir plus sur l’adéquation de l’approche agile pour les chercheurs.

atbru13-07joanne-ho02

L’un des points marquants du fonctionnement des chercheurs est qu’ils ne travaillent pas en équipe ! 

Pourtant la recherche est fondamentalement adaptée au mode itératif : étymologiquement cela ne signifie-t-il pas [Re]cherche ?
Pour Joanne Ho, chercheur environnementale, on peut faire une correspondance entre le travail de chercheur (du moins le sien) et Scrum:

  • Le client : c’est la société (au sens large).
  • Le produit : de nouvelles connaissances
  • La Définition de terminé : la pertinence sociale

Enfin oui, Joanne utilise un backlog. 

Un backlog très mouvant, il faut bien le dire, car :

  • Un item peut ne pas aboutir, nécessiter de nouvelles de nouvelles informations et donc être mis en suspens.
  • Il peut générer d’autres items.
  • Provoquer l’obsolescence d’items déjà présent dans le backlog.

Ce sont des choses qui existent déjà plus ou moins dans le fonctionnement des projets agiles. Sauf qu’il est très difficile d’avoir un plan de bataille fixe pour une itération. Donc la plupart du temps, Joanne dépile simplement l’item le plus prioritaire. Ce ne sont sont donc pas des sprints fixes et l’on est plus proche de XP que de Scrum, n’était-ce la présence du backlog…
Mais si on ne sait pas se fixer précisément d’horizon aux itérations, celles-ci gardent-elles un sens ? La réponse est : oui ! Les itérations aident à faire du bon boulot en gardant le rythme. Sans itération, la masse de travail devant soi devient vite déprimante. Les itérations permettent de se voir avancer, de délivrer de la connaissance grâce auxquelles il sera plus aisé de prendre des décisions en connaissance de cause.
Et les rétrospectives ? Mauvaise nouvelle : les chercheurs sont bien trop occupés pour se livrer à cela !

IMG_0121

Joanne Ho nous donne ensuite en exemple un travail récent sur les biogaz. Comment cela s’est-il organisé ?
Traditionnellement, la structure d’une telle équipe serait :

  • Le travail en silo est le standard.
  • Beaucoup de compétition interne.
  • Peu de transparence. Les revues de pair tournent vite aux critiques, voir aux insultes !
  • Les stakeholders sont des personnes imaginaires.
  • Une reconnaissance basée sur la quantité.

Pour cette étude, il a été constitué une équipe pluridisciplinaire, avec un mode de travail en pair et du test de groupe sur les hypothèses. Le processus était le suivant :

  • D’abord comprendre le problème, définir ce que l’on veut tester. Et donc faire l’expérience du stakeholder en allant sur le terrain.
  • Définir l’objectif, en définissant le critère de succès.
  • Une réflexion en binôme, pour modéliser toutes les facettes du problème. Ce travail doit produire des hypothèses.
  • Les tests unitaires, ce que Joanne appelle le “reality check”.
  • L’intégration continue : la mise en commun des éléments.
  • L’acceptance test : Une solution globale acceptable par le stakeholder.

En conclusion…

  • On peut utiliser l’agilité littéralement partout !
  • L’agilité est surtout une attitude.
  • Sans dialogue, on n’aboutit à rien.
  • Se déplacer pour aller réfléchir à différents endroits, sur le terrain.
  • Mettre toutes ses tâches dans un backlog.
  • Travailler en équipe est une chose nouvelle dans les université. ON n’a pas encore de modèle de fonctionnement pour cela.

En définitive, on fait émerger de meilleures questions, on prends d’avantage de plaisir !
La présentation de Joanne Ho reprends les thèmes développé dans son livre sur Leanpub.

Facile à bien utiliser, difficile à mal utiliser

C’était à mon tour, sur le créneau suivant. Pas de résumé de ma session, il ne faut pas pousser, mais la publication de ma présentation très bientôt, et celle-ci sous forme d’article lorsque je l’aurais complété !

IMG_0234

La mesure de mon temps n’était pas non plus excellente. Je vais jouer le joker “état grippal” sur ce coup. Il faut dire que j’avais quand même prévu 20 exercice pour une heure. J’ai probablement été optimiste…

atbru13-08easy-touse01

Domenico Musto : Event-Driven Architecture in Practice

Domenico est venu nous perler d’EDA. Il commence avec un point sur lequel j’achoppe : l’architecture doit être planifiée ! 

Enfin, surtout pour les gros projets d’après lui, et EDA n’est pas pour les petits projets.
Mais pourquoi EDA ? Parce que l’architecture doit être “business drivent” , suivre la structure des flux d’évènements métier. Au contraire, les architectures SOA favorisent l’intégration point à point, aboutissant à un réseau inextricable quand le nombre de composants augmente.

atbru13-09eda04

Les flux EDA ne sont pas nécessairement des messages d’un MOM, c’est surtout un concept logique qui peut se traduire en :

  • Enregistrements d’une base de données.
  • Fichiers
  • Messages d’un MOM (quand même !)

Le support de ces messages, le canal, transmet différents types d’évènements qui peuvent être :

  • Des évènements
  • Des commandes
  • Des doc-messages ; ce dernier type de message est auto-porteur. C’est un paradigme “push” dans lequel le message comporte tout ce qui est nécessaire au traitement par le composant cible. C’est le modèle vers lequel on souhaite se diriger.

L’architecture EDA implique aussi de nombreux corollaires :

  • Le cas des données de référence : Elles doivent être embarquées en partie dans le doc-message. Cela me rappelle un certain nombre de considérations autour du MDM…
  • La consistance (de l’ordre) des identifiants d’évènements : leur ordre est-il garanti ? S’il ne l’est pas, il peut y avoir nécessité de versionner les entités afin d’en reconsidérer l’historique depuis n’importe quel évènement.
  • L’idempotence, ou la capacité à rejouer un évènement. Cette propriété va de pair avec le versionning.

L’architecture EDA se matérialise par un pattern publish-subscribe asynchrone au niveau de l’architecture. Cela n’est pas sans poser certains challenges en terme de tests. Mais dans cet ordre d’idée, une fois la capacité de test acquise, les composants sont relativement indépendants les uns des autres.
La communication à base d’évènements rend aussi possible le business monitoring (le fameux BAM). Par contre les “évènements avec états” sont un autre niveau de challenge. Il est (en partie) adressé du côté des Web Services avec les corrélations, mais surtout avec les moteurs de workflow type BPEL / BPMN 2.0
Terminons avec les infrastructures techniques. Domenico s’est appuyé sur les “reactive extensions” de Rabbit MQ pour implémenter EDA. De mon côté je pense aussi à Storm que nous mettons en oeuvre actuellement…

Clôture et dernier verre !

Il est l’heure de nous rassembler à nouveau pour conclure ce second Agile Tour Bruxelles.

atbru13-10cloture01

C’est de nouveau Bruno qui nous donne rendez-vous aux prochains évènements Belges : XP Day Benelux (le seul, le vrai…), l’Agile Tour Namur … et bien entendu l’Agile Tour Bruxelles de l’an prochain !

atbru13-10cloture03

Comme l’an dernier aussi, les conférenciers ont droit à un cadeau local. Au menu : bierre, confiserie, chocolat et Schtroumph, entre autres…

Agile Tour Bruxelles 2013 : presenter gift

Pas questions de se barrer comme des voleurs à Bruxelles ! L’an dernier, on avait dégainé la bière locale. Cette année on est visiblement monté en gamme (comme je le disais au début).

atbru13-11dernier-verre02

J’avais prévu mon train de retour suffisamment tard pour discuter un peu. Et nous l’avons fait à propos de l’informatique et de l’éducation, de la représentation trop faible des femmes et des minorités dans notre métier en nous demandant pourquoi et en ne sachant toujours pas vraiment y répondre…

atbru13-11dernier-verre08

Il est temps de s’en retourner. Un grand merci à la très sympathique équipe organisatrice. Et à l’an prochain, si tout va bien…

Carnet de route : Agile Tour Bruxelles 2013 (1/2)

Nous y étions tout juste 70 l’an dernier. Cette année, ce ne sont pas moins de 180 badges qui seront distribués aux participants ! L’Agile Tour Bruxelles a pris une nouvelle dimension pour sa seconde édition.

atbru13-01accueil04

Parti à 6h20 de Paris, on apprécie évidemment d’être bien accueillis. Cela semble se vérifier d’année en année en Belgique.

atbru13-01accueil07

Petit café et discussion habituelle entre frenchies avant le début de la première pleinière. Tiens, on se demande bien pourquoi on va jusqu’en Belgique si c’est pour continuer de discuter entre nous.

Un mot d’introduction

Pas de Keynote en Belgique, et donc du coup plus de sessions “au choix” auxquelles participer. On a quand même le mot d’accueil des organisateurs.

atbru13-02ouverture06

C’est Bruno Sbille qui, comme l’an dernier, est le maître de cérémonie. Un excellent choix qui nous permet de goûter son inénarrable “accent Anglais”. Il le précise d’ailleurs lui-même : “I am speaking English right now” !

atbru13-02ouverture04

Cette introduction présentait deux petites originalité. La première était de nous présenter à nos voisins. Sympathique, quoique j’avais un peu l’impression de me retrouver à l’église à souhaiter la paix du Christ au gars situé à ma droite…
La seconde originalité devient plutôt une tradition de l’Agile Tour Bruxellois : chaque orateur est invité à teaser sa présentation devant l’assemblée entière durant une minute ! Une bonne idée, je trouve, qui était déjà présente l’an dernier.
Il est maintenant temps de se diriger vers notre première session !

My Product is a James Bond Movie, par Pierre Neis

“My name is Neis, Pierre Neis” ! C’est ainsi que Pierre débute sa session. Avec lui, le show est assuré ! L’introduction est toutefois un peu longue. Pierre bosse dans une grande compagnie, qui est globale, qui fait de l’agile et améliore ses techniques, et… Mais Pierre n’est pas satisfait !

atbru13-03Neis02

Il manque quelque chose, des choses !

  • Le “fun”.
  • L’excitation
  • La relation directe au client.

Bref, il manque de quoi faire de bons produits. Et de bons produits ne sont pas des produits standards!
Pour Pierre Neis, les bons produits peuvent s’inspirer de la recette des films de James Bond :

  • De gros succès
  • Une trame facile à comprendre
  • Toujours la même recette, en fait.

Et cette recette Pierre nous la décode ainsi : Boom ! => Yeah ! => Yeah ! => Boom !

  • Le premier “Boom” corresponds à l’avènement de la roadmap.
  • Les “yeah” suivants correspondent aux démos (amazing sessions !)
  • Le dernier “Boom” est la release vers le client.

C’est un peu long pour arriver à l’idée finale, mais celle-ci mérite d’être creusée.

Pause du matin

Parmi les petites originalités de cet Agile Tour figurent les pauses: elles ne font pas moins de 30 minutes. Les organisateurs ont en effet acté que beaucoup d’échanges s’y passent qui font la valeur de l’évènement. Ils ont donc rallongé les pauses !

atbru13-04pause-matin06

Produits bio et développement durable au menu de ces interludes.

atbru13-04pause-matin02

Et aussi, bien sûr, échanges entre participants et orateurs.

atbru13-04pause-matin10

Lean Startup for Developers : you can do it to ! Par Sébastien Arbogast

Je me suis tout bonnement trompé de salle ! Ce n’est pas cette session que j’avais sélectionné dans le programme ! Bien m’en a pris, ce fut ma session préférée.

Sébastien nous évoque sa propre expérience de Startuper. Une expérience qui a fini par s’arrêter d’ailleurs, mais qui ne signifie pas que l’orateur n’ait rien appris de valable à nous partager. Bien au contraire. Son expérience commence lors d’un startup week-end en 2011 auquel il s’était inscrit tardivement et qu’il avait préparé à la va-vite. A sa propre surprise … il a gagné ! Ainsi est né Kodesk, l’idée d’un service de partage de bureaux. Une idée qui n’a jamais pris l’ampleur escomptée car Sébastien avait sous-estimé la crainte fondamentale d’accueillir des étrangers au sein des bureaux d’une compagnie ! Mais de cette expérience a germé une autre idée : Peer Trust.
Mais ceci n’était que l’introduction. L’objet de cette présentation est à venir : Est-il possible de créer une startup pour n’importe qui ? Comment faire en appliquant le “lean startup” ?

atbru13-05leanstartup02

Sébastien veut nous convaincre et nous rassurer : NOUS pouvons le faire !

  • On a les compétences : pas besoin d’avoir un MBA !
  • Nous avons les opportunités : il suffit de regarder autour de nous.
  • Nous pouvons avoir les moyens : il existe de nombreuses initiatives destinées à aider.
  • Trop vieux ! Mais non, on n’est jamais trop vieux.
  • Mon idée n’est pas assez bonne. En fait le concept de “l’idée originale” est plutôt surévaluée. Allons même plus loin : l’idée n’a pas de valeur intrinsèque, tout est dans l’exécution.

L’une des choses qui nous effraie le plus est de perdre notre boulot … pour obtenir quoi ? En fait, il n’est pas utile de quitter son travail, en tout cas pas tout de suite. Sébastien nous conseille même d’attendre le plus possible, chose que lui-même n’a pas faite.

Votre produit n’est pas votre produit ! Votre produit est un business model. Et qui dit “business model” dit “business plan”, n’est-pas ? Erreur !

atbru13-05leanstartup05

Mais l’entrepreunariat n’est pas une loterie. En vérité, on commence en ne sachant rien sur nos clients potentiels et il faut avoir le courage de l’admettre. Et d’en admettre aussi le corollaire : on ne fera pas bon du premier coup. C’est un peu comme si on allait rater sa démo Scrum.

C’est tout l’objet du cycle Lean Startup : construire quelque chose pour le valider par le biais d’une mesure. Mais pas n’importe quelle mesure. Plutôt qu’une mesure quantitative (aka l’étude de marché, vous savez, celle avec laquelle le Paic Citron n’aurait jamais vu le jour…) on va chercher une mesure qualitative, donc en fait un (ou plusieurs, mais pas beaucoup) utilisateur avec un problème, et l’on va chercher à le rencontrer en personne !
Pour illustrer la démarche, Sébastien nous introduit la démarche Lean Startup sous forme de pseudo-code. Je ne saurais me livrer au même exercice que l’orateur (il est préférable d’aller voir sa présentation), mais cela donne des choses de ce genre :

IMG_0041

Ou pour résumer de manière plus sibylline:

  1. Revenir au problème (prendre de la distance avec la solution)
  2. Identifier les clients potentiels
  3. Identifier 3 clients potentiels. A priori les plus prometteurs, mais en définitive on fait un peu confiance à la chance…
  4. Pour chaque client, établir un Lean Canvas, celui décrit dans Running Lean (https://freethinker.addinq.uy/post/39835584866/note-de-lecture-running-lean-2nd-edition-par-ash)
  5. Trier les clients par :
  6. “pair level” c’est à dire votre alter égo, celui qui vous donnera donc le plus de feedback
  7. Facilité à atteindre. C’est à dire : puis-je facilement lui parler en direct
  8. Capacité à payer : Ou plus exactement : combien ce client est prêt à payer.
  9. Taille de marché. C’est en fait le dernier critère !

Lister les hypothèses. Attention il ne faudra tester qu’une hypothèse à la fois. En s’aidant, par exemple, du “validation board” (http://leanstartupmachine.com/validationboard/). Attention aux hypothèses ! Les clients potentiels ne paieront pas pour quelque chose qu’ils trouvent simplement “bien”, mais pour quelque chose dont ils ont vraiment besoin ! Sortir du bâtiment, pour aller faire des interviews. Le mieux est de pouvoir faire les interviews à deux, avec un observateur concentré sur la communication non-verbale. Travailler le MVP et le pricing Evaluer la solution proposée ; itérer si nécessaire Obtenir un signup et un paiement

Alors seulement, vous pouvez envisager de quitter votre travail. Mais pas avant : se sentir menacé alors que l’on a pas commencé le business est la meilleure façon de prendre de mauvaises décisions !

See you soon

Vous n’êtes probablement pas encore rassasié de ce Agile Tour Bruxelles ? Nous non plus. En fait, il est l’heure de se rendre au buffet de midi. Nous nous retrouverons très bientôt pour la suite de cette journée !

AgileTour Brussels 2013

Comme l’an dernier, je me rendrais à l’Agile Tour Bruxelles ! Pas tout à fait comme l’an dernier, toutefois, car je m’y rends cette année sous les couleurs de Zenika !

Je vais me livrer à ce que j’appelle une “session participative”, une présentation entrecoupée de participations de l’assistance. Le titre en est inspiré d’un principe promu par Scott Meyers : Easy to use correctly and hard to use incorrectly.

En voici le teaser :

We are all seeking for good advices, recipes and rules of thumbs to make our designs better, our requirements strong and accurates, our user interfaces outstanding and more and more…

But there are as many set of rules our advices as there are gurus. And as smart as they are, their rules are only good advices, not final weapons usable in each and every situation. It’s because there is no final weapon. Human mind can’t be replaced and will not be.

Then I crossed Scott Meyer advice. Amazingly it help me to challenge my ideas in programming, design, user interfaces, even in the way I can mitigate user stories or make iteration priorities !

Agile teams are targeting excellence. Code, design and functionalities are not here forever : they are reused, refactored, improved or changed. We want functionalities deighting our customers and be handled without questions. This sessions will help you make a step in this direction by illustrating what it means to build things easy to use correctly and hard to use incorrectly. We will see that successively with code, design structures, requirements, user interfaces and even agile practices !

You will be invited to juge the examples against Scott Meyer’s principle and sometime to improve them and make them better.

Mais je n’ai toujours pas répondu à la question que vous vous posez : Pourquoi Bruxelles ?

  1. Tout d’abord: la communauté Belge ! Elle n’est pas seulement très aguerri en matière d’agilité (ils ont été les pionniers d’XP en Europe), elle est aussi et surtout éminemment sympathique et accueillante !
  2. Une occasion d’entrainer mon Anglais ! Eh oui, nous sommes au pays du bi-culturalisme. Donc, la conférence se fait en langue neutre : l’Anglais !
  3. Enfin, quoi ! Nous sommes en Belgique ! Donc, il y a de la bière …

Me voici donc avec quelques travaux de vacances pour préparer cette session qui sera entièrement nouvelle !

Rendez-vous sur le site d’Agile Tour Bruxelles

Venez nombreux !

AgileTour Brussels 2013

L’Agile Tour Nantes (en images) 3/3

Troisième volet de mon retour sur l’agile Nantes (les parties 1 et 2 sont là et ), voici le programme de l’après-midi

Le paradigme de l’ingénieur dans un imaginaire ubiquitaire

Cette keynote originale nous était présentée par des membres de la compagnie “La Machine” qui, de projets en projets, construit des mécaniques savantes en faisant collaborer ensemble de multiples corps de métier en les faisant interagir en permanence, à l’image de ce que nous faisons dans nos projets agiles, par opposition à l’entreprise traditionelle où règne le “product lifecycke management”.

Le fil conducteur de l’entreprise ne sont pas les projets, mais une vision d’ensemble insufflée par son créateur et directeur artistique François Delarozière : l’imaginaire !

Les machines, comme des êtres vivants passent par 3 phases:

  • La prototype. la machine est assemblée pour en faire fonctionner les différentes parties … avant d’être désassemblée pour être finie, traitée, peinte, etc…
  • L’adolescence. La machine est utilisée dans des manifestations et des spectacles, manipulée et montée par des membres de la compagnie.
  • L’autonomie (le machine de ville). la machine est revue afin de respecter les normes lui permettant d’être accessible par le public.
atnantes2012-lamachine02

A la base de l’entreprise, il y a un meneur, François Delarozière que nous avons déjà nommé. C’est lui qui initie les différents projets. Et au départ de chacun d’entre eux il y a une histoire qui inspire dessins et mises en mouvements.

Une fois le concept posé et les premières idées arrêtées, il y a des réunions avec les différents corps de métier. L’équipe de réalisation est une équipe intégrée regroupant tous les corps de métier : Ingénieurs structure, mécaniciens, hydrauliciens, menuisiers, soudeurs, etc… Il y a une transparence totale sur les travail effectué par les différents membres. On ne parle plus de stand-up quotidien mais de boucles de feedback en continu, toute la journée.

Cet esprit d’équipe est résumé de manière humoristique “on collabore et on travail vraiment en équipe : on ne finit jamais complètement nos tâches, on en laisse pour les autres !”. Pourquoi un ingénieur structure devrait-il donner des précisions sur la réalisation d’une soudure ? Le soudeur connait son travail, mieux même que l’ingénieur ! Il saura poser des questions d’il a besoin de précisions. De toute manière à quoi bon spécifier les détails ? Ce que l’on fera au final sera différent !

L’équipe n’est pas seulement collaborative, elle est aussi plurielle et pluridisciplinaire : ceux qui conçoivente et construisent les machines seront aussi ceux qui les manipuleront et les monteront. Tous ! Comme le disent si bien les membres de la compagnie “on n’a pas vraiment le choix” !

Chaque réalisation de La machine est quelque chose de différent, un nouveau challenge, dont on ne sait pas au départ comment il sera adressé ! Mais tout ceci se réalise plus facilement quand on travaille tous ensemble, dans le même bureau.

PO et culture Agile: potion magique du succès de l’entreprise !

Frédéric Dufau-Joel nous a proposé une session une session au format original : le fish bowl. Frédéric a fait disposer les chaises en cercle, en disposant un petit cercle intérieur de 5 chaises dans lequel il s’est installé. L’un des chaises devant rester vide (la plupart du temps) les autres sont prêtes à acceuillir les personnes déirant poursuivre le débat en posant une question à Frédéric. Quand la dernière chaise est occupée, la personne la plus ancienne dans le cercle doit rendre sa place.

Bref, au lieu d’éliminer du “bottleneck”, on va plutôt en créer afin de réguler le débat. C’est une application du WIP du Kanban, si on veut bien …

atnantes2012-dufau-joel02

Le principal, pour ne pas dire le plus surprenant, c’est que ça marche !

Revenons au thème de la session, c’est à dire le PO en tant que potion magique. Frédéric nous a fait partagé son retour sur l’imporatnce du PO dans le succès des projets au sein de son entreprise. Il identifie plusieurs facteurs de succès.

Les PO viennent des métiers. Cette transition d’un rôle opérationnel vers ce rôle de PO est valorisé et est même un templin pour leur carrière !

Le casting est important. Tout le monde n’a pas le profil pour être PO. La connaissance méier ne suffit pas, car le PO est un agent de changement qui doit aussi travailler très près des utilisateurs. De plus, le formation de binômes sénior / junior aide à la parformance sur les projets, ainsi qu’à la continuité.

Une logique d’amélioration. Frédéric ne parle plus de projets informatiques. Ce sont des projets d’entreprise, des projets d’amélioration. Encore une fois, les PO sont des agents du changements.

Un dernier point que j’ai noté en outre : A la question sur la mesure sur le ROI des projets, Fréderic a dit qu’il n’en faisait aucun, à part le sourire des utilisateurs et des décideurs ! Une belle forme de conclusion.

Apologie du mur

La présentation d’Axel était certainement un peu légère, et j’avoue n’y avoir rien appris. Mais elle était fort bien présentée avec entrain et humour : une touche de légèreté et de différence que j’ai apprécié à cette heure de la journée. En fait je n’ai pas regretté mon choix, ce que je dis plutôt rarement, peut-être même jamais lorsque je pense ne rien apprendre !

atnantes2012-axel04

Mais revenons sur cette présentation. Elle s’appuie sur 3 histoires vécues présentées de manière vivante et avec humour.

La première histoire est celle d’une équipe s’enlisant dans sa stratégie de test. C’est le prix “pas de bol”. Ca arrive, et ça arrivera encore. Elle s’en est sortie en trouvant finalement le bon outil de test fonctionnel.

La seconde histoire est celle d’une équipe présentant une vélocité affichée n’ayant rien à voir avec la vélocité réelle. Une belle illustration de Death March avec son cortège de conséquences habituelles : bugs, pataches, baisse de la qualité et burn out. C’est le prix “mérité”. Pour s’en sortir, il a fallu un retour aux sources sur la qualité et la définition of done … et essuyer la date pendant un petit moment.

La troisième histoire démarre par un Product Owner fort zélé arrivant avec un backlog simplifié… de 4 items ! C’est le prix “inattendu”. Il a fallu reculer le démarrage du projet afin de pouvoir retravailler le backlog avec l’équipe afin qu’il ait une granularité présentant des items appréhendables.

Quelles leçons retirer de ces histoires ?

D’abord que les murs en gestion de projet prédictive sont dangereux. Ils peuvent même signer la mort du projet.

En mode agile, on a comme premier reflexe de cacher tout autant ces murs que l’on voit parfois arriver et qui font peur. C’est une réminiscence de l’ancien mode. Pourtant ils nous apprenent des choses. C’est même eux qui forment la plus grande part de notre apprentissage. On doit leur faire face et en sortir les enseignements lors des rétrospectives.

Pour résumer, en 4 points :

  • N’ayons pas peur des murs !
  • De toute façon, on va s’en prendre !
  • Evitons quand même les gros murs, ne soyons pas kamikazes !
  • Sachons les écouter et affichons (sur des murs physiques cette fois).

Des mots, des maux ? Démo !

Je n’avais pas encore eu l’occasion d’assister à la présentation de ma collègue Caroline Damour et ex-collègue Emilie Franchomme. C’est maintenant chose faite. Mieux encore, elles m’ont donné l’opportunité pour cette “dernière” d’apporter ma modeste contribution. J’y reviendrais.

atnantes2012-demo02

L’originalité de cette présentation était de reposer entièrement sur un appel à témoignage auprès de la communauté ! D’une part cela témoigne d’une attitude humble de la part de Caroline et d’Emilie, et je dois dire que ce n’est pas le trait marquant de notre communauté (au sein de laquelle je m’inclus) ! Cela nous donne aussi un indicateur fiable sur la façon dont la chose est appréhendée par différentes équipes.

Le premier point qui remonte est : Synecdoque ou comment prendre une partie pour un tout ! On devrait en effet parler de “revue de Sprint” et non de de “démo”, celle-ci n’étant qu’une partie de la revue.

Le second point concerne les facteurs de réussite:

  • Ca se prépare
  • Avoir une check-list pour ne rien oublier
  • Raconter une histoire pour captiver le public

Un aspect stressant qui semble réccurent : éviter la honte devant les clients !

Le point qui m’a le plus interpellé est la dualité démontrer / valider !

Ce “pattern” semble réccurent et source de problèmes et de tensions:

  • Cela créer un mur lors des démos (pardon, des revues de Sprint). En effet, on se retrouve plus en climat de client / fournisseurs, voir juge / jugé qu’en situation de collaboration. Chacun s’apprêtant à défendre son camp.
  • Cela exacerbe le problème du “scope creep”, où les utilisateurs vont s’evertuer à trouver insuffisant le périmètre montrer afin d’en avoir “toujours plus”.
  • Cela sape le rôle du PO qui doit être celui qui valide.

Bref, tout cela laisse bien moins de place à la collaboration !

Un dernier point que j’ai noté (mais ce n’était pas le seul de la présentation, vous n’aviez qu’à venir) : la célébration. C’est très américain, mais pourquoi pas ? Toutefois ce ne doit pas être le but recherché.

Et puis, c’était mon tour !

Caroline et Emilie m’ont proposé d’introduire un nouvel opus de ma saga “en finir avec”. J’avais choisi de faire court, pour ne pas canibaliser la présentation. Trop court et trop léger peut-être, je n’ai pas été très satisfait de moi. Je vais essayer de vous résumer la chose.

La démo, c’est reporter en fin de sprint la revue d’éléments que l’on a fini en cours de sprint ! Alors pourquoi ne pas faire plutôt des “micro démos” qui concluraient chaque story, plutôt que de constituer du stock en cours de sprint ? Voilà du moins la colonne vertébrale de mon propos. Je le reprendrais plus tard de manière plus travaillé et plus détaillé dans un post ici même. Stay tuned !

J’avais déjà posté la présentation de caroline et d’Emilie. Elle est accessible ici.

Partir … revenir ?

Déjà 18h30, notre train est à 20h00 et je serais chez moi à près de 23h00. Il est temps de rentrer (ouais, le campus, il est quand même un peu dans la cambrousse). le temps d’un dernier échange avec les suspects habituels, direction le bus.

atnantes2012-retour02

Une belle journée avec des sessions donnat matière à réflexion. Mes deux “keepers” de la journée, en plus d’une foule de petites choses, d’idées et de rencontres.

  • La session de Tremeur Balbous sur l’immunothérapie au changement. Le premier changement à opérer est en nous et il faut se rendre prêts à l’opérer.
  • Le PO “potion magique”. Le Product Owner est un vrai facteur de réussite, mais pas n’importe comment, pas simplement en collant une étiquette au revers de son veston. Il doit d’abord et avant tout être un agent du changement et non un scribe !
  • Mélanger présentation et validation lors d’une démo, c’est pas une idée de génie.

Alors c’est vrai, Nantes ce n’est pas à proprement parler à côté. Pourquoi aller là-bas alors que l’Agile Tour Paris est à 200 mètres de mon lieu de travail ? Pour les rencontres, tout d’abord. la communauté Parisienne, je commence à connaître. L’ambiance est un peu différente des rendez-vous de la capitale où l’on a peut-être plus tendance à pavaner, même malgré nous… Et puis j’avais rencontré quelques personnes de la communauté Nantaise lors de l’Agile Games France. Il me tardait de les revoir à nouveau. Bon allez j’avoue, c’est la raison principale.

Il est un peu tôt pour affirmer que je serais là l’an prochain. Mais cela me tente bien…

L’Agile Tour Nantes (en images) 2/3

Je poursuis ma restitution de l’Agile Tour Nantes commencée il y a peu.

J’ai 2 jours pour obtenir une vision partagée avec 15 utilisateurs pour mon projet agile !

Pierrick Thibault et Edwige Champin du groupe Atlantic nous racontent comment ils ont opéré le lancement d’un projet en mode semi-agile adoptant une approche “full agile” pour son lancement !

Pourtant les choses se présentaient difficilement : ce projet transverse au groupe impliquait plusieurs sociétés, avec 15 utilisateurs impliqués dans le lancement, issus de sociétés et de fonctions différentes. Qui plus est, la société vient d’assez loin, avec du cycle en V et une méthode “maison” … mais toutefois une pratique Lean au niveau de la production : Atlantic Production System, le pendant du TPS de Toyota !

Le début de la présentation est un peu long, avec la présentation du contexte “groupe Atlantic”. L’opportunité pour nous de savoir que le cycle en V bien que fonctionnant correctement chez Atlantic, présente quand même des lacunes (cycles trop longs fonctions inutiles) que la société souhaite adresser. Le temps aussi pour nous de découvrir le projet Metis dont il sera question.

atnantes2012-pierrick03

Alors voilà, le projet n’est pas encore commencé que déjà des obstacles sont là et bien là !

  • Le projet est déjà estimé !
  • On démarre sur un cahier des charges existant.
  • Des activités au format habituel
  • Un grand nombre de participants pour ce lancement : 15 personnes !

Aussi quelques points auxquels il faut prêter attention:

  • Le partage des pratiques métier: les personnes impliquées tiennent en effet des fonctions très diverses.
  • Se détacher de l’existant.
  • Ne pas transformer ce lancement en “lettre au père noel”.
  • Faire en sorte que les participants soient acteurs (pas facile quand on est si nombreux) !
  • Eviter le jargon agile.

Il est maintenant temps de rentrer dans le dur !

atnantes2012-pierrick02

Ces 2 jours ont été découpés en 3 phases:

  • Ouvrir
  • Explorer
  • Converger

Ouvrir

Pour ouvrir, c’est le format World Café qui a été privilégiée. En quelques points:

  • Des tables de 4 / 5 personnes
  • Des rounds de 15 minutes entre lesquels les participants changent de table.
  • Un hôte qui fait le lien au niveau de chaque table, entre les rounds.

3 rounds de 15 minutes ont permi de déveloper la reflexion autour de “comment optimiser mon organisation au jour le joursur la gestion des dépenses projet”. Ce thème étant reformulé pour le 3 ème round. Une restitution par thèmes cloturant cette première phase.

Explorer

Cette exploration s’est faite en 2 temps:

  • D’abord la définition des “persona” qui serviront à l’expression des besoins.
  • Puis un atelier Story Map pour faire émerger les besoins.

Converger

C’est un atelier de priorisation des stories qui a conclut ces 2 jours. Une priorisation “en silence” vu le nombre des participants, qui a quand même permis en 3 passes de ventiler de manière équilibrée les stories selon 3 niveaux de priorité.

Bref, une présentation intéressante, d’abord parcequ’elle m’a permi de découvrir le World Café que je ne connaissais pas, et parce que le thème du lancement de projet est rarement traité en retour d’expérience, surtout à cette échelle et dans ce type de contexte.

Immunothérapie pour le changement

Je suis resté pour suivre la session de Tremeur Balbous, dans la continuité de sa keynote. L’immunothérapie pour le changement est directement issu des travaux de Robert Kegan et Lisa Laskow Lahey que l’on retrouve aussi dans l’ouvrage éponyme. Ces auteurs, enseignants à Cambridge ont développé une approche de coaching qu’ils supportent aussi au sein de leur société Minds at work, nottament par le biais d’une certification. Eh oui : business, business…

La théorie

Elle s’appuie sur 3 éléments :

  • Les niveaux de développements
  • Les typoes d’apprentissage
  • Les filtres

Les niveaux de développement

Si le développement chez l’enfant est une matière qui, à défaut d’être complètement maîtrisée, commence à être comprise, il n’en va pas de même du développement chez l’adulte. Tremeur nous présente les 3 niveaux de développement identifiés dans cette approche

  1. Socialized minds : ce sont les joueurs d’équipe. La perception des autres compte. Mais ces personnes tendent à comprendre ce qu’ils veulent entendre.
  2. Self authoring minds : Ces personnes sont guidées par leur propre agenda. On y retrouve beaucoup de managers. Etonnant de voir cela décrit comme un stade au-dessus du précédant. Peut-être parce que ces personnes ont sû se sevrer de l’approbation des autres…
  3. Self transforming minds : ce sont les personnes qui apprennent à apprendre, qui capable d’entendre et d’intégrer les différents éléments qui leur sont soumis.

En gros, plus une personne est haut dans son développement, meilleurs sont les résultats qu’elle obtiendra.

Les types d’apprentissage

Il y en a deux:

  • Les apprentissages techniques : ils nous permettent d’apprendre le “quoi”.
  • Les apprentissages adaptatifs : ils vont nous permettre de créer de nouveaux savoirs, de développer de nouvelles capacité. C’est le travail sur nous-même. C’est ce que Tremeur apelle développer notre capacité à faire des liens.

Les filtres : ils rendent subjective notre perception de la réalité.

Le diagnotique de l’immunité

L’approche de Minds at work s’appuie sur un template en 4 parties

  • L’objectif : c’est ce que nous voulons changer dans notre comportement. Nous ne sommes pas nécessairement les mieux placés pour en juger, d’ailleurs. Pourquoi ne pas demander aux autres ce qu’ils pensent que nous devrions changer en nous ?
  • Ce que je ne fais pas (ou plus) par rapport à cet objectif
  • Quels sont mes engagements cachés qui vont à l’encontre de l’atteinte de mes objectifs.
  • Quels sont les postulats fondamentaux qui me guident.

Le travail sur cette “carte” se fait de manière itérative, mais chaque point sert de point de départ au point suivant. C’est en sorte une analyse causale que nous devons faire en nous-même…

Pour illustrer son propos, Tremeur n’a pas hésiter à montrer la carte qu’il avait construit pour lui-même ! Chapeau l’artiste, il fan avoir du courage pour se découvrir ainsi ! L’aspect auquel il faut porter attention lors de la construction de la carte, c’est que les points mis en évidence doivent s’appuyer sur des comportements identifiés et non des ressentis. Il s’agit d’objectiver les éléments, toujours la question des filtres…

Cette démarche a pour but de nous faire prendre conscience de nos immunités, à l’image des 4 stades de la connaissance :

  1. Inconsciemment immunisé
  2. Consciemment immunisé
  3. Consciemment désensibilisé
  4. Inconsciemment désensibilisé

La dernière étape est de travailler sur notre système immunitaire (mais c’est déjà bientôt la fin de la session). Il y a 3 axesChange prevention system

  • Feeling system
  • Knowing system

J’ai zappé pas mal d’éléments, mais je ne vais pas refaire la présentation de Tremeur. Je n’y arriverais pas, je la met plutôt en liens. Je ne suis pas un super-fan des techniques de coaching, mais cette présentation est un de mes “keepers” de la journée.

Revue de code et publications continue

Après la pause déjeuner, c’était la demi-heure “lightning talk”. Bon là, il va me falloir être un peu honnête : je passais en seconde partie et je suis un peu du genre stressé … bref, je n’ai pris aucune note sur la présentation d’Arthur Lutz qui précédait la mienne. C’est fort dommage car cet exemple d’intégration d’outillage mérite le détour. mais vous avez la présentation ci-dessous : have fun !

En finir avec…

Ouais voilà, c’est mon tour ! Quelques personnes quittent la salle, mais une vague tout à fait honorable s’y engouffre. Ce n’est pas salle comble pour moi, mais pas très loin en fait ! Je ne vais pas vous asséner cette présentation à nouveau, la voici en lien en attendant l’article si j’ai le courage de l’écrire…

Voilà pour cette seconde partie de mon retour sur cette riche journée. Tellement riche qu’il va me falloir un troisième opus si toi, courageux lecteur, je ne t’ai pas encore dégouté !

L’Agile Tour Nantes (en images) 1/3

Soirée entre amis

Pour nous l’Agile Tour Nantes a commencé le 14 : rendez-vous étais pris avec quelques membres d’Agile Nantes. Le lieu était fixé : La bar restaurant établi dans les anciens anciens locaux des biscuiteries Lu. Je sais désormais que LU signifie “Lefèvre Utile”. Le lieu est vaste en espace et en hauteur et garde les stigmates de l’ère industrielle. Il me rappelle un peu les squats Berlinois. J’aime bien.

atnantes2012-soiree04

Arrivé vers 19h00 avec Caroline et Emilie (qui animeront la session “Des mots, des maux ? Démo !”) nous rejoignons Frédéric, Cécilia, Cécile et Pierrick. Une agréable soirée entre passionnés qui ont plaisir à se revoir.

Wake up !

J’avais pris l’option “hôtel en cambrousse mais pas loin de la conf’”, donc j’arrive à pied ! L’école des Mines de Nantes est franchement loin de la ville, mais au moins, il y a de la place. En témoigne l’accueil dans le hall d’entrée.

atnantes2012-accueil01

Assez ri, il est temps de se rendre à la session d’ouverture, guidé par Alvin Berthelot dit “Le Policier” (mais seulement par moi).

atnantes2012-alvin

L’avantage d’être accueilli dans une école, c’est que les amphi sont bien fait pour donner de la visibilité sur la scène. Et on est pas non plus obligé de prendre nos notes sur nos genoux !

Ah, les bancs de la fac ! Me voilà revenu de 30 ans en arrière…

atnantes2012-public01

Ouverture

Pierrick Thibault donne le tempo pour lancer cet Agile Tour Nantes : il sera sur le thème du jeu ! Et on applaudit bien fort la sympathique équipe d’Agile Nantes qui a rendu cette journée possible.

atnantes2012-ouverture04

Keynote

La keynote du matin était assurée par Tremeur Balbous, Breton éxilé au Quebec et aussi créateur de la communauté agile Nantaise. Le titre de cet opus d’ouverture était simplement : On est agile !

atnantes2012-tremeur01

Le passage à l’agilité nous a évité d’aller dans le mur, alors que la gestion de projet classique nous y menait tout droit ! Evité ? Non ! Nous avons juste retardé le moment d’aller dans le mur. Et ce malgré l’agilité.

Tout d’abord, quels sont les bénéfices attendus de l’agilité ? Les enquêtes montrent au premier plan les critères suivants : Time to market, gestion des priorités, gestion du changement, respect des budgets. Des critères tels que le plaisir des équipes arrivent loin.

Quels sont les bénéfices obtenus ? Ils sont différents, avec le plaisir des équipes arrivant assez haut !

Tremeur nous assène son message : le passage à l’agilité n’est pas essentiellement un changement d’organisation, mais une philosophie qui nécessite un changement de perspective. Les causes d’échec ne sont pas exogènes, mais endogènes. Elles sont à chercher en nous (ce que l’on verra dans la session suivante : immunothérapie au changement).

“Change en toi ce que tu veux changer dans le monde” – Ghandi

Il faut donc commencer par travailler sur nous, changer nous-même, apprendre à nous connaître. Il faut investir sur nous-même, par exemple en suivant les conseils de Matt Cutts en essayant quelque chose de nouveau pendant 30 jours.

Ainsi se résume le message d’introduction de Tremeur:

  • Si on reste focalisé sur les pratiques, on va dans le mur.
  • Si on travaille sur nous-même, nous réussirons.
http://fr.slideshare.net/slideshow/embed_code/15206868

Voilà pour aujourd’hui. A bientôt pour la seconde partie !

En finir avec … (le lightning talk)

Voici le support de mon lightning talk “en finir avec …” tel que je l’ai présenté l’Agile Tour Nantes 2012. C’est une présentation courte, de moins de 15 minutes.

Teaser de la présentation

L’agilité est en pleine expansion. Nombreux sont les projets, nombreuses sont les sociétés qui l’adopte ! Nous devons nous féliciter de cet engouement, et pourtant …

Pourtant cette adoption croissante n’est qu’apparence dans certains cas. Dans plus en plus de cas, même. Si Scrum est aujourd’hui l’approche qui fédère le plus, les quelques idées centrales de la méthode sont de plus en plus souvent dévoyées. Il en va de même d’autres pratiques agiles.

Ah ! Vous faites du Scrum, je vois que vous avez un P.O. et un Scrum Master. Vous n’avez plus de cahier des charges mais des User Stories, donc tout va bien.

Cocher la liste des pratiques agiles en repeignant plus ou moins les vieilles pratiques ne convient pas, il faut en finir avec cela !

Dans cette courte session, je vous propose de faire la peau à 3 pratiques : la Roadmap, le Product Owner et les User Stories. Mais vais-je vraiment les assasiner ? Pour le savoir il vous faudra assister à ce lightning talk !

Quelques rappels sur “en finir avec”

Cette série comprend aujourd’hui une présentation générale du principe de cette série ainsi que 3 posts:
Elle compte désormais la présente présentation, et une partie de la présentation de Caroline Damour et Emilie Franchomme à laquelle j’ai participé (du moins pour “la dernière”).
Viendront cette présentation sous forme d’articles, d’autres posts (certains sont en préparation, soyez patients) et peut-être une saison 2 ?

Retours sur l’agile tour Bruxelles 2012

Je m’étais fixé dans mes objectifs sur ce second semestre, de me joindre à la communauté agile Belge à l’occasion de l’agile tour Bruxelles. je n’ai pas hésité longtemps à répondre à l’appel à orateurs de Bruno Sbille. Plusieurs raisons à cela:

  • L’opportunité de faire une présentation en Anglais. Il faut bien garder la forme !
  • L’occasion de rendre la politesse à Bruno qui nous avait fait le plaisir de venir faire une présentation dur la Programmation Neuro Linguistique lors d’une soirée du Scrum User Group.

J’espérais donc bien être retenu. Je l’ai été : merci au comité d’organisation !

L’aller-retour dans la journée, ça fait une grosse journée, mais ça valait le coup.

Pascal Van Cauwenberghe : 11 steps to perfect code

Pascal s’est présenté comme un “recovery bug writter”. Il nous a présenté son processus destiné à éliminer les bugs. Il compte 11 étapes, pas moins.

La qualité dépend-t-elle des testeurs ? La réponse est non. En fait, elle est souvent inversement proportionnel au nombre de testeurs. Cela peut paraitre provocateur, voir choquant. mais réflechissez à l’impact psychologique sur les développeurs d’‘une très importante équipe de testeurs.

1 – Mettre en évidence le bug. Jusqu’ici tout va bien.

2 – Votre réaction : et meeeerde ! Non, justement. Il faut remercier le rapporteur. Pascal nous fera faire l’exercice plusieurs fois durant cette heure: remercier à haute voix: Thank you !

3 – Reproduire le problème. Identifier les conditions sous lesquelles ce bug se manifeste est une simple question de bon sens.

4 – Ajouter (au moins) un test qui échouera suivant ces conditions.

5 – Corriger le problème. Vous suivez toujours ?

Bon ça y est, on a fini. Comment ça “non” ?

6 – Rejouer la totalité des tests unitaires. La correction d’un bug peut introduire une régression. Nous le savons tous. Mais prenons-nous tous la peine de rejouer la totalité des tests ? Bien sûr le but n’est simplement de les rejouer, mais de les rejouer jusqu’à ce qu’ils passent tous !

7 – Faire une analyse causale : pourquoi ce bug n’a pas été intercepté précédemment ? Il faut toujours faire attention aux objectifs que l’on fixe : on risque de les atteindre. Si le but est la couverture du code, est-on certain qu’elle est synonyme de tests associés ? Le véritable objectif n’est pas la couverture du code, mais la qualité de celui-ci.

8 – Améliorer les tests.

Là, ça devrait être terminé. Non, toujours pas ?

9 – Améliorer la façon dont les tests sont écrits. Mais ceci est autre chose, n’est-ce pas plutôt un point qui devrait être remonté en rétrospective ? La rétrospective ce n’est pas pour la fin de sprint. La démo ce devrait être tout le temps.

10 – “Un bug ne voyage jamais seul” : à la recherche des bugs similaires !

11 – Faites que ce bug soit impossible à reproduire !

Traquer les bugs ainsi peut sembler coûteux. En fait, ça l’est au début. Pascal s’appuie sur la théorie des contraintes pour expliquer que cette approche permet finalement de livrer plus vite ! En l’occurrence sur un projet, au bout de 5 mois au lieu de 8 !

Jan De Baere : Kaban at different levels

Jan a choisi de nous présenter Kanban tel qu’il est utilisé réellement dans les projets auxquels il a participé, avec les leçons qui ont accompagné sa mise en oeuvre.

La règle de conduite que nous propose Jan repose sur 3 axes:

  • Visualiser le workflow.
  • Limiter le “work in progress”, en s’appuyant sur l’expérimentation.
  • Mesurer et gérer le workflow.

L’exemple d’une circulation sur une autoroute illustre assez bien ces 3 points, même si les paramètres conduisant à la formation des bouchons sortent des fondements théoriques de Kanban (eh oui, il n’y a pas que la théorie des contraintes…).

Cette session avait pour but de nous exposer cette mise en oeuvre dans différents contextes:

  • Un projet classique.
  • Un projet distribué
  • Le Kanban au niveau individuel
  • la gestion d’un portefeuille de projets.

Plutôt que d’asséner les différents éléments de la présentation je préfère mettre en avant les éléments principaux:

  • Les “expedites”: lorsqu’ils sont trop nombreux, il ya un problème à régler !
  • Mettre en évidence les éléments qui sont attendus. Là encore, ils peuvent stigmatiser des problèmes à régler au niveau organisationnel.
  • Les “buffers”: ils peuvent apparaitre utiles dans le workflow, mais sont à utiliser avec parcimonie. Ce sont des sources de gâchis, au sens Lean.
  • Il y a un lien direct entre le “work in progress” et le “lead time”. Ils croissent de concert.

L’un des grands moments fut certainement la présentation du “kanban portable” (et pliable) réalisé par Jan !

atbru2012-JanDeBaere

Pour ma part, je garderais dans mes notes l’usage du “personnal kanban” avec ses limites de WIP adaptatives:

  • Les tâches “high energy” : la limite de WIP est de … 1 ! Ce sont les tâches qui demandent un haut niveau de concentration.
  • Les tâches “medium”, c’est le travail ordinaire. La limite de WIP est de 2.
  • Les autres tâches, celles qui ne nous donnent pas vraiment de faire un travail correspondant à notre niveau de qualification. Il n’y a pas de limites de WIP pour celles-ci.

Ce peut être du bon sens, mais c’est sans aucun doute un point à garder !

Alan Holtz : Lessons learned from the Scrum Master

J’espère qu’Alan me pardeonnera de ne pas avoir pris de note lors de sa session. J’étais en fait en train de faire l’ultime préparation de la mienne ! Si une photo vaux mieux que de grands discours, en voici donc une !

atbru2012-SMLessonsLearned

Yves Hanoulles : How 146 people made 13 projects

Yves a acquis une grande notoriété dans la communauté agile, par son implication dans de nombreux projets. J’avoue que j’avais du mal à comprendre comment il pouvait mener à bien cette activité débordante. Cette session répond à ces questions.

atbru2012-YvesHanoulles

Comment nait un projet ?

Yves débute simplement un projet par un problème qu’il rencontre et sur lequel il ne trouve pas sur le net de ressources pouvant l’aider.

Comment construire une communauté de contributeur ?

Simplement en demandant autour de lui, mais en s’adressant de manière directe aux intéressés, s’ils peuvent et souhaitent l’aider sur son projet. C’est une question franche et directe qui n’appelle pas obligatoirement de réponse positive : on peut ne pas avoir le temps, ne pas être intéressé par ce projet, etc… Yves accueille de manière factuelle et simple cette réponse.

A partir de là, Yves accorde une complète confiance aux collaborateurs dès le départ, avec complet accès en lecture et écriture aux ressources du projet : la confiance n’est devrait pas être “gagnée”, mais donnée !

Surtout Yves nous rappelle qu’il faut toujours penser à remercier une personne qui se propose de contribuer.

Collaboration et outillage

Tous ces projets se déroulent sans aucune rencontre face à face : tout est mené et coordonné à distance, l’outillage permettant cela est donc important. Les principaux que j’ai noté :

  • Skype
  • email: Oui, bien qu’Yves soit un fervent défenseur de la limitation de l’usage de l’email en entreprise, il reste un média essentiel pour ces projets collaboratifs.
  • Google doc.

Si les projets agiles défendent la co-location, Yves nous rappelle que selon Jim McCarthy, celle-ci n’est pas une nécessité : ce qui est nécessaire, c’est une communication avec une large bande passante.

Who is agile ?

Yves a terminé sa session sur quelques reflexions sur la rédaction d’un livre en mode agile, tel que “who is agile ?” a été rédigé.

  • La rédaction d’un livre en mode agile est possible, intégrant des itérations et du feedback. C’est non seulement possible et même souhaitable. Une plateforme comme Leanpub est un grand facilitateur en ce sens.
  • La lecture d’un livre réalisé en mode agile est pr contre moins sympathique.

Jeff Cumps : How to solve your thoughthests impediments

Jeff nous invitait à une session-atelier sur le A3 problem solving. Un réel challenge d’ailleurs car il ne disposait que d’une heure pour nous exposer les principes et nous permettre de les mettre en oeuvre sur une problématique de notre choix.

Je ne vais pas détailler l’atelier ici. Le timing était un peu serré, mais nous avons pu avoir la satisfaction de bien avancer sur nos exemples. Disons que 1h30 aurait probablement été un créneau plus confortable. Mais peut-être pas plus, non plus !

En fait le point positif du temps limité était d’aller droit à l’essentiel sur l’exercice pour en comprendre les points principaux. Ce que Jeff a fait avec clarté. Une très bonne session pour conclure cette journée !

Ambiance, boissons et rencontres

Chaque conférence agile est l’occasion de croiser ou recroiser des passionnés. L’évènement a été ciblé petit par les organisateurs : 70 personnes, donc volontairement peu de buzz autour de ce premier Agile Tour Bruxelles. Un grand “up” pour les organisateurs à propos de la convivialité et de l’ambiance sur cet Agile Tour Belge. Ca donne vraiment l’envie d’y revenir.

Couleur locale oblige, nous avons conclu la journée autour d’une bière.

Un geste sympathique pour les orateurs : un assortiment très couleur locale une fois encore. Que je vous laisse découvrir.

atbru2012-orateursgifts

The virtues of emergence

J’ai eu de nouveau le plaisir de donner mon lightning talk “les vertus de l’émergence” lors de l’agile tour Bruxelles. Cette fois, c’était en Anglais, l’exercice était donc un peu plus difficile. Voici le support de cette présentation, un peu modifié par rapport à la langue et au modèle graphique de l’évènement.

Le slide-show ne rend pas bien compte de la présentation. J’avais posté ici-même cette présentation sous forme d’article. Mais c’est uniquement en français pour l’instant.

La même présentation est aussi accessible en français, avec le modèle graphique du Scrum Day 2012.

I was lucky enough to give my lightning talk “the virtues of emergence” during the Bruxelles agile tour. This time, it was in English, so a little bit more difficult for me. Here is the slide show, slightly modified from my first presentation.

As you will see, this doesn’t reflect the presentation. That’s why I wrote an article from this, accessible from here. But it’s only in French for now. I won’t guarantee I’ll perform a translation, but I’ll take that in consideration.