Dépassez L'Etat D'Esprit “Usine A Fonctionnalités” En Utilisant Modern Agile Et OKR

L'adoption de l’agilité dans la plupart des entreprises se concentre sur la livraison. L’utilisation de frameworks de mise à l'échelle n'aide généralement pas car ils empruntent le chemin de la moindre résistance. Ils se focalisent sur l'amélioration du développement logiciel au travers de nombreuses pratiques plutôt que de se concentrer sur l’adaptation évolutive et l’innovation.

Lorsqu'il s'agit de fixer des objectifs, l'état d'esprit de commandement et de contrôle du modèle en cascade est encore la norme : les organisations utilisent un processus annuel descendant pour créer un ensemble d'objectifs statiques qui sont en conflit direct avec une approche agile.

Les objectifs en cascade sont donc un processus organisationnel standard. Et trouve-t-on plus vertical encore qu’une cascade ?

Les objectifs et métriques du modèle en cascade transforment les équipes en "usines à fonctionnalités", sans se soucier d’apporter de la valeur. Comme le décrit John Cutler, de nombreux développeurs "ne font que s'asseoir dans l'usine, réaliser des fonctionnalités à la va-vite et les envoyer à l’étape suivante du processus".

Marty Cagan souligne l'énorme opportunité manquée des usines à fonctionnalités : "Les équipes sont juste là pour préciser les détails, coder et tester avec peu de compréhension du contexte plus général et encore moins de conviction qu'il s'agit là de bonnes solutions". Autrement dit, les personnes les plus proches du travail n'ont aucune influence sur la prise de décisions pour aider leurs clients ou tirer parti des solutions existantes.

Au lieu de donner aux équipes l'autonomie de créer de bons produits, cette version ratée de l’agilité tourne autour d'un ensemble de projets approuvés par la direction.

Frederick Taylor se réjouirait de voir que ses enseignements sont toujours utilisés aujourd'hui. "Le travail de chaque ouvrier est entièrement planifié par la direction au moins un jour à l'avance" écrivait-il en 1911 dans The Principles of Scientific Management.

Dans l'approche Taylorienne de l'agilité, les équipes n’existent que pour livrer des projets et des fonctionnalités planifiés à l'avance par les dirigeants. Ce modèle de planification en cascade ralentit les entreprises et rend plus difficile l'adaptation au changement tout en augmentant les risques et le gaspillage.
Comment pouvons-nous les définir comme agiles ? Les professionnels savent qu'utiliser l’agilité pour fournir un plan en cascade présente des avantages limités : 70% d'entre eux signalent des tensions entre leurs équipes et le reste de l'organisation tandis que 63% des échecs d'adoption de l’agilité sont liés au fait que la culture et la philosophie de l'entreprise ne cadrent pas avec celles de l'agilité.

Une meilleure façon

L’alternative pour dépasser l’état d’esprit de l’usine à fonctionnalités est de s’engager dans les quatre principes de Modern Agile. Cependant comment les mettre en pratique ? Comment peut-on "être" agile dans le sens moderne du terme ? 

Il y a un outil exploitable pour l’adaptation évolutive et l’innovation qui, s'il est utilisé correctement, peut appuyer l’adoption des quatres principes de Modern Agile. Cet outil s'appelle les OKRs pour Objectives and Key Results, qui est aussi le cadre de définition d’objectifs utilisé par des entreprises comme Intel, Google ou Spotify. 

La grande différence par rapport aux méthodes de planification traditionnelles ? Les OKRs sont définis et évalués fréquemment - généralement sur un rythme trimestriel. De plus, plutôt que d'être descendus en cascade dans l'organisation par les cadres exécutifs, les OKRs sont bidirectionnels : les équipes créent la plupart de leurs OKRs, alignés avec les objectifs de l’entreprise, puis les actent avec les gestionnaires dans une approche "bubble up".

Cette approche offre un environnement beaucoup plus engageant pour les équipes qui se sentent désormais responsables et imputables des objectifs qu'elles aident à fixer et qu'elles suivent sur un cycle hebdomadaire rapide.

Fixer des objectifs ambitieux est un principe fondamental des OKRs qui stimule la créativité et l’obtention de résultats. Comme l'a rapporté Amantha Imber, les recherches montrent que si nous mettons des gens dans un rôle qui les met au défi 67% feront preuve d'une créativité et d'une innovation supérieures à la moyenne dans leurs performances.

Dan Montgomery l’exprime bien "les OKRs sont le moteur quotidien de l’agilité organisationnelle".

Comment les OKRs peuvent-ils soutenir les quatre principes de Modern Agile?

Livrer de la valeur en continu

L’agilité à l’échelle est difficile parce que passer la livraison à l’échelle (ce pour quoi les organisations adoptent l’agilité) ne passe pas par la valeur à l’échelle. Jeff Gothelf, coauteur de Lean UX and Sense and Respond.

Ainsi que l’a précédemment écrit Felipe ici à InfoQ, le Manifeste Agile se trompe. Le septième principe, "Un logiciel fonctionnel est la principale mesure de progrès", est obsolète et trompeur. Il a été conçu à une époque où les agilistes devaient convaincre les gens que fournir de la documentation ne suffisait pas.

Cette vieille supposition qu’un logiciel fonctionnel est une mesure de progrès repose sur la conviction que tout logiciel qui fonctionne apporte de la valeur. Nous savons maintenant que ce n'est pas vrai. Nous devons fournir un logiciel qui apporte de la valeur - comme dans le premier principe du Manifeste. Modern Agile nous apprend à nous concentrer sur la livraison continue de vraie valeur afin d'aider et rendre nos utilisateurs extraordinaires.

Selon Modern Agile, un élément terminé ou fini n'a d'importance que s'il ajoute de la valeur, comme c’est illustré dans cette grande provocation de John Cutler: "La colonne la plus à droite, souvent oubliée. Ça a marché ?"

Nous devons abandonner les concepts basés sur les tâches comme la Definition of Done, les burn-down charts et la vélocité, pour nous concentrer sur la valeur. A la place de critères d’acceptation nous avons besoin de critères de succès - avec les OKRs.

Bien que la formulation du Manifeste soit trompeuse certains de ses auteurs ont explicitement écrit sur la nécessité de se concentrer sur les résultats:

La clef pour vaincre le modèle en cascade c’est de réaliser que les agilistes préfèrent les résultats aux fonctionnalités. La liste de fonctionnalités est un outil précieux mais ce n’est pas une fin en soi. Ce qui importe c’est le résultat global qui est, à mes yeux, la valeur pour l’utilisateur".  Martin Fowler.

Parce que ce n’est qu’un cadre, les OKRs peuvent être utilisés pour mesurer la production. En revanche, la simple mesure des activités n’est ni une utilisation appropriée des OKRs ni compatible avec Modern Agile. 

Mettre Modern Agile en pratique requiert de définir et évaluer fréquemment des OKRs fondés sur la valeur, ce qui mesure la production et la livraison de valeur pour l’organisation ou les utilisateurs.

Les deux exemples ci-après montrent clairement la différence :

En adoptant des OKRs fondés sur la valeur, les équipes peuvent se concentrer sur la création de celle-ci. Cependant comment le faire "en continu ?"

Le cycle trimestriel des OKRs peut servir de timebox parfaite pour livrer de la valeur : chaque équipe doit générer de la valeur au cours du trimestre en faisant évoluer les Key Results sélectionnés. Au lieu de grandes livraisons en production les équipes se concentrent sur la vérification d'hypothèses, l'expérimentation et l'apprentissage rapide, ce qui nous amène au principe suivant.

Expérimenter et apprendre rapidement

Au lieu d’être pilotée par les données, l’agilité est dénaturée lorsqu’elle est dirigée par l’opinion de la personne la mieux payée (aussi appelée HIPPO: Highest Paid Person’s Opinion) ainsi que brillamment illustré dans le livre How Google Works: 

Les entreprises sont embourbées dans la vieille illusion de l’agilité selon laquelle montrer un logiciel aux parties prenantes lors d'une revue de sprint ou d'une démo est une mesure adéquate de progrès.

Il n'est possible d'expérimenter et d'apprendre rapidement que lorsque nous nous concentrons sur des résultats et des données objectives plutôt que sur des opinions personnelles.

Les OKRs remplacent cette opinion de la personne la mieux payée par des expériences mesurables qui permettent à l’équipe d’apprendre et d’itérer. Ils permettent aux équipes d’adopter des pratiques telles que le développement piloté par les hypothèses ainsi que le décrit Barry O’Reilly:

1. Nous croyons que <cette capacité du produit ou du service>
2. Donnera lieu à <ce résultat attendu>
3. Nous serons rassurés pour continuer à l’étape suivante si <nous voyons ce signal mesurable>

Si notre objectif est un résultat commercial et que nous donnons à l'équipe la liberté d'expérimenter pour l’atteindre, de petits investissements peuvent conduire à des résultats extraordinaires. Dans cet exemple, une fonctionnalité développée en 20 minutes a triplé les ventes de "Know Your Company", tandis qu’Eric Elliott lui, a livré "un ticket Jira qui a fait gagner 1 million de dollars par mois à son employeur".

Rendre les gens extraordinaires

Si vous n’utilisez vos ingénieurs que pour coder vous n’obtiendrez que la moitié de ce qu’ils valent. Marty Cagan.

L'hypothèse sous-jacente du modèle d’usine à fonctionnalités est que l'équipe est incapable de décider quoi construire. Cette approche est basée sur le principe tayloriste de séparation entre la planification et la réalisation, ce qui est à la fois toxique et démotivant.

Le principe de Modern Agile "Rendre les gens extraordinaires" prend ses racines dans les opportunités que nous leur offrons de partager leurs meilleures idées.

Quand votre équipe n’a pas son mot à dire sur ce qu’il faut construire et se contente de vider sa pile d’éléments de backlog les uns après les autres, ils ne sont pas extraordinaires. Qui plus est, vous ne bénéficiez pas de leur pleine contribution. 

Pour vraiment favoriser des équipes autonomes et auto-organisées, vous devez leur donner la liberté de décider comment obtenir les résultats de valeur souhaités. L'objectif de l'équipe doit passer de "fournir les fonctionnalités souhaitées par les parties prenantes" à "atteindre des OKRs définis ensemble et fondés sur la valeur".

Henrik Kniberg a une superbe diapo mettant en évidence ce changement d'objectif:

Dans l'approche agile traditionnelle, les équipes travaillent sur des choses parce que quelqu'un leur a dit de ("Sam", dans l’exemple au-dessus). À l'opposé, les équipes travaillent sur des choses parce qu'elles en ont envie.

Pour rendre les gens extraordinaires, nous avons besoin d’une troisième option. Des équipes qui ont un but et qui comprennent comment elles peuvent avoir un impact. Elles ont une vue claire du lien entre leur travail et la stratégie de l’organisation.

Faire de la sécurité un prérequis

Une équipe de chercheurs de Google a découvert que la principale dynamique qui distingue les équipes performantes des autres est la sécurité psychologique : peut-on prendre des risques dans cette équipe sans se sentir fragilisé ou embarrassé ? Pouvons-nous surmonter la peur et la réticence à s’exprimer avec des idées potentiellement controversées ou poser des questions ?

Un des principes fondamentaux des OKRs est que les entreprises ne doivent pas punir les gens qui poursuivent des objectifs ambitieux. En dissociant les OKRs de la rémunération et des promotions, les entreprises peuvent créer des environnements psychologiquement sûrs où les gens peuvent essayer des idées audacieuses.

Cependant, pour faire de la sécurité un prérequis, les entreprises doivent aussi raccourcir considérablement leurs cycles de validation. Plusieurs années après la sortie de The Lean Startup, la plupart des organisations travaillent encore pendant des mois sans livrer quoi que ce soit à l’utilisateur final.

Elles s’exposent à des risques en ayant des équipes, pour la plupart composées seulement de développeurs, qui livrent aveuglément et de façon incrémentale le contenu en cascade de leur backlog dans un environnement de test, sans aucune forme de validation externe. 
Pour réduire les risques, les entreprises doivent cesser de suivre aveuglément des plans et évoluer d'une intégration continue vers une livraison et une validation continue.

La seule façon que tout se déroule selon le plan c’est de ne rien apprendre. Kent Beck.

Pire, ces plans sont le plus souvent conçus par un seul Product Owner ou un Manager qui n'a parfois même pas accès aux données du produit nécessaire pour prendre de bonnes décisions. Ce genre de situation est démoralisant et dangereux. Mary Poppendieck, auteur de Leading Lean Software Development, a écrit:

La plus grande lacune des pratiques de développement agile est peut-être la manière dont les équipes décident de ce qu'elles doivent faire. [...] depuis longtemps, répondre à ces questions n'a pas été considéré comme relevant de la responsabilité de l'équipe de développement ou de l'équipe DevOps.  Mary Poppendieck.

Les OKRs font de la sécurité un prérequis en s'assurant que les équipes collaborent pour fixer leurs objectifs et décider de ce qu'il faut développer (ou expérimenter) et qu’elles adoptent des boucles de feedback plus courtes, ce qui réduit le risque et le gaspillage.

Ainsi que l’a écrit David J Bland, "[le processus de] planification annuelle et de budgétisation entrent en conflit avec vos efforts pour adapter et changer votre roadmap au fur et à mesure que les apprentissages émergent du marché... Les dirigeants se rendent enfin compte que pour rendre leurs organisations plus agiles, ils devront commencer à s'attaquer à certains de ces dispositifs [fondamentaux] pour atteindre l'agilité organisationnelle".

Conclusion

Comme pour tout autre cadre de planification, les OKRs ne sont pas parfaits et peuvent être mal utilisés. Nous pensons que les quatre principes de Modern Agile peuvent être un guide précieux pour votre pratique des OKRs et un point de départ exploitable pour votre voyage.

Combiner Modern Agile avec une utilisation appropriée des OKRs peut être un moyen léger et agréable pour les entreprises si elles veulent encourager leurs employés à obtenir des résultats extraordinaires.

Pour en savoir plus sur Modern Agile et les OKRs, consultez modernagile.org et felipecastro.com.

Merci à Lael Gold, Joshua Kerievsky, Bill Wake et Tim Ottinger pour leurs premières relectures.
 

Au sujet des auteurs

Felipe Castro est un Goal Hacker. Il aide les organisations à transformer la façon dont elles utilisent les objectifs en adoptant OKR, le cadre de la Silicon Valley pour la définition d'objectifs agiles. Il a créé le cycle Set-Align-Achieve, une méthode simple pour éviter les pièges les plus courants de l'OKR. Suivez Felipe sur son blog : felipecastro.com.

Alexandre Freire Kawakami est un programmeur, coach, scientifique, étudiant et enseignant qui aime repousser les limites de la livraison de logiciels agiles. En tant que directeur général d'Industrial Logic, il se concentre sur la fourniture de logiciels et de services de qualité pour résoudre les problèmes du monde réel de nos clients et aide à fournir les outils nécessaires pour créer une voie vers l'excellence pour son équipe.