Les méthodes : adaptez-les, ne les adoptez pas

Cela fait environ 12 ans que je travaille dans des environnements “agiles”. J’ai la chance de discuter avec plusieurs équipes de plusieurs entreprises, et d’essayer de comprendre comment elles travaillent et où elles peinent. Une chose en particulier semble préoccuper les gens, assez drôlement : les mots.

Pourquoi nous faisons du product management

Le product management, même si des personnes comme Marty Cagan (auteur de “Inspired”) le pratiquent depuis le début des années 90, est encore quelque chose d’assez nouveau. En France, en 2011, je me souviens qu’un “chef de produit” pouvait tout aussi bien être ce dont nous parlons qu’une personne gérant le rayon d’un magasin de détail. Et aujourd’hui, on voit encore beaucoup d’entreprises peiner à adopter le product management. Les petites équipes et start-ups ne savent pas quand elles devraient avoir un rôle dédié à ça. Les équipes en croissance se demandent comment cette première personne en charge de tout peut être “divisée” en plusieurs autres, avec des missions de plus en plus spécialisées.

Le product management est censé aider à trouver l’adéquation produit/marché, en allant de la compréhension des problèmes utilisateurs au développement de solutions avec l’ingénierie, et jusqu’au “go-to-market”. Tout ça nécessitant une communication interne intensive et l’alignement de tous ceux impliqués dans le produit. C’est-à-dire, en fait, tout le monde dans l’entreprise.

Un point de douleur clé à soigner

Là où nous ignorons probablement bien trop souvent les interactions du product management avec le marketing et les ventes (d’où la croissance des rôles produit axés sur le go-to-market), une interaction clé a toujours existé entre le produit et l’ingénierie.

Quel que soit le background et la formation des product managers, je les définis comme des ingénieurs au sens large du terme. Ça ne signifie pas qu’ils doivent appartenir aux départements d’ingénierie (sinon on ne verrait pas ce rôle croître séparément depuis une décennie). Ce sont des ingénieurs dans le sens où leur rôle est de comprendre profondément un problème et ses causes profondes, d’envisager et parfois de construire une solution avec le soutien d’un large éventail de compétences (pas seulement les leurs).

C’est souvent la source de malentendus et d’une collaboration déficiente entre produit et ingénierie. Qui est “responsable” de la construction du produit ? Où traçons-nous la ligne dans la définition de ce qui doit être construit, par qui ? Le produit doit donner suffisamment de briefing pour que l’ingénierie puisse faire le travail, mais pas trop pour éviter de les noyer dans les détails. Le produit doit donner des orientations sur ce qui doit être construit ensuite, mais doit éviter de surcharger les ingénieurs, et parfois même doit totalement éviter toute hypothèse sur la quantité de travail que les ingénieurs peuvent prendre en charge.

Les méthodologies à la rescousse, ou pas

(Spoilers) C’est là que nous échouons tous (fin des spoilers).

Les méthodologies sont là pour nous aider à résoudre ces problèmes. La bonne nouvelle, c’est qu’il y en a beaucoup, développées depuis des années par des personnes très intelligentes. Vous pouvez citer les anciennes comme Waterfall, Extreme Programming, Scrum, BDD, SAFe, et des plus récentes et holistiques comme Shape Up et le fameux modèle Spotify.

Chacune de ces méthodes définit des rôles, des responsabilités, des workflows et des outils. Beaucoup ont même leur sémantique propre, jusqu’à un dictionnaire complet. Elles fournissent un cadre sur lequel l’équipe peut s’appuyer pour ne pas se perdre et rester efficace lors de la construction collective.

Les méthodologies ne peuvent pas résoudre les problèmes humains

Il y a une chose que toutes ces méthodes ont en commun. Elles sont comme Jira. Certains vont l’adorer. Beaucoup vont le détester. Elles sont comme un outil. Un outil ne résout jamais rien par lui-même si vous choisissez le mauvais ou si vous l’utilisez incorrectement.

Le problème que nous essayons de résoudre ici est un problème humain. Il faut des humains pour le résoudre. Rien d’autre.

Saviez-vous que le fameux modèle Spotify n’a même pas été entièrement adopté par Spotify ?

C’est une sorte d’ellipse, mais je vois ça comme assez proche de toutes les entreprises qui publient ouvertement leurs “valeurs”. Même si j’aime l’intention et crois fortement qu’il y a un besoin ou un problème à résoudre ici, je suis assez sûr que de telles valeurs sont la plupart du temps un objectif que les entreprises se fixent elles-mêmes, plutôt qu’une culture accomplie.

Les méthodologies et les cultures ne doivent pas être vues comme des vérités absolues. Elles peuvent être quelque chose vers lequel vous voulez vous rapprocher. Et très souvent, parce qu’elles sont imparfaites, vous devriez éviter de les embrasser pleinement.

Mon expérience personnelle

Je serai honnête et transparent. Quand j’ai commencé à travailler chez SensioLabs/Blackfire, j’ai essayé d’introduire Scrum, avec lequel j’avais connu un succès incroyable chez Traveldoo. Ce fut un échec cuisant. Pour de nombreuses raisons, il y a eu beaucoup de résistance, et pas seulement de la part de l’équipe d’ingénierie. Pendant un moment, nous sommes retournés à la “Méthode à l’arrache” (©fabpot), qui est quelque chose de proche de l’Extreme Programming. Avec beaucoup de pragmatisme.

Ça a fonctionné extrêmement assez bien quand nous étions une très petite équipe. Et dès que nous avons recommencé à embaucher, les problèmes habituels sont réapparus. Progressivement, nous avons commencé à introduire des éléments de Scrum. Nous n’avons jamais osé l’appeler “Scrum”, car le simple nom de celui-ci ferait immédiatement monter certains membres de l’équipe au plafond, mais c’était quelque chose qui s’en rapprochait.

Nous avions construit notre propre méthodologie. 🍾

J’ai même commencé à envisager d’écrire à son sujet et de la nommer le Blackfire Shuffle. Pour aucune autre raison que de lui donner un nom fantaisie, et parce que je suis fan de la technique Kansas City Shuffle (Lucky Number Slevin).

Assez avec les mots fantaisie

Mais quelle valeur ça aurait apporté ?

Premièrement : je n’ai pas vérifié de façon extensive, mais je suis confiant que beaucoup d’autres personnes ont aussi publié leurs propres recettes de “sauce secrète” (plus si secrète, hein). Donc il y a de bonnes chances que personne ne s’intéresse à la nôtre. Et si par hasard nous avions eu des lecteurs et des adopteurs, ils se seraient débattus avec quelque chose qui n’a pas été construit pour eux.

Deuxièmement : des mots ! Ce n’aurait été que de nouveaux mots, sur les mêmes problèmes fondamentaux et une solution très similaire. Les utiliser donne l’impression qu’un nouveau dogme est né, à suivre à la lettre. Et que le livre devrait être blâmé quand d’autres équipes ne peuvent pas en tirer sens !

Blâmer le livre est très souvent la solution de facilité. En fin de compte, quelqu’un ou quelque chose doit porter le blâme, non ?

Il y a quelque chose que je trouve assez troublant : combien peu de personnes connaissent vraiment la racine de l’Agile.

Arrêtez de réinventer la roue

Oh oui, “Agile” est un mot fantaisie. Et la racine est un “livre” ou un “dogme”.

Mais contrairement à l’une des fameuses méthodes dont on entend parler de nos jours, ce livre ne fait pas des centaines de pages. Pas même des dizaines de pages. Il a 4 valeurs fondamentales et 12 principes. Rien de plus.

Laissez-moi mettre l’URL en clair ici, pas comme un hyperlien sur du texte : https://agilemanifesto.org/.

Pendant de nombreuses années, j’ai vu d’innombrables plaintes que “l’agile est défectueux”, “l’agile ne fonctionne pas pour nous”, etc. Je suis assez sûr que la plupart du temps, les gens faisaient référence à une méthodologie agile, qu’ils avaient essayé d’adopter alors qu’elle n’était pas faite pour eux.

Ce qui nous a finalement fait réussir avec Scrum chez Blackfire, c’est de ne pas l’appeler Scrum. C’est d’éviter d’adopter chaque ligne du Scrum Guide. C’est d’être agile dans la façon dont nous avons adopté une méthodologie agile. Nous avons pleinement embrassé le premier principe Agile : “Les individus et leurs interactions, plutôt que les processus et les outils”.

Tout jeter ?

Ne me faites pas dire ce que je n’ai pas dit. Je ne prétends pas que Shape Up, le modèle Spotify ou aucune des autres méthodes connues sont sans valeur. Elles sont excellentes à lire et à apprendre : il y a toujours des tonnes de bonnes idées dont vous pouvez vous inspirer.

Mais elles devraient être lues comme un essai, un post-mortem ou une philosophie, pas comme une recette de pâtisserie qui échouera si vous manquez un gramme.

La plupart du temps, vous devriez finir par les adapter, plutôt que de les adopter aveuglément.

Cela fait environ 12 ans que je travaille dans des environnements “agiles”. J’ai la chance de discuter avec plusieurs équipes de plusieurs entreprises, et d’essayer de comprendre comment elles travaillent et où elles peinent. Une chose en particulier semble préoccuper les gens, assez drôlement : les mots.