Comment amener les équipes à travailler ensemble vers des objectifs communs et ambitieux ? Comment garder l’ensemble des individus motivés et agiles en même temps ?

De plus en plus d’organisations trouvent une réponse à ces questions grâce au modèle OKR (Objectives and Key Results) ; parce qu’il permet :
– de lier la vision stratégique à des objectifs et des actions concrètes ;
– d’aligner les équipes sur les priorités à court et moyen terme ;
– d’accélérer le rythme d’exécution tout en permettant d’ajuster rapidement la direction.

De Google à Spotify, en passant par Renault et Veepee, le modèle OKR permet à de nombreuses organisations de mettre à profit le pouvoir du collectif pour accomplir de grands changements.

Ci-dessous, découvrez un extrait de la Méthode OKR, Objectives and Key Results : le guide pratique. Écrit par Elie Casamitjana, Henri Sora et Juuso Hämäläinen, ce livre donne les clés pratiques pour déployer efficacement la méthode OKR pour plus de dynamisme, efficacité et agilité !

Le contexte : un développeur dans une multinationale Européenne

Pour ce livre [la Méthode OKR, Objectives and Key Results : le guide pratique], nous avons interviewé un développeur de logiciels qui voulait partager son expérience OKR sans nommer l’organisation pour laquelle il travaille, ni la société cliente attachée à cette expérience.

Le client en question est une grande entreprise multinationale basée en Europe. La personne que nous avons interrogée travaille au développement d’une boutique en ligne, au sein d’une équipe d’environ 30 personnes.

Les développeuses et développeurs sont détachés dans les équipes informatiques clientes, à qui la direction des opérations a commandé la mise en place d’une plateforme d’e-commerce.

Ces moyens informatiques sont divisés en équipes composées de personnel maison et de consultants externes. Ces sous-équipes, ou « équipes projet », construisent chacune un élément de la plateforme et rendent compte à la direction produit, qui elle-même rend compte à la direction des opérations.

Erreur n°1 : Le manque de conseils ou d’informations

L’entreprise cliente applique le modèle OKR et quand la personne que nous avons interviewée a démarré sur ce projet, les OKRs se sont mis à faire partie de son travail. Mais on ne lui a donné aucun conseil ou information sur le modèle.

Ce pourrait être acceptable dans le cadre d’un projet court, très précisément défini, dont la mise en œuvre concerne un domaine bien spécifique. Mais ici, les consultants externes participent à un projet de développement à long terme, réalisé sur plusieurs années et intégré aux OKRs de l’organisation. En outre, on attend des équipes de développeurs qu’elles atteignent les cibles OKR en plus du travail qu’elles ont à faire.

Il est impossible de comprendre le fonctionnement d’une grande organisation en n’interrogeant qu’une seule personne, mais cette citation du développeur « Si vous comprenez comment ça marche, n’hésitez pas à nous l’expliquer aussi » résume assez bien la situation.

Erreur n°2 : Le manque d’implication de l’équipe & incohérence

L’équipe n’avait pas la main sur ses OKRs ; la direction des opérations les imposait d’en haut aux équipes. À charge ensuite aux équipes d’adapter leur travail aux objectifs.

On se retrouvait avec des problèmes de consistances significatifs. Par exemple, un élément développé pendant un trimestre pouvait avoir disparu sans prévenir des objectifs du trimestre suivant.

Les OKRs ne sont pas le seul guide de l’activité courante d’une équipe de développement.

Le développement d’un logiciel est également piloté selon un plan d’avancement séparé, qui comprend un calendrier plus précis des marchés pour lesquels les nouvelles fonctionnalités sont développées. L’activité au jour le jour est pilotée par le comité Kanban, qui agrège les fonctionnalités à développer, à la fois selon les OKRs et le plan d’avancement – soit deux différentes sources.

Erreur n°3 : Un top down qui fait échouer le modèle OKR

Dans cette entreprise, l’état d’avancement des OKRs n’est pas mesuré régulièrement et ils sont imposés d’en haut aux équipes chaque trimestre. L’équipe est alors supposée s’adapter, sans recevoir de conseils, sans infos complémentaires, ni discussions.

La personne à qui nous avons parlé nous a dit que les objectifs, déjà fixés pour l’équipe, figurent dans un tableau Excel, « si on sait où les trouver ». Les retours sur le trimestre écoulé se résument à « essayons de faire mieux la prochaine fois ».

La plus grande source de frustration pour les équipes de développement a été lorsque le responsable produit a tout d’un coup ajouté au Kanban des tâches qui semblaient sans rapport avec les autres. Il y avait été poussé par sa hiérarchie et ces changements étaient liés à des bonus versés à l’une des parties. L’équipe devait exécuter les nouvelles demandes sans poser de questions.

Les individus impliqués ont fini par se dire que le modèle OKR était une vaste blague, qui ne correspondait pas au travail à faire et n’établissait pas de priorité – un gadget supplémentaire qui générait de la confusion et des changements de cap inattendus. (…)

Quels sont les enseignements à tirer de ce cas ?

1. Avec les OKRs, on doit être capable de voir ce qui est important au premier coup d’œil, à tout instant. Un modèle de management complexe est source de confusion. Si le modèle est complexe et que les priorités viennent de plusieurs directions, les gens sont perdus.

2. Les OKRs doivent être négociés avec l’équipe et adaptés à elle. Bien sûr, la direction peut toujours imposer ses objectifs aux équipes, si nécessaire. Mais une caractéristique essentielle des OKRs, c’est qu’ils s’adaptent à l’activité de chaque équipe. Des OKRs bien adaptés entrent dans le langage d’une équipe, favorisent la compréhension de l’objectif et l’engagement à le réaliser.

3. L’évaluation des OKRs doit être systématique et fréquente. Les OKRs sont construits autour d’un examen systématique des objectifs environ toutes les deux semaines. C’est comme ça qu’on sait où on en est pendant le trimestre, et qu’on repère les problèmes éventuels.

4. Les OKRs doivent être publics. Pour pouvoir s’en servir, il faut que les OKRs soient visibles presque en permanence. Dissimuler des objectifs n’aide pas à diriger.

5. Les gens doivent être formés au modèle OKR – y compris les intervenants externes. Les principes du modèle OKR sont simples. Mais le vocabulaire commun, l’approche et la compréhension de ce qui est important ne sont pas transmis par magie quand on débarque dans une équipe et qu’on commence à coder. Quelques heures de formation sont nécessaires pour chaque collègue. Cette formation peut être effectuée par des « OKR Champions », des experts externes ou au travers de formations en ligne certifiantes à l’exemple de www.okrmentors.fr.

(…)

Découvrez tout ce qu’il y a à savoir sur les OKR – ce que c’est, comment les mettre en place dans votre entreprise, des cas pratiques et plus – avec le livre la Méthode OKR, Objectives and Key Results : le guide pratique, écrit par Elie Casamitjana, Henri Sora et  Juuso Hämäläinen.