L’anecdote du sous-marin

Je suis allé une nouvelle fois voir Jean-François Zobrist en conférence. Jean-François Zobrist en conférence, c’est toujours un peu la même chose ; il raconte ce qu’il a appris des années passées avec FAVI, j’ai déjà eu l’occasion d’en parler ici ; et c’est toujours un peu différent ; car il s’adapte au contexte et raconte ce qu’il lui semble le plus important de raconter en fonction de l’audience.

Cette conférence était organisée par les groupes Germe de Bordeaux dans les locaux de l’ISG. Invité par Germe, une émanation de l’APM, il a bien sur raconté ce qu’il avait appris à l’occasion des sessions de réflexion organisée par l’APM ou Germe.

Je vous livre ici une des anecdotes que Jean-François a raconté, tout en vous invitant bien sur à aller le voir ou le revoir en conférence, et à lire ce qu’il a écrit pour transmettre ses apprentissages.

Il racontait donc, que lors d’une session organisée par Germe, ils avaient invité un commandant de sous-marin nucléaire à leur parler de son rôle de management. La surprise est venue du fait que le commandant n’est pas supposé faire quoi que ce soit dans le fonctionnement normal du sous-marin. Il peut donc passer tout son temps dans sa cabine sans jamais être dérangé par quiconque.

Si par exemple, un sous-marin d’un pays « ennemi » venait a se promener sous le nez du sous-marin, l’équipage ne le le dérangerait pas et saurait parfaitement gérer cette situation prévue. Il pourrait être dérangé si par exemple un banc de poissons ressemblait trop à un banc de poissons d’après les instruments du bord.

Cette anecdote montre l’importance de contribuer à mettre en œuvre un système (individu, équipe, organisation, méthodes…etc…) fonctionnant correctement et à laisser ce système fonctionner, tout en tendant l’oreille aux signaux faibles qui seront la source des actions d’aujourd’hui et des innovations de demain.

Il explique ainsi que c’est en écoutant un chirurgien expliquer que la difficulté des opérations du cœur était aussi liée à leur durée, et donc à la réapparition des microbes. Favi s’est penché sur cette difficulté et a développé des alliages antimicrobiens.

 

L’image d’entête est le « Typhoon3 » by Bellona Foundation. Licensed under Copyrighted free use via Commons.

What’s Next ?

Cette nouvelle édition de notre club de lecture de Bordeaux était consacrée au livre What’s Next ? de Nicolas Minvielle et Mathieu Griffoul.

2016-01-16 10.53.26

Les participants ont apprécié la facilité de lecture de l’ouvrage et son côté vulgarisateur. Il est possible de réutiliser les explications bien faites pour expliquer les idées et les outils abordés dans ce livre à des néophytes.

Comme l’on dit certains des participants, ce livre présente nos outils du quotidien, on aurait pu (on aurait dû) l’écrire.

Il est malheureusement trop superficiel, regroupe du contenu déjà vu ailleurs, sans approfondir… et plus grave… sans citer les sources…

Pour le créateur d’entreprise, ou pour le manager, ce livre peut-être un bon début pour avoir une vue des outils possibles, et pour entrer dans un état d’esprit où l’on mène des expériences pour vérifier des hypothèses, et où l’on collabore avec d’autres personnes d’horizons différents.

Une fois de plus nous regrettons que les éditions papiers et numériques ne soit pas associées, il est agréable de lire le livre papier et de s’y référer, mais les versions numériques son imbattables lorsqu’il s’agit de faire une recherche rapidement.

Nos discussions ont dépassée le cadre du livre, comme lorsque nous avons évoqué l’usage des 5 pourquoi, ce qui a débouché sur cet article de Fabrice.

Vous pouvez dès aujourd’hui proposer et choisir en votant, quel va être le prochain livre du club en allant sur notre tableau Trello. Pour y avoir accès, demandez à Isabel, Fabrice ou moi-même via Twitter.

Et bien sur vous pouvez vous inscrire sur le meetup Agile Bordeaux (dont nous sommes les organisateurs) et en profiter pour regarder les autres activités proposées.

Les autres éditions du club de lecture ont été consacrées à :

 

Agile Bordeaux

Le premier meetup Agile Bordeaux s’est déroulé hier, mardi 12 janvier, au Bac à Sable, un nouvel espace de coworking à Bordeaux

Après un mot de bienvenue de Xabina Carreau qui nous accueillait dans ce lieu très agréable. Nous avons enchainé rapidement en présentant les prochains rendez-vous du groupe :

Nous avons ensuite élargi à d’autres événements pouvant intéresser les participants, comme Agile Open France, la semaine prochaine et le meetup Lean Startup Bordeaux le 28 janvier.

Suivant une tradition maintenant bien établie, nous avons ouvert par la session de présentation en 5 minutes, pour laquelle j’avais préparé un « agile en 5 minutes ». Merci pour la vidéo Isabel :)

Le groupe s’est ensuite réparti sur 2 activités en parallèle :

2016-01-12 18.20.12La scierie à pratique par Chris Deniaud

3 équipes ont échangées autour des pratiques agiles grâce à cet atelier créé par Pablo Pernot et Stéphane Langlois en s’essayant à une approche de recherche de consentement. Et ils ont tous terminés en choisissant la rétrospective comme pratique qu’ils garderaient (le jeu est bien sûr sur le wiki Agile Games France).

2016-01-12 18.36.33No Scrum, No Win? par Olivier Picaud et Olivier Patou

C’était une session de rattrapage pour ceux qui auraient voulu la suivre mais n’ont pas pu…lors de l’Agile Tour Bordeaux 2015 – Scrum est simple à comprendre et difficile à comprendre. Nous sommes à la recherche d’un Mindset agile afin de traquer nos anti-patterns agile/scrum.

Nous avons ensuite continué la discussion autour d’un verre de vin. J’avais oublié de l’annoncer, mais suffisamment de participants ont pensé à amener le nécessaire ! Bravo et Merci !

2016-01-12 20.29.22Un bel évènement apprécié par les participants comme le laisse entendre le graphique Fun / Valeur :)

Vous pouvez bien sur contribuer au programme du prochain meetup qui aura lieu le 29 mars directement dans ce document.

Joyeuse Année !

Je souhaite que cette nouvelle année vous remplisse de joie. Et que vous ayez l’opportunité d’apporter de la joie autour de vous.

Cette belle photo de David Hermans exprime bien cela.

2016-David-Hermans-Joie

Collaboration pair à pair à grande échelle

Un ami m’a demandé de répondre à 2 questions à propos de la collaboration dans les projets open source pour l’aider sur un de ces projets.

Je me demandais quelles pouvaient être les questions qui n’avaient pas déjà été répondues des millers de fois. Cette curiosité m’a conduit à une conversation captivante, et des idées intéressantes que je voudrais partager avec vous.

Première question : Quelle est la chose la plus difficile à propos des rétributions et récompenses pour soutenir la communauté contribuant à un projet open source ?

Il y a de nombreux facteurs de motivations et récompenses que l’on peut trouver à contribuer à un projet open source. La première peut être le produit / service auquel vous contribuez. La motivation et satisfaction de contribuer à un objectif plus grand que soi. La collaboration avec d’autres qui va améliorer la qualité et la sécurité du produit.

Il y a aussi les nombreuses opportunités d’apprentissage. Parce que le code est public (dans le cas du développement logiciel) et donc vous pouvez apprendre comment les autres résolvent les problèmes en inspectant leur code, et vous pouvez également apprendre des inspections des autres. De plus, cela peut conduire à détecter des opportunités d’emplois intéressantes.

Certains vont travailler dur pour augmenter leur réputation, pour gagner le statut ou l’autorité sur un projet.

Et donc, la chose la plus dure sur ce sujet des récompenses pourrait être de comprendre les motivations des contributeurs et d’adapter les récompenses à ces motivations.

Seconde question : Quelle est la chose la plus difficile à propos des prises de décision dans un projet open source ?

La question au sujet des décisions est intéressante et difficile. Certains mécanismes à l’œuvre dans les projets sont très collaboratifs et l’on peut dire que les meilleures idées gagnent. Mais parfois, les décisions basées sur l’autorité  acquise par le passé, peuvent parfois être mauvaises, et même totalement guidées par l’égo.

Les organisations de certains projets open source sont assez traditionnelles et hiérarchiques avec des conseils d’administration, des comités techniques, et une hiérarchie au sein des sous-projets. Même si les personnes sont co-optées ou élues par leurs pairs pour gagner autorité et statut. C’est toujours une structure hiérarchique.

Ces organisations émergent parce que nous avons une défaillance humaine qui nous conduit à mal comprendre les processus de décisions. Nous recherchons quelqu’un qui va ultimement « prendre » la décision.

Dans certaines organisations où il n’y a pas de mécanisme d’arbitrage en place, où personne ne peut décider ultimement, les personnes tendent à devenir plus raisonnables et commencent à construire des décisions et évitent de laisser leurs ego saper l’effort collectif. Ces personnes ont appris comment faire advenir cela.

Après une assez longue conversation autour des mécanismes de décision et des organisations. Nous sommes revenus à la première question… J’avais (intentionnellement) oublié de parler de l’argent et du partage de la valeur créée, car je n’ai pas vraiment de solution à proposer qui me satisfasse… Les personnes qui contribuent à des projets open source sont souvent employées par des entreprises qui ont besoin du produit / service, et lorsqu’elles ne le sont pas, elles sont parfois en recherche d’opportunité d’emploi… Pour d’autres, ils ont une autre source de revenu et sont satisfaits par les autres récompenses.

C’est le moment où mon ami m’a expliqué leurs idées pour résoudre le problème des récompenses et de la distribution des décisions évitant les mécanismes de concentration du pouvoir dans un centre.

Ils veulent utiliser la puissance de la technologie blockchain popularisée par l’expérience bitcoin. Je dis expérience car le bitcoin est une façon de démontrer ce que l’on peut faire avec cette technologie.

Cette courte vidéo donne un aperçu de ce qu’est le blockchain :

Si l’on utilise la technologie blockchain pour créer des services distribués, on peut créer un service de covoiturage sans centre, comme LaZooz. Ainsi les personnes qui partagent les biens et les services le font au bénéfice de la communauté sans avoir à servir les intérêts d’une entreprise classique comme uber, airbnb, blablacar…

On peut imaginer d’utiliser la technologie blockchain pour faciliter la construction des décisions dans un projet open source et de récompenser les contributeurs en fonction de la valeur de leur contribution et du risque qu’ils prennent lorsqu’ils rejoignent un projet très tôt par exemple. Plus sur ces idées en regardant http://backfeed.cc/ and https://www.ethereum.org/

Quelques leçons (ré)apprises :

  • Ne dites pas aux personnes, demandez leur. Si vous voulez que des personnes s’intéressent à votre idée, c’est probablement une bonne idée de leur poser quelques questions qui vont les aider à prendre conscience du problème que vous essayez de résoudre.
  • Accroitre la prise de conscience sur les différentes motivations et les différences entre les personnes est une partie importante lorsque l’on commence à travailler avec une équipe. Je vais réutiliser rapidement le tableau Trello qui me permet d’utiliser les moving motivators avec des équipes distribuées.
  • Ouvrez vous aux autres et à leurs idées…

Commentez et partagez cet article si vous avez apprécié la lecture :)

 

La photo d’entête est de Tim Swaan

DATFlock2015, licornes, équipes distribuées et mauvais agile

J’étais à Berlin pour 2 jours pour participer à #DATFlock2015 la conférence pour discuter, apprendre, partager autour des équipes agiles distribuées.

Le programme était un mélange de sessions open space et d’ateliers préparés à l’avance.

OKR, Retours et Récompenses

2 sessions m’ont été particulièrement utiles :

  • How to use OKR?
  • Fearless feedback and fair reward

Deux sessions proposées par Petra Liesmons et Kitty Iding, que je remercie au passage ! Les sujets et l’approche retenue pour les couvrir confirment le travail que je mène actuellement pour implémenter ces idées avec certaines équipes.

De la session OKR, je retiens :

  • Quelques améliorations dans la façon d’expliquer les OKR, spécialement la différence entre résultats clés et actions. C’est un aspect important, car les personnes tendent à proposer des résultats clés qui sont en réalités des actions, pour de pas si bonnes raisons. Par exemple : parce que le travail est fait aujourd’hui, parce que c’est important mais pas connecté à un OKR existant… Ce dernier point devrait être un bon signal, soit pour arrêter de faire cette action, soit pour reconsidérer les OKR définis précédemment.
  • Un autre point important, qui est souvent sujet à discussion est que les OKRs ne se cascadent pas depuis ceux de l’entreprise jusqu’à ceux de l’équipe. Il y a des objectifs et résultats clés au niveau de l’entreprise. Ils vont servir aux équipes à prendre leurs décisions et à définir leurs objectifs et résultats clés. Une équipe pouvant contribuer à tout ou partie des objectifs et résultats clés de l’entreprise
  • Les résultats clés doivent être difficiles mais pas impossibles. Ils montrent l’ambition que l’on a. Ce qui signifie que l’on doit changer l’habitude de vouloir atteindre les objectif à 100%. Une habitude qui tend à réduire l’ambition pour être sur de dépasser l’objectif.
  • Un comportement d’autant plus vrai si les objectifs sont associés à la rétribution. Donc les OKR ne doivent pas être connectés aux récompenses.
  • Les résultats clés représentent le succès, l’impact, le comportement que l’on veut induire dans l’entreprise.
  • Les OKR ne sont pas une approche venant de la direction de l’entreprise vers les employés. C’est une approche devant impliquer tout le monde dans la définition et l’évaluation, suivant une périodicité définie. Par exemple : chaque année pour la définition des OKR de l’entreprise, chaque trimestre pour reconsidérer ceux de l’équipe, et sur une base hebdomadaire pour l’évaluation par chaque équipe.
  • Les OKR sont publics dans l’entreprise, et un temps doit être consacré à l’alignement des OKR entre les équipes.
  • Il est probablement nécessaire d’avoir des indicateurs permettant d’identifier les effets de bords générés par les OKR sur les équipes, l’index de bonheur des équipiers peut-être un de ceux là.

 

2015-11-20 12.49.57De la session sur les retours et récompenses, je retiens :

  • Pour recevoir des retours clairs de la part de l’équipe, il est nécessaire de clarifier les attendus, et donc de définir les rôles en fonction de l’organisation de l’entreprise.
  • Un modèle que l’on peut utiliser pour définir les rôles et responsabilités peut être le modèle de Matti Klasson.
  • L’organisation d’un World Cafe pour définir les différents rôles de l’équipe semble être la façon la plus efficace d’y parvenir. Je vais devoir trouver un moyen d’organiser cela en ligne.
  • L’introduction aux types de personnalités (avec des outils tels qu’Insights, Ensize ou MBTI…) peut être une façon de faire prendre conscience aux personnes qu’elles doivent adapter leur façon de donner du feedback aux personnes à qui ils sont destinés.
  • Une suggestion pour aider les personnes à prendre en compte les feedbacks qu’elles reçoivent est de leur attribuer un coach personnel. Le coach personnel est un volontaire des équipes qui va pouvoir coacher 4 à 5 personnes. Ces coachs seront formés et coachés et formeront une équipe virtuelle de coachs.
  • La partie récompense de la discussion a introduit l’idée de l’évaluation pair à pair, en face à face, de chaque personne en fonction des rôles qu’elle tient. Le coach personnel aidant la personne à étudier ces scores. La personne évaluée est alors seule responsable de définir ces scores. Le manager a accès à tous les scores. Les personnes sont classées en fonction de leur score par rapport au(x) rôle(s) qu’elles tiennent. Ce classement est comparé au classement des rémunérations par rapport au rôle et une adaptation est proposée si nécessaire.

Organisation et Architecture

communication-overheadJ’ai également apprécié la conférence d’ouverture du deuxième jour donnée par Johannes Mainusch. Et particulièrement la façon de montrer la connexion entre la taille de l’équipe, le nombre de relations à maintenir et par conséquence le décroissement de la production de travail possible lorsque on ajoute trop de monde à l’équipe.

La conclusion de l’intervenant était qu’il souhaite des équipes pas trop petite, pour pouvoir faire de la programmation en binôme, et pour pouvoir former de nouvelles équipes par division cellulaires.

L’idée d’avoir des architectes faisant parti de chaque équipe et travaillant ensemble à rendre l’architecture évolutive et à s’assurer que les équipes pluridisciplinaires peuvent être indépendantes.

ElmoEt bien sur, je vais utilisé la technique de facilitation ELMO, qui peut fonctionner avec une équipe distribuée en vidéo conférence. Chaque personne a un papier, il peut y avoir un dessin d’Elmo, et lorsque la conversation traine en longueur, les membres de l’équipe peuvent tendre leur papier pour signifier que l’on doit passer à autre chose. ELMO veut dire Enough Lets Move On.

Un fishbowl (bocal à poisson) a été organisé lors du deuxième jour, et pour lancer la discussion Lisette Sutherland a expliqué pourquoi elle avait invité Yegor Bugayenko, fondateur et directeur technique de Teamed.io. Yegor travaille avec des personnes distribuées à travers le monde, et dit que les activités de team building sont sans intérêts. Qu’il s’agit juste d’un signe de mauvais management essayant de corrompre les personne pour remplacer la discipline par l’amitié.

Il était très intéressant d’avoir un point de vue contradictoire et respectueux dans la conférence. Yegor a expliqué sur son blog l’expérience qu’il a tenté avec les participants de son atelier.

Les idées maitresses : les clients veulent le logiciel et ne sont pas intéressés par l’équipe, et une équipe est moins efficace que des individus bien orchestrés. J’ai un désaccord principal… Mais nous y reviendrons…

Comment le système de Yegor fonctionne-t-il ?

Les projets sont découpés en milliers de tâches de 30 minutes chacune. La tâche est proposée à des développeurs qui peuvent prendre ou laisser. Ils seront payés à la tâche uniquement si ils livrent avec le niveau de qualité escompté. Ils devront garder à l’esprit qu’il s’agit de tâches d’une demi-heure, et donc si par exemple, ils ne comprennent pas la classe qu’ils doivent utiliser en un coup d’œil, c’est qu’elle n’est pas bonne et nécessite d’être refactorée. Et donc, ils doivent créer une nouvelle tâche explicitant ce dont ils ont besoin et mettre la tâche initiale en pause. Une autre personne, avec un rôle d’architecte, elle aussi payée à la tâche, validera si la tâche est réellement nécessaire.

Les risques sont gérés par le nombre. Ils choisissent de mettre 25 développeurs sur un projet qui pourrait en nécessiter 3. Si l’un d’eux échoue à délivrer une tâche d’une demi-heure (petit risque), la tâche sera réassignée à quelqu’un d’autre.

Personnes distribuées et pas équipes distribuées

Ce système ne peut probablement pas fonctionner pour tous. Yegor affirme que beaucoup de personnes veulent travailler avec eux, ils ont donc l’opportunité de choisir. Ils donnent du travail à tout les candidats, au départ sur des projets open source pour évaluer leur comportement, si cela se passe bien, ils se verront attribuer des tâches de projets clients. Si je me souviens correctement des données, 1 sur 20 candidats va rester.

Licornes

Durant le fishbowl, une personne s’est assis sur la chaise vide et a expliqué que les licornes de la silicon valley (des startups avec une valorisation de plus d’1 milliard de dollars) démontraient la validité du modèle d’équipe pluridisciplinaire… La réponse de Yegor a été que 1 ou même 100 exemples de ce type ne suffisait pas pour démontrer le rapport de cause à effet… Combien d’équipe font la même chose sans pour autant parvenir à ces résultats exceptionnels ? C’est un bon point bien sur, nous avons une tendance à interpréter hâtivement des situations en fonction de nos propres croyances…

Désaccord, Créativité et Innovation

Le principal désaccord que j’ai concerne la créativité et l’innovation. Les équipes pluridisciplinaires permettent à différents types de personne de travailler ensemble avec un but partagé. Et des frictions qui naissent de ces différences lors de la collaboration émergent de nouvelles idées géniales. Les pratiques agiles sont conçues pour permettre ces opportunités.

Mauvais Agile

Le problème est qu’avec les mauvaises implémentations des pratiques agiles. Ces équipes qui disent faire de l’agile mais pour qui :

  • Pas de collaboration dans l’équipe (Une story assignée par personne par exemple)
  • Pas de discussion avec le product owner
  • Des Story qui ressemble à des tâches dont on ne connait pas le but
  • Pas de revues avec les clients
  • Pas de découpage des tâches en équipe (ce qui devrait faire émerger des nouvelles idées et des architectures évolutives plus pertinentes)
  • Pas de programmation en binome
  • Revue par un architecte
  • Tests par une équipe d’assurance qualité en dehors de l’équipe

Si l’on combine ces mauvaises pratiques avec un mauvais management, qui ne sait pas ce qui doit être fait, qui change les priorités chaque jour, fixant des objectifs irréalistes etc…

On en vient à cette question de savoir comment implémenter une organisation efficiente pour développer des logiciels et des alertes pour les implémentations partielles sans compréhension des conséquences de certains choix.

 

Un grand merci à Lisette, Lucius et tous les autres contributeurs de cet excellent événement.

Revue annuelle de performance

Lorsque je présente les 14 points de Deming et les 7 maladies mortelles des organisations, j’ai pris l’habitude d’utiliser certains principes et maladies en fonction du contexte pour donner l’envie aux personnes de creuser un peu plus.

Une des maladies mortelles que j’utilise régulièrement est la troisième :

Évaluation à l’efficacité, au mérite, ou par des entretiens annuels.

La réaction des personnes était habituellement similaire. Ils étaient d’accord que c’était un problème qu’ils avaient, que c’était inéfficace et source de démotivation… Mais ils étaient « obligés » de se soumettre aux règles en place dans leur organisation.

Entendons-nous bien, ces règles ont été mises en place avec une intention initiale de développement des personnes et d’amélioration de la performance de l’organisation. Donc l’intention est bonne, le seul problème est l’évaluation de la performance de la solution retenue, et sa (non) remise en cause.

Depuis cet été et la médiatisation de la fin des entretiens annuels chez Accenture, dans le Washington Post, le Financial Times entre autres. Accenture a rejoins les autres entreprises ayant abandonnées cette pratique, comme Deloitte avant eux par exemple, ayant travaillées à simplifier radicalement la façon d’envisager les choses.

C’est donc une bonne opportunité pour initier un changement de modèle dans les entreprises qui utilisent encore cela. Une opportunité de repartir en redéfinissant l’intention. Que veut-on accomplir ? Développement des personnes ? Amélioration de la performance de l’organisation ? Autre chose ?