J’ai la sensation d’avoir mis le doigt sur un truc qui me fait mal depuis longtemps. Comme si j’avais un truc qui me grattait dans le dos, mais que je ne pouvais pas le voir. Et là j’ai, par un jeu de miroirs, vu ce qu’il y avait. Cet article va vous parler de la méthode OKR (Objectives and Key Results). Mais avant je veux vous parler d’agilité et de management de la performance par les KPIs de productivité.
L’Agilité devait nous rendre heureux, mais elle nous a fait souffrir.
Dans ma vie de développeur, l’agilité ça a toujours été des sentiments partagés. Quand j’étais étudiant j’étais content de montrer mon burndown chart et mon tableau de business value sur un projet de M1, même si le jury n’avait rien compris. C’était un agiliste de chez idApps (Alten) qui nous avait initiés à l’agilité et ça avait l’air génial. Et puis ensuite en entreprise ça ne s’est pas si bien passé.
Les miroirs, ce sont des rencontres. Et en particulier l’équipe de Nord Agile qui nous a proposé de produire le contenu autour de leur évènement, l’AgiLille, qui a lieu le 18 Juin. C’est en ligne et vous pourrez y participer, courir sur leur map comme si vous étiez un chokobo, peu importe le lieu où vous êtes en France (ou plus en fait, je crois que la Belgique francophone peut s’inscrire, enfin c’est pas interdit). Bref, prenez un billet, c’est 10€, l’équivalent de deux bières, que l’équipe ne boira pas parce que les bénéfices sont reversés à une asso.
La mise en action, la mise en mouvement elle vient de Benoit Gantaume – Artisan Développeur – L’excellence est un chemin. Il m’a autorisé à penser que les développeurs n’aimaient pas l’agilité. Ou encore que l’agilité ne voulait pas forcément du bien aux développeurs. Du coup je suis allé percuter cette idée sur l’équipe Nord Agile que je voyais dans la même journée. En particulier, le même jour au bureau il y avait Xavier Koma et Djamel Labani. On a enregistré le 12e épisode du Podcast dont Xavier est l’invité. Xavier rêve d’une « bonne équipe », il cherche la recette secrète, parce qu’une bonne équipe permet d’être agile. Ajoutez-le à votre playlist !
But there is a new hope
Les agilistes indépendants peuvent jouer aux casques bleus de l’Agilité. Et Xavier et Djamel ont été très contents de m’expliquer que ce que j’ai observé en matière d’Agilité est particulièrement un assemblage de Dark Patterns. C’est-à-dire qu’ils les reconnaissent très vite, et ils savent qu’il va falloir faire preuve de délicatesse pour enlever cette épine dans le pied.
À ce moment-là, j’avais mieux cerné le problème. Mais je n’avais pas encore la solution. La solution ce n’est pas le NoEstimate. Même si j’adore la revendication, et qu’elle me parait très à propos, il nous faut aller plus loin.
La solution c’est Adrien Stadler qui me l’a donnée, présentée sur un plateau d’argent. Et j’espère qu’il prendra la parole sur le blog tech d’Adeo pour expliquer sa recette secrète (abonnez-vous).
Le Maitre Jedi a réenchanté pour moi la méthode OKR. Je l’avais déjà étudié, on avait essayé, mais j’étais passé à côté de l’essentiel.
Parlons de l’agilité et des KPIs d’abord.
Quel est le KPI de productivité que vous détestez le plus et pourquoi est-ce « tous » ?
Je me souviens de mon premier projet agile à l’école. On avait fait une liste d’User Story, et donné une Business Value et un Cost à chaque fonctionnalité. On avait fait 3 sprints et choisi en premier, un jeu de stories qui maximisait notre rapport BusinessValue/Cost. C’était Scrum by the book. Et on comprenait très bien quelle était la valeur business vu que c’était notre projet, un bébé projet entrepreneurial, et qu’on avait un lot de fonctionnalités très complet. À la fin, il y avait plusieurs démos et évaluations, donc on avait besoin d’avoir un projet complet, un MVP. On faisait une release à la fin de chaque sprint. Et cela permettait à toute l’équipe de se voir.
Le Burndown Chart nous montrait la valeur business créée en fonction du temps et c’était très satisfaisant. En fin de Sprint, on se demandait comment on allait pouvoir sortir plus de Business Value encore.
Agile au forfait
Mais quand je suis arrivé en entreprise, il y avait un Redmine sans BV, sans Cost, juste des spécifications. Par contre c’était une appli mobile et je devais faire une release chaque vendredi. Pas de CI/CD, et des recettes un peu molles vu qu’on ne sait pas quoi recetter. Parfois elles étaient dures les recettes, ça dépendait un peu du recetteur et du temps qu’il avait. Cela dit, mes tickets marqués « Résolu » pouvaient se rouvrir d’une semaine à l’autre, ajoutant du travail non planifié. Pas besoin de Burndown Chart parce que de toute façon tous les tickets Redmine devaient être fermés à la fin.
Estimations et Retard
L’entreprise d’après, au premier Sprint Planning on me pose cette question : combien de temps tu mets pour implémenter un login ? Déjà faut savoir qu’en mobile on fait rarement des logins parce que ta session n’est pas censée être perdue. Bon alors un formulaire d’inscription ? Alors mes formulaires d’inscriptions sur mes projets entrepreneuriaux, je pouvais y passer 4 ou 5 jours pour qu’ils soient vraiment sans friction. Ah non c’est trop long ! Bon, on fait quoi ?
On estimait donc toutes les taches en temps lors du Sprint Planning hebdo, et notre Burndown Chart ne nous donnait que … du temps estimé en fonction du temps passé et donc du retard.
Le Retard ne m’angoissait plus après plusieurs Sprints en retard. De toute façon je ne savais pas où on allait à la fin, je ne savais pas quelle quantité de ressources était allouée au projet. En fait je savais juste les US d’une semaine sur l’autre. Oui parce qu’on ne pouvait pas choisir les US, il y en avait 15 et on pouvait en envoyer 1 ou 2, mais il n’y avait pas de quoi faire deux sprints. Juste lors de la recette, le PO faisait les tickets pour la semaine suivante.
Ces KPIs de productivité : Vélocité, Estimation, Cout, Taille de T-Shirt
On veut par exemple, obtenir une « Vélocité » pour identifier quand l’équipe a eu un coup de mou. Le plus souvent si la vélocité baisse, c’est à cause de la dette technique, d’un manque de qualité ou d’une interférence (faudrait faire de la TMA sur le projet X, une demi-journée, c’est juste un bouton à remettre au-dessus de la ligne de flottaison). Notez le « C’est juste » parce que le travail non-planifié, c’est complètement OK d’y aller sans estimation.
Les Estimations en temps, en taille de T-Shirt, avec un jeu de points, avec un planning poker. À quoi ça sert ? L’important c’est qu’à la fin du Sprint Planning l’équipe se soit engagée à livrer le scope fonctionnel avec le niveau de qualité indiqué. Oui, mais les estimations ça permet de mettre en compétition les individus pour maximiser la productivité.
Comment on fait sans eux ?
Dans mes autres expériences, j’ai toujours fait sans. Salarié en startup : peu importe tant que le résultat est là. En freelance : le client paye quand il est content, le contrat encadre une régie avec un nombre de jours pour être agile sur le livrable. Entrepreneur : on regarde les KPIs du projet.
Vous avez déjà vu un projet open source, un projet perso de développeurs qui a un Burndown Chart ? Nope, on regarde si les fonctionnalités sont utilisées, on cherche des métriques qui confirment notre traction. Les frameworks open source regardent le nombre de téléchargements. Les projets persos aussi, le nombre d’utilisateurs quotidiens, le trafic GA, la longueur des sessions.
Dans les projets entrepreneuriaux on regarde les métriques d’usage aussi. Et surtout la valeur créée. Si c’est une plateforme de covoiturage, on regarde le nombre de passagers embarqués. Sur WeLoveDevs, on regarde le nombre de conversations, le nombre de tickets support, les développeurs qui reviennent vers nous pour nous dire qu’ils ont trouvé un job 👏
Ce n’est pas toujours si facile
Si vous êtes dans une plus grande entreprise, votre équipe peut développer et maintenir un produit logiciel qui n’est pas utilisé par les utilisateurs finaux. On peut mesurer le nombre de requêtes qui tombent sur l’API, le taux d’erreur. Mais le plus souvent ce sont les KPIs de productivité qui reviennent. Ce qui est difficile c’est de savoir à quoi va servir l’API.
Dans le e-commerce ou le retail, si vous proposez une API de substitution, vous cherchez à réduire les pertes au niveau du panier, augmenter le panier moyen. Si vous fournissez une API de Recommandation, vous voulez augmenter le taux de cross-sell, et d’upsell. Ces métriques sont toutes mesurables même si vous n’êtes pas les seuls à les influencer.
Les KPIs de productivité dans d’autres métiers ?
Imaginez que le variable commercial soit basé sur le nombre de rendez-vous effectués plutôt que sur le CA apporté.
Le CA c’est un résultat. Les rendez-vous c’est de la productivité.
Imaginez un recruteur dont on mesure le nombre et la durée des appels plus que les placements.
Ah ça existe et c’est courant ? Et bien c’est pareil, les recrutements c’est le résultat, le temps d’appel c’est de la productivité.
Et les estimations en recrutement c’est pareil. « Il me faut un dev Rails 5 ans d’expérience qui vienne 5 jours par semaine à Issy. Combien de temps cela va prendre ? »
Pour répondre à la question, il faut savoir corrompre le libre arbitre des humains. Mais on n’est pas dans Le Seigneur des anneaux.
Pourquoi c’est un Dark Pattern ?
Ces KPIs sont des Dark Patterns. C’est ce qu’explique Xavier dans le Podcast : #12 – Xavier Koma – Une bonne équipe est agile
Je cite Xavier Koma : Le seul moment où on parle de « prédictions » dans le Scrum Guide : « Various practices exist to forecast progress, like burn-downs, burn-ups, or cumulative flows. While proven useful, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. » — https://scrumguides.org/scrum-guide.html
Piloter par le résultat ça nous permet aussi de sortir de l’opérationnel et travailler sur des projets de fond.
Ça permet de mettre en place de l’amélioration continue, de dépasser les résultats atteints par les processus existants.
Piloter par la productivité c’est comme courir en regardant derrière nous. On n’est pas motivés par l’objectif à atteindre, mais par le chemin parcouru.
Et quand on essaye d’optimiser les KPIs, on ne finit que par produire plus sans forcément de sens. On obtient des choses absurdes comme du présentéisme, des recruteurs qui laissent la ligne ouverte alors qu’il n’y a pas de candidats au bout pour améliorer leur KPI.
Le Manifeste Agile : « Individuals and interactions over processes and tools »
Le manifeste agile est assez simple en vrai, il tient en quelques lignes.
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a planThat is, while there is value in the items on
the right, we value the items on the left more.
Source : https://agilemanifesto.org/ avec une version française.
À aucun moment les KPIs de productivité, la vélocité, les délais sont mentionnés. Et puis si on préfère les interactions sur les processus et les outils, pourquoi toutes ces cérémonies ?
Cela valait vraiment le coût de quitter le Cycle en V si c’est pour arriver à SAFe ?
Et le manifeste Craft ?
As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:
Not only working software,
but also well-crafted software
Not only responding to change,
but also steadily adding value
Not only individuals and interactions,
but also a community of professionals
Not only customer collaboration,
but also productive partnerships
That is, in pursuit of the items on the left we have found the items on the right to be indispensable.
Source : https://manifesto.softwarecraftsmanship.org/ avec une version Française
Encore une fois, « Pas seulement l’adaptation aux changements, mais aussi l’ajout constant de la valeur » ça ne signifie pas « respecter les délais plutôt que la qualité ».
Et je vous passe les autres détails « Pas seulement les individus et leurs interactions, mais aussi une communauté de professionnels. » est complètement antinomique avec l’idée de voir de l’élitisme dans notre profession plutôt que de la compassion et de l’empathie.
De meilleurs KPIs avec la méthode OKR
Objectives and Key Results (OKR) n’est pas nouveau, mais il redevient tendance parce que l’on cherche une alternative à SMART.
SMART veut que les objectifs, les indicateurs soient tous mesurables et réalistes. OKR veut que votre équipe se fixe des objectifs non quantifiables et ambitieux.
On cherche généralement une temporalité trimestrielle, et les objectifs sont les mêmes pour toute une équipe.
En pratique comment on met en place OKR pour des Devs ?
D’abord il faut définir les objectifs. Ils peuvent prendre n’importe quelle forme, le plus souvent une proposition, une affirmation même si elle n’est pas réaliste, péremptoire ou absurde.
Par exemple :
- Une mise en production qui va plus vite que la Nespresso
- On ne veut plus de crash en production
- Améliorer le NPS utilisateur final (ou des clients qui sont vraiment refaits)
- Augmenter le nombre de leads (vous avez peut-être un site marketing)
Prenons ce dernier par exemple, parce que c’est le plus dur. On va chercher des KPIs mesurables liés à celui-ci.
Des Key Results ambitieux
On considère que si l’on atteint 100% d’un KR c’est qu’il n’était pas assez ambitieux. Atteindre 70% de complétion d’un Objectif le complète.
On cherche généralement 5 KR pour un objectif.
Par exemple, pour le nombre de leads on a les KPIs suivants :
- Le taux de booking (la conversion entre l’inscription et la prise de rendez-vous)
- Le nombre d’inscrits par jour
- Le temps de chargement des pages sur le parcours utilisateur (oups il y en a une qui est à 1500ms)
Poser les bonnes questions aux utilisateurs
Les bons KRs viennent des feedbacks utilisateurs !
Si vous n’en avez pas en flux continu, il faut en collecter. Remerciez toujours un feedback 🙏
Par exemple vos utilisateurs ont dit :
- « J’ai vu le témoignage de younameit ça m’a convaincu d’aller jusqu’au bout »
- « J’ai droppé à la question 4, parce que je ne savais pas quoi répondre »
- « Je vous ai découvert en cherchant mot-clef dans Google »
On va donc rajouter des accomplissements mesurables :
- Avoir notre landing page qui rank est sur la première page pour 5 requêtes clefs identifiées
- Récolter en afficher 5 témoignages utilisateurs publiquement vérifiables.
On peut aussi commencer à créer des Todos :
- Ajouter un Placeholder, une dropdown d’auto complétion et une description pour la question 4
- Optimiser les images pour améliorer le temps de réponse des pages
- Configurer un CDN pour compenser la latence du WordPress
Ownership individuel des KRs, Ownership collectif des Objectifs
Et enfin, ce qui est important c’est que les KR aient tous une personne responsable.
Le responsable va s’assurer que le KPI soit bien mesuré, interprété et proposer des initiatives et actions pour le corriger.
Photo finale :
Et comme on repart jamais les mains vides, je vous propose de prendre, de copier ce template de fichier OKR au format Spreadsheet.
Qu’est-ce qu’il se passe ensuite ?
L’équipe est autonome sur les actions à prendre. Vous pouvez prioriser une tâche du backlog parce qu’elle répond à un objectif.
Sortir une ou deux chores que l’on remettait tout le temps au placard. Décider de faire un sprint complet sur les performances, vu que c’est un objectif.
N’hésitez pas à introduire une Cérémonie, bi-hebdo ou mensuelle, prévoyez un temps OKR. Chacun met à jour ses indicateurs avant la réunion et on fait des TodoList.
Que vous soyez en Kanban ou en Scrum, ou à l’arrache cela fonctionne.
Pourquoi c’est si bien que ça les OKRs ?
C’est la vraie question n’est-ce pas ? Le premier bénéfice c’est de reconnecter nos tâches, nos KPIs de performance avec le résultat.
C’est vraiment agréable pour tout le monde de savoir pour quoi on travaille. Le cloc sur le projet, la PR qui change 15K lignes de code c’est satisfaisant. Mais savoir que notre projet fait la différence en termes de business, de métier, c’est encore plus satisfaisant.
Une meilleure valeur perçue des projets IT
Les autres équipes changent de perception sur l’IT et savent enfin ce sur quoi vous travaillez. Cela marche dans toutes les équipes en fait, imaginez le marketing ou le recrutement qui fait ça 😃
Et puis quand on a un projet legacy (ou pas d’ailleurs), il y a toujours des questions sur comment sont priorisés les moyens. Par exemple, vous avez remonté un bug à tel endroit de l’application, et 6 mois après il n’est pas corrigé. De votre point de vue c’est un scandale. Mais du point de vue de l’équipe, c’est un point parmi 20 000 et ils ont les moyens pour en corriger 15 000.
En vrai, dans une startup on l’a aussi. Il y a tellement de choses à faire qu’il reste toujours des choses non-faites.
Tu vois tout ce qui n’est pas fait ? Maintenant on ne voit que des OKR
J’ai mis ce bug sur le github des devs, et ils ne l’ont pas encore corrigé. Je trouve que la plaquette marketing devrait être mise à jour. J’ai poussé un suspect à l’équipe commerciale, personne ne l’a appelé. Le Discord est bien, mais on pourrait faire mieux.
On peut tout faire mieux. Je suis frustré, mais c’est parce que je constate le travail non-fait, sans considérer les priorités des autres.
L’équipe tech a release un super projet du coup et ils ont pris que les hotfix (Lancement du baromètre des salaires WeLoveDevs.com). On n’a pas eu le temps de bosser sur les supports marketings parce qu’on a 5 projets clients en même temps et les clients sont super satisfaits ! L’équipe commerciale n’a pas le temps d’approcher des suspects parce qu’il y a 50 prospects qui rentrent chaque semaine. Le Discord pourrait être mieux mais l’équipe Média se concentre sur la chaîne Youtube.
C’est ça que OKR a changé. On n’est plus frustré par les choses qui ne sont pas faites, parce que l’on sait quelles sont les choses faites à la place.
C’est de la communication interne !
Délivrer plus facilement sur des objectifs pluridisciplinaires
J’entends régulièrement dans les conversations : « On a du mal à délivrer, l’équipe product ne fait pas bien la promotion de notre travail. Les features ne sont pas utilisées parce que l’équipe RC n’en parle pas aux clients ». OKR c’est génial dans des équipes transverses. Parce que les équipes transverses sont toujours un truc qu’on fait en plus de notre quotidien.
Alors on fait des « Swarm ». C’est une pratique qui consiste à mettre tous les gens nécessaires pour une release, pour atteindre un objectif. Dans la méthode Kaisen on appelle ça le Kaikaku.
Le problème des « Swarm » c’est qu’ils épuisent l’équipe, et ils sont plus faciles à mettre en place quand on est co-localisés.
Sinon on demande aux personnes d’être vraiment fullstack et de tout savoir faire elles-mêmes pour être effectives. Je vais aller faire les interviews utilisateurs, faire des wireframe, des habillages, les intégrer, développer la feature en TDD, mettre en production, faire le billet de blog et prévoir la promotion. C’est épuisant et cette phrase fait plus de 16 mots, elle ruine la lisibilité. Vous comprenez bien que ce n’est pas pratique.
C’est satisfaisant de tirer tous dans le même sens
Bref, chez WeLoveDevs, on a un jeu OKR pour toute l’équipe. On est 10 et ça m’épuiserait qu’on soit déjà silotés avec le « Média », « les Devs », le « Commerce ». Ne rigolez pas, je l’ai déjà vu plein de fois ! Des boîtes où chaque associé tient une mini-citadelle par exemple. Bref, même si les devs sont responsables d’animer la conversation autour du produit, tout le monde y participe. Il y a une réunion commerciale et Dev/Média y participent régulièrement. Tout le monde s’intéresse au compte rendu et tableau de bord. On fait une mini-réunion de rédaction aussi, pour faire la une le Lundi.
Nos objectifs sont donc transverses. C’est beaucoup plus efficace quand on fait un effort tous ensemble sur un objectif précis que quand on prend des initiatives chacun de notre côté.
En particulier avec le télétravail ! Avant quand on avait des bureaux, il suffisait de dire tout haut « J’aimerais bien travailler sur ça, machin et bidules, vous voulez aider ? Ouep, on fait ça aujourd’hui ? ». Alors que maintenant il faut s’organiser pour se voir.
Les Key Results sont toujours atteints par l’accumulation d’initiatives individuelles. Un peu comme si nous étions tous des poissons pilotes mais que personne n’était un requin-pèlerin.
La méthode OKR nous oblige à aller au-delà du code
Des bons Key Results signifient que vous avez pris le temps de réfléchir à ce qui va ou ne va pas. Cela veut dire que vous connaissez le chemin, que vous avez identifié des points de passage, des étapes clefs, ou encore des obstacles, des bloquants.
C’est une formidable opportunité d’aller voir les utilisateurs, de leur parler, de réfléchir avec eux aux résultats attendus. Un Objectif vraiment satisfaisant ne vous donne pas de bénéfice direct. Si on est une équipe de techs, et qu’on se met en objectif « Améliorer le nombre de leads », clairement on améliore les tableaux de bords de l’équipe marketing. Mais dans le fond c’est intéressant pour tout le monde.
Je vous encourage vraiment à fixer des objectifs qui ne dépendent pas de vous. « Augmenter le nombre de leads » cela veut dire qu’une autre équipe doit faire le travail pour que l’objectif soit atteint. Cela veut dire qu’une autre équipe peut aller à dans le sens contraire de la vôtre.
Et vous, comment l’avez-vous mis en application ?
Est-ce que vous utilisez déjà les OKR (s), mais autrement ?
Est-ce que mon ressenti vous étonne ?
Est-ce que je vous ai donné envie de mettre en place des OKRs ?
Est-ce que c’est la première fois que vous lisez les manifestes agiles et crafts ?
On en parle en commentaire. Je répondrai à tout le monde 🙏
