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à.

De 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

J’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.

Et 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.