tldr;

J'ai récemment eu à remplir un questionnaire sur nos méthodes de gestion de projet chez Malt. 

Je me suis retrouvé à être agacé bêtement par les questions, questions dont la philosophie me semblait dater d'un autre âge. 

Le but était de savoir si nous étions bien agiles, et pour le savoir, chaque question portait sur une pratique spécifique des méthodes Scrum et Kanban.

La question aujourd'hui n'est plus de savoir si on est agile ou non, terme très largement dévoyé partout.

L'agilité est clamé partout mais se cantonne pourtant bien souvent au cycle de dev (le delivery) laissant le reste de l’entreprise dans un fonctionnement plus archaïque. 

Il faut aller plus loin désormais, l’Agile est censé avoir été compris (et surexploité). Il est temps de véritablement parler de comment on réalise le produit depuis les phases de discovery (l'idéation) jusqu’au delivery. Et il faut sortir de la logique des roadmaps inflexibles anti agiles pour aller vers des stratégies par objectifs et résultats clés (OKR), le tout avec un alignement complet de la société.

L'agile est mort

les cabinets de conseil devant la hype qui change

Comme tous les buzzwords, l'agilité a été la réponse universelle à tous les problèmes. Agile was the new 42. Et comme chaque buzzword, il a fini par être dévoyé, exploité, surexploité jusqu’à la moëlle par des armées de consultants pour vendre de la transformation agile à tout va. 

Coucou SAFe et les formations certifiantes :)

Je pourrais aussi mentionner certaines dérives d'implémentation où l'agilité a été le prétexte pour mettre en place un flicage journalier (les daily meeting, le tracking des temps sur les tickets).

Mais là dessus je ne dirais qu'une seule chose, ça c'est lié à votre boîte. Quand une boite est toxique, n'importe quelle bonne méthode peut devenir mauvaise. 

La hype est un peu retombée et désormais à l’inverse la hype pourrait être d’assassiner l’Agile.

Mais, autant le discours de ces dernières années sur l'agilité m'a fatigué, autant ce serait dommage de jeter le bébé avec l'eau du bain. 

L'agilité ne se réduit pas à son formalisme

Dans le fameux questionnaire dont je parlais ci-dessus, j'ai noté que les questions portaient principalement sur le formalisme :

- la présence ou non de user stories

- la façon de les rédiger 

- les méthodologies de chiffrage en story point

- la definition of done et ce qu'elle incluait

- le suivi des burndown charts 

etc...

Comme si l'agilité, dont le manifeste a été signé il y a désormais 20 ans, n'avait pas évolué. Ces méthodes sont restées gravées dans le marbre (ou plongées dans la naphtaline) alors même que ces auteurs originaux insistaient sur l'adaptabilité et l'amélioration continue permanente.

Adopter les méthodes "by the book" sans prendre de recul sur le fond n'amène pas grand chose, si ce n'est l'obtention de l'étiquette "agile" qui permet ensuite de le mettre partout dans sa communication corporate. Sauf que, on peut être parfait sur le formalisme et être pourtant très mauvais en pratique à faire du produit. 

On pourrait penser que j'ai une dent contre l'agilité et ce serait faux.

Je pratique l'agilité depuis 2007. J'ai été coach agile pendant 1 an sur une DSI de 120 personnes en 2010, même si ce n’était pas la meilleure expérience de ma carrière.

Mais aujourd'hui je sature ad nauseam des sujets autour de l'agilité qui ne s'attardent que sur le formalisme sans en comprendre ces principes et sans parler de résultats clés. 

Je sature également des serious game, ou des conférences qui ne font qu'effleurer la surface des choses mené par des consultants certifiés avec aucun succès produit à la clé.

Repêchons ce qui peut l’être

Je suis loin de tout jeter. De nombreuses méthodes agiles donnent des outils à adopter et adapter pour sa propre organisation et certaines méthodes sont très efficaces.

Cependant, désormais :

- Est ce que le sujet est toujours sur l'adoption de l'agilité ?

Non. Tout le monde revendique être agile. Les entreprises sont agiles, les équipes sont agiles, la communication est agile. 

On a des formations certifiantes, des annonces pour Scrum master (un rôle à l'origine, pas un métier). L’Agile est adopté et vous ne voyez plus d’entreprise dire qu’elle ne l’est pas.

- Est ce que le sujet c'est d'avoir toujours plus de formalisme pour faire rentrer l'agilité dans le monde de l'entreprise ? 

Non. L’agilité se satisfait d’un formalisme minimal et se doit d’être adapté en permanence. Plus on laisse faire les cabinets de conseil plus ça dérive et on finit par aboutir à des frameworks comme SAFe (Shitty agile framework for enterprise comme dirait Martin Fowler)

Bref, la grande majorité des équipes produits connaissent l'agilité. C'est désormais enseigné à l'école depuis au moins 10 ans. La majorité des grandes boîtes ont des armées de coach agiles en exercice dans leurs équipes.

Le sujet c’est de se recentrer sur l’essentiel, le produit qu’on délivre.

La plupart des équipes produit le savent bien, l'agilité se cantonne bien souvent au delivery, la phase située tout en bout de chaîne. 

Mesurez ce qui compte

L'agilité en tant que cadre de développement pour le delivery, ok, je considère que c'est acquis. Il faut arrêter le formalisme à outrance et laisser les équipes dev le mettre en place et l'adapter par rapport à leur besoin. C’est leur responsabilité. 

Vous voulez mesurer votre degré de maturité ? Posez-vous des questions sur vos résultats visibles. 

Si on parle de plateforme, voici un exemple de métrique de succès issu de "Accelerate" : 

- Fréquence de déploiement en prod

- lead time for changes 

- temps moyen de résolution d'incident 

- change failure rate 

Charge aux équipes ensuite d'introduire et modifier les pratiques nécessaires pour s'améliorer. Si une équipe met en prod tout les trimestres, elle n’est pas agile. Challengez la pour faire mieux et elle devrait arriver d’elle-même à mettre en place les bonnes pratiques nécessaires.

Mais au global sur une équipe produit, il faut mesurer sa performance par ses succès chiffrés.

Je me fous littéralement de savoir qu'une équipe fait 30 story point par sprint.

Je me fous complètement de savoir qu'une équipe réalise toujours 95% de son sprint avec un burndown chart qui colle parfaitement à la courbe théorique.

Vraiment.

Voilà le genre de truc que je veux entendre/lire :

- on a réussi à augmenter de 10% l'étape X du funnel

- on a permis de faire x3 sur le trafic venant du SEO

- grâce à cette fonctionnalité on a diminué de 30% le volume de support portant sur ces questions 

- le NPS a augmenté de 20 points

C'est ça la vraie mesure de votre succès à la fin. 

Pensez objectif et résultat clés !

Et pour ça il faut s'attaquer à l'amont de la chaîne. Et c'est là qu'interviennent la définition des objectifs (les OKR), la gestion de l'idéation (la discovery) et son enchaînement avec le delivery. 

Si vous ne connaissez pas encore les OKRs, je vous recommande fortement d'y jeter un œil. Je ferais sans doute un billet dédié sur le sujet mais pour résumer, c'est la définition de la stratégie de la boite pour contribuer à la mission et la vision sur une période donnée. 

La stratégie se décline en objectifs, eux-mêmes mesurés par des résultats clés. 

C'est d'une simplicité désarmante et pourtant très puissant. Les OKR permettent d'aligner l'ensemble d'une société sur les bonnes priorités, de donner de la visibilité à tous lorsque les OKR sont déclinés par équipes et de se focaliser sur le résultat plutôt que les projets. Un projet n'étant qu'un moyen pour atteindre un résultat. 

La ou les roadmaps traditionnelles se focalisent sur les dates de sorties de telle ou telle feature, les OKR se focalisent sur l'atteinte d'objectifs, les problèmes à résoudre.

Une feature est un accomplissement en soi, c'est un output. 

Les OKRs se concentrent sur le résultat. Une feature n'est qu'une étape et le travail ne s'arrête qu'une fois l'objectif atteint, le problème résolu. 

outcome vs output.

Stop aux Product Owner, passez aux Product Manager

Le PO a souvent été vu comme simple proxy des "stakeholders" et dont le rôle se cantonne à administrer un backlog tout en maintenant un équilibre entre les prios de chacun.

Un gestionnaire de ticket jira en somme. 

Il est parfois aussi très impliqué dans le delivery en bossant avec le Scrum master comme proxy de l’équipe mais ça reste lui le responsable des délais et on arrive bien souvent à un PO qui “manage” une équipe de dev.

Les roadmaps annuelles remplies de features étant encore bien ancrées, le PO se retrouve dans la meilleure configuration schizophrénique possible. D'un côté des équipes de delivery soi-disant itératives, de l'autre une roadmap figé, au milieu le PO qui fait des claquettes.

Le product management ne doit pas se cantonner à la gestion de backlog, des stakeholders et de la chefferie de projet. 

Appuyez-vous sur l’équipe d’ingénierie et le Product Designer pour assurer le delivery et ne vous en occupez pas directement. Concentrez-vous sur votre valeur ajoutée, l’identification des problèmes à résoudre pour contribuer aux objectifs de votre entreprise et l’identification de l’espace des solutions avec le reste de l’équipe. 

Vous avez 7 compétences clés à développer pour cela : 

• Product Design
• Product Data
• Product Marketing
• Product Discovery
• Product Growth
• Product Ops (org & process)
• Product Tech

(Cf article de Thiga pour plus de détails)

Et enfin, renvoyez votre processus de roadmap...

Place à la Discovery

Je vais reprendre un schéma de Marty Cagan qui résume bien le sujet. Il faut passer de ca :

Cf conférence https://www.mindtheproduct.com/video-the-root-causes-of-product-failure-by-marty-cagan/

 à ca :

du même Marty Cagan : https://www.mindtheproduct.com/product-is-hard-by-marty-cagan/ 

Côté produit, l'idéation est une phase importante qui permet de partir de ces objectifs et résultats clés (OKRs) pour travailler à résoudre des problèmes qui sont posés.

L'idéation consiste à constamment identifier l’espace des problèmes puis identifier l’espace des solutions. C’est donc en permanence le fait de tester des hypothèses (AB Test, interviews, maquette, prototypes etc...).

La discovery correspond à l'ensemble des activités liées à l'identification des initiatives qui pourront contribuer à un objectif stratégique et aux expérimentations menées pour trouver des solutions.

La delivery vient ensuite pour industrialiser, passer à l'échelle ces solutions. Solutions qui auront été validées en discovery.    

Bref, c’est pour toutes ces raisons que le questionnaire que je mentionnais en introduction m’a agacé. Il semblait contribuer à cette vision dysfonctionnelle d’une équipe produit idéale.

Chez Malt nous sommes passés par là mais nous avons constamment remis en cause nos pratiques. Nous avons mis en place les OKR il y 3 ans maintenant. Je qualifierais notre pratique encore de jeune et je pense que nous allons beaucoup progresser dessus.

Côté produit nous sommes passés en impact team il y a seulement quelques mois fin 2020, ce qui a été très bien expliqué par Johan dans son billet de blog et nous donnons la part belle à la Discovery même si là aussi nous avons encore beaucoup de progrès à faire.

Et si vous voulez en savoir plus, ou même nous aider à nous améliorer, sachez qu’il y a plein de jobs ouverts en ce moment chez Malt :

https://jobs.lever.co/malt