Une transformation Agile est souvent mise en œuvre par des équipes de production qui croient que l’Agilité leur permettra de livrer de meilleurs produits plus rapidement. Les organisations parlent de « mise en marché plus rapide » et de « meilleure qualité ». Elles examinent le coût de la transformation et l’approuvent.

La réalité est que souvent ces équipes réussissent à diminuer leur délai de livraison sans vraiment améliorer leur façon de penser leur produit, c’est-à-dire l’Agilité du produit. Et une livraison plus rapide de produits médiocres est toujours une proposition perdante.

La principale valeur d’une transformation Agile est la capacité de réagir rapidement aux conditions complexes du marché, et cela inclut la capacité de faire un produit primé à partir d’une mauvaise proposition. L’histoire de la manière dont le Design Thinking a aidé Airbnb à effectuer cette transition précise est un exemple classique. Ne pas aider vos équipes à atteindre l’Agilité du produit élimine les principaux avantages de votre transformation.

Nous allons souligner ici trois obstacles à l’Agilité du produit que l’on rencontre souvent dans les organisations et expliquer comment les surmonter.

1. Ne pas avoir des pratiques de gestion de produit centrées sur l’utilisateur

Dans les organisations traditionnelles, les décisions de gestion de produit sont souvent basées sur des suppositions de longue date à propos des utilisateurs ; telles que croire, comme Kevin Costner, que si vous le construisez, ils viendront1.

Pour des raisons budgétaires, les plans du produit sont préparés plusieurs mois d’avance et sont rigoureusement suivis pour qu’ils respectent la portée, le budget et les délais. Lors de conversations, on entend plus parler de « projets » et de « ressources » que de « besoins » et d’« utilisateurs ». En fait, l’utilisateur n’est impliqué nulle part dans le projet.

Comme chaque supposition comporte le risque de se révéler fausse, la probabilité d’atteindre une adéquation avec le produit ou le marché n’est pas augmentée par la transformation.

Voici trois conseils pour vous aider à recentrer votre développement de produit sur l’utilisateur :

  • Arrêtez de parler de vos projets, ce qui est une façon de suivre les unités de travail, et commencez à parler de produits au service de vrais utilisateurs.
  • Retenez-vous jusqu’au dernier moment de parler des fonctionnalités et des solutions. Parlez plutôt d’utilisateurs, de besoins et de valeurs.
  • Surtout, incluez l’utilisateur dans la conversation. N’oubliez-pas le vieux jeu du téléphone dans lequel le message est transmis à travers une chaîne d’individus, les uns après les autres. Le message final n’est jamais le même que celui d’origine. Cela s’applique également à la compréhension des besoins des utilisateurs. Le fait d’avoir des non-utilisateurs qui relaient l’information à l’équipe qui travaille sur la solution implique de nombreuses suppositions. Pour éviter cela, le contact direct avec les utilisateurs est nécessaire. Certaines approches mentionnent l’idée d’amener l’utilisateur dans l’équipe, d’autres encouragent l’équipe à sortir et à « marcher dans ses souliers ». En fin de compte, nous voulons une collaboration qui nous permet de mieux comprendre ce qui doit être fait.

2. Ne pas valider les hypothèses

Une supposition est considérée comme vraie, alors qu’une hypothèse n’est rien de plus qu’une conjecture. Dans The Four Steps to Epiphany, Steve Banks identifie plusieurs catégories qui regroupent les hypothèses que nous faisons en développant une solution, et qui devraient être validées.

  • Hypothèses sur le client : Comprenons-nous vraiment les motivations, les besoins et les peines de nos clients ?
  • Hypothèses sur la solution : Est-ce que notre solution résout le problème ? Est-elle utilisée ? Est-elle acceptée ?
  • Hypothèses sur la tarification et la distribution : Le modèle d’affaires est-il viable ? Est-ce que les projections et hypothèses de distribution ont été validées ?
  • Hypothèses sur la demande : Est-ce que les messages et les suppositions marketing ont été validés ?
  • Hypothèses sur le marché et la concurrence : Est-ce que le marché réagit en concordance avec vos attentes ? Qu’en est-il de la compétition ? Y a-t-il des problématiques légales ?

Nous ne pouvons comprendre le marché, la valeur du produit et ses utilisateurs que par le biais de courts cycles d’hypothèses et de validation, ce qui permet aux équipes de prendre de meilleures décisions de gestion de produit. Les organisations doivent, le plus rapidement possible, soutenir les responsables de produit (Product Owners) dans la validation de leurs hypothèses.

Cela peut sembler être du gros bon sens, mais de nombreuses organisations trouvent difficile de mesurer les répercussions du travail de leur équipe. Comme il est plus facile de surveiller le coût associé à une équipe, il devient naturel d’investir sur la base du coût plutôt que du retour sur l’investissement.

Pour valider efficacement des hypothèses, les organisations doivent aider leurs responsables de produit.

Évaluer l’impact du travail effectué

Pour n’importe quel type de produit, les responsables de produit voudront valider s’il est utilisé, comment est-il utilisé, et par qui. Principalement, ils veulent savoir si le travail produit la valeur projetée (l’hypothèse) et quelles répercussions le travail a eues sur les indicateurs de rendement de l’organisation.

Plusieurs modèles d’indicateurs peuvent aider les organisations à démarrer. Scrum.org suggère une série d’indicateurs pour sa pratique d’EBM (Evidence-based Management). Les indicateurs visent à mesurer les répercussions de la transformation incluant l’Agilité du produit. Ils peuvent être utilisés pour valider ce qui est le plus important pour votre organisation et définir des façons de mesurer les répercussions du travail effectué.

Un autre modèle introduit par 500 Startups est souvent utilisé pour les startups Lean : AARRR, ou les indicateurs Pirate ! Le modèle suggère de suivre chaque point de contact du produit, en fonction du parcours du client. Par exemple, en utilisant ce modèle, vous pourriez mesurer l’effet d’un nouveau communiqué de presse sur le référencement et suivre ses répercussions à travers l’ensemble du cycle de vie de la clientèle.

L’organisation pourrait devoir adapter certaines pratiques comptables et de gestion du service à la clientèle pour permettre le suivi et être transparente à propos des chiffres.

Valider chaque hypothèse en elle-même

Pour acquérir la connaissance que nous cherchons à travers la validation d’une hypothèse, les responsables de produit doivent être en mesure de valider une hypothèse à la fois. Cela génère quelques défis organisationnels.

Traditionnellement, les organisations cherchaient à faire des coups d’éclat lors desquels, en une seule journée, elles diffusaient des communiqués et des conférences de presse, donnaient des entrevues, démarraient des campagnes publicitaires et livraient un gros incrément du produit. Le but était d’obtenir du bouche-à-oreille dans un environnement non numérique. De nos jours, vous pouvez considérer l’utilisation d’une approche plus granulaire dans laquelle vous êtes en mesure de valider les répercussions de chacune de vos hypothèses. Vous pouvez découvrir qu’un message fonctionne mieux dans un marché et moins dans un autre, ou qu’une fonctionnalité est utilisée pour une raison différente que ce qui est montré dans une publicité. Chaque découverte est un indice en vue d’une meilleure adéquation entre le produit et le marché.

Pour en arriver à des cycles de validation courts, les équipes doivent avoir le soutien de leurs organisations par rapport à l’investissement technologique et le paiement de la dette technique. Les organisations devraient réviser ces coûts en ayant les bénéfices finaux en tête. En l’occurrence, pour recevoir une rétroaction rapide de la part du marché, certaines équipes pourraient vouloir investir dans une technologie de livraison continue, alors que d’autres pourraient vouloir investir dans le remaniement (refactoring) de l’architecture.

Les responsables de produit pourraient proposer de nouveaux outils, tel que des tests A/B et des éléments de désignation (feature toggles), pour raccourcir la boucle de rétroaction ou limiter le test à une petite portion de votre marché. En tant qu’organisation, vous pourriez vouloir revoir les besoins de vos équipes et soutenir la mise à l’échelle de tels outils.

Finalement, vous pouvez utiliser le prototypage pour tester certaines hypothèses. Il peut être rapide, n’utilisant que papier et crayon, ou plus complexe en utilisant une interface semi-fonctionnelle. Tandis que le prototypage est une excellente façon de valider des hypothèses rapidement, il est recommandé de retirer le prototype une fois que le test est complété. Si la solution est validée, construisez-la selon vos standards de qualité. Si vous effectuez des tests supplémentaires, ou ajoutez de nouveaux éléments prototypiques au prototype existant, vous pourriez rencontrer certains des problèmes suivants :

  • Puisque le prototype contient encore des suppositions qui peuvent être erronées, développer de nouveaux tests sur celui-ci augmente le risque de ne pas valider vos hypothèses correctement.
  • Puisque le prototype est une version incomplète de la solution qu’il représente, il y a un coût pour le terminer. En y ajoutant de nouveaux tests ou prototypes, vous ajoutez à ce coût. C’est ce qui s’appelle la « dette technique ».
  • Souvent, les prototypes ne satisfont pas aux normes de qualité contrairement aux fonctionnalités ordinaires. Ils peuvent ne pas être aussi robustes et être plus sujets à comporter des défauts. Bâtir sur cette assise pourrait diminuer votre capacité à développer mieux et plus vite.
  • Le fait de conserver « au cas où » des éléments de cette solution qui n’ont pas été validés crée une complexité supplémentaire autant au niveau du code que de l’expérience utilisateur.

3. Ne pas comprendre le responsable de produit

Le rôle du responsable de produit est de maximiser la valeur du produit. Ce que cela signifie pour une organisation n’est pas toujours clair. Nous avons découvert que dans de nombreuses situations, son rôle est confondu avec celui d’un gestionnaire de produit, d’un analyste d’affaires ou d’un gestionnaire de projet. Ne pas comprendre et soutenir le rôle du responsable de produit peut coûter à l’organisation la perte des avantages de l’Agilité du produit.

Prise de décision

Les responsables de produit devraient avoir le pouvoir de prendre toute décision qui concerne le produit, incluant celle de cesser son développement. Dans les organisations traditionnelles, il peut être difficile de déléguer une telle autorité. Dans un environnement Agile, utilisez la transparence et la collaboration pour aider et soutenir les responsables de produit dans leurs décisions.

En tant qu’organisation, vous devriez avoir confiance envers votre responsable de produit, qui apprend de ses propres erreurs, et non des vôtres.

Empirisme

Les responsables de produit croient que l’expérience est la meilleure source de connaissance et que les décisions sont basées sur celle-ci. Il n’y a pas de plan fixe sur la table, et certainement pas de diagramme de Gantt. Ils sont zélés et mesurent tout. Leurs plans peuvent changer périodiquement.

Comme organisation, n’attachez pas votre responsable de produit à un plan fixe et comprenez que la complexité du développement logiciel est telle qu’il est très difficile de prédire avec précision les dates de livraison pour une portée précise.

Collaboration

Les responsables de produit croient que la collaboration crée de meilleurs produits. Ils cherchent à réunir toutes les parties prenantes du produit pour faire la revue des incréments du produit et pour faire de la planification. Ils utilisent des outils pour rendre toutes les données et décisions visibles à tous et ils demandent ouvertement l’implication de quiconque peut avoir une influence positive sur le produit.

En tant qu’organisation, aidez votre responsable de produit en soutenant ses parties prenantes, incluant les utilisateurs du produit.

Ils possèdent plus d’empathie que d’habiletés de gestion

Les responsables de produit doivent être capables de « respirer le même air » que les utilisateurs et de partager leurs peines. Leur principale fonction est d’optimiser la valeur du produit en commandant le travail à effectuer. Ils se concentrent sur l’espace du problème et la valeur du produit.

En tant qu’organisation, ne demandez pas au responsable de produit de constamment remplir un rapport d’avancement, de réviser l’état du travail ou d’évaluer le rendement des « ressources ».

Les organisations d’aujourd’hui compétitionnent à tous les niveaux : marketing, recrutement, produits, services, financement, etc. Atteindre l’Agilité du produit devient un avantage fondamental de la transformation numérique.

1 Field of Dreams (1989), http://www.imdb.com/title/tt0097351/

Billet précédent

La culture DevOps pour le développement logiciel

Billet suivant

Pitié, ne construisez pas le nouveau pont Champlain en Agilité…

Luc St-Laurent

Luc est un professionnel certifié Scrum (CSP) et un coach Agile. Il a commencé son trajet dans les technologies de l'information il y a plus de 20 ans, et ce, bien avant d’adopter les valeurs Agiles (2007). Il se dévoue à aider les équipes et les gestionnaires à mieux collaborer afin de livrer un meilleur produit entre les mains de l’utilisateur. Luc croit au développement personnel au sein de l’équipe et au développement de l’équipe au sein de l’organisation. Il aspire à croire au développement de l’organisation au sein de notre société.

1 Commentaire

  1. didier@innotelos.com'
    19/06/2019 at 00:37 — Répondre

    Excellent article. Bravo !

Laissez un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.