Developer's notebook

Icebreakers à distance

Florence Chabanois — Mon, 18 Jan 2021 22:33:00 +0000

Nous sommes partis pour travailler à distance pour encore un moment. Je profite du fait que plusieurs personnes m'aient posé la question pour tracer ici les derniers icebreakers réalisés dans mes équipes, à l'occasion d'onboardings à distance.

Comment accueillir les nouvelles recrues et entretenir du lien à distance ? Je vous propose quelques activités d'icebreaking testées et approuvées.

1. Onboarder une nouvelle recrue

Contrairement à un onboarding en présentiel, où il y a "juste" un café, la distance oblige à prendre un peu plus le temps d'accueillir les nouvelles personnes, en équipe.

Ils durent environ 30 minutes, le temps de faire le tour de l'équipe.

Nous commençons systématiquement par un tour de table rapide sur qui nous sommes et notre rôle dans l'organisation. Afin que le tour se fasse de façon fluide, chaque personne venant de s'exprimer désigne le nom de la personne suivante. Cela "oblige" aussi un peu plus à écouter.

Sur chaque support d'onboarding, je mets une image : un petit déjeuner appétissant ou une illustration de l'exercice.

En terme d'exercice, mon but est qu'il y ait des échanges et du piquant (par le rire ou la réflexion). L'essentiel étant de se découvrir les uns les autres et d'avoir envie d'en savoir encore plus.

2 vérités et un mensonge

Chaque participant·e écrit deux vérités et un mensonge à son sujet sur un board partagé (https://metroretro.io par exemple ou https://draft.io/).

Personnellement, je préfère demander à avoir les post-its masqués tant qu'ils ne sont pas évoqués.

Quand chaque personne a trouvé les 3 faits, nous déroulons le board dans le sens de la lecture ou sur volontariat. Les post-its sont dévoilés personne par personne. Après lecture par l'auteur·rice, le groupe débat afin de deviner quelle carte est un mensonge. Pour prendre position, je demande aux personnes de poser leur curseur de souris près de la carte soupçonnée. Quand les curseurs deviennent stables, le mensonge est dévoilé et nous pensons à la carte suivante.

Question carrière

Sur cet onboarding, j'utilise Mentimeter (https://www.mentimeter.com/), car j'ai besoin d'anonymat dans les réponses. J'ai une seule slide avec photo et la question : "Racontez un moment fort de votre carrière". Comme il y avait aussi une alternante dans l'équipe, j'ai un peu élargi la question avec "/ ce qui vous plait dans votre travail".

Une fois que tout le monde a fini de répondre, j'affiche les réponses. J'ai fait l'erreur d'afficher toutes les réponses d'un coup, il vaut mieux les afficher une par une pour éviter que des petits malin·es ne procèdent par élimination sur les réponses suivantes.

Vous l'aurez compris, le principe est que le groupe devine qui est l'auteur·rice de chaque carte.

Qui l'a fait ?

Chaque participant·e réfléchit à un fait surprenant sur lui·elle et l'envoie en privé à l'animateur·rice par messagerie par exemple.

Une fois toutes les réponses récoltées, l'animateur·rice les "mélange". Mentimeter permet également de récolter les réponses en live anonymement si vous préparez la slide en amont.

Ensuite, iel les partage une à une au groupe. Ce dernier discute ensemble pour définir qui est l'auteur·rice de la carte, avant de passer à la suivante.

Une autre option est de distribuer à chaque personne une "carte". Chacun·e sera en charge de lire sa carte et d'en deviner l'auteur·rice. Cela assure à chacun·e un moment de parole.

Ma dernière barre de rire

Comme les deux derniers exercices, le principe est que chacun·e partage quelque chose le concernant et que les autres en devenir l'auteur•rice.

Ici, il s'agit de partager un moment heureux comme le dernier fou rire. Il peut avoir eu lieu en milieu personnel ou professionnel, chacun·e choisit ce qu'iel veut bien partager.

Au groupe ensuite de deviner qui a rigolé à quel moment.

Variantes

La liste de variantes est quasiment infinie :

"Quelque chose dont je suis fière / qui m'a intéressé ces 6 derniers mois"
"Cette année je veux"

D'autres questions sont proposés sur ce site https://www.thebalancecareers.com/thoughtful-team-builder-questions-to-use-as-ice-breakers-1919233.

2. Cultiver du lien au sein de l'équipe

Ce qui n'a pas très bien marché

Pour les temps plus relax, comme beaucoup, nous avons tenté les apéros à distance. C'était sympa mais a fini par lasser. La parole ne se répartit pas facilement et passer encore plus de temps devant un écran n'est pas particulièrement relaxant.

Nous avons aussi des temps de coworking, en mode "discord". Le principe est d'avoir une visio ouvert pendant 30 min sur un canal d'équipe pour pouvoir travailler les un·es à côté des autres. Selon les équipes, il fallait que j'aille chercher les gens, la réunion ne fonctionnait pas d'elle-même. Parfois il y avait des bons échanges et parfois rien du tout. Ce n'est pas nécessairement un souci mais cela fait bizarre.

Une cafétaria virtuelle a été créée : je n'y passe pas assez de temps pour me prononcer sur sa fréquentation, même si je trouve l'idée top.

Ce qui fonctionne bien

Sur le deuxième confinement, j'ai délégué une partie des animations car j'ai vraiment trop de réunions. Je précise régulièrement que chaque membre de l'équipe peut proposer des activités conviviales. Une personne a organisé un Secret Santa pour Noël par exemple, c'était très sympa.

Une autre est (presque) officiellement le game master de l'équipe.

Skribbl : https://skribbl.io/ . Un espèce de pictionnary. Tout le monde est mauvais, c'est la course et c'est très drôle.
Téléphone arable : https://garticphone.com. Les retours de l'équipe ont été excellents.

Sur un plan plus "entreprise", le Groupe La Centrale a organisé des escapes games à distance. Je n'étais pas particulièrement emballée à la base et au final, c'était très amusant.

Il y a aussi régulièrement des challenges et des thématiques sur le canal slack de l'entreprise du type "partagez une photo de votre passion / quelles sont vos 3 séries préférées ?" qui ont encouragé des personnes qui ne se seraient pas forcément parler dans les bureaux à échanger ensemble.

Lors du premier confinement, il y avait des ateliers cuisine. Un·e collaborateur·rice apprenait une spécialité culinaire aux autres. C'était vraiment chouette de se mettre en posture débutant·e et de découvrir de nouvelles saveurs.

Ce que je n'ai pas encore testé

Among us : https://www.bluestacks.com/fr/apps/action/among-us-on-pc.html
Loup garou : https://wolfy.fr

3. Autres ressources

A la base en présentiel mais peuvent s'adapter :

Le cookbook "L'art de briser la glace sans briser les participants" : https://coach-agile.com/produit/ice-breaker-cook-book/
Klap.io : https://www.klap.io/jeux-icebreakers/
10 icebreakers de Forbes : https://www.forbes.fr/management/10-icebreakers-pour-creer-de-la-cohesion-dequipe/

Sur des questions types pour briser la glace

Et vous, qu'avez-vous déjà essayé (avec succès ou non !) ?

The power of goals

Florence Chabanois — Mon, 17 Nov 2014 22:49:00 +0000

Lately, a product owner told me how agiles methologies were actually GREAT only for product owners. Developers don't like redoing things over and over again, even if driven by customers feedbacks. Being put that way, who would ?

Common goals

This is actually a matter of (different) goals and definition of done.

If the developer's job is to develop X feature, yes, this is highly frustrating, just like Sisiphus punishment. It can be perceive as a lie ("You said that US would be over after this modification") or lack of skills ("Why can't product owner just know what they want once for all ?"/"why didn't he anticipate ?").

If the developer's job is to help solve a problem as a member of the team ("increase the conversion on that page by 1%"), we are telling a whole different story. A user story become a step, not an aim by itself.

This is where product owners can make a difference. Tell your team about the user stories that worked and the ones that failed. Make the numbers always visible if you can.

Having to share this notion of success forces the product owner to think of the functionnal acceptance criteria for each user story early, with hard facts. You can't know if it is a success before actual users use your product. You can't say Bravo only because something is developed, you have to look at the real results.

I've met a developer who was daily scrutinizing the number of visitors and deals made. Guess what ? He didn't care when he had to re-do a feature. The US just was not "done" yet, in a business perspective.

Micro goals

It is a error to underestimate the power of feeling progress. We need to have things finished. To have that, we need explicit goals. How do YOU feel when you spend a week-end hanging around asking yourself what to do next, websurfing with no purposes ? When monday comes, you feel you've done nothing and this is not a good feeling (well most of the times).

The key here is planning. Planning is boring when someone else makes it for us but it becomes challenging when it's your choices. You can see your tasks being done one after another, it's very fulfilling.

Most of all, you keep the focus. You know you will be late if you go off topic for too long, you know that something else is coming after. This is some stress that makes you feel you are going somewhere. You are achieving something.

Beyond traditional project deadlines, setting goals for each day is a life changing habit. It can be during the daily standup meeting ("yesterday, I've done this; today, I will finish that" and NOT "I plan to start this") or more private on a sheet of paper. When I'm not sure where I'm going, I make a list and then I know. I can also organize it according to the contraints and hence, maximize the chances of success.

If you don't have goals, you can't fail (/can't see that you are failing) and you can't win (/can't see that you are winning). Besides, how can you reach something you don't see ?

So... do you make common goals with global acceptance criteria ? How often do you plan your day ? What kind of goals do you particularly like ? My goal for this evening was to write a blog post in english in one hour. Without that goal, perhaps I would save it for a third proofreading or put illustrations. This blog post is not perfect but it is live.

Mémo pour le PO de plus tard

Florence Chabanois — Thu, 19 Jun 2014 22:13:00 +0100

Quand nous arrivons quelque part, nous voyons assez bien ce qui ne va pas ou ce qui pourrait être améliorer. On a encore pas mal de recul. Puis très vite, on s'engloutit dans le quotidien et toutes ces bonnes idées s'envolent. D'habitude, je fais un rapport d'étonnement sur un cahier et/ou note les idées dans un trello. Pour plus tard.

Ou jamais.

J'ai un blog, alors autant m'engager un peu plus publiquement.

Depuis quelques jours, je prends un peu plus le rôle de product owner.

Je découvre

Premier constat : c'est trop bien d'avoir une feuille blanche sur laquelle dessiner la page web de nos rêves. C'est incroyable de n'être limité par aucune contrainte technique. En plus c'est gratuit. Je peux avoir toutes les idées que je veux, même si elles apportent finalement peu de rendements. Tomber dans le "c'est joli" est un risque assez fort. Cela peut être difficile après avoir mis tant de soin à dessiner cette page magnifique de ne pas la défendre bec et ongles.

Deuxième constat : j'ai de nouveaux des délais à tenir individuellement. En tant que ScrumMaster, c'est assez simple : il faut régler les problèmes tout de suite et faciliter au quotidien. Je n'ai pas besoin de faire d'estimations. Maintenant, j'ai des zonings à faire pour telle date car derrière, il y a du design, des validations à faire et du dev à programmer. Si je prends du retard, tout le reste prend du retard.

Je lis un bouquin (hum une BD) sur les options réelles en ce moment. Le slogan c'est "don't commit until you know why". Je vous le recommande.

Je n'ai pas encore de vision globale sur ce flux mais je ne serai pas étonnée de voir pas mal d'attentes et de gaspillages. En tant que ScrumMaster, j'avais du mal à avoir des données sur la partie spécifications et validation. Je vais pouvoir mieux voir tout cela maintenant.

Je m'engage

Là où je me suis un peu ratée en acceptant des dates de livraison sur les zonings est le temps de préparation.

Pour moi, avant de faire un zoning sur un site existant, on fait des tests utilisateurs. Il parait que dix tests couvrent généralement 80% des cas. Plus qu'idéalement, je refais des tests avant que le dev ne soit trop avancer pour in/valider les hypothèses.

On croise aussi les données et les stats pour voir ce que recherche l'internaute, quel est son problème.

On définit des critères de succès quantitatifs sur le projet et les users stories.

On ne perd pas de vue l'utilisateur (=idéalement, on l'identifie avec un persona).

On prend du feedback (business + technique + design), régulièrement. On teste les modifications suite à ces feedbacks et on valide ces hypothèses.

Enfin, et c'est audacieux de dire cela, mais j'espère augmenter de 10% les rendements. En deux mois :-D. Pour ça, il va falloir dégager du temps pour monter des projets data en parallèle et les faire prioriser au niveau de la stratégie de l'entreprise.

Dernier souhait et là je ne vois pas très bien le moyen : qu'on arrive à avoir des contenus nickels chrome. Ce n'est pas possible d'avoir une armée de relation client qui sensibilise les clients à ces sujets. Pour cette raison, j'avais pensé à une petite vidéo où il y a un test utilisateur qui montre le désintérêt total de l'internaute devant une annonce avec une photo mal choisie par exemple. Le principe aurait été de proposer un kit avec des conseils, chiffres à l'appui de ce qu'apporte une annonce bien renseignée, critère par critère à chaque nouveau client. Nous avons en plus un service dédié au nouveau client. Nous serions excellents de contacter les clients et les internautes pour leur dire qu'on soupçonne une erreur dans la saisie de leur annonce ou de leur alerte email, de vraiment les aider à obtenir de meilleurs rendements avec des mini audits. Je ne pourrai pas faire tout ça, mais appeler une personne appartenant à ce service fait définitivement partie de ma todo list.

Oui, c'est vraiment facile d'avoir des idées. Le plus dur, c'est la réalisation. Je ne sais pas si j'aurais fait une seule chose de cette liste dans un mois. Ce qui est sur, c'est que je ne veux pas "l'oublier" dans le feu de l'action. Nous savons plein de choses mais qu'appliquons nous vraiment ?

Et vous, où est passé votre moi du début et vos bonnes idées ? Combien en avez vous réalisé, quelle est la prochaine à faire, et avant quand allez-vous le faire ?

Pourquoi je propose des confs

Florence Chabanois — Fri, 02 May 2014 22:03:00 +0100

A chaque fois que je propose une session à une conf, je passe par les étapes suivantes :

(je vois passer un appel à orateurs) Ah tiens, si je proposais un sujet. Allez, je prends une heure pour rédiger un topo.
(je vis ma vie)
ce sont les résultats ! j'espère que je vais être prise ! Heu ou pas, quand est ce que je vais caser la préparation ? D'ailleurs c'est quand déjà la conf ?
hourra ma session a été retenue !
(je vis ma vie)
J-10 : mais pourquoi j'ai soumis une session, pourquoi, pourquoi ?
J-9 : j'ai plein d'idées, je n'avais pas remarqué que j'avais autant appris.
J-7 : où est ce que je peux trouver une photo de castor avec un chapeau ?
J-6 : mais pourquoi j'ai soumis une session, pourquoi, pourquoi ?
J-5 : j'ai trouvé le castor !
J-2 : je ne vais jamais y arriver
J-1 : ça commence à être pas mal
J : stress stress stress
J : coup de barre
J+1 : m**** j'ai oublié de dire ça.

Les confs et moi

J'ai assisté à ma toute première conf en 2009 : c'était les XPDays. Depuis, j'ai un attachement très particulier à cette conférence (il est encore temps de s'inscrire).

L'année suivante, je lis clean code et le blog de Misko Hevery. C'est une révolution pour moi. J'ai envie de partager ces découvertes et propose une session à Agile France. Le jour J, la salle est bondée. A la fin, je découvre 2 feuilles de feedback en cadeau sur la table. Je ne connaissais même pas à l'époque. Concrètement, il s'agit d'une feuille A5 avec une note et des commentaires pour expliquer ce qu'on a apprécié et ce qu'il aurait fallu faire pour que ce soit parfait. L'une d'entre elles me donnent comme critère d'amélioration d'être debout et d'avoir des slides moins chargé en texte. A la pause, un gars vient me voir les yeux brillants en disant qu'il allait coder différemment maintenant, qu'il avait eu un déclic et me remerciait pour cela.

Deux ans après, je suis scrum master et les barrières intra/inter services me désolent. Je propose une session sur l'abaissement de ces barrières. C'est une session que j'ai préparé pendant les pauses du midi et la matinée de la conférence. J'ai énormément de choses sur le coeur à ce sujet et je suis morte de trac. J'ai vraiment juste envie de me faire plaisir et décide d'être simplement honnête : je raconte une histoire. Ma super souris sans fil me permet de me déplacer dans la salle. Encore aujourd'hui, même si la préparation laissait à désirer, je pense que cette session a été ma meilleure prez. J'avais eu 5 feedbacks appréciant le retour scrumMaster/manager ainsi que les histoires. Les axes d'amélioration sont de réduire le débit de paroles et qu'il n'y ait pas eu de liens entre le jeu et la prez (je manquais de temps).

L'année d'après, un autre sujet me tient à coeur : l'écoute et le respect entre les personnes pour une meilleure communication. Mes enfants m'ont beaucoup appris sur ce sujet mais tout le monde n'a pas d'enfants ! Je crois qu'un monde meilleur est possible et j'ai envie d'y contribuer à ma petite échelle en touchant ne serait-ce qu'une personne avec ma session. Je propose un sujet sur l'écoute et le modèle DISC. Cette fois, je prépare bien mieux ma présentation. De belles images, peu de texte, j'essaie de mettre en pratique les éléments énoncés pour améliorer sa com. Le format de 30mn me permet de faire plusieurs répétitions. Je suis archi rodée. Verdict : au moins 15 feuilles de feedbacks, un record pour moi. Pendant que je cherche une salle, une personne m'interrompt et m'expose son souci avec son boss, avec qui il n'arrive pas du tout à communiquer. Normal, il a un profil opposé. Je n'ai pas de réponse mais lui donne quelques pointeurs.

Mixit 2014

Cette année, c'était différent. Déjà, le lieu : c'était à Mixit Lyon. J'ai proposé un retour d'expérience simplement parce que je trouvais qu'il n'y en a pas assez d'une part, et d'autre part j'avais envie de prendre un peu de recul sur notre propre situation. Je n'avais aucun message à faire passer. Pire : au moment de soumettre la session, je n'avais aucune idée d'où on en serait le jour J, si l'expérience serait un succès ou non. De fait, trouver un fil rouge a été plus compliqué à trouver.

J'ai fait mon truc devant un public que je n'avais jamais vu, après une journée de confs exceptionnelles. Je me demandais un peu ce que je faisais là mais il était trop tard pour reculer. A la fin, quelques questions. Deux personnes sont venues me voir. Une fois seule, j'ai regardé ma table et me suis sentie un peu bête. Aucune feuille de feedbacks : on n'est pas à Agile France ! A la place, sur le mur :

Ce type de feedbacks ne m'aident pas a améliorer mes prez :-(

I'm not a serial speaker, I need words !

Je propose des sessions pour plusieurs raisons

cela me force à travailler les sujets encore un peu plus en profondeur, tout en apprenant a être synthétique
cela me donne du recul sur ma propre situation. Je vois des choses que je n'aurais pas vu autrement.
cela peut générer des aha à d'autres personnes
je rencontre des personnes qui ont les mêmes centres d'intérêts que moi et aies des supers échanges avec eux
cela me permet de travailler ma prise de parole en public
participer à des confs gratuitement / découvrir d'autres confs
c'est fun

Donc s'il vous plait, Madame, Monsieur, un p'tit feedback serait le bienvenu en commentaire : 1. ce que vous avez apprécié, 2. ce qu'il aurait fallu faire pour que ce soit mieux.

C'est réellement mon unique axe d'amélioration pour mixit, et encore. Le reste a été tellement bien ! Merci aux orgas, speakers et participants.

Les slides de la prez sont dispos ici sur slideshare.

REX Le kanban va-t-il fluidifier notre chaîne ? from Fou Cha

Aller plus vite

Florence Chabanois — Wed, 04 Dec 2013 21:52:00 +0000

Je n'aime pas me presser au moment de partir de chez moi. Quand je le fais, je dois souvent revenir quelques minutes plus tard parce que j'ai oublié quelque chose. Se dépêcher donne l'impression d'avancer, mais tout ce qu'il génère, c'est du rework. En développement logiciel, les reworks sont des corrections de bug.

L'inverse n'est pas garanti : ce n'est pas ce qu'on prend son temps que le résultat sera parfait.

Si on demande aux clients de l'IT quel est leur plus gros problème, la réponse fera partie de cette liste :

il y a trop de bugs
les délais de réalisation sont trop longs (souci le plus fréquent)

Mon job, c'est de faire que le produit livré ait une bonne qualité dans les délais impartis. Je ne veux pas en sacrifier un pour l'autre.

C'est leeeeeeeeent

Derrière le problème de délai, on va surtout penser plus ou moins consciemment que les développeurs sont trop lents (peu importe les raisons). Même si la rédaction des spécifications a pris trois fois plus de temps ou s'il a fallu un mois pour avoir la validation de toute la chaine de commande. Quelques exemples de cause courante :

"Si les specs étaient plus claires, nous n'aurions pas eu besoin de tout ré-écrire"
"Si le client avait pensé à tous les cas dès le départ, nous n'en serions pas là"
"Il y a trop de tests. Vu le peu de régression, autant les corriger directement en prod".
"Le binômage coute trop cher"
"Il y a trop de réunions"
"Le PO a priorisé des problèmes de production devant donc nous ne pouvons pas tout faire"
"Les développeurs ne font pas assez d'heures"
"La direction met trop de temps à valider les maquettes"
"La recette révèle souvent des régressions"
"L'exploitation n'était pas disponible quand nous avons eu besoin d'eux"

Ces causes disent en réalité une seule et même chose : "c'est pas moi, ce sont les autres". Avoir des délais courts nous permet de proposer des solutions aux plus près des besoins du marché. Ce n'est pas forcément au détriment de la qualité. Développer des bugs ne sert à rien et livrer des produits se basant sur des specs d'il y a un an non plus. Les usages changent vite.

Se focaliser sur l'une de ces causes peut améliorer le time to market... ou pas. Le tout est de ne pas pédaler dans le vide.

Visualiser le problème

Mes compères de barre verte ont publié un ebook gratuit "Petit Guide de Lean Management à l'usage des équipes agiles". Il est juste passionnant, je vous le recommande chaudement. Chaque cas pratique parle de "Visualiser le problème". Régis en parle à chaque Agile France et pourtant ce n'est pas encore complètement rentrer dans ma tête. En lisant le livre, j'ai eu une idée sur la visualisation du flux. Je vais y revenir un peu plus tard.

La première fois que j'ai entendu Antoine Contal au XPDays, il évoquait des barres qu'il ajoutait chaque jour sur les post-its en cours. J'avais trouvé cela marrant mais assez peu applicable, c'est un peu chaud pour les équipes ! Quatre ans plus tard, j'entends un coach de la société générale évoquer le même principe mais avec des points. Il appelle ça la varicelle. Cela m'a définitivement poussé à faire une expérience que je voulais faire depuis quelques semaines : logguer le cycle de vie chaque jour.

J'abandonne donc mon diagramme de flow cumulé excel pour un système plus old school. Chaque jour, j'ajoute un petit symbole sur les User Stories indiquant à quelle étape elle est. L'idée étant de visualiser le goulet d'étranglement et à fortiori ce qu'il serait le plus important à optimiser. Je pense que les attentes sont plus nombreuses que l'on pense et qu'éviter des allers retours nous ferait gagner du temps. Ce n'est qu'une intime conviction, à vérifier.

Cela fait environ presque deux mois que l'opération est appliquées sur les user stories mais aussi les imprévus. A chaque MEP, je loggue le cycle de vie de la user story dans un fichier excel, Je renseigne également le nombre de jours ouvrés entre la création d'une demande et sa priorisation. Voici les premiers retours :

toute l'équipe voit au standup depuis quand une story a été engagée. Cela permet de voir des problèmes potentiels.
il y a plus de retours de recette que je pensais
on voit tout de suite les stories qui trainent depuis plus d'une itération.
c'est surprenant de calculer les métriques en partant de ce qui est visible en prod. Vu de l'extérieur, il y a relativement peu de choses livrées au final pour l'utilisateur. Cela fait bizarre car nous sommes chaque jour 100% occupés à faire cela. L'écart est presque choquant.
je sais à peu près en combien de temps en moyenne un imprévu important va être traité. C'est encore trop variable pour une user story par contre. Cela nous permettra de donner des délais approximatifs aux clients.
entre le moment où un ticket est crée et où il est priorisé, il peut s'écouler plusieurs mois. C'est logique : 1. c'est plus facile de créer un ticket que de faire des specs+développer+recetter+mettre en prod. 2. il y a beaucoup plus de personnes pour créer les tickets que pour les traiter. 3. Ils n'ont pas tous la même importance et la même urgence. En conséquence, j'ai ventilé les tickets par catégorie afin de donner un peu de relief : ticket projet, ticket hot topic et ticket problème de production.

Lorsque j'aurais plus de données, je pourrai travailler efficacement sur notre lead time.

Je veux livrer ce billet maintenant. J'aurais pu le publier sur barre verte et du coup avoir une top qualité (chaque billet est relu par plusieurs personnes avant publication). Mais pour un billet qui parle de livrer vite, ce serait un comble. Je le relirai plus tard, ou pas. J'espère que toutes les phrases ont un sens. Bonne nuit !

Au secours, je vois des goulots d'etranglements partout

Florence Chabanois — Mon, 07 Oct 2013 21:49:00 +0100

Olivier a raconté de façon détaillé le jeu du Bottleneck Game. Pendant cet atelier, Pascal nous a prévenu : "c'est un jeu dangereux, vous allez voir des goulots d'étranglement partout. Il avait raison :

aller à une conf alors qu'on a déjà plein de données à absorber et plein d'axes d'améliorations que l'on ne prend pas le temps d'implémenter
continuer à faire des rétros alors que l'équipe n'arrive pas à réaliser les actions engagées
développer en urgence alors que l'exploit n'a pas de disponibilité pour livrer
rédiger des spécifications de nouvelles user stories alors les développeurs sont archi full
parler à quelqu'un qui n'est pas disponible pour écouter
livrer une application dont l'offre commerciale n'est pas définie
continuer de manger alors qu'on n'a plus faim
emprunter 10 livres à la bibliothèque alors qu'on a du mal à en lire deux

A la manière des formules à volonté, nous pouvons nous dire que "cela ne mange pas de pain", "au moins c'est fait".

Faux.

De cet atelier, je retiens que

cela ne sert à rien de tenter d'aller plus vite que le goulot d'étranglement. C'est même mal.
ce focus sur les réussites locales nuit au flux global. Faire un avion prend du papier. Écrire des spécifications prend du temps. Il y a des coûts de production pour ces objets gâchés. De plus, cela ne fait que mettre encore plus en péril la capacité de réalisation du goulot d'etranglement.
pour ces raisons, il ne faut pas se tromper en optimisant quelque chose qui n'est pas sur le chemin critique.
personne ne veut être le goulot d'étranglement. C'est stressant et démotivant de voir les tâches s'empiler encore et encore. C'est peut être pour cette raison qu'il est si tentant de se débarrasser d'une tâche en envoyant un mail plutôt qu'en allant voir les personnes.
pour débloquer le goulot d'étranglement, l'entraide directe est une solution de dernier recours. Avant d'en arriver là, le goulot lui même peut avoir des idées pour s'aider, mais il faut l'aider à lever la tête. Les autres services ont également des leviers : en amont, nous pouvons l'aider avec des users stories bien délimitées pour lui épargner des hésitations. En aval, partager avec le développeur le critère de succès lui donne les moyens de tester efficacement sa production et ainsi éviter les retours de recette. Je pense que le plus dur au quotidien est de dépasser le "on n'y peut rien" et de se rendre compte que le changement est possible quelque soit notre place dans l'équipe. On peut aussi sortir du cadre et tordre le système.
le feedback et la mesure sont des bons moyens d'obtenir un système équilibré

Merci donc à Pascal pour ce "vieux" jeu qui est toujours bien d'actualité !

Pourquoi votre projet va dans le mur

Florence Chabanois — Mon, 02 Sep 2013 21:31:00 +0100

70% des projets sortent en retard ou jamais. Les raisons sont nombreuses. Certaines, comme la difficulté d'estimer, sont difficiles à éliminer. Je voudrais parler de celles qui sont "faciles" à anticiper.

L'équipe n'était pas à 100% dessus
La spec a changé
Nous nous sommes mal compris
L'exploit n'a pas préparé les machines à temps
Les développeurs ont glandé
C'était mal codé
Le tech lead a eu une angine
Le designer était en congés

"L'équipe n'était pas à 100% dessus"

On vous avait promis que cette fois, juré, craché, vous seriez à 100% sur le projet. Même que la direction s'est mis d'accord et que c'est affiché dans une grande salle de réunion.

Le product owner a pris une marge de 20% car les estimations sont à la louche et préfère assurer ses arrières.

Cette fois, j'ai ouvert les yeux et aies épluché les stories passées. Ces "petites" demandes courantes que nous casons à droite à gauche représentent en réalité 55% de l'engagement de l'équipe, en moyenne sur les deux derniers mois. 45% sont consacrés au vrai projet priorisé. Viennent s'ajouter ensuite les imprévus "urgents" en cours d'itération. Ceux là représentent une journée de dev par semaine.

Pour avoir une date, il ne suffit donc pas d'additionner les points et de diviser par la vélocité de l'équipe. Regardez à quoi ressemblent vos itérations précédentes pour de vrai : quel est la part de projet, de bugs, de courants, d'imprévus ? La projection de la date doit tenir compte de ces chiffres.

Deuxièmement, un développeur me chuchote à l'oreille que c'est ennuyeux et démotivant de travailler plusieurs mois sur le même sujet. Que certaines tâches ne sont pas parallélisables, qu'elles ont un ordre, des dépendances et que cela ne sert à rien de mettre 100% de projet dans ces cas là. Tâtez donc le terrain pour moi s'il y a beaucoup de stories "non parallélisables". Le corollaire de cela veut aussi dire qu'il est tout à fait improductif de rajouter des personnes sur un projet en retard : au mieux, ils vont devoir attendre, au pire, ils vont prendre du temps à ceux qui avance pour leur formation.

"La spécification était incomplète"

"La spécification n'était pas claire / a changé" peut aussi être invoquée par quelques perfectionnistes. L'erreur est humaine et la personne qui rédige la spécification aussi. Avec le temps, elle peut avoir de nouvelles informations et changer d'avis. C'est pire de coller au "contrat" et d'aller au bout d'un projet qui ne servira juste à rien...

Le produt owner ne pense pas à tout, le développeur fait des bugs, le marketeur se trompe parfois de cible, bref il faut arrêter d'exiger des autres d'être irréprochables. C'est une très mauvaise habitude que j'ai aussi. Chercher la perfection, cela s'appelle juste être chiant.

La méthodologie agile est un excellent médicament : nous livrons un petit incrément (peut être imparfait), puis récoltons du feedback, puis ajustons en fonction. Ce cycle permet de taper plus juste. Si à la fin tout ne peut pas être livré, ce n'est pas grave. Premièrement parce que 80% de la valeur est construit avec 20% d'efforts. Deuxièmement, parce que ce qui aura été produit sera plus pertinent que le projet original fait à 100%.

"Nous nous sommes mal compris"

Voir "Le projet est en retard parce que la spécification était incomplète". En faisant tester le plus tôt possible, les malentendus sont limités. Mieux : faire relire les spécifications exécutables au product owner avant de développer. Lâchez aussi votre clavier pour discuter de vive voix de temps en temps avec "l'autre".

"L'exploit n'a pas préparé les machines à temps"

C'est le problème dont la solution est la plus simple : il faut poser à plat toutes les dépendances extérieures et les prévenir au plus tard au début du projet. Le SMIC consiste à leur envoyer un mail. Le luxe à faire un point avec eux en amont du projet.

"Les développeurs ont glandé"

Autrement appelé "le syndrôme de l'étudiant" : Nous trainons doucement au début et speedons comme des malades les derniers jours. Certaines personnes travaillent mieux sous le stress et aiment l'adrénaline à l'approche de la deadline. Il y a de la fierté à en avoir baver. Malheureusement, quand un souci apparait quand nous sommes déjà un peu justes, la date ne peut alors être que décalée.

Que l'on ait besoin de stress ou pas, il est difficile de se projeter sur un projet qui sort six mois plus tard. Nous nous rendons compte trop tard que nous sommes en retard. Nous avons besoin de voir des avancées. Livrer des incréments régulièrement n'est pas suffisant. Je pense important que ces lots aient du sens, qu'il y ait quelque chose à célébrer.

Plus un projet est gros, plus il y aura du retard dessus. Attention aux gros chiffrages. Ils reflètent surtout de l'inconnu et nous amènent tout droit vers un effet tunnel. Pour les éviter, je tente en général une de ces trois options :

les découper
créer un story de prototype intermédiaire
faire une timebox.

"C'était mal codé"

Les développeurs non plus ne peuvent pas penser à tout. Il y aura des bugs. Le tout est de réserver suffisamment de temps pour la recette et corriger les bugs avant la mise en production.

"Le tech lead a eu une angine"

L'estimation du projet doit être valable pour l'ensemble de l'équipe. Si une tâche est très facile pour Jeanne et compliqué pour Jean, se baser uniquement sur l'estimation positive de Jean est une grave erreur. S'il y a des dépendances internes (des spécialisations), il vaut mieux les aborder en début de projet tant que tout le monde est là.

Il y a aussi beaucoup plus de chances pour que des stories soient plus longues que prévues que l'inverse. Mieux vaut se prévoir une petite marge d'erreur sur les estimations si la deadline est dure.

Je répète néanmoins que la deadline ne doit pas être trop lointaine, c'est aussi démotivant (revoir la section "Les développeurs ont glandé") . Un copain me disait que dans sa banque, aucun projet ne dépassait 30 jours car, au delà, la date n'était jamais tenue.

"Un développeur est en vacances / Le designer est en congé"

C'est une variante évidente mais un homme avertie en vaut deux : ayez une idée des vacances des parties prenantes afin de les répercuter sur le projet et d'organiser le projet au mieux.

Conclusion

Je ne dis pas que ces solutions suffisent à limiter les retards. Mais sans en tenir compte, on est quasi certains de se planter. Vous pouvez aussi ne pas piloter le projet, masquer les retards dans de nouveaux lots ou les abandonner en plein envol pour "tenir la date".... Je précise également que l'on peut faire dire ce que l'on veut aux métriques. Pour cette raison, elles doivent être internes et évolutives.

Et vous, quelle est votre formule magique ?

5 astuces qui ont fait chuter ma procrastination

Florence Chabanois — Sun, 11 Aug 2013 20:35:00 +0100

La cible à abattre : la procrastination. Il s'agit de cette force invisible qui vous fait trainasser pendant la réalisation de vos tâches. Vous les peaufinez longuement pour au tout dernier moment speeder comme un malade.

Bien que largement pratiquée, la procrastination a plus d'inconvénients que d'avantages : beaucoup de tâches entamées mais non terminées, moins d'accomplissement et du bâclage sans parler du stress. Du côté des (faux) avantages : une adrénaline superficielle et le sentiment d'être un artiste/un incompris.

J'ai essayé les plannings sur plusieurs mois, le backlog, trello, excel, la feuille de papier, le tableau de post-its... J'ai enfin trouvé un mode d'organisation qui marche assez bien chez moi comme au travail.

1. Plan de la journée sur un bout de papier

Pendant le petit déjeuner, dans le métro ou à mon bureau, je note les tâches de la journée sur un bout de papier (pas un cahier, nous y reviendrons). Cette mise à plat évite de partir dans tous les sens, de commencer trois trucs et de ne rien terminer. Je barre les tâches réalisées au fur et à mesure de la journée.

Si en cours de journée, je réalise que j'ai oublié une tâche, je la note également. Si je me mets à faire des choses qui n'ont rien à voir, j'écris ces changements de programme tout en bas de la feuille.

Le format de la feuille est important : il doit être suffisamment petit pour imposer naturellement un WIP limit. L'éphéméride est pas mal car il permet de planifier un petit peu en reportant les surplus de tâches au lendemain quand je suis déjà trop staffée pour la journée. En effet, trop planifier est non seulement une perte de temps mais aussi assez décourageant.

Le plus gros atout de l'éphéméride est son historique. Je vois les tâches que je reporte de jour en jour. Un moment, je finis par trancher : soit je la supprime soit je la fais réellement.

Comme sur les projets agiles, au fil du temps, je finis par connaître ma véritable capacité. Auparavant, je sous-estimais la durée de la plupart de mes activités, il m'en restait toujours les trois quart. Je m'étonnais simplement de ne pas y arriver sans véritablement savoir pour quoi. Maintenant, il m'en reste une au maximum.

Quand je n'ai pas d’éphéméride, j'écris le plan sur un coin de papier brouillon que je jette le lendemain. Il vaut mieux cela qu'un cahier qui permettrait de mettre trop de tâches.

Les tâches sont suffisamment petites pour être totalement accomplies indépendamment les unes des autres. Par exemple, pour le linge, j'ai une tâche "plier les habits", une autre pour le "détachage+lavage" et encore une autre pour "étendre le linge". Cela me permet d'avoir un avancement plus vite que si j'avais un fourre-tout "lessive" qui a des contraintes (il faut que le linge soit complètement sec pour plier les vêtements, alors que je pourrais lancer la machine quand même). Oui, j'évite les grosses stories.

La journée est rythmée par la rature progressive de l'ensemble des tâches. Cela rappelle évidement les post-it à déplacer.

2. Éteindre l'ordinateur

Éteindre l'ordinateur. Vous pouvez remplacer "ordinateur" par l'objet qui vous distrait le plus, vers lequel vous revenez régulièrement sans vraiment vous en rendre compte. Si c'est trop dur, éloignez au moins l'objet de convoitise afin que vous ayez le temps d'hésiter. Si c'est Internet, fermez votre navigateur. Si c'est l'armoire à provision, fermez la porte de la cuisine. Si c'est votre téléphone portable, mettez le en mode avion. Le principe est que VOUS repreniez le contrôle plutôt que réagir à des stimuli extérieurs. Avant, je pensais avoir suffisamment de self control. Maintenant je sais qu'à chaud sur le moment, je suis bien moins résistante qu'à froid quand j'imagine la situation. Selon les expériences de Dan Ariely, il y a de grandes chances que vous soyez pareils...

Il fut un temps où l'ordinateur n'était allumé qu'une fois par jour pendant quinze minutes le temps de regarder ses emails. Je me rappelle même que c'était choquant de le laisser allumer toute la journée. Ce n'était pas une tâche de fond. Ce n'est pas si grave de ne pas pouvoir regarder tout de suite qui a composé cette musique déjà sur Wikipedia. Nous n'avons pas besoin d'avoir tout, tout de suite à notre disposition. Quand j'ai quelque chose à regarder sur l'ordinateur, je le note simplement pour plus tard sur mon éphéméride magique.

Maintenant, j'entends le silence. C'est une véritable libération.

Autre effet, quand je suis sur l'ordinateur, je suis dessus pour de vrai. Ce n'est pas en coup de vent. Je suis plus efficace et j'en profite plus.

3. Chronométrer le fun

Pire, quand je suis dessus, je me chronomètre avec timer-tab. Cela ramène de la réalité. J'ai l'impression d'avoir passer 5mn à écrire ce billet ? Nope : le chrono me dit que cela fait 1h15 que je suis dessus...

D'autre part, voire défiler le chronomètre me presse un peu et m'oblige à aller droit au but. Il doit y être pour quelque chose sur mon plus grand focus.

4. Juste 20 minutes

Le plus dur dans une corvée, c'est de commencer. Une fois que le processus est lancé, nous sommes bien dedans et voulons mener l'action jusqu'au bout. Cela revient à appliquer la méthode du pied dans la porte à soi-même.

Pour me mettre en mouvement, je ne m'engage que sur 20 minutes, toujours avec le chronomètre. C'est suffisamment peu pour se dire qu'on peut bien le faire. Au début, j'ai l'impression d'y avoir passé deux heures alors que cela fait cinq minutes, puis je ne regarde plus. Au final, je suis toujours allée bien au delà des vingt minutes.

Il peut évidemment y avoir des variantes sur des périodes encore plus courtes. Je passe "juste" cinq minutes à regarder ce bug casse-pied ou à rédiger une doc. Une fois dedans, j'ai juste envie de le résoudre car j'ai changé de perspective.

5. Action immédiate

Quand une action me prend moins de deux minutes, je la fais tout de suite. Si je suis en train de me poser la question, je me dis stop, je fais. Cela évite d'avoir à y repenser plus tard et à me remettre dedans. Surtout, ces micro-actions donnent un sentiment de DONE assez appréciables. Typiquement : ranger un email, répondre à quelqu'un, ranger la boite de céréales, demander une info, etc.

Et vous comment faites-vous pour être efficace ?

Kobo glo

Florence Chabanois — Wed, 17 Jul 2013 10:55:00 +0200

Je voulais une liseuse numérique quand j'étais encore en master. C'était encore une rumeur et on avait du mal à croire que cela allait exister. Comme j'aimais aussi tourné les pages et que je ne lis pas tant que cela non plus, je n'ai sauté le pas qu'il y a un an. L'effet fun et techno a eu le temps de s'estomper mais j'aime toujours énormément mon kobo ! C'est même un de mes meilleurs achats.

Une liseuse est-elle rentable ? Kobo ou Kindle ? Ca marche avec Linux ? Comment vont les yeux ? Quels sont les bonnes surprises ? Les inconvénients ? Voici mon retour d'expérience.

Pourquoi une liseuse ?

J'ai beaucoup de PDF que je ne lis pas car la lecture à l'écran fatigue vite avec le rétroéclairage : sur GIT, le feedback, le référencement naturel et j'en passe.

Sur Internet, il y a de plus en plus d'écrivains improvisés et les ebooks de moins de 100 pages ont fleuri comme des champignons. Ils sont de bonne qualité et souvent gratuits.

Vous pouvez trouver honteux de payer presqu'autant un livre papier qu'un livre numérique. Si pour vous le prix se définit plus par l'effort de production que la valeur reçue alors vous avez raison. Vous trouverez aussi justifié de payer 1 million d'euro un stagiaire pour fabriquer votre maison vu qu'il y aura passer vingt années plutôt qu'un architecte qui n'y aura passer qu'un mois. La compétence a un prix et il n'est pas toujours (voire inversement) proportionnel au temps de production. Quand on achète un livre, le papier et le transport sont des détails. C'est le contenu que vous voulez payer.

Avec une liseuse, je gagne du temps : je n'ai plus besoin de me torturer pour savoir quel livre je vais emmener dans le métro. Je gagne aussi beaucoup d'espace chez moi. Au prix du mètre carré en Ile-de-France, ce n'est pas rien!

N'achetez pas de liseuse si...

vous pensez obtenir des livres moins chers
vous aimez tourner les pages et les sentir défiler sous vos doigts. Que c'est indispensable pour prendre du plaisir à lire.
vous aimez parcourir rapidement des livres en diagonale et ne faites finalement que cela.
vous avez de la place chez vous et aimez avoir une jolie bibliothèque avec une belle collection d'ouvrages

Kobo ou Kindle ?

J'achète la majorité de mes livres sur Amazon donc j'étais plus naturellement porté vers le Kindle d'Amazon, en particulier le paperwhite. J'aime les contrastes élevés. Mes besoins étaient les suivants :

autonomie de l'appareil.
contraste
lumière pour lire la nuit, mais "non fatigante" pour les yeux (autrement j'aurais pris une tablette)
variété des formats d'ebooks supportés
compatible Linux
liberté (ne pas dépendre d'un logiciel de transfert propriétaire à la itunes)

Trois facteurs m'ont définitivement fait basculer vers le Kobo Glo :

sur la façon d'acheter des livres : avec le Kindle, visiblement on achète le livre et il est envoyé sur la liseuse en Wifi. Nous n'avons pas de Wifi chez nous. Les livres achetés sont stockés sur le cloud d'Amazon. Cela pourrait doit être pratique pour les gens super connectés. Par pour moi, j'aime bien avoir le fichier physique et pouvoir le transférer entre différents systèmes d'exploitation à coup de copier coller sur une clef USB. Surtout que l'ordinateur de la maison est sur Linux Gentoo.
le kobo supporte le format epub, format ebook "officiel" et ouvert qu'Amazon a préféré snober. Ce frein reste surmontable dans la mesure où le logiciel Calibre permet la conversion.
il y avait trois mois d'attente pour le kindle paperwhite.

Amazon proposait aussi une liseuse avec 3G illimitée inclus qui aurait pu être intéressante si elle n'était pas limitée aux téléchargements des ebooks...

Kobo Glo

J'ai adoré

le confort de la liseuse pour les yeux, que du bonheur. Je peux agrandir la taille de police, le retour à la ligne se fait automatiquement si le format est en EPUB. Plus besoin de naviguer sur la page dans tous les sens.
l'autonomie. Je n'ai jamais eu à le charger exprès. Je me contente de le laisser connecté un peu plus longtemps quand je rajoute des livres une fois tous les deux mois.
le produit léger et beau
ne plus avoir à faire de choix cornélien en emportant à chaque fois une dizaine de livres avec moi en déplacement
les statistiques d'avancement sur le livre. Le Kobo vous dit au fur et à mesure à quel pourcentage j'en suis de ma lecture. Cela m'a incité à finir plus de livres que d'habitude.
la centralisation de mes livres. Avant j'avais un livre que j'emmenais au boulot, un autre que je lisais au petit dej, encore un autre avant de dormir. Ils étaient partout ! Du coup, j'avais tendance à ne pas les lire en entier en les laissant au travail par exemple.
les annotations : fini les post-its découpés qui se décollent ! Vous avez la possibilité de surligner des passages ou de leur accoler des notes.
l'affichage de la couverture du livre en mode "éteint". C'est presqu'un vrai livre finalement !
tourner les pages. Une seule main est nécessaire pour lire un ebook. Il suffit de toucher (et non slider) la partie droite de l'écran pour tourner la page. C'est vraiment pratique quand on a un bébé qui occupe souvent l'autre bras.
lire la nuit discrètement avec la lumière intégrée.
le rangement par étagères permet de mettre un peu d'ordre dans les livres, ainsi qu'un tri par date. Il y a aussi des favoris.
opérationnel sur linux en deux temps trois mouvements.

C'eut été bien de

permettre de facilement bookmarker plusieurs pages, typiquement quand nous sommes plusieurs à lire le même livre, ou que quelqu'un veut juste le feuilleter. Actuellement, le livre s'ouvre à la dernière page lue.
pouvoir remettre un livre en "non lu", après un feuilletage rapide par exemple. Je ne peux que manuellement retourner à la première page et obtiens "1% lu" dans ce cas là. Mais non je l'ai pas lu !
encore améliorer la rapidité de défilement des pages. C'est largement suffisant pour lire normalement mais pour feuilleter, la réactivité quand on tourne une page est encore trop juste.
d'accélerer le temps d'allumage du kobo glo. Il est un peu long par rapport aux normes d'aujourd'hui. De plus, le temps de réaction pour ouvrir un livre est un petit peu lent quand le kobo vient d'être allumé.
au format EPUB, les images ne sont pas zoomables. Du coup je n'ai pas pu lire certaines illustrations sur un de mes livres.
au format PDF, tourner une page peut être compliqué... Surtout quand la police 100% est trop petite pour nous et que l'on a zoomé. Il faut slider jusqu'à arriver tout à droite de l'écran puis appuyer sur une bande noire. A la longue, c'est contraignant. Du coup, je ne lis pas les PDF dont la police d'origine est un peu juste sur le kobo glo. J'ai bien tenté de convertir quelques PDF en EPUB mais c'est une catastrophe : tout est décalé, les lignes sont interverties bref, à éviter.

Ne (me) sert à rien

le navigateur web car le clavier numérique n'est pas assez au point
l'outil croquis. Il répond mal. A leur décharge, c'est en version béta je crois.
le format bande dessinée supporté

Jamais testé

le dictionnaire
la traduction

Ces deux fonctionnalités sont accessibles avec le menu des annotations. Elles semblent assez fournies. Il y a un bon paragraphe de définition pour un mot donné.

Pour finir, j'utilise Calibre pour transférer les livres avec Linux. Calibre permet de convertir, faire des bibliothèques, récupérer des jacquettes, donner des notes aux livres. Ces données ne sont pas synchronisés avec le kobo. Sur linux, je ne peux pas non plus transférer des ebooks contenant des DRM (c'est logique me direz-vous). Sur mon windows, je me contente de copier coller sur le media externe.

Même si le Kobo Glo n'est pas parfait, il est allé au delà de mes espérances sur bien des aspects, c'est une très bonne surprise. J'en suis vraiment contente et je lis plus qu'avant. Vous pouvez le trouver à la Fnac pour 130 €.

Agile Innovation Printemps 2013

Florence Chabanois — Thu, 13 Jun 2013 18:37:00 +0200

Cette année, j'ai quitté la grisaille de Paris pour tenter de retrouver le soleil. Il s'était planqué à Valence pour Agile Innovation Printemps.

C'est sous la forme d'un forum ouvert que des praticiens agiles de Valence, Grenoble, Lyon, Montpellier et Paris se sont mutuellement enrichis. Vingt-cinq personnes, un nombre parfait pour nouer des liens de qualité et creuser suffisamment les sujets des participants.

J'ai apprécié

l'organisation irréprochable
la variété des profils des participants (enseignement, hors agiles, entrepreneur, développeur JS/Java, scrummaster, coachs)
la qualité des discussions
le cadre rustique
la qualité du repas (ben oui)

Leçons re(apprises)

l'agilité créé des silos
les vis mon job sont appréciés
commencer par un story mapping sur chaque projet donne une vision globale et aligne les différents acteurs dessus. Par contre, le backlog flat est plus pratique pour gérer les stories au quotidien.
les règles doivent être claires pour tous en début de réunion mais elles peuvent aussi apparaitre au milieu : "pas de téléphone, est ce que tu es ok avec cvela ?"
la posture de l'animateur de réunion peut changer l'implication des participants : debout face aux autres, en cercle, stylos au milieu de la table.
le keep drop start fait appel au côté rationnel des gens, le mad sad glad à leurs émotions
chacun a un masque, un crapeau et un prince en lui. Si on est crapaud, c'est le crapaud de l'autre qui répondra. Merci JF.
une très bonne idée de startup peut s'avérer plutôt mauvaise une fois confronté aux autres (=aux votes des autres). Ou l'inverse !
faire un pitch lean start up en quelques mots est "facile", c'est plus compliqué d'aller voir "tous" les investisseurs pour défendre son projet. On se lasse vite...
c'est différent d'échanger avec une majorité d'internes (par rapport à des coachs). Moins de "y a qu'à", "faut qu'on" et d'ayatolla. No offense les coachs, j'aime juste la mixité.
les habitants de Valence s'appellent des Valentinois

J'ai été intriguée

que certaines entreprises invitent leurs clients mécontents à venir voir comment ils travaillent. Pour qu'ils comprennent leurs contraintes et leurs choix.
par le système de carton rouge que chaque participant de réunion peut lever quand une "règle" est enfreinte (plusieurs personnes parlent en même temps, prime directive violée, etc.)
par le principe de scotch à lancer sur celui qui parle trop. Apparemment, les gens s'auto-régulent bien du coup.
"interdire tout réunion hors cérémonie agile incite a plus respecter celles qui restent et les rend plus efficaces."
pas mal d'enseignants à cette édition
souvent les mêmes têtes aux sessions que j'ai choisi. Nous devions avoir les mêmes goûts.

J'ai été baffée

quelqu'un a déjà fait "fonctionner" des journées innovations ! J'avais eu la même idée mais ne l'ai pas porté jusqu'au bout. Concrètement, il s'agit d'adresser des problématiques avec livrable en moins d'une journée avec les différents métiers. La personne qui l'a fait fonctionné a engagé l'ensemble de la société et la participation était obligatoire (ce qui décomplexe les personnes pour laisser le courant en suspens). La journée innovation a eu lieu tous les mois pendant un an. Cela a aussi le mérite de faire travailler les gens sur les problématiques des autres.
pour tenir les délais, il faut ramener de la réalité au rêve, avec des KPI business. Quel est le coût du retard et les scénarios possibles ? Ne pas non plus oublié de voir l'ensemble (entreprise entière) comme un système.
visiblement je connais peu d'agilistes en province. De très jolies rencontres. A faire plus souvent.
trop sympa de boire un coup à la gare pour que je ne rate pas mon train !
j'écris vraiment très mal. C'est frappant quand on voit toutes les restitutions côte à côte.

C'aurait été parfait si

il y avait eu plus de mobilité entre les sessions encours.
nous nous étions resynchronisés une ou deux fois au cours de la journée pour adapter le "backlog" des sessions
j'avais enfin pu tester le jeu de la crevasse.

Merci donc au CARA et à tous les participants !

Le prochain Agile Innovation aura lieu à Grenoble en novembre.

Agile France 2013 - Mais pourquoi y m'écoute pas ?

Florence Chabanois — Fri, 17 May 2013 15:02:00 +0200

Une fois n'est pas coutume, la conférence Agile France aura lieu sous la pluie. Qu'à cela ne tienne, personne ne nous enlèvera les arbres et le lac du Chalet de la Porte Jaune. Comme chaque année, elle réunira des praticiens avancés du monde agile les 24 et 24 mai 2013. Je crois que le dernier jour pour s'inscrire est aujourd'hui !

J'aurai le plaisir d'écouter Pascal Van Cauwenberghe, Nathaniel Richand, Régis Médina, Ellène Dijoux, Pierre Pezziardi, Antoine Contal, Laurent Bossavit, Olivier Soudieu, Myriam Roux, Guillaume Duquesnay... ou pas. Je préfèrerai peut-être tirer des apprentissages du groupe en participant à des ateliers, ou échanger avec mes pairs dans la salle communautaire. Dans tous les cas, ce sera FUN !

J'y présenterai la session "Mais pourquoi y m'écoute pas ?" :

"Les individus et leurs interactions", "La collaboration avec les clients"... Sur le papier, le manifeste agile est beau. Dans la vraie vie : votre chef a poliment acquiescé devant votre value stream mapping mais rien n'a été fait pour réduire les goulots d'étranglement; vous avez proposé de mettre les noms des binômes sur les tâches du tableau mais vous êtes le seul développeur à le faire; le product owner n'a toujours pas priorisé votre idée révolutionnaire pour lever plus d'inscriptions (l'a-t-il lu d'ailleurs ?). Bref, "personne" ne vous écoute.

[Spoiler alert] Si vous souhaitez vous faire entendre plus souvent, il va falloir commencer par améliorer votre propre écoute. [Fin du spoiler]

Je vous propose de vous donner quelques pistes pour écouter efficacement et baillonner votre "Moi-je". Nous aborderons également certains aspects du modèle DISC pour comprendre pourquoi nous n'entendons pas tous de la même façon et verrons comment y remédier.

Cette session s'adresse à toute personne souhaitant mieux travailler en équipe, à tous les niveaux.

Si vous avez 1m50, je me suis aussi lancée dans la vidéo, c'est une première ! ("si vous avez peur de quelque chose, go harder on it") :

Les slides sont disponibles sur Slideshare :

Session : abaisser les barrieres en 5 points

Florence Chabanois — Mon, 08 Apr 2013 21:51:00 +0200

J'ai présenté la session "Abaisser les barrières" à l'Agile France en 2012.

Les obstacles se suivent et ne ressemblent pas. Pourtant, qu'ils soient techniques, organisationnels ou structurels, chaque solution à ces problèmes dépend des hommes et femmes qui l'actionneront. De la même façon, la meilleure idée du monde ne verra jamais le jour si les équipes n'arrivent pas à travailler ensemble.

L'humain est au centre plus que jamais. Je vous raconterai comment la confiance ne se décrète pas, ainsi que les pistes suivies pour que développeurs, marketing, production, product owners, scrum masters et direction évoluent dans un climat de collaboration plutôt que de défiance. Nous parlerons de one on one, d'ateliers, d'objectif commun, de confiance, de communautés de pratiques, de fun, d'humilité.

Loin d'être des solutions toutes faites, il s'agit plutôt de réflexions et de tentatives (plus ou moins réussies) pour que les équipes travaillent ensemble sur l'essentiel.

1. Créer des connexions

Plus il y a d'intermédiaires, plus il y a de difficultés à avoir un time to market court entre une idée et sa réalisation. Multiplier des connexions secondaires en parallèle de connexions "officielles" permet d'augmenter sa fluidité : s'adressez toujours à la même personne est un smell.

Quand l'intermédiaire commence à faire uniquement du passe plat, il est en temps de passer outre. Typiquement, le product owner est pertinent au moment de la priorisation d'une demande; par la suite quand le véritable client est un webanalyste, il vaut mieux que les développeurs traitent directement avec ce dernier.

Un autre exemple est le manager qui veut être au centre de tout, mais humainement, ne peut juste pas. Fatalement, les sujets en attente de réponse s'empilent car les membres de l'équipe n'ont pas la "légitimité" pour répondre / ont peur de se tromper / n'ont pas envie de bosser pour rien.

Multiplier les connexions entre services permet de tracer des passages pour les messages. Une fois établis, un minimum de confiance doit se mettre en place pour que des choses puissent y circuler.

2. Fluidifier avec de la confiance

Un bon moyen de gagner la confiance des autres consiste déjà à la donner. Jusqu'ici, je ne l'ai encore jamais regretté.

Rester humain me parait également important : je fais aussi des erreurs et m'excuse quand cela arrive.

A côté des erreurs, les frictions sont aussi nécessaires. Je ne peux pas faire confiance à quelqu'un qui est toujours d'accord avec moi. C'est louche. On peut également monter une équipe de Zorros qui pense uniformément et qui dépote. Le souci, c'est qu'elle sera démunie quand une autre compétence sera requise (de la rigueur sur des stories d'architecture par exemple).

Quelque que soit notre position dans l'entreprise, les feedback positifs et négatifs permettent d'équilibrer le système. Donnez en à vos subalternes mais aussi à vos collèges et à votre manager. Ils seront peut être surpris au début mais apprécieront les deux tant que vous y mettez la forme.

3. Alignez vous sur votre but

Pourquoi travaillez-vous ? Qu'est ce qui vous rend fier de travailler sur votre projet ?

Nous travaillons pour gagner notre vie. Mais l'entreprise existe pour une raison, elle génère du cash (ou pas) pour satisfaire une demande un besoin. Autrement, elle n'existerait pas et vous travailleriez ailleurs. J'ai travaillé pour que des propriétaires arrivent à gérer leurs travaux d'immeuble, j'ai travaillé pour que des gens puisse mieux voir, j'ai travaillé pour que des entreprises puissent s'enrichir, j'ai travaillé pour que des personnes trouvent du boulot. Et vous ?

Les équipes passent plus tellement plus de temps à diverger et pinailler sur des détails, au point d'oublier qu'on a forcément un but en commun : que notre projet marche. Que les utilisateurs soient contents. S'il y a des frictions, c'est bien que l'on s'en soucie. C'est quelque chose que l'on oublie bien trop vite et qu'il faut régulièrement rappeler.

4. C'est pas lui, c'est son poste (et le vôtre)

Sur le plan professionnel, Jean a vraiment un problème avec Laura. Elle vient toujours l'interrompre pour des sujets sans importance et ne lui dit même pas Bonjour le reste du temps.

De son côté, Laura travaille avec 5 interlocuteurs différents qui lui disent tous qu'ils ont mieux à faire que traiter ses sujets. Pourtant, ce sont des utilisateurs qui sont pénalisés. Elle court partout pour essayer de trouver son sauveur et c'est vrai, omet parfois de saluer dans la précipitation. Cette personne, en fait, c'est parfois vous.

Dans une autre vie, ils se seraient entendus comme cochons et auraient 4 enfants. J'exagère à peine. C'est parce qu'elle travaille au support et vous au développement que vous avez "du mal". C'est la même chose avec ce super collègue que vous ne pouvez plus voir depuis qu'il est manager. Il s'agit pourtant de la même personne.

Les développeurs ont du mal avec les opérationnels, les intégrateurs avec le marketing, le marketing avec les commerciaux, les commerciaux avec les clients (et l'inverse)... c'est cliché, non ? Comment cela se fait-il au sein d'un même groupe, il y ait moins de tension ? SImple : on réfléchit ensemble à des solutions. On se comprend. On ne nous demande pas d'assurer des urgences.

La distance crée la méfiance et attise la rancoeur. Dur d'apprécier la demande de celui qui nous parle une fois par an pour son bug top prioritaire.

Si vous vous êtes juste parlés quelques fois avant, pendant une pause midi, la demande passe mieux. Bizarre. Trop bête que vous ne travailliez pas au même étage. Pour cette raison, il me semble important de multiplier les opportunités de rencontre, de brassage des équipes. Cela permet aussi de mieux comprendre le besoin de l'autre et de trouver des solutions plus adaptées.

5. Surveillez la barrière : elle repousse toute seule !

La barrière est pleine de mauvaise herbe. Elle pousse encore et encore. Si vous n'entretenez pas sa coupe, elle deviendra si haute que vous ne verrez plus l'autre, vous commencerez à imaginer les pires intentions / négligences derrière chaque action / non action de sa part.

C'est le moment d'organiser un apéro. Nourrissez la relation. Brassez-vous avec les autres.

Certains détestent les réunions parce qu'ils ne produisent pas pendant ces moments là. C'est vrai qu'il ne faut pas qu'il y en ait trop. Je suis néanmoins choquée lorsque j'entends le discours de Jason Fried à ce sujet. Si un jour, je ne communique plus que par mail, je saurai que c'est la fin.

J'aime produire mais j'aime aussi les relations, c'est ce qui permet de progresser en tant qu'individu et d'avoir un projet performant. Si on ne voit jamais l'autre, je pense sincèrement que l'on finit fatalement par au mieux s'ignorer. Ce qui revient aussi à travailler les uns contre les autres en privilégiant son objectif local.

Exemples d'outils

Voici quelques exemples d'actions permettant d'abaisser les barrières.

A l'échelle d'une équipe

Rétrospectives
One on One
Workshop
Brainstorming
Déjeuner d'équipe
Recrutement
Binômage

A l'échelle d'un métier

Communauté de pratiques
Projets communs
Recrutement
Retour d'expériences (technique ou fonctionnel)

A l'échelle d'un projet

Rétrospectives mixtes
Binômages transverses
Portfolio
Poules aux standup
Guests aux réunions
Demandes d'aides
Brainstorming
Aller voir / gemba walk

A l'échelle d'une entreprise

Atelier de zoning
Retour d'expérience d'un métier : une personne du référencement intervient à une réunion d'équipe pour nous parler de son job
Vis mon job : pendant une demi journée, nous avons la possibilité de vivre un autre métier, une fois par an. Accueillir quelqu'un est aussi assez sympa pour avoir un autre point de vue.
Brainstorming
Prototype / tests utilisateurs (qui aligne sur un but commun, factuel)
Design studio
Pilotage par la mesure (qui aligne sur un but commun, factuel)

Et vous, quelles sont vos barrières et quelles sont leurs conséquences ? Que faites-vous pour travailler ensemble ?

Af2012 abaisser les_barrieres from Fou Cha

Un rapport de tests clair avec Test in Progress

Florence Chabanois — Mon, 04 Mar 2013 12:43:00 +0100

Quand les tests ne passent plus sur l'intégration continue, le(s) coupable(s) ne saute pas tout de suite aux yeux.

Il n'y a pas non plus d'indication sur la durée d'un test et vous ne savez pas s'ils sont bientôt terminés.

Le tout nouveau plugin Test in progress pour Jenkins vous assiste sur ces aspects.

Mon risotto est enfin agile... et bon

Florence Chabanois — Mon, 25 Feb 2013 23:32:00 +0100

Quelque chose d'incroyable est arrivé hier : j'ai réussi un risotto. C'est peut être un détail pour vous mais pour moi ça veut dire beaucoup.

Qu'est ce qu'il s'est passé ? J'ai récolté du feedback plus tôt, tout le long de la cuisson. Tout simplement en goûtant. Ce geste super simple m'a évité le trop salé, le riz pas assez cuit, la sauce écœurante. D'autres éléments m'ont aidé mais s'il faut retenir une seule chose, c'est bien ce feedback.

Feedbackez

Quand je suis une recette de cuisine, je goûte rarement les plats. L'auteur sait ce qu'il dit non ? Je ne veux pas me gâcher la surprise, je veux découvrir l'explosion de saveur au moment d'être à table avec mes pairs. C'est sûrement aussi ce que se disent les créateurs de logiciels qui ne font pas de version béta ou de tests utilisateurs. Ou ceux qui veulent foncer tout seul sans consulter personne, de peur de devoir changer d'avis. Ou les développeurs qui sont trop bons pour faire des tests automatiques. Le hic, c'est qu'à la fin, il arrive plus souvent que ça ne marche pas et ce n'est finalement pas si étonnant. Si vous avez besoin de prier, c'est que vous n'avez pas eu assez de feedbacks tout le long.

Partagez votre histoire et celle du produit

Comment se fait-il que, même avec la meilleure volonté du monde, on puisse rater une recette ? Sisi ça vous est déjà arrivé. M'enfin c'est écrit noir sur blanc. Facile : ce que je pense être des détails ne l'est pas toujours, je pensais que le plat pouvait se garder au frigo avant d'être servi eh bien non, j'ai raté la ligne qui mentionnait le sel, je n'avais pas tout ce qu'il fallait dans mon frigo alors j'ai pris des libertés là où il ne fallait vraiment pas... En cuisine comme dans l'IT, le cahier des charges parfait n'existe juste pas. Suivre aveuglément les spécifications ne marche pas. Il faut un minimum savoir ce que l'on fait.

Pour cette raison, j'aime bien les recettes qui expliquent dans un encart pourquoi il faut plonger les feuilles d'épinards dans de l'eau froide par exemple. Donnez du relief aux spécifications : lesquelles vont égarer l'utilisateur si elles ne sont pas réalisées ? Expliquer le pourquoi et ce qu'on peut perdre autrement permet de réaliser que l'on travaille dans un système plus grand que nous. Si la page ne propose plus que deux inputs, c'est parce que les tests ont révélé qu'au delà, l'utilisateur était distrait. La pub rapport 30% du chiffre d'affaires alors il faut quand même lui faire de la place. Il n'y a pas de demandes idiotes. Elles ont toutes une raison.

Faites simple

Exit les recettes compliquées avec 50 ingrédients dont 3 que je ne connais même pas. Dehors les recettes qui nécessitent un robot et 3 outils bizarres. Adieu les recettes qui prennent plus d'une heure de préparation (surtout que je le dépasse tout le temps...). Poubelle les plats avec une forme bizarre dont chaque étage d'aliments nécessite une cuisson différente.

Dans mon risotto, je me suis retenue de mettre quinze épices et cinq types de fromage. Juste du sel, du poivre, du parmesan et de la crème.

En logiciel comme en cuisine, faites simple. Il n'y a pas de honte à faire simple, c'est très compliqué, il faut s'y prendre à plusieurs fois.

Faire simple vous épargnera des déceptions. Déjà, votre produit sera utilisé.

Si par miracle, le produit final ressemble à l'attendu, les gens ne sont pas prêts. C'est trop subtil, c'est un peu sucré mais pas vraiment, et qu'est ce que c'est que ce goût là, bref le consommateur n'y comprend rien. Or votre boulot consiste à lui faciliter la vie.

Montrez une photo de la destination

Enfin, je n'essaie pas de réaliser des recettes sans photo. Si en plus, la recette dépasse une page, je ne la regarde même pas. Un ensemble d'instructions n'est juste pas sexy et j'ai besoin d'avoir en tête la cible, ce vers quoi je veux aller. Cette image m'accompagne tout le long de la réalisation, me motive et me permet d'arbitrer quand il y a des choix à faire.

Dans le développement d'un logiciel, montrez un planning plus global avec des wireframes du produit final aux parties prenantes : développeurs voire même exploitants. Donnez une vision. Affichez la. Une accumulation de user stories toutes belles ne suffit pas et on s'y perd. Personne n'aime marcher les yeux bandés, même si on sait marcher, même si on nous tient la main. C'est une véritable motivation de savoir à quoi l'on contribue.

Acceptez de faire des ratés, à couts encadrés

Il y a quand même un cas où je suis prête à tenter une recette sans vision : quand elle est rapide à lire et à réaliser. Je ne sais pas très bien où je vais, mais si c'est raté, je n'aurai pas perdu grand chose. Je me serais juste amuser à tester une recette. Par contre, vu son coût, si elle est bonne, c'est le jackpot. Tant que le coût est encadré et que l'on est prêt à perdre, il devient tout à fait acceptable de faire des prototypes ou des mini produits. A défaut d'un produit, nous aurons gagné des leçons. Et apprendre, c'est fun.

Bref, je sais maintenant pourquoi je réussis mieux mes plats improvisés que les recettes suivies "à la lettre".

Des wikis tout frais

Florence Chabanois — Wed, 20 Feb 2013 17:14:00 +0100

Deux wikis viennent de naitre en 2013 : sur le coach retreat et sur les jeux agiles.

Coach retreat

Wiki : Coach Retreat

Le principe est de passer la journée à se coacher sur les mêmes situations encore et encore, mais de façon différente. Animée par Oana Juncu et Yves Hanoulle, la session de l'année dernière était simplement passionnante. Sat Philora a fait un résumé sur son blog. Le wiki manquait cruellement car après avoir fait les exercices, j'aurais aimé avoir une endroit où les retrouver. Je n'ai plus d'excuses désormais :-).

Agile Game France.

Wiki : Agile Games France

L'initiative est encore plus jeune. Par exemple, il n'y a pas encore de nom de domaine réservé. Le principe est de centraliser les comptes rendus et de référencer les jeux testés à chaque saison. Tasty cupcakes propose énormément de jeux et nous pouvons vite être inondé par tant de choix. J'espère que l'on arrivera à trouver un moyen de donner du relief aux jeux les plus populaires.

Au passage, j'ai du désactiver mon wiki personnel sur ce site car il utilisait un système de fichiers. Free interdit cette pratique depuis peu. J'ai donc commencé à migrer les données sur google site.

J'aime bien les wikis car ils mettent un peu d'ordre aux informations éparpillées. Ils favorisent la collaboration plutôt que la juxtaposition de travaux individuels. Leur création est facile, c'est leur entretien qui est compliqué par la suite.

Les deux wikis sont ouverts aux inscriptions, n'hésitez donc pas à aider ces wikis à devenir matures en contribuant.

Listes de diffusion

coachretreat@googlegroups.com
agiles-games-france@googlegroups.com

Un tableau brulant

Florence Chabanois — Tue, 22 Jan 2013 14:55:00 +0100

Un scrum master de mon entreprise a commandé des magnets personnalisés super fun pour rendre les risques et les urgences encore plus visibles.

Je trouve le principe des aimants mieux que des bouts de post-its découpés, qui finissent par se fondre dans la masse des post-its. J'en profiterai pour vous parler d'autres bombes utilisées sur nos murs.

Concrètement :

Bombe nucléaire = ça va nous exploser à la figure un jour et ça va faire mal
Pompier = ça a explosé, à réparer sans trainer

Il a vu l'idée dans Lean from the trenches. C'est tout nouveau donc je n'ai pas encore de feedback sur son système. Mais j'ai hâte de voir !

Des bombes pour la gestion des problèmes

J'utilise aussi le principe de bombe pour des sujets plus moyen-long terme, également sur le tableau.

Concernant la gestion des problèmes de fond, une feuille A5 avec une bombe nucléaire [1] est affichée pour chaque sujet qui risque de nous exploser à la figure. A chaque fois qu'on a un incident à ce sujet, je rajoute un petit post-it avec le numéro du ticket dessus.

Quand la feuille commence a être pleine, il devient vraiment urgent d'arrêter de juste contourner l'incident pour passer à la résolution de fond. Par exemple, pour un traitement qui plante parce que l'export dure un peu plus longtemps, un contournement consiste à augmenter le timeout. Rapide, pas cher, pertinent car il faut rétablir le service le plus vite possible. Quand c'est "résolu", ni l'équipe ni la direction n'a vraiment envie de revenir sur le sujet.

Le problème est qu'à force de faire des patchs à l'arrache sans changer les mécaniques (trop cher!), on fini par payer le prix fort. C'est dur de mettre la nouvelle fonctionnalité qui déchire en standby "juste" pour remplacer le logiciel en C que personne ne peut maintenir. Après tout, "ça marche là".

Typiquement, les bombes de chez nous concernent les dettes techniques sur l'architecture, en général des briques transverses, donc difficile à faire évoluer car impliquant plusieurs équipes.

Et pour les demandes insistantes de l'équipe

Les bombes me permettent aussi de noter certaines demandes des équipes pour monter des dossiers auprès de ma direction, comme des besoins en recrutement sur des outils particuliers.

L'autre avantage est de sortir du ressenti "je dis qu'on a besoin de ça depuis 2 ans et tout le monde s'en fout" dans la mesure où l'on note des conséquences concrètes de ces manques. Nous partons sur des impacts négatifs concrets, des faits. Par exemple, tel jour, j'ai perdu 1/2 journée à cause de la base de dev qui ne répondait pas.

L'avoir sous les yeux empêche le manager d'oublier ce sujet, ainsi que l'équipe.

C'est surtout utile pour les demandes un peu touchy qui nécessitent plus d'arguments, ou qui sont récurrentes mais sur lesquelles la réponse peut tarder à venir. Cela peut concerner des machines à remplacer ou un DBA à recruter.

Et vous, quelles sont les particularités de votre tableau ?

[1] Le template est sur github.

Aimez-vous le changement ?

Florence Chabanois — Thu, 10 Jan 2013 14:38:00 +0100

La gestion du changement est un sujet à part entière dans le management. Pourtant, peu de gens ont conscience d'avoir un problème avec.

Vous pensez être différent ? Ne trouvez-vous pas que M.Dupont dans un autre bureau a souvent des idées farfelues ? Alors que les vôtres relèvent juste du bon sens... Que pensez-vous du nouveau système de classement que votre épouse a trouvé pour vos livres ? Et des décisions de votre N+3 ? Pourtant, sur le fond, en y réfléchissant bien bien, c'est parfois une idée que vous pourriez avoir eu quand vous écoutez ce qui a emmené la personne à lancer ce changement.

En réalité, nous sommes à l'aise, voire enthousiaste avec un changement tant que l'on en est l'initiateur. Il est plus difficile à digérer lorsqu'il vient de quelqu'un d'autre. Je pense qu'il s'agit d'un facteur clef. Il ne s'agit pas que du fond. C'est en regardant mon enfant que j'ai palpé cette tendance d'encore un peu plus près.

Un changement à l'école

A l'entrée à l'école, il a pleuré tous les matins pendant 3 semaines. Puis, il a fini par y prendre gout. Finalement, c'est bien l'école.

Deux mois plus tard, petit changement, c'est moi qui le dépose. Le deuxième jour, il se met à pleurer.

What the fuck ?

Troisième jour, même scénario. La maitresse est un peu agacée et le gronde. Il pleure plus fort. J'ai encore moins envie de partir. Je reconnais un positionnement en "persécuteur". Retenant mes leçons [1], je me retiens de le "sauver" avec un gros câlin afin de ne pas renforcer sa position de "victime[1]". Je ne me positionne évidemment pas non plus en deuxième persécuteur en reniant sa peur / tristesse avec un "oh c'est bon, arrête de pleurer agacé", ni en m'en prenant à la maitresse.

Le lendemain, je passe au plan B, où j'ai fais une grosse promotion de l'école la veille, lui rappelant les nombreux jeux et camarades qu'il va rejoindre, à coup de questions du type : "qu'est ce qu'il y a comme jeux ? comment on joue avec ? bref l'école c'est vraiment chouette dis donc !" Une fois là bas, je suspends son manteau, me retourne et... raté. Mon fils me regarde tremblant, avant d'exploser en larmes.

Pour le cinquième jour, je consulte l'expert école : son papa. J'apprends qu'ils ont un espèce de rituel où c'est mon fils qui fait tout. Il accroche son manteau tout seul, va tout seul dans sa classe, récupère sa fiche d'élève, la met sur le tableau, bisou et direction jouets. Bref, il se démerde.

Le lendemain, je suis le protocole : je ne fais rien. Tout au plus, je lance quelques questions ouvertes du type : que fait-on de ton manteau ?. Et bien bingo. Il fallait juste le laisser agir.

En entreprise

Souvent, un choix est mal pris simplement parce qu'il vient de quelqu'un d'autre. D'un "other". Si je suis à l'exploitation et que je dois modifier mon script suite à une décision des développeurs, je suis forcément en mode rejet. Normal, je n'ai rien à y gagner et j'ai du mal à comprendre le pourquoi. Pourtant, si j'avais eu connaissance de la problématique, c'est peut-être la solution que j'aurais apporté. Il faut juste avoir l'opportunité de réfléchir aux alternatives.

Le changement en question n'est qu'une solution à un problème. La toute première étape consiste à l'identifier.

1. Identifier le problème

Cela permet de fédérer tout le monde sur la bonne chose et surtout de communiquer sur le problème. Au lieu d'une entreprise où l'on en veut à X qui nous oblige à faire des choses farfelues, on fait partie d'une entreprise où les problèmes aussi sont communiqués. Cela nous donne une opportunité d'y remédier ou de proposer autre chose.

2. Evaluer les conséquences

Parfois, une fois posées, on se rend compte que le problème est acceptable. Tête baissée sur la résolution, nous n'avions pas remis en cause le besoin.

3. Evaluer les options en impliquant les parties prenantes

Impliquer les parties prenantes (un des "others") dans le processus permet de mieux faire accepter le changement.

Concrètement, il s'agit de transformer les personnes qui subissent le changement en acteurs, en particulier en problem solver. Posez leur des questions qui commencent par "Comment ... ?" plutôt que leur imposer votre solution.

Pour ne rien gâcher, la décision a de fortes chances d'être meilleure, compte tenu de la vision élargie du problème.

L'inconvénient est que le processus de décision peut devenir beaucoup trop long. Cette démarche n'est ni possible ni souhaitable systématiquement. Elle est utile quand la décision est importante et que l'adhésion des gens est déterminante, et surtout que l'on est prêt à renoncer à la solution de base. Si ce n'est pas le cas, il me parait essentiel d'au moins communiquer sur le pourquoi du changement. C'est aussi une forme d'implication. Les gens peuvent ne pas être d'accord sur la solution, mais au moins, ils savent.

4. Avec ou sans l'étape 3, communiquer sur le pourquoi de la solution.

C'est d'autant plus important si elle est imposée et non négociable sur le contenu. Croire que c'est une perte de temps est une grosse erreur si l'on prend en compte les incompréhensions qui en découlent.

C'est avec un processus de concertation régulier ou même occasionnel que la confiance peut s'installer. Même si je n'ai pas assisté à la concertation, j'ai confiance au groupe pour avoir pris la bonne décision / je suis prêt à assumer l'échec possible avec eux. Si l'entreprise est trop grande pour avoir confiance en tout le monde, le fait qu'un pair soit présent peut suffire à rassurer.

La dernière chose à retenir de cette petite histoire :

Demander de l'aide, c'est bien :)

Et vous, en tant qu'acteur, vos changements sont-ils bien accueillis ? Etes-vous partisan du passage en force brutal mais rapide ou de la concertation ? En tant que récepteur, comment amorcez-vous le changement ? Les fois où vous l'avez mal accueilli, qu'est ce qui aurait pu être fait pour qu'il passe bien, ou mieux ? Qu'auriez vous fait à la place de l'investigateur ?

[1] "Victime, Bourreau ou Sauveur, comment sortir du piège" : il ne peut pas y avoir de triangle dramatique si personne ne joue avec nous.

Les plugins dotclear pour aider le référencement

Florence Chabanois — Wed, 05 Dec 2012 11:37:00 +0100

Après avoir abordé un peu de front, je souhaitais aborder les aspects référencement naturel du site. C'est l'occasion de voir quelques bases et de se rendre compte que ce travail n'a rien de "naturel" justement.

L'air de rien, le blog avait accumulé les anti-patterns. Dotclear proposent des plugins [1] qui devraient y remédier facilement.

J'ai dû monter la version de Dotclear vieille de 3 ans : 2.1.6 (2009-10) à une 2.4.4. En effet, le plugin qui rajoutait des billets connexes nécessitait une version "récente" du site. Tant que tout fonctionne, on touche à rien... Crainte infondée car le process s'est très bien passé, à un petit souci près.

Freins à lever

Les axes d'amélioration étaient les suivants :

Multiplier les liens internes : ce n'est pas parce qu'un billet date qu'il n'est plus pertinent.
Effectuer des redirections 301 afin de supporter les changements d'url. L'outil Webmaster Tools révélait régulièrement des erreurs 404, suite à de très très vieux changements de nom de billets. Visiblement, les anciennes urls persistaient longtemps.
Générer des urls propres en particulier sans accents ou ponctuation. Remplacer "index.php?post/des-pratiques-%c3%a0-reprendre" par "index.php?post/des-pratiques-a-reprendre"
Générer de belles urls avec des slashs : "billet/des-pratiques" au lieu de "index.php?post/des-pratiques"

Plugins utilisés

J'ai testé plusieurs plugins avant d'arriver à cette shortlist :

RelatedLinks : sur chaque billet, j'ai maintenant la possibilité de rajouter à la main des billets connexes. Cela peut sembler fastidieux mais il m'a fait redécouvrir des sujets encore d'actualité, que j'avais oublié avoir écrit. Cela vaut le coup de connaitre l'ensemble de ces billets et j'espère aussi que les billets remontés sont un peu plus qualifiés.
CleanURLs : génère une URL propre, sans accents, pour chaque billet. Mon préféré. Je le faisais à la main auparavant quand j'y pensais.
Log404Errors : permet de voir les pages 404 souvent générés justement par des URL avec des soucis d'accents. Je fais une passe dessus de temps en temps.
Meuh : une fois repéré, je vais sur le billet correspondant et nettoie l'url à la main. Meuh permet de garder l'historique des anciennes urls, et effectue des redirections 302 vers la nouvelle. Pour que la redirection soit permanente, il faut effectuer une petite modification dans le code.

Fail

Pour information, les plugins suivants n'ont pas fonctionné avec mon installation (Free.fr + posgresql + Dotclear 2.4.4) / Je n'ai pas su les utiliser / Ils ne m'ont pas plu.

Related posts/billetConnexes : échec à l'installation, il faisait planté le blog entier. Dommage. Sur un billet, il affichait les billets ayant le même tag. Il y avait visiblement d'autres options sympas comme des billets aléatoires.
Series : il permet de lier plusieurs billets entre eux manuellement. Typiquement quand il y a une séquence à suivre dans un billet du type "Retour devoxx 1/2", "Retour devoxx 2/2". Il fonctionnait mais le mode de linkage en créant un système de tags parallèle m'a semblé un peu compliqué et redondant.
ExternalLinks : il aurait permis d'ouvrir les liens externes dans une nouvelle fenêtre, évitant à l'internaute de sortir.
HttpRedirect : ce plugin me permettait de résoudre la problématique des urls "sales" en créant un autre billet avec l'ancienne url en statut "non publié". Il marchait mais la maintenance est laborieuse : pas d'endroits centralisés pour voir les urls liées et surtout autant de billets que d'url différentes. Bref le bordel.
MiniSeo : fail à l'installation. il aurait permis de customiser les métas des billets.
Alias : mon plus gros fail. Free ne permettant de pas de faire des redirections sur le htaccess, je comptais l'utiliser pour rediriger les urls de type "index.php?post/monBillet" vers "billet/monBillet". Même sur un exemple tout simple, je n'ai jamais réussi à obtenir quoique ce soit de ce plugin.

J'ai appris un peu tard que Dotclear permet de générer des URL propres en modifiant simplement un paramètre. Sans la main sur le Htaccess, il aurait avoir ce paramétrage dès le début pour préserver mon référencement actuel.

Autres actions

Par ailleurs, j'ai modifié les templates du thème afin de ne plus avoir de sauts dans les balises Hx. Avant, le titre de niveau 1 était le même sur toutes les pages : "Developers' notebook". Dans mes billets, je passais directement du h1 au h3, sans h2 intermédiaire. C'est contre-indiqué.

Des outils d'audit SEO [2] me conseillent d'avoir un compte Twitter associé, de favoriser le partage vers les réseaux sociaux, de publier plus souvent et proposer un moyen de contacter l'auteur.

Travailler l'écriture des billets sur les titres de pages et mots employés a de l'importance.

En parallèle, la mise en forme permet de faciliter la lecture des robots et humains : en structurant le contenu à coup de h1, h2 mais aussi avec du gras et de l'italique. J'essaie aussi de me tenir à une idée = un paragraphe.

Enfin, l'introduction de micro-données pourrait aider Google à mieux comprendre mes données et les faire ressortir plus joliment dans la liste de résultats.

Il y a aussi des plugins Firefox pour les pros du référencement, autour du page rank et compagnie. Je ne suis pas allée jusque là.

Conclusion

Sur le SEO, je souhaite juste limiter la casse. Même si cette contrainte est essentielle, j'ai du mal à accrocher car le feedback est très très long à avoir.

Si j'avais pris en compte le référencement dès le début, les choses auraient été plus simples ! Par contre, le blog n'aurait probablement jamais vu le jour ;-)

Et vous, quels sont vous outils ? Comptez-vous travailler votre référencement ou préférez-vous vous concentrer sur le contenu ?

Ressources

[1] Plugins pour dotclear 2
[2] Audit SEO en ligne, avec préconisations : Rezoactif, Marketing Grader
Introduction au référencement naturel, par le train de 13h37
Checklist des bonnes pratiques SEO (PDF)
Guide de démarrage SEO, by Google (PDF)
Ecrire pour le web
Vidéos youtube sur le SEO
Plugins Firefox pour piloter votre référencement

Comment vous estimez-vous ?

Florence Chabanois — Sun, 18 Nov 2012 11:50:00 +0100

Les problèmes de délai sont récurrents dans les projets. La capacité des équipes à effectuer des estimations dépend beaucoup de la connaissance que l'équipe a du projet, ainsi que des technologies impliquées.

D'autres facteurs moins souvent évoqués entrent en jeu : le rapport à l'échec, l'humilité, l'intérêt du challenge et l'estime de soi.

J'aimerais évoquer avec vous ces trois façons si différentes que j'ai rencontré, de prédire ses capacités.

Couvrons-nous pour réussir

Je vous parlais la dernière fois d'à quel point, je ne voulais pas me mouiller concernant un chiffrage sur un jeu de balles. Il s'agissait d'un contexte inconnu, je ne connaissais pas mes partenaires et surtout je n'avais pas franchement confiance en moi sur ma capacité à rattraper les balles. Je tirais donc plutôt l'objectif vers le bas afin qu'il soit atteignable, quitte à le réhausser petit à petit par la suite.

Concrètement, je ne voulais pas échouer. Vis à vis de l'animateur, je voulais aussi tenir notre engagement.

Nous avons tenu l'objectif "faible".

Puis, quand nous avons su qu'on pouvait faire 10 fois mieux, nous avons fait 9 fois mieux...

Pas d'objectif, je fais de mon mieux

Dans un autre cas de figure aussi inconnu, j'ai fait un choix tout à fait contraire : c'était lors de la naissance de mon enfant. Dans la mesure du possible, je voulais être pleinement présente et actrice de l'évènement : pas de péridural.

L'accouchement a été déclenché. Pendant certaines contractions, je me suis demandé si j'allais y passer. Il est aussi né au forceps, avec une épisiotomie au passage. Si vous n'avez pas d'enfant, vous vous dites peut-être "ok, soit."

De retour dans la chambre, plusieurs sages femmes m'ont félicité. Le lendemain, une que je n'avais jamais vu m'a dit "ah c'est vous qui avez accouché comme cela ! Vous avez une endurance incroyable à la douleur". Des années plus tard, des personnes de la profession s'étonnent en me donnant du waouw. Je n'en tire aucune fierté.

Je croyais juste que c'était normal.

Parce que je ne savais pas jusqu'où je pouvais aller, je n'ai pas mis de but. Pas d'objectif, pas de pression, pas d'échec possible, pas de regrets. J'étais la seule personne à qui rendre des comptes. Mon seul engagement était d'essayer.

Je suis certaine que je l'aurais vécu différemment si, dès le début, quelqu'un m'avait dit "tu ne vas pas y arriver".

Par rapport à ce même enfant, chaque jour, je suis étonnée de qu'il peut faire (quand je ne le freine pas inconsciemment). J'ai parfois des vieux réflexes de "il est trop petit, il ne peut pas faire cela", c'est difficile de ne présumer de rien. A peine entré à l'école maternelle, il sait compter jusque 13, lire les chiffres, les lettres, quelques accents et quelques mots. Il connait par coeur certaines histoires et fait semblant de les lire. Je ne sais pas si "normal", en tout cas, je suis épatée. Comme la plupart des gamins d'aujourd'hui, il sait lancer des jeux différents sur l'ordinateur et taper des mots au clavier. De mon côté, j'ai eu mon premier PC à 18 ans et je connais une seule chanson par coeur.

Toujours plus haut

Pendant une période, nous avions dû mal à avoir des sprints verts. Du coup, je tenais vraiment à enlever une story quand nous en prenions une en plus. Quelqu'un s'y est opposé car "elle ne fait pas de mal sur le mur, et puis cela donne un peu de challenge".

Pour certaines personnes, la pression d'une cible "inatteignable" est extrêmement stimulant. Néanmoins, s'il y a déjà eu un certains nombre d'échecs et que la connaissance sur ce sujet a augmenté, je ne pense pas que ce soit un facteur moteur. C'est juste un grand mensonge.

Une réussite visiblement impossible ne me motive pas. J'ai besoin de voir quelques étapes, d'obtenir des feedbacks réguliers sous formes de succès/échecs intermédiaires.

Réflexions

Je ne crois pas qu'il y ait un juste milieu. Il faut peut être secouer un peu le tout de temps en temps. Je constate en tout cas que :

se couvrir dans nos estimations nous tirent parfois vers le bas. Si toutes les itérations sont tenues, il y a probablement un problème...
viser trop haut peut être décourageant;
quand je veux juste faire au mieux sans regarder la ligne d'arrivée, je vais plus loin;
quand je crois que je peux y arriver, je vais plus loin. Sur un bug par exemple, dans la mesure où j'ai le code, je sais qu'on peut le résoudre. Je ne me dis pas "ce n'est pas à moi de le faire, c'est de l'exploit, c'est la faute à machin qui est parti".
l'ignorance du sujet nous voue souvent à l'échec mais parfois aussi nous fait dépasser la norme; il nous permet de sortir du cadre prédéfini, de tricher;
savoir que des projets similaires ont bien mieux réussi peut nous faire changer de vision et nous amener à viser la cour des très grands (cf jeu des balles);
trop d'échecs peuvent finir par rendre n'importe quel objectif trop difficile. Une plus petite action atteignable peut relancer la dynamique et permettre de re-situer son propre niveau;
sans deadline, on tombe plus facilement dans le piège de la perfection et le projet a du mal à se terminer;
avec une deadline, nous pouvons faire des mauvais choix juste pour tenir la date. Au détriment de ce qu'il faut faire.
s'il y a beaucoup de pression (extérieure mais aussi intérieure) à un moment donné pour qu'un projet "passe", cela peut marcher. Ce n'est pas gratuit néanmoins;

L'estime de soi joue un rôle essentiel dans nos estimations. Donner une estimation basse nous donne une image de bon développeur ("je ne vais pas dire 10 jours, ils vont penser que je suis nul") . Dépasser le délai nous oblige à constater notre véritable vitesse. C'est douloureux.

Par ailleurs, si douter est nécessaire, c'est aussi inutilement ravageur quand il s'agit de soi. Lors des ces traversées du désert où l'on sent qu'on n'y arrivera jamais, qu'on est un imposteur, Amy Cuddy suggère d'utiliser notre posture pour renverser la vapeur et se voir en winner.. Nous connaissons le pouvoir de l'esprit sur le physique, mais trop rarement de l'inverse.

Simplement sauter dans l'eau vous permettra de vous rendre le pouvoir et d'aller bien au delà que ce que vous auriez imaginé.

Et vous, qu'en pensez-vous ?

Retour sur le jeu 'Fais passer les balles'

Florence Chabanois — Thu, 08 Nov 2012 14:22:00 +0100

Géry Derbier a animé le 3e Agile Playground à Valtech.

Cet atelier présentait quelques jeux coopératifs. Je vous propose de faire un focus très détaillé du premier jeu : "Fais passer les balles".

Objectif du jeu

Je ne connais pas l'objectif officiel de ce jeu. Ni son nom, que j'ai improvisé pour le différencier du ball point game ou autres jeux impliquant des ballons.

Ce jour là, cet atelier a soulevé les thématiques suivantes :

processus itératif de tests. Un peu comme le parcours de billes que Gilles Mantel a eu l'occasion d'animer.
feedback rapide
expérimentation plutôt que de longs débats
quel est l'objectif par rapport aux contraintes ?
contraintes implicites que l'on peut se mettre, bien qu'elles soient inexistantes
processus de décision au sein d'une équipe nouvelle ou formée

Déroulement du jeu

Durée : moins de 10mn. Prévoir du temps après pour le débrief.

Chaque groupe de 6 personnes avait un animateur et 3 couleurs de balles à faire circuler. Ce dernier donnait des consignes au fil de l'eau.

Formez un cercle
Je te donne une balle. Lance la à quelqu'un d'autre
Maintenant toi, passe là à quelqu'un d'autre. Ah mais non pas à la même personne ! Vous devez la transmettre à quelqu'un qui ne l'a pas encore eu.
Ah zut elle est tombée, on recommence, on y va, on y va.
ok, c'est pas mal
Maintenant, je t'en redonne une autre, fais la circuler dans le même ordre
Ah bah tu t'es trompé, on recommence
Il faut que les trois balles aient circulé, voici la dernière, faites la tourner
...
(Nous répétons trois fois l'exercice pour bien mémoriser l'ordre et améliorer notre process. Par exemple, je ne regardais plus que la personne qui devait me lancer la balle pour ne pas être distraite par le reste.)

Concrètement, l'animateur ici donnait le rythme et diffusait les règles au fur et à mesure. Chaque membre du groupe était assez concentré sur sa contribution individuelle pour ne pas compromettre le groupe.

Et puis les choses se sont corsées.

Je vais vous chronométrer, vous pensez mettre combien de temps ?
10 secondes ?
(je nous trouvais assez mauvais et j'ai tendance à faire tomber les balles donc heu non plus haut pour moi)
15, 20 ?
Ouais allez, 15 secondes, on peut le faire

17 secondes.

Vous pouvez faire mieux !

L'équipe se concentre, ouais on peut le faire, on y va, en mieux !

15 secondes.

Pas mal. Vous pouvez faire mieux !
Comment ça, on peut faire mieux ? C'est quoi les règles au fait ?
Que les trois balles circulent jusqu'à revenir à l'envoyeur et que chaque personne les touche dans le même ordre
''ach so !' bah on va changer notre cercle et se mettre dans le bon ordre

13 secondes

Vous pouvez faire mieux !
et avec trois balles en même temps ?

10 secondes

Vous pouvez faire beaucoup mieux ! Je connais des équipes qui ont fait 2 secondes.
(silence)
c'est quoi déjà les règles ?
juste que chaque personne touche les balles dans le même ordre

L'animateur relâche un peu son rythme. Il y a peut-être le premier silence précédent une action concertée.

et si on mettait nos mains les unes sur les autres en les faisant tomber ?

En même temps, j'ai eu l'idée de poser les balles par terre et qu'on les touche à tour de rôle. Mais c'était tellement fun, j'avais envie de suivre la proposition avant de tenter autre chose. L'équipe ne se concertait pas mais s'écoutait et tentait toutes les expériences du premier qui avait parlé. Et ce n'etait pas toujours le même.

6 secondes

"les balles peuvent rester au milieu par terre et chacun les touche à tour de rôle ?"

3 secondes

Vous pouvez encore faire mieux.
"on n'est pas pas obligés de lâcher la balle en fait. Si l'un d'entre nous tient la balle et va vers vers les autres pour qu'elle soit touché au fur et à mesure ?"

3 secondes.

C'est l'heure du debrief !
Bon, on est quand meme passé de 15 à 3 secondes !

Débrief

Nous sommes conditionnés par des suppositions, pourtant fausses

Nous avons considéré au départ que tout ce que l'animateur nous demandait constituait une contrainte. Le client aura plus tendance à exposer une solution qu'un besoin. A nous de poser des questions pour faire émerger le véritable objectif.

Une fois que les règles étaient posées, nous nous promenions et améliorons notre performance mais sans objectif précis. J'aurais pu m'en contenter. A partir du moment où Géry est passé du "Vous pouvez faire mieux" à "J'ai déjà vu des gens le faire en 1s", tout à changer. Nous avons changé de paradigme et sommes devenus créatifs.

Faire juste "mieux" est un objectif mou qu'il faut à tout prix éviter.

L'objectif simple, mesurable et régulièrement rappelé permet de garder le focus

Dans cet exercice, l'objectif venait de l'extérieur. Il était bête et méchant, personne n'a songé à le contester. Cela a permis d'y adhérer et de se consacrer pleinement à son accomplissement.

Avoir un indicateur clair et régulier de notre avancement avec le chronomètre a permis de savoir exactement où l'on se situait pas rapport à cet objectif. Le burn down chart pendant une itération a le même but.

Le prérequis est également que la cible soit reconnue par tous. Si des membres de l'équipe ne voit pas l'intérêt de faire toutes les stories du sprint, l'effet radar tombe à l'eau. Accomplir l'engagement juste pour faire des points en sacrifiant la qualité ou un bug pénalisant la prod serait en effet une bien mauvaise idée.

Dans un projet réel, le rappel récurrent de l'objectif global est compliqué car d'autres facteurs rentrent en jeu. Par exemple, pour un site d'emploi, afficher toutes les semaines le nombre moyen de candidatures à un poste d'emploi par rapport à la moyenne d'un concurrent permettrait de s'évaluer. Cet objectif dépend néanmoins de nombreux acteurs : le marketing, la RC, le développement, l'IHM, le commerce, le contexte économique, etc.

Si l'on ne peut pas voir l'effet de notre action sur l'objectif, c'est un coup d'épée dans l'eau.

Avec de la pression, nous nous précipitons sur l'action

Quand l'animateur a cessé de donner le rythme, j'ai arrêté de rester scotchée sur les balles et ai regardé mes partenaires pour la première fois. Il y a eu un micro-flottement et nous avons discuté pour trouver notre prochaine action.

Cela m'a fait pensé à l'internaute qui scanne les pages à la recherche du prochain clic.

Trop réfléchir, c'est s'arrêter. Et c'est moins fun.

Discuter est plus long que tester

La version plus barbante aurait été de faire un tour de table, de générer des propositions, de s'écouter, de prendre des décisions (ou pas) et de se planter quand même. Comme dans le développement logiciel et son big design up front, c'est une erreur que de vouloir réussir du premier coup, avec un plan prévu pour être parfait.

Ce plan parfait n'existe pas. 178 heures de discussion n'y changeront rien. Cela va plus vite de se tromper puis de réessayer.

Dans un groupe où les personnes ne se connaissent pas, l'exercice de convergence est encore plus difficile car occupé à réfléchir et à proposer, nous avons du mal à écouter. Géry Derbier propose d'utiliser le protocole "decider" pour la prise de décision.

Il n'y a pas de vérité absolue mais des points de vue différents, avec chacun son système de valeur. Deux experts en ergonomie peuvent être en totale opposition sur un sujet précis. Ils ont plus ou moins raison en fonction du contexte. Tester des solutions sur la cible permet de lever des discussions d'égo stériles. Je suis fan des tests utilisateurs et multivariés pour cette raison : la conclusion récurrente est que l'on sait peu de choses ! Il permet aussi de rapidement valider ou invalider une hypothèse.

C'est d'ailleurs le même sujet avec les méthodes agiles. J'étais certaine que certaines pratiques marchaient forcément : le mur de post-its, le découpage en tâches, etc. Parce que je les ai vu fonctionner à merveille. Pourtant, appliquer à une autre équipe, elles n'ont pas prises. Il y a des voies différentes à explorer pour atteindre les mêmes besoins d'appropriation collective et de visibilité. Les meilleures seront celles venant de l'équipe, pas celle du scrum book.

Mes Ah ha

Quand on ne sait pas ce qui est possible, on se contente du premier petit succès

Mon apprentissage le plus frappant était de voir qu'on s'arrêtait quand on croyait que ce n'était plus possible d'aller plus loin. C'était donc possible de faire le circuit en 1s ??? Un peu comme dans une course, on s'arrête pile poil à la ligne d'arrivée. Ou juste devant la porte dans le métro quand ce dernier va partir, quitte à bloquer les gens qui couraient derrière nous. C'est pourtant plus fun d'être à fond que d'économiser nos efforts. Viser plus haut nous amène plus haut et il vaut mieux croire que tout est possible. Mais j'ai besoin de viser quelque chose de précis, pas de courir dans le vide.

Le deuxième aha est plus un rappel :

même un objectif simple doit régulièrement être répété, rappelé, martelé.

Il donne un tempo en permettant à l'équipe de se situer par rapport à l'objectif.

Je vous invite a voir les , puis

Les autres jeux

Les deux autres jeux ont été plus mitigés, je suis un peu restée sur ma faim. Ils m'ont troublés pourtant. Si je ne tarde pas trop, mes réflexions seront assez fraiches pour que j'en fasse des billets.

Le baton d'hélium : un groupe de 5-7 personnes alignées doit maintenir le contact de ses doigts sur une baguette ensemble. L'objectif est d'avoir le niveau le plus bas, tout en maintenant ce contact. Beaucoup plus compliqué que l'on ne croit et les leçons tirées ont été très différentes selon les groupes. Le jeu permet d'aborder les problématiques d'organisation d'équipes, de culpabilité et de visibilité des contraintes.
Le jeu de la corde / la quadrature du cercle : par groupe de 5 à 7, nous devons dessiner une forme avec une corde. Le tout avec les yeux fermés et la la corde toujours dans ses mains. Ici, c'est la communication qui est mise à mal par manque de feedback.

Propositions d'amélioration

J'ai mis un ROTI maximum pour cet atelier. En cherchant bien, j'ai quelques suggestions :

plutôt que débriefer tout de suite après l'exercice avec le groupe large, j'aurais aimé avoir un sas et débriefer en petit groupe avant.
sur les deux derniers jeux, j'ai eu des difficultés à voir une application sur un projet réel. Un retour d'expérience concret aurait pu m'aider à dépasser le basique "tout le monde fait de son mieux, c'est le contexte qui est comme ça" ou "zut il y a eu un problème de communication".
ce serait pas mal un nom, pour les jeux non ?

Mes déplacements sont plus que comptés en ce moment mais l'excursion en valait la chandelle. Merci donc aux organisateurs, à Gery Derbier et à Valtech pour cette chouette soirée.

[Edit du 9/11/2012] Mise à jour des noms des jeux -> le baton d'hélium, et la quadrature du cercle.