Le Manifeste Agile se trompe.
Il y a un article publié sur InfoQ qui parle du Manifeste Agile comme étant faux. Mais gardez vos fourches pour l'instant. J'adore le Manifeste, cependant l'un des 12 principes est faux :
Le logiciel opérationnel est la principale mesure d'avancement, Agile Manifeste 2001
C'est incorrect. Ca l’est maintenant et ça l’était déjà en 2001. La principale mesure d’avancement qu'on devrait prendre en compte est le résultat des équipes commerciales et pas juste un logiciel opérationnel.
D'ailleurs, ce principe est en conflit avec le premier à savoir :
Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.
Alors nous ne devrions pas mesurer des logiciels opérationnels mais des logiciels de valeur. Ca c’est 100% correct. Mais qu’est-ce qu’un logiciel de valeur ? Comment définissons-nous la valeur ? La valeur peut vouloir dire plusieurs choses pour différentes personnes en fonction de leurs points de vue. Il existe plusieurs techniques pour gérer la valeur business dans les projets agiles comme les Points de valeurs, ou encore la modélisation de la valeur business et d'autres encore.
Mais la plupart d'entre eux ne sont que des estimations et non de véritables mesures de valeur qui ne peuvent être mesurées qu'après la livraison de la fonctionnalité.
En janvier 2015, Ken Schwaber a écrit, pour décrire son cadre d'Agilité à l'échelle Nexus :
Dans notre cas, un nexus c’est 3 à 9 équipes Scrum qui travaillent sur un Backlog Produit unique pour construire un incrément intégré qui répond à un objectif.
Pas un mot sur ce qu’est cet objectif, ni comment le définir.
Nous avons besoin d’un moyen d’établir des objectifs clairs et de les partager à la fois avec les différentes parties prenantes et l’équipe.
Qu’est-ce qui ne va pas avec la mise en place des objectifs ?
La planification statique. C’est comme cela que je qualifie le processus de planification annuel traditionnel. On sait tous comment ça se passe : on organise une retraite d’entreprise où l’on définit les objectifs de l’année à venir pour l’entreprise au travers d’une réflexion stratégique. Puis, au cours des semaines, les objectifs se déclinent en cascade à travers l’organisation créant un plan annuel détaillé et immuable pour l’entreprise.
Le modèle statique part de l’hypothèse que (1) toutes les étapes du plan peuvent être définies en détail et à l'avance ; (2) que la majeure partie du plan sera dans le vrai ; (3) que les conditions du marché resteront pour la plupart les mêmes ; et (4) que les changements dans le plan seront petits et pourront être gérés dans une revue en cours d'année où un nouveau plan détaillé statique sera créé.
L’analogie de la cascade elle-même fait littéralement référence à un phénomène "top-down" à sens unique - une chute
En revanche, la planification dynamique embrasse le changement et fonctionne dans des cycles de planification plus petits dans un modèle incrémentiel et itératif. La planification dynamique suppose que les conditions du marché et le plan lui-même changeront.
Nassim Taleb, auteur de Le Cygne Noir, aime comparer le modèle statique aux planificateur centraux du Kremlin qui ont créé des plans descendants sur 5 ans en croyant pouvoir prédire le futur. Si vos équipes travaillent sur des itérations d’une à quatre semaines (ou des sprints), sortent du bureau pour parler à de vrais clients, utilisent des résultats d’apprentissages concrets pour tester des hypothèses, comment pouvez-vous utiliser un ensemble statique d’objectifs définis dans un processus annuel en cascade qui aurait pu être conçu par le Kremlin ?
La réponse est que vous ne pouvez pas le faire. Il doit y avoir un autre moyen.
Dans son article publié sur le MIT, Sloan Management Review et intitulé "Peut-on construire une stratégie comme on construit des logiciels ?", Keith R. McFarland écrit ceci :
Parce que la stratégie ne fait que capturer la meilleure réflexion de l’entreprise à un certain moment donné, la stratégie (comme un logiciel) doit être affinée et améliorée au fur et à mesure que les gens acquièrent et partagent de nouveaux savoir et de nouvelles expériences.
Face à cette réalité, un processus de développement de stratégie solide devrait permettre à une entreprise de créer et d’adapter sa stratégie rapidement et de façon itérative… et de répartir ses ressources dans des environnements en mutation.
Du coup, bien que nous ayons utilisé l’état d’esprit et les processus “Lean/Agile” de manière tactique, nous continuons d’utiliser la pensée en cascade pour définir des objectifs. Cela doit changer.
Mais comment mettre en place une nouvelle approche ? McFarland mentionne l’utilisation d’un “scrum de la strategie" mais un cadre plus formel manquait encore. C’est là que les OKRs entrent en scène.
OKR : un cadre pour définir les objectifs Agiles
OKR (Objectives and Key Results en anglais) est un cadre de définition d'objectifs, ils ont été créés par Intel et adopté par plusieurs entreprises de la Silicon Valley. Google est l'entreprise la plus célèbre à avoir adopté les OKR dès sa première année d'existence. Twitter, LinkedIn, Dropbox et Oracle font partie de ceux qui les ont adoptés.
Le célèbre investisseur en capital-risque? John Doerr, qui a introduit les OKR chez Google, propose cette formule pour définir ses objectifs :
Je vais________ mesuré par ____________.
Donc un OKR peut être considéré comme un engagement exprimé sous la forme suivante :
Je vais (Objectif) mesuré par (Résultat Clé).
Il se compose alors de deux éléments : l’Objectif (le but à atteindre) et le Résultat Clé (comment y parvenir) :
Objectifs :
- Ce que nous cherchons à accomplir
- Ce qui est qualitatif.
Utiliser des objectifs inspirationnels est hautement recommandé. Personne ne se lève le matin avec l’envie “d’améliorer la conversion de 10%”.
Les Résultats Clés (un petit ensemble par objectif)
- Permettent de savoir si nous progressons vers l'objectif fixé
- S'ils sont quantitatifs.
- Indiquent les critères de succès montrant que nous progressons
- Des métriques (recommandés) ou étapes clés
Par exemple, imaginons une entreprise tech qui veut augmenter la satisfaction et l’engagement de ses clients:
Objectif : créer l'enthousiasme chez nos clients
Les Résultats Clés :
- Les visites récurrentes : une moyenne de 3,3 visites par semaine et par utilisateur actif.
- Atteindre un Net Promoter Score de 90%.
- Le trafic gratuit (ou référencement naturel) de 80%.
- L'engagement : 75% des utilisateurs remplissent entièrement leur profil.
Qu’est-ce qui rend les OKR uniques?
- Simplicité : pour permettre des cycles fréquents de définition des OKR (Intel les définissait mensuellement), le processus est extrêmement simple. Les OKR eux-mêmes sont censés être simples et facilement compréhensibles.
- Une cadence plus courte : au lieu d’utiliser un processus annuel et statique, les OKR utilisent des cycles plus courts (généralement chaque trimestre), permettant ainsi une planification dynamique et une plus grande adaptation au changement.
- Open Source: les OKR sont un cadre de travail open source que les entreprises adaptent en fonction du contexte et de la culture ce qui en crée différentes versions. C’est un grand bénéfice puisque le cadre est facilement adaptable mais il peut induire en erreur ceux qui recherchent une recette étape par étape.
- Des objectifs ambitieux : des objectifs qui obligent les équipes à sortir de leur zone de confort et à repenser la façon dont elles travaillent pour atteindre leur plein potentiel (en savoir plus).
- Séparation entre compensation et évaluation : dissocier les objectifs du salaire et des promotions est la clef pour que l’équipe se lance dans des objectifs difficiles et ambitieux (en savoir plus).
La Pratique des OKR
Le principal objectif des OKRs est de générer un alignement au sein de l’organisation. Pour ce faire, la transparence est importante. Les OKR sont publiques à tous les niveaux de l’entreprise, tout le monde à accès aux OKR de tout le monde. Tous y compris ceux du CEO qui sont généralement disponibles sur l’intranet ou son équivalent.
Les OKR existent pour établir des priorités claires et se focaliser sur l’organisation. Et pour cela, vous devez définir quelques Objectifs et Résultats Clés. Chaque individu ou équipe devrait avoir au maximum 5 Objectifs et 5 Résultats Clés par objectif - selon la devise "moins, c'est plus".
Etablir des objectifs adaptatifs de façon incrémentale
Les OKR fonctionnent généralement sur un double rythme :
- Des objectifs de haut niveau pour l'entreprise sont fixés chaque année.
- Des objectifs détaillés et incrémentaux des équipes ou des individus sont définis sur des cycles plus courts, des itérations pouvant aller de 30-45 jours à un trimestre
Au début de l’année, l’entreprise détermine un ensemble réduit d’OKR de haut niveau (de préférence avec la contribution de l’équipe) sans forcément définir de plan détaillé pour l’année.
Au début d’un cycle d’objectifs, chaque équipe passe en revue ses résultats de la précédente itération, puis détermine ses objectifs détaillés pour le prochain cycle. En parallèle, les individus et les équipes définissent les objectifs qui sont liés à ceux de l’organisation et validés par le management, dans un système qui est à la fois bottom-up et top-down.
Grâce aux OKR de l'entreprise, les équipes peuvent obtenir une orientation claire et comprendre comment elles peuvent atteindre ces objectifs. Environ 60% des ces OKR doivent être définis par l’équipe.
Les objectifs non atteints dans le cycle précédent sont réévalués afin de déterminer s’il est pertinent de les inclure dans le prochain cycle ou s’ils ne sont plus nécessaires et donc peuvent être mis de côté.
Alignement Horizontal
Pour déterminer ses OKR, les équipes et les individus débattent ensemble pour résoudre les interdépendances et créent un alignement horizontal. Si une équipe a besoin de quelque chose d’une autre portion de l’organisation, les personnes impliquées discutent et définissent des priorités communes ou même décalent l’initiative au prochain cycle d’objectifs.
Puisque les OKR sont transparents, si une partie de l’entreprise n’est pas alignée avec les autres, cela peut rapidement être déterminé par les autres et être corrigé.
Renforcer l’alignement : des OKR partagés
Pour renforcer l’alignement, des OKR partagés peuvent être créés au sein de différentes équipes créant ainsi des critères de succès partagés entre elles. Du coup, au lieu de diviser une initiative donnant différents objectifs à différentes équipes - ce qui peut amener certaines d’entre elles à perdre de vue le vrai objectif - un seul OKR partagé est créé.
Par exemple, imaginons qu’une équipe produit souhaite lancer un nouveau produit et a besoin que l’équipe de développement travaille sur une nouvelle fonctionnalité pendant que l’équipe commerciale signe des accords de partenariats sur les contenus.
Objectif : lancer le produit Acme avec succès
Les Résultats Clés :
- 500 000 utilisateurs actifs quotidiens sur la version gratuite
- Taux de conversion d’utilisateurs gratuits vers payants de 8%
- Net Promoter Score de 75%
- Moins de 5 bugs critiques ou bloquants signalés par les utilisateurs
- Au moins 40% de revenus issus de 5 partenaires de contenu cible
Au lieu d’avoir trois différents objectifs qui pourraient être individuellement atteints sans générer le résultat commercial désiré, cet unique OKR est partagé au sein de ces équipes. Chacune a différente tâche, mais un seul OKR - une même définition de succès.
Pendant la durée de cet OKR, une équipe virtuelle sera créée parmi les trois domaines qui se réuniront régulièrement pour suivre les progrès de l'avancement.
Comment les OKR complètent l’Agilité et le Lean
Les OKR apportent de la discipline à l'apprentissage validé
Steve Blank a écrit dans son article:
Utiliser le Business Model Canvas pour formuler des hypothèses, le Customer Development pour sortir de votre bureau et tester des hypothèses et le développement agile pour construire le produit de façon itérative et incrémentale
Mais comment savoir que vous réussirez ? Qu’est-ce que nous considérons comme étant une hypothèse validée ? Nous avons besoin de critères de succès clairs et partagés pour nos apprentissages. Alors j’ajouterais à la citation ci-dessus :
…Et les OKR pour vérifier que vous allez dans la bonne direction.
Les OKR définissent les critères de succès au-delà des fonctionnalités
Le succès des projets agiles est généralement mesuré par la rapidité avec laquelle ils livrent des fonctionnalités (avec de la “qualité”).
La coach OKR Christine Wodtke a fait un super tweet sur le "succès":
Le succès ce n'est pas de cocher une case.
Le succès a un impact.
Si vous accomplissez toutes les tâches et que rien ne s'améliore jamais, ce n'est pas un succès.
En fait, fournir des fonctionnalités qui n'affectent pas positivement les mesures sélectionnées (Résultats Clés dans le langage OKR) peut générer des rendements négatifs : le nouveau code peut avoir des bugs, il devra alors être maintenu et le produit lui-même deviendra plus complexe.
Marty Cagan a écrit un post sur le sujet comme plusieurs autres à lire absolument. Si vous n’avez pas encore lu son livre et son blog, je vous le conseille:
C’est pour cela que je suis heureux de voir la réapparition des OKR. Lorsqu’ils sont utilisés convenablement, ils aident à recadrer les choses, détournent l’attention donnée aux fonctionnalités et à la roadmap pour la mettre sur les résultats attendus.
Les OKR permettent d'éviter le problème de la “température de l'eau”
Si vous continuez à tourner le robinet de la douche, l'eau n'atteindra jamais la température souhaitée. C'est la même chose avec l'innovation, si vous continuez à pivoter tout le temps, vous n'arriverez jamais là où vous voulez.
L'utilisation de cycles d'objectifs plus courts peut aider à éviter le problème. Bien sûr les choses iront de travers mains ainsi que l’a dit l’ancien Senior VP Produit de Zynga Jon Tien dans une superbe vidéo Spark Session sur les OKR :
Les choses peuvent foirer mais ça ne veut pas dire que vous ne devriez pas ré-utiliser la même discipline.
Les OKR permettent l’auto-organisation des équipes
Les meilleures architectures, spécifications et conceptions émergent d'équipes auto-organisées.
Mais comment mettre en place des équipes auto-organisées ?
Pour avoir une organisation horizontale, fortement alignée, autonome et composée d'équipes auto-organisées, vous devez définir une approche "True North" au sein de l'entreprise. Il faut donner une direction claire aux équipes. Un ensemble d’OKR pour chaque équipe fera exactement cela.
Les OKR permettent de créer un lien entre l’équipe, le métier et les utilisateurs
Il est facile pour une équipe de se perdre dans les spécificités techniques du code et de la conception. Mais lorsqu'on commence à parler de résultats métier dans un processus ascendant, on observe des membres d’équipes qui commencent à questionner le sens de ce qu’ils font.
Si vous continuer à parler de livrer des fonctionnalités, comment s'attendre de la part de l'équipe qu'ils réfléchissent aux utilisateurs ou au business ?
Comment les OKRs complètent Scrum
Les OKR donnent de l’autonomie aux équipes
Dans certaines entreprises, le Product Owner est appelé un “Proxy Product Owner”, il se contente alors de faire naviguer des fonctionnalités qui ont déjà été priorisées par le management. Comment lui confier le mandat pour qu'il/elle gère le produit ? Comment veiller à l'autonomie de l'équipe ?
Si le rôle de l’équipe est de "fournir les fonctionnalités souhaitées par le client/le management", cela n’arrivera jamais. L'état d'esprit doit être le suivant : "le rôle de l'équipe est d'atteindre les critères de réussite tels que décrits dans les Résultats Clés et convenus avec le client/la direction. Donnons leur l’autonomie de faire cela".
Les OKR permettent de prioriser le backlog produit
Même si on a besoin de se concentrer sur la livraison de résultats métier et non de fonctionnalités, on aura toujours besoin de prioriser un backlog produit.
Mais comment le Product Owner est-il censé faire cela ? Il/elle est supposé (e) utiliser la valeur perçue en tant que critère, mais c’est subjectif. Les OKR peuvent être la pièce manquante, un cadre simple et clair pour décider de la prochaine fonctionnalité à développer.
Comme l’a écrit Cagan à propos des fiches d'évaluation produits ou KPI (maintenant remplacé par les OKR):
Un des bénéfices des fiches d'évaluation que je préfère est qu'elles peuvent souvent éliminer une bonne partie de la road map ou du backlog. Si une fonctionnalité ne concerne pas directement l'un des principaux indicateurs [Key Result] sur la fiche [OKR], elle est généralement éliminée.
Conclusion
J’espère que cet article aura permis de démontrer que les OKR sont un cadre de travail idéal pour générer de l’alignement et améliorer la communication entre les équipes et sont un complément au Lean et à l’Agilité à plusieurs niveaux. C’est un cadre léger, simple et direct, demandant seulement quelques conversations bien cadrées pour définir des objectifs.
Pour en savoir plus sur la pratique des OKR, rejoignez-nous à OKR Alliance, un groupe de pairs à but non lucratif, dédié à la promotion d’une utilisation efficace des OKR.
Et vous, utilisez-vous les OKR ou envisagez-vous de le faire? Avez-vous des questions? N'hésitez pas à le mentionner dans les commentaires et parlons-en !
A propos de l'auteur
Felipe Castro (@meetfelipe) est coach OKR et partenaire chez Lean Performance, une société de conseil spécialisée qui aide les entreprises à développer des cultures organisationnelles axées sur les résultats et les données. Felipe est titulaire d'une licence en génie informatique de la Pontificia Universidade Católica de Rio de Janeiro.