Gartner estime que les budgets des DSI vont baisser de 8% en 2020 par rapport à 2019.
Dans ce contexte, c’est toujours la même sempiternelle question qui revient : comment faire plus quand on a moins d’argent ?
Il n’y a pas de solution miracle
Si la réponse à cette question était si simple, quelqu’un en aurait fait une méthode et serait devenu probablement très riche en très peu de temps.
Pas de solution miracle donc, mais peut-être des pistes de solutions à chercher dans les modes de fonctionnement de certaines équipes.
Première piste : dépenser moins.
Maigrir : lean, lean, lean…
Il s’agit ici d’optimiser les processus, de standardiser et d’automatiser au maximum pour réduire les coûts. L’approche Lean et ses dérivés dans l’industrie, l’IT ou le Management contient tout un tas de méthodes pour arriver à cet objectif. Cet article à ce sujet est très intéressant : “Sorry, But Lean Is About Cost Reduction…” et identifie certaines pistes :
Eliminer les gaspillages (c’est ce qui est le plus connu dans Lean et parfois on s’arrête là).
Analyser et catégoriser les coûts et s’attaquer aux coûts non justifiés
Rationaliser les activités
Supprimer des postes (mais pas les personnes que l’on emploiera à travailler sur le système)
… Oui mais pas n’importe comment !
Vous noterez que cet article au titre provocateur insiste finalement sur le fait que l’approche Lean n’a pas pour seul but de réduire les coûts, mais permet de le faire si on l’adresse de manière globale et intelligente.
Sur ce point, considérer qu’il est possible de réduire les coûts en supprimant des postes et en demandant toujours plus aux employés a peu de chance d’être rentable. Les coûts cachés ne sont pas loin : augmentation du turnover, de l’absentéisme, désengagement.
Par exemple, cette étude montre qu’une implémentation d’une approche Lean qui ne serait centrée que sur les aspects méthodologiques au détriment des aspects humains peut conduire à une augmentation de 82% du nombre d’arrêts maladie et de 62% de leur fréquence moyenne. En effet, une culture du process à outrance peut conduire à une diminution de l’autonomie et du contenu cognitif du travail, deux facteurs jouant sur la motivation intrinsèque du travailleur comme nous le rappelle Dan Pink dans cette vidéo “la vérité sur ce qui nous motive”.
Simplifier
Vous connaissez les 4 valeurs du Manifeste Agile ? Normalement oui.
Vous connaissez les 12 principes sous-jacents ? Moins sûr n’est-ce pas ?
Je les relisais récemment et l’un d’entre eux me semble totalement aligné avec le thème de cet article : La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.
Apprendre à faire simple pour travailler moins et donc dépenser moins, vous en avez forcément entendu parler.
Innovation frugale vous connaissez ? Allez lire cet article où Navi Radjou nous dit :
“L’objectif est également de faire des produits simples, robustes et durables. Et d’aller vite.”
Qu’est-ce qui nous empêche de faire pareil dans la DSI ?
Planifier juste à temps et pas tout le temps : roadmap produit, sprint planning, et basta !
Estimer par comparaison plutôt que chiffrer : j’ai réussi un jour à réduire à 45 minutes une session d’estimation d’une équipe de 8 personnes qui durait d’habitude 1 journée entière, et qu’ils réalisaient une fois par mois. Je vous laisse faire le calcul des économies réalisées. De mon côté les remerciements des participants de ne plus avoir à subir cette journée infernale m’ont suffit.
CoProj, coPil, CoStrat, ComInvest, etc… Privilégiez la transparence et la visibilité à froid (emails, supports de communication) et ne participez à des comités que si des décisions importantes sont à prendre. Sinon traitez les petites décisions en point à point.
Développeurs, écoutez Uncle Bob et codez proprement avec Clean Code : Keep it simply stupid !
Antoine de Saint-Exupéry annonçait d’ailleurs le Lean et l’Agilité avant l’heure :
La perfection est atteinte, non pas lorsqu’il n’y a plus rien à ajouter, mais lorsqu’il n’y a plus rien à retirer.
Investir
Comment ? Dépenser moins en investissant ? Mais qu’est-ce qu’il raconte ?
Et pourtant : investir au début et régulièrement permet d’économiser sur la durée.
Pas le temps d’industrialiser les tests, il faut qu’on produise de la valeur, c’est notre PO qui l’a dit.
Expliquez donc à votre PO que produire du code sans automatiser les tests aujourd’hui est plus rapide et moins coûteux, mais qu’il est probable qu’il devra repayer une toute nouvelle application dans 3 ans quand celle-ci sera impossible à maintenir.
Nous pouvons regrouper toutes ces pratiques d’automatisation (des tests, des déploiements, de l’infrastructure) sous le terme chapeau de DevOps (je préfère parler de BizDevOps). Ces pratiques et outils nous servent à faire des économies :
moins d’évaluation et de gestion des risques en amont car on teste plus tôt et on obtient rapidement les feedback des utilisateurs
moins de charges de recette manuelle qui ont tendance à augmenter de manière exponentielle avec le temps
moins de temps perdu à bricoler parce qu’on n’a pas à disposition les bonnes données ou l’environnement pour les tests de performances (coucou Infrastructure as code)
Sans oublier que BizDevOps, c’est avant tout un mode de fonctionnement qui favorise les interactions et la collaboration. Qui n’a jamais entendu une phrase du type : « Mon job c’est développeur, …peu importe ce qui arrive …je développe » ? Phrase qui annonce de bien mauvaises nouvelles dans quelques sprints…
Deuxième piste : produire plus de valeur
Prioriser
Cela fait plus de 10 ans que je travaille autour de l’agilité. Ce qui m’avait passionné dès le début, au-delà de l’amélioration des interactions et des relations humaines qui en découlent, c’est la priorisation par la valeur. Je ne sais pas combien j’ai fait d’ateliers avec des Product Owners (PO) pour les aider à appliquer ce principe si simple à énoncer, si difficile à mettre en œuvre.
Évidemment, aujourd’hui tout le monde est d’accord sur le principe de faire d’abord ce qui a le plus de valeur. Il y a 10 ou 20 ans, ce n’était pas si naturel, puisque de toute façon il fallait tout faire, alors pourquoi ne pas commencer par le plus facile, ou le plus difficile…
Avec mon équipe de coachs agiles, nous avons créé une école pour les PO d’une grande entreprise leader du e-commerce. Nous avons dédié un module entier d’½ journée à la valeur. Pas à la priorisation, mais à la représentation de la valeur. Car c’est un travail qui peut être extrêmement complexe. Il consiste à identifier les drivers ayant un impact sur la valeur et à les catégoriser : risques, valeur intrinsèque, valeur d’investissement, technologies…
En travaillant sur la priorisation du backlog, le processus de développement en agile permet donc, pour un coût constant, de livrer en premier des fonctionnalités qui génèrent plus de valeur.
Alistair Cockburn nous propose d’ailleurs la définition suivante :
“Agile is early delivery of Value and less bureaucracy”
Comprendre et mesurer
Pour produire plus de valeur, il faut probablement développer sa compréhension des utilisateurs et des clients.
Et pour aller plus loin que cette simple phrase, j’aime beaucoup la combinaison des 3 approches Design Thinking + Lean Startup + Agile :
Design Thinking ou l’approche centrée utilisateur vise à se mettre à la place du client/utilisateur pour bien comprendre quels sont ses problèmes.
Lean Startup permet de poser des hypothèses sur les solutions à mettre en oeuvre en face de ses problèmes, et de boucler très vite pour savoir si nos hypothèses sont bonnes, ou pas.
Le développement Agile permet d’organiser le processus de livraison des fonctionnalités de sorte que ce soit régulier (itératif) et incrémental en priorisant par la valeur (comme vu précédemment).
Si même le Gartner le dit…
La combinaison de ces 3 approches est pour moi indispensable dans la réussite d’un produit car on peut très facilement en arriver à développer vite et bien des fonctionnalités parfaitement inutiles. J’intègre tout cela dans tous mes accompagnements pour product owners et product managers.
Au final : lean et agile, la solution ?
Ce qui définit l’Agilité, c’est cette importance donnée à l’apport de valeur plus qu’à la réduction des coûts. Il y a bien sûr une recherche d’efficacité, mais surtout d’efficience.
Avec plusieurs années d’expérience derrière moi, une combinaison des 2 est probablement une bonne approche : optimiser au maximum ce qui va être répétitif (tests, déploiements…) et accélérer au maximum le processus de création de valeur (priorisation, less is more…).
Comme dans un bon cocktail, tout est question de dosage et de vision globale : pour avoir un système efficient, il se peut que certaines parties du système ne soient pas optimisées au maximum, générant de fait une capacité à innover et à créer plus de valeur.
Pour arriver à trouver ce bon dosage permettant de produire plus de valeur, plus vite et avec moins d’argent, vous avez probablement besoin d’une bonne équipe produit qui :
Comprend les problèmes réels de ses clients (avec un profil UX par exemple dans l’équipe)
Expérimente fréquemment des morceaux de solutions pour mieux comprendre son écosystème et valider ses hypothèses (avec le Lean Startup). Cela implique de systématiquement mesurer a posteriori de la livraison les indicateurs liés à ces hypothèses, chose qu’on a parfois tendance à oublier de faire
Développe son produit avec des principes agiles : en favorisant les interactions, en livrant fréquemment des fonctionnalités en production, en documentant le nécessaire et en étant ouvert à des changements fréquents (vous avez reconnu les 4 valeurs du Manifeste Agile ?)
Met en place un système de mesure de la performance et s’organise pour l’améliorer en continu (avec le Lean). Je me permets d’insister sur ce dernier point : la mise en place d’une véritable démarche d’amélioration continue est la base de l’optimisation d’un système. C’est également ce qui fait trop souvent défaut dans les implémentations Agiles qui prennent insuffisamment en compte le changement de mindset nécessaire
J’ai observé personnellement une équipe de 6 personnes (PO, UX, devs) produire en 6 semaines ce qu’une équipe de 12 n’avait pas réussi à finaliser en 6 mois.
Leur différence ? Probablement un peu plus d’expérience (et donc un TJM plus élevé coucou les fausses économies) et surtout une capacité à se poser les bonnes questions.
Rappelez-vous A. Einstein qui disait :
“Si j’avais une heure pour sauver le monde, je passerais 55 minutes à définir le problème et cinq minutes à trouver la solution.”
Attention je le répète : ceci n’est pas une solution miracle. Ca ne fonctionnera pas si votre organisation n’est pas collaborative, si vos métiers et vos IT ne savent pas se parler, si votre management met des bâtons dans les roues plutôt que d’aider les équipes de dev. Mais si vous prenez maintenant ce chemin, ce sera toujours mieux que la situation actuelle. C’est dans les situations de crise que l’Homme est le plus innovant.
Une entreprise leader du e-commerce fait face à une croissance très rapide de ses effectifs. Une réorganisation des équipes vers un recentrage sur le métier et les clients est nécessaire pour gagner en agilité et réactivité, mais aussi pour favoriser l’innovation.
Un « Head of Product » est nommé, qui a pour objectif de mettre en place 50 équipes produit en 18 mois.
Solution
Cadrage et mise en œuvre de la transformation de l’organisation :
Formalisation des apports de la nouvelle organisation
Découpage du programme en 20 chantiers
Identification des directions pilotes et initialisation du plan de transformation
Accompagnement sur la communication : prises de paroles de membres du COMEX, réalisation de contenus (réseaux sociaux, vidéos…)
Conception et animation d’une « Ecole du PO » visant à former les Product Owners
Conception et animation d’une formation sur le Leadership Agile à destination des managers
Mise en place dans les équipes d’un système de mesure de la performance basé sur les Objective Key Results (OKR)
Accompagnement de la direction de la transformation pour identifier les impacts de la nouvelle organisation sur l’existant
Bénéfices
Forte autonomie et sentiment d’appartenance dans les équipes produits
Les PO deviennent des chefs d’entreprises
Rythme de livraison des incréments de valeur accéléré
Les autres success stories qui peuvent vous intéresser
Dans le cadre de sa transformation, Claranet souhaite acculturer ses référents produits à la culture produit et développer ses pratiques de product management avancées. De par la grande variété des produits adressés par Claranet, les pratiques abordées devront autant couvrir les thématiques de discover que que build tout en permettant une projection sur les problématiques terrains concrètes rencontrées par les équipes.
Solutions
Après une phase de personnalisation de parcours, avec l’équipe Portfolio, en charge du catalogue de produits Claranet. Un parcours de formation de 7 modules renforcés de 3 open spaces dédiés à des cas pratiques d’application terrain, est déployé sur 4 mois.
Bénéfices
Des référents forts capables de retranscrire et d’infuser la culture produit dans l’organisation
Des outils précis et de référence adaptés à chaque contexte
Résolution de problématiques terrains & facilitation à l’émergence de nouveaux produits innovants
Les autres success stories qui peuvent vous intéresser
Il faut que je vous avoue que lorsqu’on me demande sur quelle certification agile je peux former les gens, j’ai parfois un peu honte de dire que je peux le faire sur SAFe avec la Scaled Agile Academy.
Aussi, je m’empresse le plus souvent d’ajouter que je suis aussi formateur licencié Management 3.0. Comme pour me dédouaner.
Cette opposition de genres peut surprendre. Encore plus lorsqu’on connaît également mon penchant pour les organisations plates (pour ne pas dire entreprises libérées) et les interventions et articles que j’ai pu faire à ce sujet.
Pour autant, je ne vois pas cela comme une schizophrénie. Et oui, j’ose le dire, j’aime bien SAFe !
Alors pourquoi SAFe est-il un framework qui crée autant de débats ? Pourquoi est-ce que cela peut sembler honteux d’utiliser SAFe ? Autrement dit, SAFe est-il vraiment agile ?
Je vous propose de décrypter tout cela à travers 9 affirmations. 9 arguments massue trop souvent utilisés pour jeter SAFe en pâture dans la fosse aux lions. 9 critiques à la véracité insuffisamment questionnée.
Non, je ne vous ferai pas le coup des “10 affirmations sur SAFe, la 10éme va vous étonner…” mais restez quand même avec moi jusqu’à la fin ;).
Pour commencer, je reviendrais sur l’une des sentences les plus souvent prononcées à son encontre : “SAFe est trop complexe”.
C’est une affirmation que je peux totalement comprendre. Pour qui a un jour regardé le poster SAFe, cela peut même sembler une évidence, tant on peut se trouver perdu à son premier regard.
Pourtant ce défaut de complexité, au-delà du fait qu’il n’est surtout qu’apparent et s’éclaire grandement quand on appréhende pleinement la logique du framework, est l’une des véritables qualités de SAFe.
Si le framework est compliqué, c’est qu’il imbrique beaucoup de sources de connaissances différentes. Il s’attache à faire le lien entre elles ; ce qui n’est jamais chose facile.
En y regardant de plus près, c’est cependant une manière (mais pas la seule) de construire une véritable approche systémique. Réunir autant de savoirs différents, c’est s’attacher à ce que l’ensemble des aspects de l’équation soient pris en compte. Et de ce point de vue, je pense que c’est le framework qui permet la meilleure vision d’ensemble. On y retrouve du lean startup, du design thinking et de l’UX, du Scrum, du Kanban, du DEVOPS (dont le continuous delivery), du Beyond Budgeting et de la gestion de portefeuille, du Management 3.0, du Lean etc.
On a donc une vision qui n’oublie ni les personnes, ni les pratiques, ni la stratégie, ni le client, ni les environnements, ni le management et ni même la culture !
Donc oui, SAFe peut être complexe (au sens des systèmes complexes), mais c’est une complexité nécessaire. Je citerais d’ailleurs à ce sujet Max Boisot qui dit:
La complexité d’un système doit être en adéquation avec la complexité de l’environnement dans lequel il se trouve.
Max Boisot
The Interaction of Complexity and Management
Cela dit, SAFe ne cherche aucunement à être complet sur l’un ou l’autre de ces composants. Il propose des outils dont il nous laisse en partie le soin d’approfondir le contenu.
Il n’y a par exemple pas d’explication détaillée du Gemba, qui fait partie des éléments inhérents à une approche Kanban. Bien que s’appuyant sur Kanban (et plus largement le Lean), SAFe considère que c’est à nous d’en maîtriser les concepts.
Sur ce sujet, SAFe n’impose d’ailleurs aucune méthode. Pour preuve, même si Kanban est devenu aujourd’hui un pilier important, il était autrefois cantonné à la seule gestion de portefeuille. Jusqu’à la V4 du framework en effet, seul Scrum était utilisé comme moyen de piloter une équipe agile.
SAFe est ainsi un framework qui, en son coeur, encourage la sélection des pratiques et outils. Ce qui nous permet alors de nous adapter à l’environnement auquel nous sommes confrontés. Ce faisant, nous pouvons sélectionner le juste niveau de complexité dont nous avons besoin !
2. SAFe n’a rien inventé (sous-entendu “donc c’est pas bien !”)
[br]Autre objection que l’on entend trop souvent, SAFe n’aurait innové en rien ! C’est tout d’abord un faux reproche. Il est parfois plus utile de relier des savoirs que d’en créer de nouveaux. Je rappellerais d’ailleurs cette citation de Bernard de Chartres reprise par Pascal ou même Newton en leur temps :
Nous sommes comme des nains assis sur des épaules de géants. Si nous voyons plus de choses et plus lointaines qu’eux, ce n’est pas à cause de la perspicacité de notre vue, ni de notre grandeur, c’est parce que nous sommes élevés par eux.
Bernard de Chartres
Metalogicon – Livre III
Pour autant, SAFe est un framework qui a lui aussi apporté sa pierre à l’édifice de l’agilité. L’intégration des savoirs agiles et la proposition d’une représentation cohérente à l’échelle de l’entreprise n’est déjà en soi pas un mince exploit. Quand bien même cela aurait été la seule contribution de SAFe, cela aurait eu de la valeur. Mais SAFe va plus loin. Au-delà de cette mise en cohérence, il amène également ses propres nouveautés.
J’en citerai simplement deux: le PI Planning et l’intégration des architectes au coeur de l’agilité.
Le PI Planning est certainement le plus emblématique des apports de SAFe. Qui aurait pu penser que réunir jusqu’à 125 personnes pendant deux jours était une bonne idée ? Pour autant, cet événement est loin d’être la foire à laquelle on pourrait s’attendre. En vivre un est même bien souvent déterminant pour convaincre une entreprise de s’engager dans SAFe. Et ce quand bien même le PI planning peut justement être l’un des éléments qui auraient tendance à faire peur !
Ce sont d’ailleurs généralement ces mêmes détracteurs du PI planning qui viennent ensuite en faire l’apologie. Ils sont enthousiastes face à l’énergie libérée et l’efficacité avec laquelle les problèmes sont gérés. Ils sont surpris de la transparence et de la vision apportées, heureux de l’engagement suscité.
L’intégration des architectes dans SAFe, même si elle est moins souvent mise en avant est également très intéressante. D’abord elle permet de casser un tabou ! Celui d’une agilité qui ne pourrait pas avoir de vision à moyen terme ou de planification.
En effet, les architectes ont longtemps été les laissés pour compte de l’agilité. Le fait de chercher à obtenir des équipes auto-organisées, autonomes et ayant toutes les compétences pour réaliser le produit a pu être vu comme une critique de leur rôle.
Il faut dire qu’ils avaient fini par être perçus comme un élément de rigidité des organisations. En codifiant les méthodes, outils et langages à utiliser ils venaient entraver les besoins d’adaptation des équipes agiles. La guerre était déclarée.
Pourtant l’autonomie sans vision partagée est la meilleure recette du chaos. Sans celle-ci, il est impossible de créer l’alignement et chacun part dans sa propre direction.
SAFe en intégrant le rôle d’architecte aux différents étages du framework, redonne ce rôle de porteur de sens. Les architectes ne sont plus là pour établir une vision figée de l’organisation, mais une vision évolutive.
Ils viennent donc en soutien des équipes en permettant l’alignement de celles-ci avec des approches dont ils garantissent la cohérence. Ils s’assurent également que si les choix sont ouverts en début de réalisation, ils finissent par se stabiliser avec le temps. Ils permettent ainsi d’éviter l’oscillation permanente qui frappe parfois certaines équipes agiles, incapables de converger vers une solution.
3. SAFe est un framework de command and control
L’idée que SAFe serait en fait une approche de command and control, est peut-être la dernière grande critique que l’on entend régulièrement professée à son égard.
Cette notion d’une approche dictatoriale est sans doute accentuée par le célèbre poster de SAFe. Cette représentation détaillée peut en effet donner l’impression d’un framework très orienté processus. Visuellement, la représentation des différents étages de coordination en se rapprochant des structures pyramidales des sociétés, peut laisser penser à une forme de hiérarchie. Une idée bien ancrée dans l’esprit de certains.
Je soupçonne néanmoins la Scaled Agile Academy de maintenir volontairement une certaine ambiguïté sur le sujet. À travers son poster et sa représentation à étages, SAFe laisse penser à une continuité du fonctionnement hiérarchique de l’Ancien Monde. Un choix qui explique le succès commercial de SAFe. Cette représentation de l’agilité, proche des méthodes traditionnelles, et de nos anciennes croyances, est en effet bien plus rassurante aux yeux des dirigeants.
Malheureusement, cette vision d’un SAFe qui ne nécessiterait pas de changer notre compréhension du monde, mais d’adopter simplement de nouveaux processus est également une des raisons principales d’échec de son implémentation.
SAFe, comme tout framework agile, nécessite savoir-faire et savoir-être. Ce dernier étant essentiel ! N’appliquer bêtement que les processus (le savoir-faire), ne peut donc qu’engendrer un échec.
SAFe nous prévient pourtant dès le départ. Il n’est pas une recette prévue pour une application dans sa globalité. Il doit être adapté. Au-delà même des sous-ensembles directement proposés que sont l’Essential SAFe, le Large Solution SAFe, le Portfolio SAFe ou le Full SAFe. C’est une adaptation qui demande une véritable conscience (au sens de savoir-être) des principes et valeurs de l’agilité.
Pour ma part, il m’arrive assez fréquemment de mettre en place chez mes clients une couche de gestion de portefeuille inspirée du Portfolio SAFe. Alors même que les projets/produits ne nécessitent pas de mécanismes d’agilité à l’échelle. Elle apporte en effet un bénéfice réel à l’organisation par les mécanismes de priorisation des projets/produits qu’elle propose.
SAFe est donc un framework qui, peut-être plus que d’autres, peut facilement être dévoyé et implémenté de manière coercitive. On perd ainsi tout bénéfice d’agilité.
Pour autant, il ne m’a jamais empêché de discuter avec certains clients d’organisations plates alors que nous faisions une implémentation de SAFe. Dans le fond, il n’y a rien d’incompatible à ce qu’une entreprise Opale utilise ce framework.
Si l’on peut certes reprocher l’ambiguïté, SAFe n’en reste pas moins un framework agile. Ce n’est pas SAFe qui est anti-agile, mais ce que nous en faisons qui le transforme en outil de command and control.
4. Les métriques dans SAFe sont un retour vers l’utopie de la prédictibilité
Autre critique que l’on entend surtout parmi les agilistes, SAFe propose une approche des métriques qui peut sembler un peu utopique. Dans un monde complexe (et donc volatile du fait des mécanismes d’émergence), SAFe donne l’impression de chercher à tout prédire. C’est une partie que j’ai personnellement mis un certain temps à maîtriser.
En fait, SAFe ne cherche pas à obtenir un chiffre précis, juste et absolu. Son approche des métriques est un moyen d’éclairer la prise de décision. Autrement dit, c’est un moyen de vérifier nos hypothèses, de détecter les changements éventuels et de s’y adapter le mieux possible.
Prenons pour exemple la mesure de prédictibilité du train, qui se base sur le pourcentage de business value atteinte. Cette mesure n’est pas tant effectuée pour suivre l’avancement de nos engagements que pour déterminer à quel point notre environnement est changeant. On ne cherche pas à savoir si l’on va tenir nos objectifs, mais à ajuster notre manière de piloter en fonction du degré d’incertitude de l’environnement dans lequel on se trouve.
Si parfois l’expérience montre une certaine fiabilité dans l’atteinte de nos engagements, tant mieux ! C’est que nous sommes dans un environnement relativement stable. Nous pouvons alors poursuivre une certaine stratégie d’efficience.
Si au contraire la prédictibilité du train est faible, c’est que notre environnement est extrêmement incertain. Dans ce cas, il ne convient pas de rechercher l’efficience. C’est tout l’inverse. Il faut alors s’attacher à développer nos capacités d’adaptation. Cela veut dire se préserver un maximum d’options, le plus tardivement possible (on pourrait aussi travailler à accroître la stabilité de notre environnement. Tout un challenge !).
Le fait que SAFe repose sur un paradigme de changement se retrouve à la fois dans son fort focus sur la création de valeur et dans la manière dont il la définit.
Dans un contexte où nous ne maîtrisons pas l’évolution de nos écosystèmes, il est en effet essentiel de s’assurer d’investir de manière à ne jamais regretter nos choix. Même si nos prévisions étaient déjouées.
C’est pourquoi SAFe, tout comme l’agilité de manière générale, cherche à travailler en permanence sur les éléments dont nous estimons pouvoir dégager le plus de valeur. Le travail est même découpé d’une manière qui nous permette d’en retirer le maximum de bénéfice, quel que soit le moment où nous devrons procéder à des ajustements.
Autrement dit, face au changement, il s’agit d’être dans une situation où force est de constater que nous n’aurions pas pu mieux nous organiser. Nous n’aurions pas pu créer plus de valeur. Nous n’aurions pas pu mieux limiter nos pertes. À moins évidemment d’avoir eu connaissance du changement à l’avance, mais ce serait là un biais de lecture a posteriori…
Comme je le disais, cette incertitude se retrouve jusque dans la façon dont SAFe définit la valeur. C’est en effet le seul framework à parler d’hypothèses de bénéfices et non de bénéfice tout court.
Il met ainsi en lumière le raccourci trop souvent commis entre la valeur escomptée d’un projet/produit et sa valeur réelle après rencontre avec le marché.
En ajoutant cette notion d’hypothèse, SAFe met en exergue la nécessité de piloter le bénéfice escompté. Dès la réalisation de l’epic hypothesis statement, le framework recommande la définition d’indicateurs de pilotage de la valeur (les leading indicators).
Par la suite, ces KPIs permettront de vérifier la justesse de nos suppositions et de mieux détecter les éventuelles adaptations nécessaires (dans nos priorités comme dans notre stratégie). C’est une approche typiquement Lean Startup dans l’esprit (et une belle utilisation de l’innovation accounting) !
De tout cela on retiendra surtout que SAFe ne cherche pas tant la prédictibilité ou la mesure exacte que l’obtention d’informations suffisantes pour prendre des décisions et les piloter.
5. C’est vraiment compliqué d’évaluer la valeur dans SAFe
Au rang des critiques portées à l’encontre de SAFe, on entend encore celui de la manière dont la valeur y est évaluée. Ce n’est pas sans lien avec les reproches faits au regard de l’apparente précision des métriques et leur illusion de prédictibilité.
Sur ce point, il est essentiel de bien comprendre que lorsque SAFe tâche d’évaluer la valeur d’un élément (notamment avec un WSJF), il n’essaie pas de le faire de manière absolue, mais de manière comparative. En ce sens, il est tout aussi facile de mesurer un WSJF dans un contexte logiciel que de production.
Le Cost of Delay effectif de l’élément A reste certes inconnu, mais sa comparaison avec l’élément B reste relativement facile à réaliser et facilite la décision de prioriser l’un par rapport à l’autre.
En cela nous sommes proches de l’esprit de How to measure anything (de Douglas Hubbard) : il ne s’agit pas d’avoir un chiffre précis, mais bien d’avoir un encadrement de celui-ci par un intervalle de confiance suffisant. Toutes choses étant égales par ailleurs et tous nos biais de mesures et erreurs étant d’une magnitude similaire, nous pouvons ainsi prendre des décisions justes sur la base d’évaluations pareillement fausses.
À ce sujet, j’aime bien évaluer la valeur en m’appuyant sur des mécanismes d’intelligence collective (diversité, décentralisation et indépendance/autonomie suivant James Surrowiecki, l’auteur de La Sagesse des foules).
Pour cela il suffit le plus souvent d’avoir un groupe de personnes suffisamment diversifié et d’utiliser des techniques adaptées de la magic estimation (qui permettent de comparer au plus vite un grand nombre de critères entre eux).
C’est parfois étonnamment rapide. J’ai ainsi pu évaluer le WSJF de près de 80 projets et les prioriser en moins d’une journée avec une dizaine de membres d’un COMEX !
Personnellement, j’apprécie également le côté global de la manière dont SAFe aborde l’évaluation de la valeur. Elle prend en compte aussi bien la user business value (incluant la valeur de satisfaction client) que la valeur liée au coût de ne pas faire (la fameuse Time Criticality) ou la valeur indirecte (réduction de risque et développement d’opportunités futures).
En cela, le framework est plus riche qu’un simple Scrum. Il ne se contente pas de la seule valeur business mais rend explicites d’autres types de valeurs. En retour l’attention constante pour la satisfaction client peut cependant paraître moins évidente.
Ainsi, même si SAFe nous incite à évaluer la valeur sur plusieurs axes, le fait de le faire de manière comparative ne rend pas les choses plus compliquées qu’avec une autre méthode.
6. SAFe, contrairement à LeSS ou au modèle Spotify n’est pas adapté à une démarche produit
On a tendance à penser qu’un framework adapté pour des projets à 125 personnes et plus n’est pas pertinent pour l’adoption d’une démarche produit. C’est là encore une critique que j’ai pu entendre surtout en comparaison avec LeSS ou le modèle Spotify.
On précisera d’abord, comme nous le rappelle Séverin, qu’il n’y a pas de modèle Spotify. Il ne s’agit que d’un retour d’expérience. Une expérimentation dont le bénéfice, même chez Spotify, est aujourd’hui remis en question. Il n’y a rien de magique. Spotify n’a finalement rien fait de plus que de créer une organisation spécifique à son contexte. Si le mot feature teams peut sembler sexy, il ne s’agit pour autant pas d’autre chose que d’une équipe pluridisciplinaire.
Ceci étant posé, SAFe est bien lui aussi un framework construit pour fonctionner dans une démarche produit. C’est sans doute moins visible que dans le framework LeSS, car SAFe se veut plus versatile. Il cherche à la fois à pouvoir définir le fonctionnement d’une organisation complète et à permettre la cohabitation de différentes démarches (y compris donc du cycle en V avec de l’agilité).
La vision produit de SAFe est essentiellement portée par la manière de financer les values stream et l’approche capacitaire qui en découle. À travers cela, SAFe promeut la stabilité des équipes dans le temps.
Il facilite également le suivi des produits tout au long de leur cycle de vie en n’externalisant pas la gestion du run. Dans cette logique, SAFe introduit Kanban comme méthode de gestion au niveau équipe lors de la parution de sa V4. Il permet ainsi un meilleur pilotage d’activités de build et de run simultanées, courantes lorsqu’on travaille sur un produit.
Au niveau équipe, SAFe met également en avant la constitution d’équipes organisées en feature teams avec toutes les compétences (quand c’est possible) pour développer et maintenir l’intégralité du produit.
Cela fait d’ailleurs relativement sourire de voir SAFe opposé au retour d’expérience de Spotify dans la mesure où les équipes pluridisciplinaires sont bien présentes dans le framework (de mémoire au moins depuis la V3 et avec les communautés de pratiques et d’intérêt dès la V4).
Il serait donc temps d’arrêter de déifier le modèle Spotify et de le prendre pour le retour d’expérience qu’il est.
L’organisation en feature teams, l’utilisation de Kanban ou la promotion d’équipes pérennes sont autant d’éléments de SAFe adaptés à une approche produit.
7. SAFe n’est que pour les grosses entreprises
Si l’on arrive à faire face à tous ces arguments anti-SAFe, il en reste encore un qui tient à l’idée que SAFe ne serait de toute façon adapté qu’à de grandes organisations.
Ce n’est pas totalement faux. À moins de 50 personnes sur un projet, SAFe a effectivement peu d’intérêt. Dans ce cas, le surcoût de pilotage nécessaire surpasse le plus souvent les bénéfices obtenus.
De manière générale d’ailleurs, la première règle de l’agilité à l’échelle devrait être de ne pas faire d’agilité à l’échelle !
Trop souvent, on cherche en effet à mettre en place des mécanismes d’agilité à l’échelle pour compenser un manque de rigueur dans l’optimisation du système.
Affronter les problèmes en face est difficile. Changer une culture peut sembler un véritable travail d’Hercule. Rechercher les causes racines d’un problème est bien plus délicat que de trouver un coupable. Aussi, pour ne pas remettre en questions nos habitudes, on s’efforce trop souvent de compenser en ajoutant plus de monde sur le projet ou en essayant d’appliquer le dernier framework à la mode.
Plutôt que de prendre le risque d’adopter une véritable démarche d’amélioration continue et de régler les problèmes qui nous font face, nous choisissons de grandir dans une fuite en avant. Nous cherchons à avoir toujours plus de ressources en espérant que cela va miraculeusement tout résoudre!
Si je me souviens bien, Alistair Cockburn rapportait d’ailleurs cette anecdote : sur un projet, il avait déterminé qu’avec les bonnes personnes, il était réalisable avec 6 développeurs. Comme il ne les avait pas, il lui en fallait 50 !
Cela étant, il y a bien sûr des situations où il est indispensable de faire grandir les projets. C’est là une des forces de SAFe qui propose un système facilement scalable.
J’ai déjà dit qu’il m’arrivait de n’avoir recours qu’à la partie Portfolio du framework, mais il est aussi possible de n’utiliser que l’une ou l’autre des couches. Si vous le souhaitez, vous pouvez parfaitement vous contenter de ne mettre en place qu’un seul train. Non seulement rien ne vous force à tout déployer, mais il sera par ailleurs très facile d’ajouter de nouveaux éléments ultérieurement.
La règle devrait être de ne mettre en place que le strict minimum de processus que vous pensez nécessaire et ceci fait d’en retirer encore ! De manière surprenante, vous vous rendrez compte que même ces éléments que vous pensiez indispensables et que vous venez de supprimer n’ont rien d’obligatoire.
Ainsi, nul besoin d’être un grand groupe du CAC 40 pour utiliser SAFe, le plus important c’est d’adapter et de ne pas vouloir systématiquement utiliser tous les étages de la fusée !
8. Pour faire de l’agilité à l’échelle, il vaut mieux construire son propre framework
À en croire certains SAFe ne serait finalement pas un bon framework d’agilité à l’échelle, car chaque entreprise étant unique il n’est pas possible d’avoir une solution pertinente pour tous. Il vaudrait donc mieux concevoir son propre framework.
C’est d’ailleurs la tendance dans tous les grands groupes. J’ai pu participer à la création de quelques-uns et en observer d’autres. Je dois avouer que cela m’a laissé perplexe…
Certes, on peut se féliciter de voir que même les grands groupes, pourtant peu connus pour leur rapidité à s’adapter, ont fait leur ce principe d’adaptation de l’agilité au contexte. Cependant, je ne peux que constater que tous ces frameworks maison, ne sont en fin de compte que de pâles copies de SAFe. J’ai même pu observer l’intervention de grands noms du conseil qui en créant ces modèles, ne faisaient rien d’autre que recopier SAFe. Parfois, et c’est un comble, ils y ajoutaient même des erreurs !
Il en résulte que toutes ces tentatives de développement d’une solution maison aboutissent souvent à des coûts importants, des délais à rallonge et un framework déjà obsolète au jour de son lancement ! Il n’y a rien de surprenant à cela.
En effet, vouloir dès le début se construire une approche spécifique, c’est le faire au plus mauvais moment. Celui où nous ne maîtrisons ni l’agilité, ni ses conséquences sur notre organisation.
Bien sûr, il y a de nombreux frameworks d’agilité à l’échelle. Mon propos n’est pas de dire que SAFe est le meilleur d’entre eux. Je dirais surtout que c’est probablement le moins pire !
Ce qui est essentiel n’est pas d’en faire une implémentation rigide, mais de le prendre comme point de départ.
C’est un moyen de se construire une expérience de l’agilité à l’échelle au sein de notre organisation et de notre contexte.
Cela n’est en aucun cas un objectif ou une destination !
Alors que nos connaissances sur la nature de notre environnement, nos particularités culturelles et les attentes de nos clients progressent, nous pouvons alors commencer à élaborer nos adaptations en connaissance de cause. Il sera alors temps de concevoir une approche dans un esprit de continuous organization. C’est-à-dire, une entreprise capable de se réinventer et de s’améliorer en permanence.
Ainsi utiliser SAFe comme point de départ est un raccourci intéressant. Cela nous évite de devoir directement construire une approche spécifique, à un moment où notre compréhension des mécanismes est largement insuffisante. Créer son propre modèle quand on n’en a pas la maturité est une perte de temps. Tout comme faire de SAFe une vérité absolue à suivre à la lettre serait une erreur grossière
9. SAFe n’est pas de l’agilité à l’échelle
Quant à la dernière objection à faire à SAFe, c’est à moi d’intervenir et de la soumettre à votre réflexion. Si l’on en revient au coeur du problème qui est la manière de faire de l’agilité à l’échelle, je crois que SAFe, LeSS, DAD et autres Nexus sont tous foncièrement biaisés.
Face aux problématiques d’échelle, tous ces frameworks proposent de gérer la complexité liée à l’augmentation du nombre d’échanges (facteur d’émergence) par ajout de processus (ou mécanismes de coordination).
Ceux-ci peuvent être plus ou moins lourds, ils n’en restent pour autant pas autre chose qu’une forme de procédure. C’est à dire quelque chose par essence figée et qui ne peut être adaptée à toutes les situations.
Multiplier ainsi les processus reviendrait donc à réduire notre capacité d’adaptation.
Sur ce sujet d’ailleurs, il est intéressant de voir combien, dans le domaine militaire, les forces spéciales laissent une grande place à l’autonomie.
Certes, elles sont entraînées à réagir de manière quasi automatique à un grand nombre de situations. N’oublions pas qu’elles interviennent à des moments laissant souvent peu de place à la réflexion. Dans ces contextes, l’automatisme peut faire la différence entre la vie et la mort.
Si nous cherchons réellement à être agile à l’échelle, nous devons donc fuir les règles préétablies.
Dès lors, il s’agit bien de diminuer le nombre de processus pour accroître notre capacité d’adaptation. En effet, plus nous serons nombreux, plus nous multiplierons les interfaces avec nos environnements et plus nous serons fréquemment confrontés au changement. Avec la taille, la nécessité de développer notre faculté d’adaptation gagne en criticité.
Si l’on devait proposer une définition de l’agilité à l’échelle, on pourrait l’écrire ainsi : Être agile à l’échelle, c’est savoir accroître les capacités d’adaptation, de résilience ou d’innovation de l’organisation plus rapidement que sa taille n’augmente.
Sur ce sujet SAFe, tout comme l’ensemble des frameworks d’agilité à l’échelle, de par leurs ajouts de processus au fur et à mesure que l’organisation grandit, ne sont donc pas réellement adaptés…
Mais alors… l’agilité à l’échelle est une utopie ?
Bien sûr que non ! Mais le changement pour y parvenir est loin d’être évident !
Si l’on accepte que l’agilité à l’échelle c’est l’adaptabilité à l’extrême, il existe bel et bien une approche en ce sens.
Si l’on regarde les principes de construction des organisations plates, tels que présentés par Frédéric Laloux dans son livre Reinventing Organizations, on s’aperçoit en effet que c’est précisément cette philosophie qui est à l’oeuvre.
L’entreprise libérée n’est à ce titre ni plus ni moins qu’une société dont la capacité d’adaptation a été poussée à l’extrême. Laisser chacun libre d’entreprendre les actions qui lui semblent les plus justes pour l’entreprise c’est permettre d’agir au plus près du changement. C’est comme de mettre le volume de l’agilité à 11 !
Plus l’entreprise est apte à laisser de l’autonomie à ses collaborateurs, plus elle gagne en agilité.
C’est un chemin qui, s’il peut être séduisant, comporte ses propres embûches !
À commencer par la difficulté à proposer une vision transcendantale, véritable lien de l’organisation qui permette à chacun d’avancer indépendamment dans la même direction.
Sur ce sujet, vous pouvez d’ailleurs tout de suite oublier les visions du type: faire un milliard de chiffre d’affaires ou être le premier sur son marché.
Une vision ne vaut que si elle est partagée et bénéficie à tous. Tant que la poursuite de votre vision ne se traduit pas dans les actes de chacun au sein de l’organisation, vous n’avez pas encore trouvé le bon message.
Ce genre de transformation représente une véritable révolution culturelle et une route ardue.
Vous serez confrontés aux difficultés de la transparence, de l’acceptation des erreurs et de la valorisation de l’apprentissage et de l’expérimentation.
Vous affronterez la perte de repères de l’abandon des statuts et le challenge de la redéfinition des plans de carrière.
Vous devrez construire une entreprise apprenante qui permette le développement de chacun et se réinvente en permanence.
Aller dans cette direction, c’est accepter d’avancer sur un chemin peu emprunté où il vous faudra découvrir vos propres leçons.
De fait, même si un tel mode d’organisation serait finalement une réponse plus pertinente aux problématiques d’échelle dans un monde complexe, le challenge est indéniable.
Il est ainsi souvent plus aisé d’apporter une réponse s’appuyant sur un framework d’agilité à l’échelle que de s’engager sur ce chemin. Quand bien même l’agilité à l’échelle porte ses propres limites.
Il n’y a aucune honte à cela et vous pouvez vous réconcilier avec SAFe.
Et si d’aventure votre coeur d’agiliste vous poussait vers davantage, n’ayez aucun regret.
Comme je l’ai dit et le répète : avec le bon accompagnement, l’un n’est pas nécessairement incompatible avec l’autre.
Si SAFe n’est pas la destination, c’est peut-être néanmoins l’un des meilleurs premiers pas…
Un voyage de mille lieues commence toujours par un premier pas.
Si plusieurs méthodes existent pour faire le tri parmi les besoins fonctionnels, seul le modèle de Kano tient compte de la satisfaction client. Comment en tirer ? Réponse, exemple à l’appui.
Sur le podium des buzzwords, l’agilité se partage la première marche avec la « transformation digitale ». Et pour cause : l’impératif de réduction du « time-to-market » appelle une gestion de projet rapide et efficace, agile donc. Pour y parvenir, encore faut-il savoir trier et prioriser les besoins fonctionnels. Pas si simple : entre la crainte de voir un concurrent débarquer à tout moment et celle de voir son service boudé par les utilisateurs, la tentation est grande de courir après plusieurs lièvres à la fois.
Pour limiter ces risques, plusieurs solutions sont à disposition :
La Méthode de Moscow : Elle propose de noter les priorités du backlog en faisant intervenir les parties prenantes mais sans stratégie de satisfaction client. Pour plus d’information, allez voir: PRIORISER, MÉTHODE 1 : MOSCOW
La Story map : Avec elle, les fonctionnalités sont classées selon deux axes : le parcours utilisateur sur l’axe horizontal et la priorité des User Stories sur l’axe vertical. Ici encore, aucun lien n’est établi avec des critères de satisfaction client.
Le Modèle de Kano : Comme son nom le laisse entendre, il s’appuie sur le diagramme de Kano qui a pour finalité d’évaluer la satisfaction client. Cet outil a été inventé par le Dr Noriaki Kano en 1984. Conférencier, écrivain et surtout consultant dans le domaine du management de la qualité, au Japon. Il est actuellement professeur émérite de l’Université des sciences de Tokyo.
Si ces 3 solutions permettent une priorisation, une seule – celle qui s’appuie sur le modèle de Kano – tient donc compte de la satisfaction client
Dissocier satisfaction et non-satisfaction
L’objectif du modèle est de prendre en compte les retours des utilisateurs du produit et/ou du service pour modéliser la satisfaction client sur un diagramme. L’approche réside dans la dissociation de la satisfaction et de la non-satisfaction au regard de la présence ou pas de la fonctionnalité attendue par le client. La satisfaction client est une clé majeure aujourd’hui, qui rend le client fidèle et est donc un pilier de rentabilité important. Le modèle de Kano présente l’intérêt de se décliner sur les différentes phases.
Pré-développement : L’équipe marketing peut utiliser ce modèle pour cibler le marché commercial et analyser les chances de réussite du produit – plus la satisfaction client est élevée plus les chances de réussite sont grandes. Le modèle permettrait de faire apparaître les caractéristiques fortes dans une perspective de succès du produit.
En cours de développement : le responsable projet, le Product Owner dans le cas d’un projet en méthode Agile, manage la priorisation des fonctionnalités livrées en se basant sur la satisfaction client. Ce qui permet de livrer, dans le cas de sprint, les fonctionnalités de la plus haute valeur business dès que possible.
En post-production : des évolutions pourraient être valorisées (ou non) par ce modèle. Une étude de marché pourra aussi utiliser ce modèle pour assurer la pérennité du produit.
Concrètement voici le diagramme qui porte le modèle de Kano :
Pour construire le modèle, un questionnaire recueille, pour chaque fonctionnalité, le niveau de satisfaction de l’interviewé. La méthode consiste à évaluer successivement la satisfaction en présence et en l’absence de la fonction. Mais le modèle va bien plus loin en modélisant 3 groupes principaux sur la courbe de Kano :
Les attentes de base : généralement non exprimées, elles représentent les attentes que les fournisseurs doivent impérativement satisfaire pour rester sur le marché. Priorité Haute.
Les attentes proportionnelles : la satisfaction augmente avec le niveau de performance délivré par la fonction. Priorité Basse.
Les attentes attractives : le fournisseur surprend son client avec une fonctionnalité à valeur ajoutée qu’il n’attendait pas. Les fonctions vont au-delà des attentes client. Un terrain propice à l’innovation. Néanmoins leur absence se solde par une frustration client. Priorité Moyenne.
Les bénéfices du modèle de Kano dans la pratique
Dans la pratique, la méthode de Kano apporte donc plusieurs atouts :
Elle contribue à évaluer les attentes des clients grâce au niveau de satisfaction associé.
Elle suscite une rencontre avec les clients pour les écouter et améliorer ainsi la compréhension des attentes
Elle aide à trier et prioriser les fonctionnalités à développer
Elle facilite l’évaluation des produits innovants.
Elle augmente la fidélité des clients, un client non satisfait cherchera tôt ou tard le même service chez la concurrence. L’objectif est de la satisfaire avant qu’il parte.
Un impératif : bien structurer les questionnaires
Pour l’exécuter, il est capital de bien mener les questionnaires. Voici un exemple – avec des réponses arbitraires à des fins d’illustration.
Si votre téléphone portable possède les apps des réseaux sociaux dès son premier démarrage (Facebook, Twitter, LinkedIn, …) : a. cela vous plait beaucoup b. cela vous intéresse c. vous trouvez ça normal d. vous vous en contentez e. cela vous déplaît
Si votre téléphone permet de joindre vos amis en faisant un appel téléphonique classique a. cela vous plait beaucoup b. cela vous intéresse c. vous trouvez ça normal d. vous vous en contentez e. cela vous déplaît
Si votre téléphone n’a que 5 sonneries différentes (cela est transformé en une fonctionnalité manquante, telle que « choix de 50 sonneries » ) a. cela vous plait beaucoup b. cela vous intéresse c. vous trouvez ça normal d. vous vous en contentez e. cela vous déplaît
Si votre téléphone présente un écran 4k a. cela vous plait beaucoup b. cela vous intéresse c. vous trouvez ça normal d. vous vous en contentez e. cela vous déplaît
En appliquant ici le modèle de Kano, nous obtenons donc les catégories de priorités suivantes :
Fonctionnalité « réseaux sociaux » : elle figure dans le groupe rouge et fait donc partie des attentes attractives : c’est une priorité moyenne, cette fonctionnalité devrait être présente.
Fonctionnalité « pouvoir joindre ses amis » : dans le groupe vert, elle représente une attente de base et une priorité haute.
Fonctionnalité « peu de sonneries » : sans incidence réelle car attente proportionnelle, sûrement une fonctionnalité à améliorer dans le futur, priorité basse.
Fonctionnalité « écran 4k » : de même, cependant la décision de l’inclure ou pas dépend aussi du coût associé. Il faudrait étudier les risques de cet investissement. Priorité basse.
Récapitulatif des fonctionnalités priorisées :
Pouvoir joindre ses amis
priorité haute
Applications “réseaux sociaux” déjà installées
priorité moyenne
5 sonneries disponibles
priorité basse
écran 4k
priorité basse
Inspiré ? A vous d’appliquer le modèle de Kano sur vos propres projets.
Vous gérez un produit : apprenez à prioriser et à mesurer la valeur de votre produit !
Comment choisir entre développer un « bot de messagerie » sur votre application ou bien un nouvel onglet ? Peut-on mesurer en amont la valeur de ces fonctionnalités ? Quelles sont les approches pour calculer, voire traduire cette valeur en € ?
Voilà les problématiques auxquelles font face les Product owner pour qui les métriques sont devenues une obsession.
Nous allons aborder les concepts et les outils à maitriser pour y arriver, accrochez-vous, c’est parti !
Prioriser, méthode 1 : Moscow
Ci-dessus un exemple d’application de la méthode MOSCOW sur le sprint backlog d’un site de vente quelconque.
La première approche qui se veut pragmatique n’est jamais très loin de la méthode MoSCoW (Must have, Should have, Could Have et Won’t Have). On affecte un niveau de priorité aux « actifs / features / fonctionnalités* » que l’on veut intégrer au produit. Pour le faire bien, on essaie de le faire souvent, en travaillant uniquement ce qui est le plus prioritaire. * pour un produit qui n’est pas informatique ou qui comporte des contenus sans développements (vidéos, …), on pourra parler d’actif ou de feature
Par exemple, imaginons que vous ayez 3 mois pour développer un site de vente, comment s’y prendre ?
On liste l’ensemble des grandes fonctionnalités : accéder au catalogue de produits, visualiser l’historique des achats, acheter, etc …
On assigne une priorité à chacune
Les Must have : acheter, accéder au catalogue de produits
Nice to have : accéder à l’historique de ses achats…
Le planning reste clair : les « must have » seront développés en premier et les « nice to have » restants, etc … si jamais il nous reste du temps !
Prioriser, méthode 2 : orientée données
La seconde, orientée données, s’inscrit une démarche Lean Startup (Build, Measure, Learn).
Ci-dessus un exemple d’application orientée données sur le développement de facebook connect pour un site de vente quelconque.
Facebook Connect est un module social externe ousocial loginpermettant à un site web de proposer à ses visiteurs d’utiliser leur compte Facebook pour s’identifier sur le site visité. On fait des hypothèses basées sur notre compréhension du marché, on mesure notre adéquation et on apprend de ses choix. Pour le faire bien, on met en place des standards de calcul, on identifie au préalable les métriques à suivre pour un actif donné et on les suit. La dernière étape permet de savoir dans quelle mesure valider ou invalider ses choix. Dans notre exemple ici, on estime que la valeur (ou BV : « Business Value ») de développer Facebook Connect pour que nos visiteurs s’identifient sur notre site de vente est de 10 000€ par jour. Une fois la fonctionnalité priorisée/développée, on suit notamment le taux de conversion : pourquoi n’atteint-il pas les 20% d’augmentation estimés ? Le taux d’abandon en page d’identification a lui fortement diminué, le taux d’abandon sur une autre page a t il augmenté ? Où ? … A mi-chemin entre les 2 approches ? Toutes les méthodes de priorisation/mesure que l’on appellera « par scoring ».
Ce n’est pas indispensable d’être orienté données
Tout d’abord, la force de l’approche orientée données réside dans sa capacité à adresser des problématiques business globales et complexes. C’est donc dans ce type d’environnements (où la connaissance des usages est particulièrement importante) qu’elle prend tout son sens, ce n’est peut-être pas le cas de votre environnement… La deuxième variable est temporelle, il faut savoir qu’un produit suit un cycle de vie :
Tant qu’il n’a pas atteint sa forme minimale viable, ça n’a peu/pas de sens de chercher à valoriser les actifs qui le composent. Le MVP est par définition le premier ensemble qui constitue le produit que l’on peut valoriser et le produit finit sa vie lorsqu’on ne peut plus le valoriser.
Enfin la dernière composante est le rapport à la concurrence. « Combien va me rapporter tel service ? Telle feature ? Quel est la « business value » de passer maintenant sur telle technologie ? Ou au contraire, combien est ce que ça va me couter de ne pas faire cette migration pendant 1 an ? » Ce sont des questions qu’il est d’autant plus naturel de se poser que la capacité d’une entreprise à mettre sur le marché très rapidement un produit ou une nouvelle version est devenu un facteur concurrentiel à part entière. L’approche garantit des retours fréquents et qualitatifs permettant de s’adapter d’autant mieux dans ce type de contexte.
Quels sont les outils pour calculer la valeur d’une fonctionnalité de son produit ?
La valeur « business » représente ce que vaut une fonctionnalité ou un service en embrassant tous les aspects qui font sa force. Par défaut il ne faut pas perdre de vue qu’il y aura toujours certains aspects qui seront mal appréhendés par ces méthodes : comme la valeur qui est créée lorsque des utilisateurs interagissent avec notre contenu ou alors la « prime au premier » que l’on obtient à délivrer un service qui n’existait pas auparavant… L’important est donc de savoir que cette mesure ne se substitue pas à l’intuition et d’utiliser des métriques de calculs comparables pour chacun de vos actifs :
Pour une fonctionnalité ou un service qui est supposé générer des revenus ou une réduction de couts, c’est bien ce que l’on cherchera à estimer pour calculer un ROI (cf. 2nde image)
Idem pour un actif qui contribue à ce qu’un autre rapporte : si un actif ne peut fonctionner sans un autre, c’est que cet actif contribue à la valeur générée : Imaginons (si on reprend notre exemple) que le développement de FB Connect pour notre site de vente nécessite le développement d’une autre fonctionnalité ou d’un autre actif. On parlera alors d’un « enabler » et il s’agira d’estimer dans quelles proportions il contribue à notre hypothèse d’augmentation de BV portant sur l’augmentation de taux de conversion (et potentiellement à d’autres) pour en estimer la valeur.
Pour d’autres fonctionnalités, services ou contenus, liés à une échéance, comme une amende réglementaire (Hello GDPR) ou un spot publicitaire, on estimera à l’inverse ce que cela nous coute de ne pas faire, on appelle ça le cout du délai :
Exemple d’application du coût du délai sur 2 contenus comparables
Quantifier la valeur d’une feature n’a pas de sens si l’on ne suit pas les résultats …
L’AB Testing ou Split Testing est un bel exemple d’utilisation bout en bout de la donnée. Le procédé est notamment poussé par de nombreux designers pour affiner leurs choix et leur compréhension des usages. Il s’agit de tester plusieurs variantes d’un même élément directement face à des utilisateurs : les utilisateurs sont renvoyés aléatoirement vers chacune des variantes pendant un temps donné. On garde à la fin la meilleure variante : celle qui a les meilleurs taux de conversion, de transformation ou n’importe quelle métrique que vous voulez améliorer.
Exemple d’AB Testing sur une page web
A ce jeu, les principaux leaders sur des services numériques excellent (75 % des sites ayant un trafic supérieur à 1 million de visiteurs font de l’A/B Testing). Au-delà d’optimiser la décision, le procédé permet d’en apprendre plus sur ses visiteurs et ce qui fonctionne, d’en connaitre finalement plus sur la « capitalisation » vue de l’utilisateur de son produit. Même si l’on n’est pas dans une logique d’AB Testing, lorsque l’on déploie une fonctionnalité ou un service, il faut suivre :
l’impact sur les métriques identifiées auparavant, on cherche les « tendances »
l’écart avec ses hypothèses, cela permet de se poser les bonnes questions et de tirer les bons enseignements au moment de refaire des hypothèses
l’évolution de la valeur des différents actifs qui composent le produit,
C’est tout l’intérêt de l’approche qui en dépend… Pour finir, il faut garder en tête que cette démarche orientée données est intéressante parce qu’elle pousse à la réflexion autour de vous, améliorant ainsi votre compréhension du marché et celle de vos équipes. Pour autant, nous travaillons tous dans des organisations dont la valeur générée ne correspond pas à la somme des valeurs individuelles de ses produits. Contribuer à, collaborer avec d’autres équipes vous mèneront parfois à faire des choix qui ne favorisent pas la valeur de son produit, ce sont pourtant souvent de bons choix !
