Et si nous traitions nos OKR comme du code ?

J'ai passé une bonne partie de ma carrière dans le domaine de l'intégration continue (CI) et de la livraison continue (CD) (salut Atlassian Bamboo, bonjour Bitbucket Pipelines 👋). Une chose était claire pour moi quand nous avons construit Tability : nous allions devoir emprunter quelques idées à l'ingénierie pour résoudre le problème des OKR.

Attendez, quel est le problème avec les OKR ?

Je vous recommande vivement le livre de Christina Wodtke, Radical Focus, car il illustre l'un des pièges les plus courants des OKR : les gens oublient.

Voici comment l'histoire se déroule en général. Une équipe a grandi au-delà du point où les fondateurs peuvent encore tout suivre. Ils commencent à chercher une meilleure façon d'organiser le travail. Ils entendent parler des OKR, ou en lisent quelque chose. Ils adorent ça ! Ils définissent le premier ensemble d'OKR et mettent tout dans un tableur. Tout le monde est enthousiaste. Ils se mettent au travail sur les priorités principales.

Un mois plus tard : plus personne ne se souvient de ce qu'étaient les OKR, et chacun repart dans des directions différentes. Ils ont mis tous leurs efforts dans la planification et ont oublié de définir un moyen de suivre les progrès.

Loin des yeux, loin du cœur.

Le travail est paradoxalement un puissant générateur de distractions. Chaque projet semble développer un ensemble de fonctionnalités supplémentaires, devenant une pieuvre géante qui tient l'équipe en otage. Chaque semaine produit des dizaines d'appels, des centaines d'e-mails, détournant votre attention de vos priorités principales. Chaque tâche a ses propres inconnues inconnues qui vous entraînent dans le terrier du lapin.

Donc, pour en revenir à nos OKR, ils sont voués à l'échec à moins d'avoir une sorte de cadre en place pour les soutenir. Pas parce que l'équipe s'en moque, mais parce qu'elle n'aura pas le temps d'y penser — à moins qu'on ne le lui impose.

Les principes CI/CD à la rescousse

Voici une définition de l'intégration continue tirée du site de Martin Fowler.‍

L'intégration continue est une pratique de développement logiciel où les membres d'une équipe intègrent leur travail fréquemment, généralement chaque personne intègre au moins une fois par jour - menant à plusieurs intégrations par jour. Chaque intégration est vérifiée par une construction automatisée (incluant des tests) pour détecter les erreurs d'intégration aussi rapidement que possible. De nombreuses équipes constatent que cette approche réduit considérablement les problèmes d'intégration et permet à une équipe de développer un logiciel cohérent plus rapidement.‍

Bon — c'est super technique. Il ne s'agit donc pas tant d'activer l'IC dans vos tableurs que de comprendre pourquoi c'est une approche populaire du développement logiciel.

Les équipes produit du monde entier ont adopté le CI/CD parce qu'elles ont réalisé que des itérations rapides produisent de bien meilleurs résultats qu'une planification grandiose avec une approche en cascade de la livraison. Vérifier les progrès tôt et souvent réduit le coût de se tromper et vous permet de valider votre direction en obtenant des retours de vos clients.

Les choses deviennent encore plus intéressantes quand on regarde les 5 principes de la livraison continue publiés par Jez Humble :

1. Intégrer la qualité dès le départ
2. Travailler par petits lots
3. Les ordinateurs effectuent les tâches répétitives, les humains résolvent les problèmes
4. Poursuivre sans relâche l'amélioration continue
5. Tout le monde est responsable

Je crois absolument que vous pouvez et devez appliquer ces principes au processus des OKR.

Les 5 principes des OKR

Intégrer la qualité dès le départ

« Il est bien moins coûteux de corriger les problèmes et les défauts si on les détecte immédiatement »

N'attendez pas la fin du trimestre pour réaliser que l'un de vos Résultats Clés a dévié. Un rythme quotidien pour les OKR est excessif, mais vous devriez vérifier les progrès de vos Résultats Clés chaque semaine (idéalement un lundi pour relancer les choses après le week-end). Occupez-vous de chaque KR qui est au rouge depuis plus de 2 semaines.

Travailler par petits lots

« Cela réduit le temps nécessaire pour obtenir des retours sur notre travail, facilite le tri et la résolution des problèmes, augmente l'efficacité et la motivation, et nous empêche de succomber au sophisme des coûts irrécupérables. »

Des phrases comme « on ne pourra pas suivre les progrès avant le mois prochain » sont des signaux d'alarme. Le travail effectué pour progresser sur les Résultats Clés devrait commencer à produire un impact en l'espace de semaines, et non de mois.  Ne visez pas les grands coups d'éclat. Faites de votre mieux pour obtenir des progrès incrémentaux tout au long du trimestre.

Les ordinateurs effectuent les tâches répétitives, les humains résolvent les problèmes

« L'objectif est que les ordinateurs effectuent des tâches simples et répétitives, comme les tests de non-régression, afin que les humains puissent se concentrer sur la résolution de problèmes »

Celui-ci est une mise en garde contre une automatisation excessive des OKR. J'ai vu des cas où des équipes voulaient que les progrès des Résultats Clés soient mis à jour automatiquement via des scripts ou des intégrations, sans aucune intervention humaine.

Cela anéantit les bénéfices des OKR car vous perdez la partie résolution de problèmes. La valeur des OKR vient (1) du fait que les gens se souviennent des priorités principales, et (2) du fait que les gens réfléchissent activement à l'écart entre où ils en sont et où ils sont censés être.

L'automatisation complète des OKR supprime la touche humaine. Les ordinateurs devraient vous aider à collecter les données, mais seule votre équipe peut les interpréter et les utiliser pour prendre des décisions critiques.

Poursuivre sans relâche l'amélioration continue

« Ne traitez pas la transformation comme un projet que l'on entreprend puis que l'on termine pour revenir aux affaires courantes. »

Je pense que les OKR souffrent un peu de leur histoire. C'est un processus souvent associé au comité de direction et aux grandes entreprises, et cela ressemble beaucoup à du jargon stratégique. Cela peut rendre la chose difficile à vendre pour certaines équipes qui y voient une autre façon de faire du micro-management (et parfois elles ont raison !).

Les OKR devraient responsabiliser les équipes et encourager l'innovation ascendante — mais il faut avoir la bonne culture. Cela signifie créer un espace où les gens peuvent essayer et échouer, et cela signifie investir dans les bons outils et processus pour permettre à votre équipe de grandir.

Tout le monde est responsable

« Tout le monde travaille ensemble pour atteindre les objectifs au niveau de l'organisation, plutôt que d'optimiser ce qui est le mieux pour son équipe ou son département. »

Les OKR concernent avant tout l'alignement. L'objectif est de créer une étoile polaire commune et de définir un langage commun pour décrire à quoi ressemble la réussite.

C'est aussi pourquoi les OKR devraient être basés sur l'équipe plutôt que sur les individus. Il s'agit de faire ce qui est le mieux pour les clients et l'entreprise, pas ce qui est bon pour chaque membre de l'organisation.

Ce que cela signifie en pratique

Vérifiez les progrès chaque semaine

Dans un flux normal de livraison continue, vous voudriez que le code soit intégré chaque jour. Ce serait excessif pour les OKR, et une cadence hebdomadaire est largement suffisante.

Mettez à jour les progrès des Résultats Clés le lundi, puis laissez l'équipe se concentrer sur le travail pendant la semaine. Ils auront le bon contexte en tête et devraient pouvoir avancer avant la prochaine réunion OKR.

Utilisez des statuts rouge/jaune/vert pour indiquer vos niveaux de confiance

Vous avez besoin d'un moyen simple de comprendre quand les choses déraillent. Dans le logiciel, cela se produit quand la construction passe au rouge. Vous pouvez obtenir des résultats similaires en utilisant des feux de circulation pour indiquer votre niveau de confiance pour chacun des Résultats Clés.

Veillez à conserver l'historique de vos points d'avancement ! Ne remplacez pas les valeurs existantes dans votre tableur, car cela vous empêchera de voir les tendances.

Rendez vos KR mesurables

Évitez les Résultats Clés binaires (c'est livré/pas livré) ou les formulations vagues (les utilisateurs adorent notre produit). Si vous voulez que votre équipe soit efficace, vous aurez besoin de moyens concrets pour mesurer les progrès.

• C'est livré -> Nous passons de 0 à 350 utilisateurs actifs hebdomadaires
• Les utilisateurs adorent notre produit -> Nous augmentons notre NPS de 20 à 60

3 rouges = tout le monde sur le pont

L'intégration continue exige que la construction soit réparée dès qu'elle est cassée. Les choses doivent être un peu plus souples avec les OKR car les progrès peuvent fluctuer, mais je recommande d'avoir une discussion sérieuse dès la 3e mise à jour rouge.

Il ne s'agira pas toujours de faire en sorte que l'équipe abandonne tout pour se concentrer sur un seul objectif. Parfois, vous réaliserez que vous étiez peut-être trop ambitieux, ou que ce n'était pas le bon KR dès le départ. Mais — vous devez avoir cette discussion pour que tout le monde soit sur la même longueur d'onde.

Restez léger !

La livraison continue n'est possible que si déployer du code en production est un jeu d'enfant. Il en va de même pour la mise à jour des OKR.

Si cela ressemble à une corvée ou prend des heures aux gens pour mettre à jour leurs KR, alors ils arrêteront de le faire. Et s'ils arrêtent de mettre à jour leurs KR, ils les oublieront bientôt. Vous seriez de retour à la case départ.