Que les personnes le réalisent ou non, la "liberté de choisir" est le principe sous-jacent derrière beaucoup de pratiques Agile. On appelle ce principe les Options Réelles. Une compréhension des Options Réelles nous permet de développer et raffiner de nouvelles pratiques Agile et d’emmener l’Agilité dans des directions qu’elle n’avait jamais prises auparavant. Les Options Réelles nous aident aussi à comprendre pourquoi certaines personnes résistent à certaines pratiques.
En utilisant une phrase familière, le concept des Options Réelles permet de "repousser les décisions au dernier moment raisonnable", qui est un principe explicite de l’approche Lean Software. En évitant les engagements prématurés, on gagne en flexibilité dans les choix que l’on a plus tard. Une définition plus formelle suivra.
Voir l’Agile au travers des Options Réelles
Les Options Réelles sont partout dans les pratiques Agile. Pour illustrer cela, jetons un oeil à quelques pratiques Agile et regardons où les engagements sont évités aussi longtemps que possible. Ce ne sont que quelques exemples. Une fois que vous aurez pris conscience des Options Réelles, vous en découvrirez bien plus.
Le Développement piloté par le comportement (BDD) et le Développement piloté par les tests (TDD) procurent plusieurs options, surtout "l’option de changer le logiciel, en sachant quand on l’a cassé". Sans le développement piloté par les tests, il n’y aurait pas de refactoring. En d’autres termes, le développement piloté par les tests supprime le besoin d’engagements de conception, le choix du design peut être différé jusqu’au début du codage. Plus subtilement, le développement piloté par les tests permet aux développeurs de savoir avec certitude qu’ils ont fini, au lieu de déterminer au préalable quand la programmation sera terminée. Le développement piloté par les tests ne nécessite aucune décision, arrêtez simplement de coder lorsque tous les tests sont verts. De manière similaire, les objets mock permettent aux développeurs de repousser la décision sur l'implémentation d'une classe à une date ultérieure lorsqu’ils auront plus d’informations sur ce qui est requis par la classe. Ils créent également un joli pattern d’implémentation récursif.
XP et Scrum retardent la décision de quelle story développer jusqu'à peu avant le début du développement. Cela permet à l'équipe d'incorporer les informations qui arrivent au dernier moment, comme une nouvelle requête client. Le Backlog Scrum fournit un forum où toute idée pour une fonctionnalité peut être enregistrée sans avoir besoin d'un engagement immédiat pour la construire.
Dans le projet sur lequel Chris travaille, le développement est priorisé à partir des requêtes clients. En effet, les ventes guident le processus de priorisation en présentant l'importance relative d'un client. L'équipe ne commence pas à travailler sur une fonctionnalité tant que les clients ne l'ont pas demandée. Des réunions de "stratégie" ont été annulées il y a plusieurs mois car elles n'étaient que boules de cristal contemplant les fonctionnalités dont l'équipe pensait que les clients aimaient. Maintenant, l'équipe attend de voir ce que les clients demandent vraiment.
En retardant l'engagement sur les fonctionnalités construites, l'équipe a la possibilité de réduire le time-to-market pour les nouvelles fonctionnalités demandées. Quand le client demande une fonctionnalité, l'équipe est libre d'agir, car ils ne sont pas occupés à travailler sur des fonctionnalités non désirées. Cela est uniquement possible avec de courtes itérations et un rapide retournement en test de régression.
Travailler en paire donne des options dans le fait que plus d'un développeur aura une intime connaissance de n'importe quelle partie du système. Cela couvre le risque du "numéro du camion" (a.k.a. "j'ai gagné au loto") ou de la dépendance à "l'homme clé" (le numéro du camion est la taille du plus petit groupe de personnes dans un projet de manière à ce que, si elles se font toutes heurter par un camion, le projet aurait de sérieux ennuis[1]. En répartissant la connaissance du système, le projet n'est pas en danger si quelqu'un dans l'équipe gagne à la lotterie).
Alors que sont les Options Réelles ?
Les Options Réelles sont une approche qui permet aux personnes de prendre des décisions optimales au sein de leur contexte actuel. Cela peut paraître difficile, mais dans l'essence, c'est une vision différente sur le comportement permettant la prise de décisions. Il y a deux aspects dans les Options Réelles, les mathématiques et la psychologie. Les mathématiques des Options Réelles, qui sont basées sur la théorie des options financières, nous fournissent un processus optimal de décision [2]. La psychologie de l'incertitude et de la prise de décision (basée sur la Programmation Neuro Linguistique [3][4] et la théorie cognitivo-comportementale) nous explique pourquoi les personnes ne suivent pas ce processus optimal de décision et prennent par conséquent des décisions irrationnelles.
Les options financières sont des options écrites, de stock et d'actions. Une énorme quantité de mathématiques a été développée pour fixer le prix et gérer le risque de ces options. Les "Options Réelles" sont un terme que nous avons inventé pour décrire notre utilisation des mathématiques des options financières pour nous aider à prendre les décisions optimales du monde réel... Les Options Réelles sont les décisions du monde réel.
Une grande partie de la littérature existante explique comment nous pouvons utiliser le modèle de Black Scholes pour fixer le prix des options réelles. Fisher Black, Myron Scholes et Robert Merton, lauréats du prix Nobel d'économie, ont inventé une équation pour évaluer une option financière. Malheureusement, la plupart de cette littérature est fausse lorsqu'on l'applique aux Options Réelles. On ne peut pas fixer de prix aux options réelles en utilisant la célèbre formule de Black Scholes. Alors qu'un PhD ou un Master en mathématiques financières est nécessaire pour dériver Black Scholes ou prouver les déclarations que nous avons juste émises, aucune compréhension des maths n'est requise pour utiliser les résultats de ces maths.
Les "seules" choses que les maths des Options Financières peuvent nous dire au sujet des options sont :
- Les Options ont de la valeur.
- Les Options expirent.
- Ne jamais s'engager prématurément à moins de savoir pourquoi.
Bien simplement, les maths nous disent de ne pas effectuer d'engagement avant la dernière minute à moins que l'on ne sache avec certitude pourquoi l'on veut prendre cette décision prématurément. Impression de déjà vu ?
Le processus de décision des "Options Réelles" n'est pas nouveau. Preston Smith était l'un des premiers à parler de "S'engager au dernier moment responsable"[5]. Cependant, alors que la déclaration de Preston était une opinion tenant compte de nombreuses observations, les Options Réelles sont basées sur les mathématiques financières.
Pendant l'été 2006, nous avons effectué une série de sessions sur les Options Réelles. Un participant, Iain Brocklehurst, un senior IT manager au sein de JP Morgan a dit "C'est juste du bon sens en bouteille". Les Options Réelles, alors basées sur les maths, se concentrent sur les aspects psychologiques de la prise de décision qui sont probablement plus importants que les maths. Sans comprendre la psychologie, la plupart des tentatives d'implémentation d'un nouveau processus de décision échoueront.
Choix
Pour n'importe quelle décision à prendre, il y a trois catégories de décisions possibles, à savoir, une "bonne décision", une "mauvaise décision" et "pas de décision". La plupart des personnes pensent qu'il n'y en a que deux ; on a soit raison, soit tort. Comme normalement on ne sait pas laquelle est la bonne ou la mauvaise décision, la décision optimale est en fait "pas de décision", vu que cela repousse l'engagement jusqu'à ce que l'on ait plus d'informations pour prendre une meilleure décision.
Cependant, si l'on observe le comportement de la plupart des personnes, on remarque qu'une aversion à l'incertitude fait que les personnes prennent des décisions prématurées. Les Options Réelles adressent cette aversion à l'incertitude en définissant la date exacte ou les conditions à remplir avant que la décision ne soit prise. Au lieu de dire "pas encore", l'approche des Options Réelles dit "Prenez la décision quand ...". Cela donne aux personnes la certitude sur quand la décision sera prise, et par conséquent, sont plus confortables avec le délai de décision. Retarder l'engagement donne aux décisionnaires plus de flexibilité puisqu'ils continuent à avoir des options. Cela leur permet de gérer les risques / l'incertitude en utilisant leurs options.
Les Options Réelles semblent non-naturelles au début. Comme se pencher dans le sens de la pente lorsque l'on skie, ou se pencher en arrière lorsque l'on saute d'une hauteur à cheval. Peu de gens les adoptent naturellement. D'autres ont besoin d'un coach, de temps et de pratique pour les acquérir. Impression de déjà vu ? Peut-être comme l'Agile ? Peut-être que la sensation "non-naturelle" de cette incertitude est l'une des raisons pour lesquelles certaines personnes sont si opposées à l'Agile.
Plutôt que des décisions, les Options Réelles sont véritablement à propos d'engagements. Bien souvent, les personnes prennent une décision qui devient un engagement émotionnel à une idée. Elles ne réalisent pas qu'elles peuvent changer d'avis.
Est-ce que accepter de sortir avec un(e) ami(e) est une option ou un engagement ? La plupart diront un engagement parce qu'ils ont un accord avec leur ami(e), alors qu'en réalité c'est une option. Si quelque chose arrive et vous procure une plus grande valeur (comme le/la partenaire de vos rêves qui vous demande d'aller dans les coulisses d'un concert de U2 avec lui/elle), vous allez appeller votre ami(e) et replanifier. Un accord est une option.
Les options financières ont une date d'expiration contractuelle (date à laquelle elles se terminent, ou expirent). La date d'expiration des Options Réelles est conditionnelle plutôt que contractuelle. L'aspect le plus puissant des Options Réelles est la capacité de repousser la date d'expiration d'une option, donnant ainsi plus de temps pour découvrir une solution optimale. Il y a de la valeur à payer pour repousser un engagement.
Exemples dans le business
Ces pratiques sont déjà utilisées. Comme dit plus tôt, il n'y a rien de nouveau. Trois célèbres sociétés utilisent déjà cela avec succès : Toyota, Microsoft et Google.
La relation de Toyota avec les options est bien documentée dans "Lean Software Development" [6] de Mary et Tom Poppendieck. De notoriété publique, Toyota attend qu'un client achète une voiture avant de commencer à la construire. N'est ce pas là un bel exemple de délai d'engagement ?
La relation de Microsoft avec les Options Réelles est bien connue, comme la fameuse exposition où le stand Microsoft "ressemblait à un bazar". Alors que d'autres sociétés pariaient leur entreprise sur un simple produit ou une simple stratégie, Microsoft couvrait sa position de manière à ce qu'il puisse encore gagner la bataille de l'automatisation des bureaux même s'il perdait sur le front des systèmes d'exploitation. Microsoft est le maître ultime dans la stratégie de l'attente, et l'attente, et l'attente, et on voit. Pensez à l'épisode Internet Explorer où Microsoft à attendu jusqu'à ce que l'internet émerge comme une technologie avant d'y aller. Une question à laquelle nous aimerions avoir une réponse est : "Combien d'équipes de programmation et de solutions Microsoft a-t-il considéré face à cette crise ?" A-t-il adopté la traditionnelle approche de la meilleure solution "optimisant les coûts", ou a-t-il analysé plusieurs alternatives ? Nous suspectons que la réponse est assez évidente.
Google est l'une des premières sociétés Informationalistes[7]. Plutôt que d'entrer en conflit avec ses clients, elle coopère avec eux. Pas de banières publicitaires aléatoires, mais plutôt des publicités pour des produits et services par lesquels vous pourriez en fait être intéressés.
Le Futur de l'Agile
Il est souvent trop facile de détruire les options de quelqu'un d'autre. Par conséquent, les Options Réelles fonctionnent le plus efficacement si les participants coopèrent les uns avec les autres. Cela va à l'encontre des pratiques communes de cacher nos intentions. Cependant, on peut apprendre de l'approche de Google. Après tout, comment puis-je t'aider si je ne sais pas ce que tu veux réaliser... Peut-être que ce pourrait être le point de départ des pratiques de management Agile.
Nous avons besoin d'apprendre comment écouter pour pouvoir aider les autres personnes à atteindre leurs objectifs. D'une manière assez ironique, "Ecouter" est un mot qui n'apparaît pas dans la Déclaration d'Inter-dépendance". Les leaders doivent fournir et créer des options aux personnes avec qui ils travaillent, plutôt que de prendre des décisions pour elles.
Les Options Réelles sont un ensemble de principes qui valident certaines pratiques, comme démontré ci-dessus, et qui peuvent être utilisées pour générer de nouvelles pratiques. Actuellement, l'Agile a besoin de développer des pratiques de Leadership et de Management (au-delà du management de projet) en support de l'état d'esprit agile, pour sortir du département IT et entrer dans le reste de l'organisation.
Pour donner quelques exemples de comment cela pourrait fonctionner, jetons un oeil aux processus de décision et de gestion des ressources.
Processus de Décision
Le processus de décision optimal est comme suit :
- Pour chaque décision, identifiez les options disponibles.
- Identifiez le dernier point auquel la décision peut être prise. i.e. les conditions à remplir pour s'engager. Cela est calculé en examinant les dates limites d'implémentation d'une option, puis en revenant au point de décision (i.e. le Takt time). La première décision est prise lorsque la première option expire.
- Jusqu'à la date d'expiration, continuez à chercher de nouvelles options.
- Tentez de repousser le moment de la décision. Bien souvent, cela est gratuit ou de très faible coût. Pour se faire, nous avons besoin d'avoir la possibilité d'implémenter l'option le plus rapidement possible. Pendant ce temps, travaillez sur comment accélérer le processus (juste comme Toyota fait dans ses usines de production).
- Comprenez que l'optimisation des coûts n'est pas la même chose que l'optimisation des revenus ou la réduction des risques. Parfois, cela vaut la peine d'investir dans plus d'une option, même si cela peut coûter légèrement plus. Après tout, les options ont de la valeur (demandez à Microsoft).
- Attendez pour prendre vos décisions... et attendez... et attendez... jusqu'à ce que les conditions soient correctes.
- Lorsque vous avez besoin de vous engager et d'agir... faites le le plus rapidement possible. Et vous pouvez procéder avec confiance puisque vous savez que vous avez pris la meilleure décision possible.
Récemment, j'ai été dans une réunion où nous discutions du besoin d'un "Plan B". Nous avions un "Plan A". Il y avait une querelle au sujet du besoin d'avoir un "Plan B" tout court. Le succès du "Plan A" était évalué à 99%, 50%... et beaucoup d'autres pourcents. J'ai appliqué les Options Réelles et suggéré que nous identifions en premier quand couper à travers le "Plan B". Nous avons aussi identifié l'investissement initial supplémentaire nécessaire pour faire du "Plan B" une option. Il apparaissait qu'environ dix minutes d'effort étaient nécessaires, mais que cela prendrait quelques jours à faire à cause du grand nombre d'étapes et de départements impliqués. Nous avons entamé l'option "Plan B". De plus, nous avions esquissé ce "Plan B" grossièrement. "Plan A" échoua. Nous savions exactement à quel moment switcher au "Plan B", et tout le monde su ce qu'ils avaient à faire. Le switch fut un processus fluide. Loin de l'expédition d'urgence de tâches, et le chaos résultant, le "Plan B" se passa tellement en douceur que nombre de personnes ne s'étaient même pas rendu compte que nous avions changé de cap à la dernière minute. -- Chris Matts
Une des leçons clés à prendre des Options Réelles est que le bon moment pour décider qu'une idée est une bonne idée, est après l'avoir essayée, plutôt qu'avant de l'avoir entendue.
Management de Ressources
Les Options Réelles, quand appliquées au management de ressources, nous disent que l'on devrait déployer des ressources du moins expérimenté vers le plus expérimenté. Les membres de l'équipe les plus expérimentés, avec le plus d'options (les plus chevronnés etc.) devraient être alloués en dernier. Cela signifie que votre personnel le plus expérimenté peut être déployé pour adresser n'importe quel problème émergent. Alors qu'ils ne sont pas alloués, ils peuvent coacher les membres plus juniors (créant des options) en travaillant en paire avec eux. Cela permet de s'assurer des bonnes pratiques et de suivre l'architecture de l'application. Cela pourrait être le Manager de Projet ou le Lead Développeur. Ils devraient apprendre à être paresseux - un bon début est de lire "Slack" [8] de Tom DeMarco.
Les cadres dans les organisations devraient adopter une stratégie d'investissement basée sur les options plutôt que de s'engager sur des budgets projets. Les cadres devraient repousser l'engagement pour l'investir entièrement lorsqu'ils verront le succès de l'investissement initial ou la validation d'un cas business. L'investissement devrait être effectué pour chaque release basée sur les critères de succès. Le succès ne devrait pas être lié au développement mais plutôt au projet business. i.e. l'augmentation de la valeur business. Un projet où le développement d'une fonctionnalité coûte le double de l'estimation originale serait un succès si l'augmentation du revenu était suffisamment haute. De manière similaire, le projet parfait qui coûte la moitié de l'estimation devrait être viré s'il ne génère pas assez de revenus. Les cadres devraient pouvoir augmenter l'investissement dans un projet s'il se passe bien. Pour pouvoir le faire, ils ont besoin de liquidité de développement du personnel qui est facilitée par une gestion des ressources basée sur les Options Réelles.
Enfin, les cadres dans une société liée à l'IT devraient considérer d'adopter un développement piloté par le client où les vrais clients choisiraient et prioriseraient les fonctionnalités (i.e. les clients qui sont externes à la société, pas les sortes d'experts qui font partie de l'équipe projet). Pour atteindre cela, les départements des Ventes et du développement IT devraient être intégrés. Les ventes donnent un menu à la carte de fonctionnalités (options) aux clients, plutôt qu'une liste de fonctionnalités pour la prochaine release. Les Ventes offrent tout ce qu'il y a sur le menu, ou l'option de choisir quelque chose qui est hors du menu. Pour introduire un nouvel élément, l'équipe brainstorme sur les fonctionnalités, effectue juste assez d'analyse pour déterminer le Takt Time pour la fonctionnalité, et identifier les risques majeurs. Les estimations de Takt time sont données à l'équipe des Ventes pour qu'elles puissent les offrir aux clients. Si les clients ne les veulent pas, ne les construisez pas. S'ils les veulent, faites les. De cette façon, vous évitez de construire les 67% des fonctionnalités identifiées dans le Standish Chaos Report comme "Rarement ou Jamais Utilisées"[9].
C'est l'approche que nous prenons sur nos projets actuels. Les Ventes l'adorent. Au lieu de vendre aux clients les fonctionnalités dont ils ne veulent pas, ils leur demandent ce qu'ils veulent et le leur donnent. Impression de déjà vu ? (si cela marche pour Google...) Nous avons vu l'équipe des Ventes commencer à inviter l'équipe projet aux réunions client pour que l'on puisse expliquer l'approche plus en détails.
Il y a de nombreuses pratiques encore à découvrir...
Un mot de précaution : les Options Réelles sont une stratégie active de gestion des risques. Il est nécessaire de contrôler constamment votre portefeuille d'options pour vous assurer qu'elles ne sont pas en train d'être détruites. De plus, c'est un processus avide d'informations comme il requiert le praticien à activement chercher l'information. Rappelez-vous également que de ne rien faire est une option. Ne rien faire doit faire partie d'un processus actif de décision. Les Options Réelles ne sont pas une excuse pour procrastiner.
Conclusion
Les Options Réelles sont un principe sous-jacent à l'Agile. Beaucoup de pratiques Agile repoussent les décisions aussi longtemps que possible. Les sociétés prospères comme Toyota et Google utilisent les Options Réelles à leur bénéfice. Les Options Réelles nous donnent la possibilité de prendre l'état d'esprit agile et de le projeter dans des zones encore jusque-là inexplorées.
Dernière pensée : l'année dernière, Chris a vu un ami dans un pub à Londres. A la différence de beaucoup de personnes, elle "comprit" instantanément les Options Réelles. Dans les dix minutes qui ont suivies, elle examina les nombreuses implications des Options Réelles. (Cela nous a pris six mois pour comprendre ce qu'elle a compris en dix minutes). Puis elle devint silencieuse. Après quelques minutes de silence, elle dit "Il s'agit de créer un meilleur espace de travail". Elle a raison, mais il y a plus. C'est pourquoi nous les utilisons. Pas parce qu'elle vont nous rendre riches, ce qu'elles feront, mais parce qu'elles sont amusantes.
Amusez-vous :-)
Références
1. http://c2.com/cgi/wiki?TruckNumberFixed
2. http://en.wikipedia.org/wiki/Real_option
3. "NLP Unplugged", Gary Sage & David Hagan,
4. "User Manual for the Brain,' Bodenhammer, Bob G. & Hall, L. Michael
5. "Flexible Product Development" Smith, Preston G.; (Sept 2007)
6. "Lean Software Development", Poppendieck, Tom and Mary; Addison-Wesley Professional (May 2003)
7. Informationalism: "a technological paradigm based on the augmentation of the human capacity of information processing and communication made possible by the revolutions in microelectronics, software, and genetic engineering." From Castells, M. "Informationalism, Networks, and the Network Society: A Theoretical Blueprint." See also http://en.wikipedia.org/wiki/Netocracy.
8. "Slack", De Marco, Tom; Broadway (November 2001)
9. This chart is visible on page 5 of this document: www.clarkeching.com/files/why_your_business_needs_agile_software_development_v1.0.pdf
Rose photo credit - Ed Parcell
A propos des Auteurs
Chris Matts est project manager et business analyst avec plus de dix années d'expérience dans le développement de systèmes de trading et de risques pour des banques d'investissement incluant JP Morgan Chase, BNP Paribas et Dresdner Kleinwort Wasserstein. Ancien développeur, Chris a un Master en Trading Mathématiques et en Finance (incluant les mathématiques d'options financières) et un MEng en Micro-Electronique et Génie Logiciel. Chris est actuellement le programme manager sur un product où il utilise les Options Réelles et des techniques Agile pour intégrer les équipes de ventes et de projets.
Olav Maassen est ingénieur en chef à QNH, Pays-Bas, et possède neuf années d'expérience dans l'IT à faire des projets pour des institutions financières. Il est co-auteur de "Applied Java Patterns". Son intérêt principal est d'aider les équipes à développer du logiciel plus efficacement. Olav lutte pour l'amélioration continue, autant pour lui que pour ceux avec qui il travaille.
Actuellement, Chris et Olav collaborent sur un livre au sujet des Options Réelles et comment elles fonctionnent véritablement.