Cet article est le 2ème d’une série de 3 articles sur OKRs & Scrum, retrouvez sur le blog la première partie sur la description du framework OKRs et la troisième partie sur notre premier retour d’expérience et apprentissages chez Cleverconnect.

Dans la première partie de cette série d’articles, nous avons vu (ou revu) les bases du framework OKR. Dans ce second article, notre objectif sera d’aborder les complémentarités possibles entre les framework OKR et Scrum. Nous ne reviendrons pas en détail sur Scrum, mais c’est un sujet très documenté! (cf. Scrum Guide par exemple 😉 ).

Le framework OKR est concentré sur le pilotage des objectifs par l’impact. Le framework en lui-même ne va donc pas répondre à tous les aspects de l’organisation de l’équipe, et il vient souvent s’intégrer dans une organisation déjà existante, avec ses propres règles du jeu. Scrum, le framework agile le plus utilisé dans le monde, néglige quant à lui une grande partie des aspects “produit” qui doivent être couverts par l’équipe.

Sans spoiler, les deux frameworks ont donc un grand intérêt à être utilisés ensemble car ils répondent tous deux à des axes différents de l’organisation d’une équipe produit agile efficace!

Intégrer Scrum dans un cadre produit

Scrum, dans sa facilité à être compris, mais dans son étonnante complexité à être bien utilisé, ne donne pas beaucoup de guidelines sur comment définir et gérer ses objectifs produit. Et on se rend compte qu’appliquer Scrum sans avoir mis en place auparavant une approche produit va vite nous limiter dans notre recherche d’agilité. Le framework OKR est ainsi un très bon moyen de définir des objectifs en étant tirés non pas par les features qu’on veut mettre en production, mais par les impacts qu’on veut avoir sur nos clients, nos utilisateurs et notre business.

Il est très facile, en implémentant Scrum, de tomber dans le piège de la feature factory. Notre vélocité et notre prédictibilité sont excellentes, on montre des features à chaque sprint aux parties prenantes, on fait évoluer nos pratiques en rétrospective, on a tout bien fait pour que Scrum fonctionne à merveille dans l’équipe (ou les équipes). Et pourtant, la valeur apportée par notre produit ne décolle pas, les résultats sont décevants. Et c’est souvent parce que la notion de “valeur” décrite dans le Scrum n’est pas bien appréhendée.

Dans le scrum guide, on parle de “créer de la valeur”, de “maximiser la valeur”, de “créer des incréments de haute valeur”, mais cette notion est finalement assez compliquée à définir, et c’est pourtant une clé indispensable à la réussite d’un produit. En effet, à quoi bon livrer des tas de nouvelles features si elles n’ont pas ou peu de valeur ? Et pour vérifier que les features livrées ont de la valeur, il va falloir aller mesurer leur impact.

C’est là que les OKRs vont pouvoir être complémentaires de Scrum, car ils vont aider à piloter nos décisions en se basant sur l’impact que l’on veut avoir, et en alignant stratégie et tactique pour maximiser cet impact. Cela amène donc à notre framework Scrum une orientation produit qui va faire en sorte de mesurer et s’assurer que les features développées ont bien l’impact et la valeur espérées au départ, que nos hypothèses sont vérifiées. Comment apprendre et mettre en œuvre l’amélioration continue prônée par Scrum sans vérifier concrètement que ce qu’on fait a de la valeur ? C’est ce qu’apporte l’approche OKRs.

Intégrer les OKRs dans un contexte Scrum

Les OKRs peuvent très bien s’intégrer dans les rituels et artefacts de Scrum, tout en gardant leur complémentarité et leur efficacité. Les deux approches sont réellement intéressantes à utiliser ensemble car elles répondent à deux aspects de l’organisation d’une équipe, à deux visions et approches complémentaires.

En début de cycle, définir les OKRs en alignement avec le product goal

Au début d’un cycle tactique (trimestriel par exemple, cf. partie 1/3), les équipes vont travailler sur la définition de leurs OKRs. Ils vont donc identifier quels sont les objectifs qu’ils veulent atteindre, les impacts qu’ils veulent avoir, en alignement avec les OKRs stratégiques (annuels). Ces OKRs tactiques vont guider tout au long du trimestre les éléments de backlog que l’équipe inclura dans ses sprints.

Au moment de la définition des OKRs, l’équipe va utiliser un artefact Scrum qui donne également la vision de l’objectif à atteindre par le produit : le product goal. Les OKRs ainsi alignés avec cet artefact vont permettre de détailler et expliciter le product goal : quelles sont nos ambitions pour ce produit, et comment va-t-on mesurer son succès ?

Les OKRs sont définis par l’équipe lors d’ateliers qui ne sont pas forcément liés à des rituels existants, mais qui vont utiliser des notions fondamentales de Scrum. Mais on verra plus bas que c’est du temps bien investi !

Au début de chaque sprint, utiliser les OKRs pour définir le sprint goal

Si les Key Results ont bien été définis en termes d’impact et non pas d’activités, alors les équipes vont pouvoir réfléchir à quelles initiatives inclure dans leur backlog pour essayer de faire bouger les mesures de leurs Key Results. Les OKRs mettent l’accent sur l’autonomie des équipes à trouver des actions qui vont pouvoir permettre d’atteindre les Key Results et Scrum permet l’itérativité pour pouvoir le faire de manière empirique durant toute la période.

Le sprint goal pourra ainsi être directement en lien avec les OKRs en définissant sur quelle partie des Key Results et des Initiatives de la période l’équipe va se concentrer pendant le sprint.

Les OKRs sont donc ici un outil d’alignement et de priorisation, qu’on peut tout à fait utiliser en complémentarité des autres outils que préconise Scrum. La vélocité, la prédictibilité, la capacité de l’équipe vont nous dire combien d’items on peut mettre dans notre sprint, les OKRs vont nous dire quoi mettre dans notre sprint en priorité, en nous aidant à prioriser notre backlog. Si on se rend compte qu’un élément de notre backlog ne nous fait pas avancer vers l’atteinte de nos OKRs, on va peut-être choisir de ne pas le démarrer tout de suite ou de l’abandonner si le manque d’impact se confirme.

Les OKRs vont également ici inciter les équipes à être le plus itératives possible. En effet, ce qu’on veut voir c’est un impact mesurable avant la fin du trimestre. Donc si nos items de backlog sont trop gros et n’apportent pas de valeur rapidement et régulièrement, on n’aura pas le temps de tester et de valider nos hypothèses. On veut pouvoir tester plusieurs approches si on se rend compte que l’hypothèse d’impact n’est en fait pas vérifiée, et donc on ne veut pas passer de temps à développer une feature qui n’aura au final pas de valeur. Donc il faut tester, être itératif et si on se trompe — se tromper vite.

A la fin de chaque sprint, utiliser les OKRs pour prendre des décisions

Il sera très important de suivre les OKRs très régulièrement pour voir si les initiatives prises ont bien l’impact attendu. Si les initiatives prises n’ont pas eu l’impact espéré, les OKRs doivent alors être un outil de décision pour prévoir la suite, et éventuellement ajouter d’autres initiatives, tester d’autres hypothèses en prenant d’autres actions.

Lors de chaque sprint review, c’est donc l’occasion de faire le bilan : où en sommes-nous dans la progression vers nos objectifs, et sur la confiance de l’équipe pour l’atteinte de ces objectifs ?

Ce bilan pourrait prendre la forme suivante (c’est celle donnée par Cristina Wodtke dans Radical Focus 😉 ) :

Comment utiliser ce tableau ?

• En haut à droite, on retrouve l’état actuel de nos OKRs, ce qui nécessite déjà de les mesurer régulièrement (ne souriez pas, ce n’est pas si facile que ça quand on part de zéro). On voit alors où on en est, si on observe des mesures bouger suite à nos initiatives. Si rien ne bouge, on peut se poser des questions et réfléchir à quelles décisions on devrait prendre pour essayer d’augmenter notre impact.
• L’équipe peut également se positionner sur une échelle de confiance de l’atteinte de chaque KR, par un vote par exemple. Encore une fois, cet indice de confiance doit être discuté, analysé, et utilisé pour prendre des décisions.
• En bas à droite, on retrouve les indicateurs de santé de l’équipe (“health metrics”), autrement dit les KPIs, les indicateurs qu’on veut suivre sans forcément infléchir singulièrement leur valeur (sinon on les aurait mis dans nos OKRs). Ces indicateurs sont importants, on veut les maintenir à un certain niveau, et si l’un d’eux chute, on veut être au courant rapidement pour prendre les actions nécessaires.
• Sur la partie gauche, nous passons aux priorités des prochains sprints : que va-t-on prendre comme initiatives dans le futur pour essayer d’avoir de l’impact sur nos Key Results? Dans quel ordre? Doit-on anticiper des choses ? A-t-on des dépendances à valider ? Sur la partie du bas, nous nous projetterons sur un plus long terme, pour être sûr de pouvoir anticiper ce qui arrive après dans le pipeline.

Ce tableau doit donc être mis à jour tous les sprints, voire même toutes les semaines, et être utilisé comme un input lors des rituels Scrum de fin de Sprint : il donne des inputs précieux pour la sprint review (lors de laquelle on va adapter la suite de notre backlog), mais aussi pour la rétrospective, et ensuite pour le sprint planning.

En conclusion, OKRs et Scrum font bon ménage ! Ce sont des approches complémentaires, qui peuvent être puissantes quand bien utilisées ensemble !

Dans le prochain article de cette série, nous partagerons les premiers apprentissages concrets de notre aventure avec les OKRs chez Cleverconnect.

A bientôt !

N’hésitez pas à me suivre sur mes réseaux pour être au courant de mes prochains articles !