Étiquette : product owner

Comment pouvez-vous surmonter le défi que seulement 20 % des fonctionnalités que votre équipe livre soient réellement utilisées ?

Le par mopertodans experience sharingLaisser un commentaire

Nishita Hathi, chef de produit, partage des stratégies pour augmenter l’utilisation des fonctionnalités du produit et améliorer la fidélisation des clients.

Overcoming the 20% feature usage challenge par Nishita Hathi

https://www.mindtheproduct.com/overcoming-the-20-feature-usage-challenge/

Beaucoup d’entre nous dans la communauté des produits sont confrontés au défi de l’utilisation limitée des fonctionnalités du produit. Une enquête Pendo a révélé que la plupart des utilisateurs de produits n’utilisent pas 80 % des fonctionnalités du produit. Microsoft a également observé qu’un utilisateur moyen de PowerPoint utilise moins de 10 % des fonctionnalités PowerPoint disponibles. Ma propre expérience s’aligne également sur les résultats de l’enquête Pendo. Pourtant, l’augmentation de l’utilisation des fonctionnalités est cruciale pour fidéliser vos clients et favoriser votre croissance grâce à la vente incitative.

Dans cet article, je partage mes observations sur les motivations derrière l’introduction de nouvelles fonctionnalités, pourquoi les utilisateurs finaux sous-utilisent les fonctionnalités, quel en est l’impact potentiel et je décris les approches que j’ai utilisées pour augmenter l’utilisation des fonctionnalités.

Motivations pour l’introduction de nouvelles fonctionnalités

En tant que chef de produit, vous introduisez de nouvelles fonctionnalités et capacités dans vos produits pour plusieurs raisons :

  • Vous assurer que le produit est aligné sur les tendances du marché et de la technologie.
  • Vous assurer que le produit présente des caractéristiques uniques et différenciatrices.
  • Répondre aux demandes et défis spécifiques de vos clients.
  • Vous assurer que le produit est comparable à celui d’un concurrent.

Dans le monde B2B, les équipes des achats privilégient souvent les produits riches en fonctionnalités. La plupart des appels d’offres exigent de fournir une gamme complète de fonctionnalités, ce qui oblige les fournisseurs à les prendre en charge dans leurs produits afin de remporter le marché. De plus, dans des secteurs tels que les télécommunications mobiles, les normes technologiques évoluent constamment, ce qui oblige également les fournisseurs à prendre en charge les nouvelles technologies en fonction de l’évolution des normes.

Observations sur l’utilisation des fonctionnalités

Malgré la disponibilité de fonctionnalités complètes, les utilisateurs finaux n’en utilisent souvent qu’un petit sous-ensemble.

D’après mon expérience, cela est attribué à plusieurs facteurs :

  1. Se concentrer sur les besoins immédiats : Les utilisateurs finaux utilisent des fonctionnalités qui les aident à accomplir leurs tâches actuelles.
  2. Manque de temps : Les utilisateurs manquent souvent de temps pour explorer des fonctionnalités supplémentaires, même si celles-ci peuvent apporter une valeur supplémentaire.
  3. Manque de notoriété : Parfois, les utilisateurs ne sont pas au courant ou ont oublié ce qui est disponible dans le produit.

D’autres facteurs limitent également l’utilisation des fonctionnalités, notamment l’inertie à apprendre quelque chose de nouveau ou à faire quelque chose de différent. Avec des fonctionnalités complexes, la facilité de configuration ou le temps nécessaire à l’exécution de tâches spécifiques peuvent également dissuader de les utiliser.

Impact d’une faible utilisation des fonctionnalités

Une faible utilisation des fonctionnalités peut entraîner les conséquences suivantes :

  • Réduction des opportunités de vente incitative : Une utilisation limitée rend plus difficile la vente de fonctionnalités supplémentaires.
  • Risque accru de désabonnement : Si les utilisateurs n’utilisent que des fonctionnalités de base ou très limitées, ils peuvent plus facilement se tourner vers des concurrents offrant la même chose.

Approches pour stimuler l’utilisation des fonctionnalités

Afin d’augmenter l’utilisation des fonctionnalités, les utilisateurs finaux doivent être conscients de la valeur des fonctionnalités supplémentaires et doivent être en mesure de les utiliser avec très peu de friction.

Voici les approches que j’ai utilisées ces dernières années pour faire bouger l’utilisation des fonctionnalités :

  • Engagement régulier des utilisateurs – Apprendre, informer et éduquer

Un engagement régulier avec vos clients vous permet de comprendre leurs besoins et vous donne l’occasion de présenter des fonctionnalités qui peuvent apporter une valeur ajoutée dans le contexte de votre client.

Dans mes interactions avec les clients, j’ai rencontré des situations où le client essaie de résoudre un problème et n’est pas conscient de la capacité du produit à résoudre le problème, comme des moyens plus simples de configurer le produit pour leur cas d’usage ou la possibilité d’effectuer des types de modélisation spécifiques.

En plus d’informer et d’éduquer, ces interactions régulières peuvent également conduire à de nouveaux cas d’utilisation des capacités existantes.

  • Mises à jour fréquentes des fonctionnalités et accès facile aux informations

La présentation des fonctionnalités dans le cadre d’un atelier aide vos utilisateurs à comprendre l’étendue des capacités. Cependant, il est probable qu’ils ne se souviendront pas de tout ce que vous avez présenté. Par conséquent, il est important de fournir des mises à jour fréquentes. Il peut être difficile d’avoir du temps en face à face avec vos clients sur une base régulière et cela peut devenir écrasant. Il est important d’exploiter différents formats pour promouvoir les fonctionnalités de vos produits.

L’une des approches que j’ai utilisées consiste à partager de brèves vidéos explicatives (2 à 3 minutes) sur une base mensuelle par e-mail et sur les plateformes de médias sociaux. Chaque vidéo se concentre sur un aspect très spécifique du produit. Il peut s’agir d’un ensemble de fonctionnalités d’utilisabilité qui entraînent une réduction du nombre de clics ou d’une fonctionnalité technologique qui leur permet de modéliser une nouvelle technologie. L’objectif est de démontrer et d’informer l’utilisateur de la valeur ajoutée que votre produit peut créer.

La disponibilité de plateformes de synthèse vocale telles que Synthesia facilite la création de vidéos explicatives.

  • Mise en œuvre simplifiée

Une fois que l’utilisateur est convaincu qu’une fonctionnalité ou une capacité particulière peut apporter une valeur ajoutée, il est important de s’assurer qu’il y a très peu de frictions lors de la configuration et de l’exécution de cette capacité. Lorsqu’il s’agit de fonctionnalités complexes, les utilisateurs s’abstiennent souvent de les utiliser car elles sont complexes à configurer. Même si le produit peut disposer d’un ensemble complet de documents de support tels que des guides d’utilisation, des guides techniques, des vidéos explicatives, il est souvent difficile de s’y retrouver dans un volume élevé d’informations.

Plus récemment, j’ai exploré l’utilisation de l’IA générative pour changer la façon dont les utilisateurs interagissent avec les différents supports de produit. Au lieu de rechercher dans des documents individuels, l’utilisateur peut poser des questions spécifiques et obtenir une réponse cohérente, ce qui rend le processus beaucoup plus fluide.

  • Culture interne d’apprentissage continu

En plus de faire référence aux garanties, vos utilisateurs auront parfois besoin d’un soutien supplémentaire de la part des équipes en contact avec les clients. Il est important d’établir une culture interne d’apprentissage continu afin de s’assurer que vos équipes en contact avec votre clientèle peuvent promouvoir et défendre les capacités de votre produit.

Voici quelques-unes des approches que j’ai mises en œuvre :

  • Un webinaire interne mensuel régulier sur un sujet ou une fonctionnalité spécifique.
  • Une plateforme LMS (Learning Management System) interne pour héberger le matériel de formation sur les produits.
  • Un programme d’évaluation interne qui mène à une certification et à d’autres récompenses.

Réflexions finales

À l’avenir, l’IA offre des opportunités pour accroître drastiquement l’utilisation de toutes vos fonctionnalités. Lors du lancement de Microsoft Office 365 Copilot, son vice-président principal, Sumit Chauhan, s’est demandé :

Et si les outils pouvaient apprendre comment vous travaillez, plutôt que l’inverse ?

Cela signifierait que les utilisateurs seraient automatiquement informés des fonctionnalités qui généreraient plus de valeur pour eux et guidés sur la façon d’exploiter les fonctionnalités, ce qui entraînerait une utilisation beaucoup plus élevée de celles-ci !

Ne sortez plus de nouvelles fonctionnalités dont personne ne se soucie !

Le par mopertodans agile, best practicesLaisser un commentaire

L’opposé d’une usine à fonctionnalités est une équipe responsabilisée qui se concentre sur les résultats et qui est impatiente de montrer ses livrables et de s’adapter en permanence en fonction des retours des utilisateurs.

Releasing new features nobody cares about par David Pereira

https://www.mindtheproduct.com/releasing-new-features-nobody-cares-about/

Lisez un court extrait du livre de David Pereira sur la sortie de fonctionnalités dont personne ne se soucie.

Livre sur Amazon

Quelle est votre expérience lors de la sortie de nouvelles fonctionnalités ? Peut-être est-ce un peu aléatoire. Malheureusement, de nombreuses équipes tombent dans le piège de devenir des usines à fonctionnalités. Dans son livre, David Pereira, coach produit et auteur, aide les équipes à surmonter ces pièges dangereux et à créer des produits que les clients aiment vraiment.

Vous trouverez ci-dessous un court extrait de son livre sur la sortie de fonctionnalités dont personne ne se soucie. Si vous aimez ce que vous lisez, vous pouvez obtenir le livre complet ici.

Comment fonctionnent les entreprises « Feature Factory » (usines à fonctionnalités) ?

Après des mois de travail acharné et une coordination exhaustive, l’équipe produit publie enfin une nouvelle fonctionnalité. Tout le monde dans l’équipe et dans l’entreprise l’adore. La nouvelle fonctionnalité brillante est prête pour les clients, mais quelque chose d’inattendu se produit. Les clients qui interagissent avec la nouvelle fonctionnalité ne comprennent pas son objectif et n’en tirent pas de bénéfices. Confus, les clients rejettent la nouvelle fonctionnalité brillante tant appréciée des parties prenantes de l’entreprise, et inévitablement, tout le monde est frustré.

Construisez-vous des fonctionnalités dont les clients n’ont pas besoin ?

Ce n’est pas la raison d’être des équipes produit que de créer des solutions que leur entreprise adore mais dont les clients se moquent. Pourtant, cela se produit plus souvent qu’il ne le devrait. J’appelle cela un bug, pas une fonctionnalité. Comme pour tous les bogues critiques, il nécessite un correctif.

Le remède : Des équipes responsabilisées grâce à des flux collaboratifs.

Si l’usine à fonctionnalités est un bogue, qu’est-ce qui résoudrait cela ? Vous ne pouvez pas vous attendre à une solution simple, mais la promotion d’équipes autonomes avec des flux collaboratifs transformera la situation.

Marty Cagan, partenaire SVPG, définit les équipes responsabilisées comme suit :

« Les grandes équipes sont composées de gens ordinaires qui sont responsabilisés et inspirés. Ils sont habilités à résoudre des problèmes difficiles d’une manière que leurs clients aiment, tout en travaillant pour leur entreprise. Ils sont inspirés par des idées et des techniques pour évaluer rapidement ces idées afin de découvrir des solutions qui fonctionnent : elles sont précieuses, utilisables, réalisables et viables. »

Comment les méthodes de travail courantes piègent-elles ou libèrent-elles les équipes ?

Les équipes responsabilisées ont beaucoup plus de chances de créer de la valeur que les équipes d’usine à fonctionnalités. Pourtant, il n’est pas facile de responsabiliser les équipes. Pour l’instant, concentrons-nous sur les défis de la collaboration.

Flux de développement de produits coordonnés ou collaboratifs

Au fil des ans, j’ai remarqué 2 flux standard de développement de produits dans les entreprises, quel que soit leur cadre :

  1. Flux de coordination : Les membres de l’équipe passent beaucoup de temps à coordonner les activités entre eux, les parties prenantes et les autres équipes. La majeure partie de leur énergie est consacrée à l’organisation de la façon de faire le travail. Cette approche vise à éviter les erreurs et les échecs, obligeant les équipes à être rigides dans leur flux de développement. Cela devient un contrat « strict » parce que quelqu’un est blâmé lorsque quelque chose ne va pas.
  2. Flux collaboratif : Les membres de l’équipe se concentrent sur la collaboration pour utiliser leurs connaissances actuelles afin de découvrir des opportunités prometteuses. L’objectif ultime est de créer de la valeur pour les clients et l’entreprise. L’équipe est flexible dans la façon dont elle fait le travail tout en se concentrant sur la création de valeur. La confiance est à la base de l’approche collaborative. Lorsque quelque chose déraille, l’équipe prend ses responsabilités et trouve ensemble une solution.

Le flux coordonné : Une façon logique de travailler avec des résultats inattendus

Comment transformer une idée en quelque chose de précieux ? C’est l’une des questions les plus importantes pour les entreprises. Une mauvaise réponse conduit au gaspillage et à la démotivation.

Les étapes d’un flux coordonné

  1. Priorisation : Le flux de coordination commence par la hiérarchisation, visant à trouver l’idée la plus prometteuse. Cependant, c’est plus facile à dire qu’à faire car plusieurs tours de discussion auront lieu. Lorsque vous dites oui à une idée, vous dites non à de nombreuses autres, et presque aucune partie prenante de l’entreprise n’accepte facilement cette réponse
  2. Conception : La phase de conception commence une fois que vous avez défini ce sur quoi l’équipe va travailler. Le résultat est souvent un prototype haute-fidélité que les parties prenantes de l’entreprise approuvent. Cette approche est dangereuse car les ingénieurs logiciels et les clients ont tendance à être laissés à l’écart. Malheureusement, la solution devient l’objectif, et non le résultat.
  3. Test utilisateur : Après beaucoup de coordination, les parties prenantes de l’entreprise approuvent finalement la conception et il est temps de la tester avec des clients potentiels. Les résultats sont probablement biaisés car tout le monde aime déjà la solution. Malheureusement, être la proie du biais de confirmation n’est pas l’exception, mais plutôt le résultat typique. Compte tenu de leur passion pour la solution, les concepteurs de produits recherchent des signes positifs et, sans surprise, ils les trouvent. Ils peuvent accepter des ajustements mineurs de la solution, mais aucun pivot ou abandon de solution ne se produira dans cette phase.
  4. Développement : Une fois que les concepteurs de produits ont confirmé que le prototype haute-fidélité a du sens pour les utilisateurs finaux, il est temps de développer la solution. Les concepteurs de produits jettent les spécifications par-dessus le mur et espèrent que les ingénieurs logiciels font le bon travail. Bien sûr, il est peu probable que les ingénieurs logiciels accueillent la solution à bras ouverts, car ils n’ont pas participé aux étapes précédentes. Malgré cela, c’est à eux de transformer le prototype haute-fidélité en une solution fonctionnelle.
  5. Lancement : Compte tenu de la quantité de coordination nécessaire, il faut des mois pour transformer une idée en solution. Vous ne devriez pas être surpris quand quelque chose prend six mois. Chaque phase est strictement définie et comporte de nombreuses étapes pour assurer une solution parfaite à la fin de celle-ci. Pourtant, quelque chose d’inattendu se produit lorsque vous lancez la solution. Malgré tout l’enthousiasme interne et l’amour pour la nouvelle solution sophistiquée, les clients ne s’y intéressent pas, et vous ne savez pas pourquoi.

Ce qui me choque, ce n’est pas de me retrouver dans cette situation tragique. J’y suis allé plus de fois que je ne peux compter, mais j’ai appris la leçon. La question est de savoir ce que vous faites après avoir été confronté à un résultat indésirable. La réponse la plus courante n’a guère de sens pour moi. Revenez à la hiérarchisation, choisissez une autre idée et recommencez. Lorsque vous suivez la même approche, il y a de fortes chances que vous soyez à nouveau confronté aux mêmes résultats. Le flux de coordination oblige les équipes à se concentrer sur les résultats plutôt que sur les résultats, ce qui les réduit au rang d’usines.

9 idées sur 10 échoueront

Notre taux de réussite est pire que ce que nous pouvons imaginer. Regardez les start-up : 90% d’entre elles ne tiennent pas plus de cinq ans. Les idées subissent à peu près le même sort. Curieusement, cela passe inaperçu car les équipes investissent beaucoup de temps à trouver comment réduire le temps de développement. Je vois de la valeur dans cette affaire, bien que je perçoive une autre question comme plus urgente : « A quelle vitesse pouvez-vous laisser tomber les mauvaises idées ? »

Nous supposons que nos idées sont bonnes, mais la réalité nous montre le contraire. Pourtant, nous insistons pour suivre la même approche à plusieurs reprises. Pas étonnant que nous soyons confrontés à des résultats indésirables.

Un bon management de produit nécessite de s’adapter en apprenant. C’est OK de se tromper. Il n’est pas bon d’ignorer la réalité. La collaboration plutôt que la coordination est le principe qui peut vous sortir de ce piège. Au lieu de rendre votre flux de développement rigide et complexe, vous bénéficierez d’une simplicité et d’une flexibilité accrues. Explorons une autre méthode de travail qui augmente les chances de générer de la valeur plus rapidement.

Flux collaboratif : Une méthode de travail simple qui apporte des résultats exceptionnels.

Personne ne mérite de perdre du temps. Après de nombreuses années d’expérience, j’ai appris que les échecs sont inévitables. Au lieu d’ajouter des étapes pour prévenir les échecs, il est plus logique d’identifier et d’abandonner rapidement les mauvaises idées. Contrairement au flux coordonné, le flux collaboratif se concentre sur des itérations plutôt que sur des phases.

Les étapes d’un flux collaboratif

  1. Évaluez : Le début d’un flux collaboratif est le même que pour un flux coordonné. Vous avez plein d’idées, et tout le monde veut que tout soit terminé d’hier. L’astuce n’est pas d’identifier les idées les plus prometteuses dès le départ, mais plutôt de les évaluer toutes et de laisser tomber celles qui ne conviennent pas. Laisser tomber des idées vous donne de la liberté parce que vous avez moins d’attentes à gérer.
  2. Apprenez : L’itération d’apprentissage commence par des idées adaptées à votre stratégie, mais cela ne signifie pas qu’il faille passer directement à la mise en œuvre. Vous devriez laisser tomber les idées que vos clients ne désirent pas, que l’entreprise ne peut pas soutenir, que vous n’avez pas la technologie pour développer ou qu’il est contraire à l’éthique de poursuivre. Restez simple et posez les questions suivantes sur chaque idée restante :
  • À quel point les clients veulent-ils ceci ? (Désirabilité)
  • Quels sont les bénéfices pour l’entreprise ? (Fiabilité)
  • Dans quelle mesure pouvons-nous le faire ? (Faisabilité)
  • À quel point est-il bien de le faire ? (Éthique)
  1. Expérimentez : Après avoir compris les aspects clés de vos idées, il est temps de mener des expériences plus robustes. Vous voulez tester les solutions qui peuvent donner les résultats potentiels. Il est essentiel d’explorer quelques alternatives et de s’en tenir aux plus prometteuses. Il est trop courant de choisir une solution et de se lancer à fond. Je vous décourage de suivre cette voie, car elle augmente rapidement l’engagement. En tant qu’êtres humains, plus nous sommes investis dans quelque chose, plus nous y investissons volontiers.
  2. Déployez : Les idées qui survivent à l’itération de l’expérience sont les plus importantes. Dans l’itération précédente, vous avez construit pour apprendre. Maintenant, vous créez pour évoluer. Il est fondamental de rembourser la dette technologique avant de mettre la solution à la disposition de l’ensemble de votre public ou de passer à votre prochaine opportunité

Principaux points à retenir

  • La première étape pour libérer votre équipe consiste à examiner votre situation actuelle. Comprendre la dynamique peut révéler des opportunités pour simplifier votre flux de développement.
  • Les symptômes d’une usine à fonctionnalités comprennent l’absence d’objectifs, l’obsession de la production, la fourniture de solutions qui ne résolvent aucun problème, une direction peu claire, une réticence à laisser tomber des idées et un manque d’attention aux résultats. L’opposé d’une usine à fonctionnalités est une équipe responsabilisée qui se concentre sur les résultats et qui est impatiente d’examiner ses livrables et de s’adapter en permanence.
  • Plus vous vous rapprochez d’un flux de développement coordonné, plus il faut de temps pour générer de la valeur et plus vous créez de déchets. Les flux coordonnateurs transforment involontairement les plans en objectifs.
  • Plus vous vous rapprochez d’un flux de développement collaboratif, plus tôt vous créez de la valeur et moins vous produisez de déchets. La collaboration vous aide à adapter vos plans pour atteindre vos objectifs lorsque la réalité rend votre plan obsolète.
  • Lorsque vous comprenez parfaitement le flux de développement d’un produit, vous pouvez favoriser les changements étape par étape. La première étape consiste à collaborer avec les parties prenantes de l’entreprise et les membres de l’équipe pour reconnaître ce qui est inutilement complexe. Équipé de cette compréhension, vous pouvez obtenir du soutien et collaborer pour simplifier votre travail.
CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM

SPIDR : 5 façons simples mais puissantes de découper les histoires utilisateur / user stories

Le par mopertodans agile, best practicesLaisser un commentaire

Presque toutes les histoires peuvent être divisées avec l’une des 5 techniques suivantes. Apprenez ces cinq approches simples et vous serez prêts.

SPIDR: Five Simple but Powerful Ways to Split User Stories par Mike Cohn

https://www.mountaingoatsoftware.com/blog/five-simple-but-powerful-ways-to-split-user-stories

L’une des difficultés les plus courantes rencontrées par les équipes agiles est la nécessité de découper des histoires utilisateur. Je suis sûr que vous avez aussi eu du mal avec cela. C’est certainement ce que m’est arrivé au début.

En fait, quand j’ai commencé à utiliser Scrum, dans certains de nos arriérés de produit, les histoires étaient si grosses que nous avons parfois opté pour des sprints de six semaines. Avec un peu plus d’expérience, cependant, cette équipe et moi avons vu suffisamment de façons de décomposer le travail pour que nous puissions faire des sprints d’une journée si nous l’avions voulu.

Mais décomposer les histoires a été difficile au début. Vraiment dur.

J’ai de bonnes nouvelles pour vous. Non seulement j’ai compris comment découper des histoires par moi-même, mais j’ai aussi appris à expliquer comment le faire afin que tout le monde puisse rapidement devenir un expert. (Si vous voulez jeter un coup d’œil dans les coulisses de vraies histoires d’utilisateurs de certains de mes premiers backlogs de produits, avec des commentaires sur ce que je ferais différemment aujourd’hui : Télécharger 200+ exemples de User Story).

Ce que j’ai découvert, c’est que presque toutes les histoires peuvent être divisées avec l’une des cinq techniques suivantes. Apprenez ces cinq techniques simples et vous êtes prêt.

Mieux encore, les cinq techniques forment un acronyme facilement mémorisable : SPIDR.

Je présente chaque technique ci-dessous, et cette vidéo les montre en action.

Technique SPIDR pour diviser les histoires

Il y a quelques années, je créais le cours « Better User Stories ». Parce que ce cours couvrirait tout ce que quelqu’un doit savoir pour travailler efficacement avec des histoires, je savais qu’il fallait d’un module sur le fractionnement.

Pour créer ce module, j’ai imprimé plus d’un millier d’histoires ‘utilisateur que j’avais rassemblées pendant 15 ans. Pour chaque histoire, j’avais l’histoire originale et les sous-histoires dans lesquelles elle avait été divisée. J’ai collé chaque histoire sur le mur, en les regroupant en fonction de la façon dont elles avaient été divisées. Je cherchais les approches communes utilisées pour découper toutes ces histoires. Je suis passé par une variété de regroupements, en essayant de trouver le plus petit ensemble d’approches possible. Je savais qu’il serait plus facile de se souvenir de 5 techniques de fractionnement plutôt que de 20.

Les cinq que j’ai obtenues forment l’acronyme SPIDR : S, P, I, D et R (spider sans E).

Jetons un coup d’œil aux cinq techniques de fractionnement des user stories qui composent l’acronyme SPIDR, avec des exemples de la façon dont votre équipe pourrait les utiliser.

#1 – Diviser les User Stories à l’aide d’un Spike

S comme Spike. C’est un problème que la plupart des équipes agiles connaissent. Un spike est une activité de recherche qu’une équipe entreprend pour en savoir plus sur un élément de l’arriéré. Les spikes peuvent également donner aux équipes les connaissances dont elles ont besoin pour diviser une histoire complexe. Considérez-le comme une activité de recherche, mais il peut inclure du prototypage ou du codage expérimental.

Au cours d’un spike, une équipe n’essaie pas de développer la nouvelle fonctionnalité, mais plutôt de développer de nouvelles connaissances qui l’aideront à développer la fonctionnalité plus tard.

Prenez YouTube par exemple. Remontez dans le temps, à l’époque où YouTube ajoutait le sous-titrage automatique. L’équipe qui s’est chargée de cela aurait peut-être été confrontée à une décision de construction ou d’achat. Utilisent-ils un logiciel disponible dans le commerce pour générer les sous-titres ? Ou leurs besoins sont-ils si uniques qu’ils doivent développer quelque chose à partir de zéro ? La façon de régler cela serait un spike pour tester un ou plusieurs produits de sous-titrage disponibles dans le commerce.

L’extraction d’un spike réduit la taille de l’article d’origine, car une partie ou la totalité des recherches incluses dans l’article d’origine est supprimée. C’est absolument un moyen essentiel de diviser les histoires. L’extraction d’un spike est donc l’une des cinq techniques de fractionnement que vous devriez utiliser. Mais normalement, ce ne sera pas la première technique que vous utiliserez.

#2 – Diviser les User Stories par Path (chemin)

P comme Path. Si un utilisateur peut faire quelque chose de plusieurs façons (par exemple, payer avec une carte ou Apple Pay), c’est un excellent domaine pour diviser.

Pour diviser une histoire en chemins, recherchez d’autres chemins d’accès à travers l’histoire.

Pour rester sur YouTube, utilisons l’histoire : « Je peux partager une vidéo avec mes amis ».

Lorsque je clique sur le bouton « Partager » sur YouTube aujourd’hui, on me montre 14 boutons sur lesquels je peux cliquer pour partager directement sur divers réseaux sociaux. On me montre également un lien que je peux copier. Et j’ai la possibilité de personnaliser ce lien pour démarrer la lecture de la vidéo partagée à un moment précis de la vidéo.

Il s’agit de 16 chemins différents à travers l’histoire « Je peux partager une vidéo ». Je ne sais pas si cette histoire a besoin d’être divisée en autant de sous-histoires plus petites. C’est à l’équipe de décider en fonction de l’effort impliqué. Mais, avec la seule technique du chemin, nous avons identifié 16 chemins à travers l’histoire originale.

#3 – Diviser les User Stories par Interfaces

I est pour Interfaces : Diviser votre histoire par navigateur ou matériel, ou fournir une interface complexe par itérations. Par exemple, vous pouvez proposer une version qui ne fonctionne que dans Chrome dans cette itération et prévoir Safari pour une autre itération.

Dans d’autres cas, le découpage par interface signifie la création d’une version simple de l’interface et d’une version plus complexe en tant qu’histoires distinctes. Cela s’applique généralement à l’interface utilisateur.

En appliquant cela à notre exemple de partage de vidéos YouTube, au lieu de diviser cette histoire par des chemins, nous aurions pu séparer une histoire de partage de base telle que : « En tant que spectateur de vidéos, je peux obtenir une URL que je peux partager ». Cela pourrait être mis en œuvre sans autre interface utilisateur qu’un bouton de partage sur la page vidéo. La fenêtre contextuelle avec les 16 différentes façons de partager ne serait pas nécessaire si la seule façon de partager est avec une URL.

Une histoire ultérieure pourrait être : « En tant que spectateur, je peux partager une vidéo sur divers sites de médias sociaux. » Cela pourrait être fait avec une interface utilisateur très simple au début – pas de fantaisie de faire défiler une liste de logos, peut-être juste une liste déroulante de texte avec les noms des sites sociaux.

L’histoire finale pourrait alors ressembler à quelque chose comme : « En tant que spectateur, je peux choisir le réseau social sur lequel partager en faisant défiler une liste montrant les logos de chacun. »

La division par interface fonctionne parce que la fonctionnalité finalement souhaitée peut être atteinte par des interfaces de plus en plus détaillées et meilleures.

#4 – Diviser les User Stories par Data / Données

Le D de l’acronyme SPIDR signifie Données.  Pour diviser une histoire par données, demandez-vous si vous pouvez apporter de la valeur dans une itération en simplifiant ou en limitant les données prises en charge. Peut-être pouvez-vous faire une version initiale d’une histoire qui ne traite qu’un sous-ensemble des données qui devront finalement être prises en charge. Par exemple, n’autorisez pas les soldes bancaires négatifs dans la première itération. Ajoutez la prise en charge de ceux avec une histoire utilisateur différente dans la prochaine itération.

Pour revenir à l’exemple de YouTube, YouTube vous permet de télécharger une vidéo dans l’un des 16 formats de fichiers différents. Si nous construisons un concurrent de YouTube, oublions les 16 formats de fichiers. Commençons par 1. Nous allons prendre en charge un type de données. Pour l’instant, tous les téléchargements doivent être au format MP4. Nous ajouterons tous les autres plus tard en tant qu’histoires distinctes.

Le fractionnement par données est une approche efficace. Souvent, il y a quelques types de données qui ajoutent beaucoup de complexité. Eh bien, faites une mise en œuvre initiale qui ignore les données les plus complexes. Faites en sorte que cela fonctionne, puis ajoutez la prise en charge des données plus complexes. Vous ne pouvez probablement pas mettre en production la version la plus simple, mais vous pouvez toujours la construire dans cet ordre.

J’ai travaillé sur un système de ressources humaines qui faisait exactement cela. Le système suivait qui était le manager pour chaque employé et faisait des choses comme acheminer les demandes de congé à ce manager. La plupart des employés ont un manager, mais certains employés en ont plusieurs. Nous devions supporter le fait d’avoir plusieurs managers, mais certaines histoires ont été simplifiées au départ en supposant que chaque employé avait uniquement un manager.

#5 – Diviser les User Stories par des Règles / Rules

R comme Règles. Le relâchement temporaire de l’implémentation de règles qu’un article devra au final prendre en charge peut réduire la taille des grandes histoires.

Si l’on s’en tient à YouTube, par exemple, YouTube a des règles strictes concernant l’inclusion de musique protégée par des droits d’auteur dans les vidéos. Si nous construisons un concurrent à YouTube, la première histoire de notre équipe sera : « Je peux télécharger une vidéo pour que d’autres puissent la regarder. » Cette histoire semble probablement simple, mais il y a déjà beaucoup de choses à faire.

Donc, dans la première itération, ignorons la règle selon laquelle les vidéos ne peuvent pas contenir de musique protégée par des droits d’auteur. De toute façon, nous n’annonçons pas notre nouveau concurrent à YouTube au monde après une seule itération. Nous aurons tout le temps après ce premier sprint de nous conformer à notre règle interne interdisant les vidéos contenant de la musique protégée par des droits d’auteur.

Comme cet autre exemple lié à YouTube, supposons que nous voulions empêcher certains textes d’apparaître dans les commentaires. Il peut s’agir de jurons ou de commandes SQL qui peuvent être des tentatives de piratage. Bonne idée : Protégeons nos utilisateurs et notre système de ce type de texte dans les commentaires. Mais une première histoire du type « En tant qu’utilisateur, je peux entrer un commentaire sur une vidéo » peut ignorer cette règle. Cela rend l’histoire plus petite afin qu’elle puisse s’intégrer dans une itération. Et la prise en charge de la règle peut être ajoutée quelques itérations plus tard.

S’améliorer dans le fractionnement des histoires

S’améliorer dans le découpage des histoires d’utilisateurs est une compétence importante. Avec les courtes itérations utilisées en agile, il est utile d’avoir de petites unités de travail. Les cinq techniques que nous avons abordées ici (fractionnement par Spikes, Paths, Interfaces, Données et Règles) devraient vous permettre de fractionner n’importe quelle histoire.

Les techniques SPIDR sont faciles à retenir, mais leur mise en pratique peut nécessiter un peu d’entraînement et beaucoup de pratique. C’est pourquoi j’ai mis en place un cours vidéo « Better User Stories » qui inclut la méthode SPIDR pour diviser les histoires, et bien plus encore.

CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM

Déroulement d’une session d’affinement de l’arriéré de produit (Product Backlog Refinement) par Sam Adesoga

Le par mopertodans agileLaisser un commentaire

La session d’affinement de l’arriéré de produit n’est pas un événement Scrum obligatoire, mais une pratique complémentaire très utile qui aide l’équipe Scrum et ses parties prenantes à parvenir à une compréhension commune de l’arriéré de produit, de l’objectif produit et des priorités.

What Happens in a Product Refinement Session

https://samadesoga.me/posts/what-happens-in-a-product-backlog-refinement-session/ par Sam Adesoga

La session d’affinement de l’arriéré de produit (Product Backlog Refinement) n’est pas un événement Scrum officiel, mais c’est une activité cruciale qui aide les équipes Scrum à parvenir à une compréhension commune des éléments de l’arriéré de produit en préparation à la planification du sprint. Les équipes qui adoptent l’amélioration de l’arriéré de produit comme pratique complémentaire ont tendance à avoir des événements de planification de sprint plus fluides. Le nombre de sessions de raffinement au sein d’un sprint dépend de divers facteurs tels que l’état de l’arriéré de produit, la maturité du produit, la disponibilité et l’expérience de l’équipe Scrum.

Il y a de nombreuses de façons de faciliter une session d’affinement de l’arriéré de produit, mais je présente ici certaines des activités que j’attendrais d’une équipe Scrum dans l’une de ces sessions. Celles-ci ne sont pas présentées dans un ordre particulier.

Ventiler les éléments de l’arriéré de produit (Product Backlog Items / PBI)

Dans la session d’affinement de l’arriéré de produit, l’équipe Scrum doit chercher à décomposer les PBI jusqu’à ce qu’ils soient suffisamment petits pour tenir dans le sprint.

La définition de terminé (done) doit être utilisée comme guide pour discuter du travail à accomplir pour chaque PBI du sprint.

Il y a de nombreuses techniques qui peuvent être utilisées pour décomposer les PBI, mais je préfère le découpage vertical des PBI, car l’équipe Scrum a une plus grande probabilité de fournir un incrément utilisable à partir d’un PBI, lorsque le PBI est découpé verticalement.

Estimer les PBI

Les équipes Scrum qui pratiquent l’estimation en tant que pratique complémentaire doivent fournir une prévision de l’effort requis pour fournir des PBI en utilisant la définition de terminé (done) pour le produit comme guide.

Pour ces équipes, l’estimation des PBI aide l’équipe Scrum à sélectionner des éléments de l’arriéré de produit jusqu’à la pleine capacité des développeurs. Si des estimations ont déjà été fournies pour les PBI, l’animateur de la session d’affinement de l’arriéré de produit doit reconfirmer que chaque développeur reste à l’aise avec l’estimation qui a été précédemment enregistrée sur le PBI.

Certaines techniques courantes d’estimation incluent Story Pointing, T-Shirt Sizing and Planning Poker.

Critères d’acceptation de la revue

Les critères d’acceptation devraient être revus pour en vérifier la clarté et l’exhaustivité lors de la séance d’amélioration de l’arriéré de produit. L’animateur doit inviter les participants à la session d’amélioration de l’arriéré de produit à poser des questions et à demander des éclaircissements si nécessaire. Il y a des cas où l’équipe n’arrive pas à s’entendre sur les critères d’acceptation, en particulier pour un PBI complexe ; L’équipe Scrum pourrait alors trouver utile de réexaminer le « pourquoi ? ». Le Product Owner doit être en mesure d’exprimer clairement la valeur du PBI ; D’après mon expérience, une fois que la valeur est transparente pour tous les participants, les développeurs peuvent s’autogérer pour déterminer les détails de ce qui doit être fait et comment le travail serait accompli.

Discutez des dépendances et des blocages

Attention aux dépendances croisées qui s’emmêlent et créent des nœuds inextricables.

Cela n’aurait aucun sens d’intégrer une histoire utilisateur / story avec des dépendances et des blocages dans un sprint, car cette story ne sera probablement pas terminée dans le sprint. L’équipe Scrum doit discuter de toutes les dépendances et de tous les bloqueurs pour s’assurer que tout le monde a une compréhension commune des dépendances et des blocages ; L’équipe Scrum doit mettre en place un plan pour résoudre ces dépendances et ces blocages. Le cas échéant, ces dépendances et blocages doivent être représentés dans l’arriéré de produit et attribuées aux personnes qui travaillent à les supprimer. À titre indicatif, l’équipe Scrum ne doit PAS présenter d’éléments avec des dépendances et des blocages non résolus pour la planification du sprint, sauf s’il existe un plan pour résoudre ces obstacles au sein du sprint.

Priorisez l’arriéré de produit

Le Product Owner est responsable de la priorisation de l’arriéré de produit et il existe un certain nombre de raisons qui peuvent être prises en compte telles que la Valeur, la Priorité, la Cohérence Business, la Cohérence Technique, etc. Le Product Owner doit prendre l’habitude de garder l’arriéré produit ordonné à tout moment et une session telle que la session d’affinement de l’arriéré de produit est un bon moment pour examiner et mettre à jour l’ordre des PBI dans l’arriéré de produit.

CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM

Comme indiqué dans l’introduction, la session d’amélioration de l’arriéré de produit n’est pas un événement Scrum obligatoire, mais une pratique complémentaire très utile qui aide l’équipe Scrum et ses parties prenantes à parvenir à une compréhension commune de l’arriéré de produit, de l’objectif produit qu’il contient et des éléments de l’arriéré de produit qui ont émergé pour atteindre l’objectif produit.

Sam Adesoga

Sam Adesoga

Coach Agile Principal et Formateur Principal at Valuehut, un cabinet de conseil en coaching et formation agile, qui aide les organisations à explorer les méthodes de travail agiles. Sam a beaucoup d’expérience dans le soutien aux dirigeants et à leurs équipes en matière d’agilité d’entreprise avec un objectif ambitieux : Aider les organisations à développer un état d’esprit agile nécessaire pour continuer à garder une longueur d’avance sur la concurrence et les marchés.

Mener un spike technique à l’aide du développement axé sur le comportement par Sam Adesoga

Le par mopertodans agileLaisser un commentaire

Mener un spike technique à l’aide du développement axé sur le comportement

https://samadesoga.me/posts/driving-a-technical-spike-using-bdd/ de Sam Adesoga

Visitez le site SAFe

La plupart des méthodologies agiles prévoient l’application d’un Technical Spike pour explorer une nouvelle technologie ou les zones à risque d’un produit. La méthodologie SAFe (Scaled Agile Framework) définit le Spike comme un type d’histoire d’exploration et de catalyseur.

Il existe un certain nombre d’approches qui ont été recommandées pour les Technical Spike.

Il s’agit notamment de :

  • Estimation et dimensionnement d’une histoire de Technical Spike
  • Limiter dans le temps (Timeboxing) un Technical Spike.

Le Technical Spike est de nature exploratoire et il est contradictoire d’essayer d’estimer la complexité d’un travail qui n’est pas bien compris. D’après mon expérience, la plupart des équipes préféreraient limiter dans le temps les efforts nécessaires pour réaliser un Technical Spike.

Il y a quelques semaines, j’ai eu une conversation avec un développeur qui était à mi-chemin d’un spike et j’ai eu un moment « ah-ha », et cet article est une tentative d’expliquer ce qui pourrait être une approche alternative aux Technical Spikes.

Je suggérerais au Product Owner / Business Analyst en collaboration avec un membre technique de l’équipe, par exemple un architecte, un responsable technique, de définir les exigences de haut niveau à l’aide de la méthodologie de développement axée sur le comportement.

CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM

Les avantages de la spécification des exigences axée sur le comportement dès le départ sont les suivants.

  • L’objectif du Technical Spike est clairement défini à l’avance et, en tant que tel, le développeur est clair sur ce qu’est le livrable.
  • La définition de DONE pour le Technical Spike est dès que toutes les exigences spécifiées sont satisfaites.
  • Le développeur ou un testeur peut automatiser le script de développement axé sur le comportement en exigences exécutables.
  • Le risque de consacrer trop de temps/d’efforts au Technical Spike est minimisé.
  • Une ligne de base d’exigences pour la mise en œuvre réelle évolue à partir du Technical Spike.

Comme pour tout le reste, il n’y a pas de solution miracle, mais il faut veiller à ne pas aller trop loin avec les exigences. Étant donné qu’il s’agit d’un Technical Spike, il est nécessaire de s’assurer que l’exigence est à un niveau très élevé suffisant pour décrire les objectifs du Technical Spike et qu’elle ne soit pas prescriptive.

Cela semble bien fonctionner pour ce projet, alors n’hésitez pas à l’essayer.

Sam Adesoga, Principal Coach and Lead Trainer

  • Praticien agile et agnostique ainsi qu’un formateur professionnel Scrum avec Scrum.org
  • L’expérience professionnelle de Sam comprend Développeur, Développeur de logiciels, Test and Release Manager, Scrum Master et récemment coach Agile d’entreprise
  • Sam utilise des approches agiles comme fondation, et s’intéresse à aider les individus, les équipes et l’ensemble des organisations à développer l’état d’esprit et la culture nécessaires pour réussir dans un monde VUCA.
  • Nombre total d’années d’expérience dans le développement et la livraison de produits à l’aide de cadres de travail agiles – 17 ans.

« Libérez l’agilité organisationnelle ! Les indicateurs clés que tout leader devrait mesurer. » Sam Adesoga.

Le par mopertodans leadershipLaisser un commentaire

Explorez 5 indicateurs clés qui aident les leaders à suivre l’amélioration des équipes et des produits dans l’ensemble de l’organisation.

Unlocking Organisational Agility: Key product metrics every business leader should measure par Sam Adesoga

https://www.valuehut.co/blog/unlocking-organisational-agility-key-product-metrics-every-business-leader

 Le paysage concurrentiel actuel est en évolution rapide, caractérisé par l’arrivée de nouveaux acteurs dans des domaines d’activité établis, l’évolution des besoins des utilisateurs et l’introduction de nouvelles technologies à un rythme très rapide.  La plupart des organisations ne peuvent suivre ce rythme et l’agilité organisationnelle est une capacité essentielle pour votre réussite.

Les leaders sont souvent désireux de comprendre l’impact de l’adoption de méthodes de travail agiles et, dans cet article, nous explorons 5 indicateurs clés qui aident les leaders à suivre l’amélioration des équipes et des produits dans l’ensemble de l’organisation. Ces métriques sont d’excellents indicateurs pour ouvrir la voie à l’innovation, à la résilience et à une croissance soutenue.

#1 – Fréquence de livraison (de sortie)

Une mesure de la fréquence à laquelle une organisation délivre des mises à jour de son ou ses produits est l’un des principaux indicateurs du développement de ses capacités d’agilité business. Les approches agiles telles que Scrum aident les organisations à livrer fréquemment de la valeur aux utilisateurs. Avant même qu’un produit ne soit construit, la valeur qu’il apporte à ses utilisateurs cibles est estimée et les organisations valident les hypothèses lorsque le produit est finalement mis à la disposition du client. Une organisation dont la fréquence de sortie est plus rapide recueille potentiellement plus fréquemment les commentaires de ses utilisateurs.

L’organisation doit s’efforcer d’augmenter la fréquence de mise sur le marché de ses produits au fil du temps. Une fréquence de sortie plus élevée améliore l’agilité de l’entreprise en permettant une innovation plus rapide, une réactivité aux besoins des clients et une adaptabilité aux changements du marché.

Il y a un certain nombre de facteurs que nous pourrions prendre en compte pour augmenter la fréquence de sortie de ses produits :

  • Investissement dans les capacités d’intégration et de déploiement continus.
  • Tests fonctionnels et non fonctionnels automatisés.
  • Amélioration des capacités de management de produits, y compris la capture et l’analyse des commentaires des utilisateurs.
  • Créer des équipes inter-fonctionnelles dans le cadre des efforts de conception de l’organisation.
CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM

#2 – Incidents par période

Les équipes produit sont responsables de la livraison de produits utilisables à leurs clients et les incidents, lorsqu’ils se produisent, nuisent à la convivialité de vos produits. Les incidents font référence aux temps d’arrêt du produit, aux pannes du produit et aux défauts non détectés du produit, entre autres. Les leaders doivent encourager et soutenir l’équipe produit afin de réduire le nombre d’incidents rencontrés par les utilisateurs par période. Les entreprises doivent investir dans des capacités techniques qui permettent de capturer automatiquement ce type de problèmes à partir des relevés d’incidents et, en outre, de fournir aux utilisateurs un moyen de signaler ces problèmes.

Les entreprises gagnent beaucoup de bonne volonté de la part de leurs clients si ces problèmes peuvent être détectés et corrigés avant qu’ils ne soient visibles par les utilisateurs. Pour s’assurer qu’un produit conserve sa valeur pour ses utilisateurs, le nombre d’incidents par période doit avoir tendance à diminuer au fil du temps.

Voici quelques facteurs qui pourraient contribuer à réduire le nombre d’incidents par période :

  • Capturez la dette technique en tant qu’éléments de premier ordre de l’arriéré de produit.
  • Augmentez les tests automatisés autour des fonctionnalités sujettes aux incidents.
  • Obtenez l’engagement de l’équipe produit à réduire la dette technique sur une période donnée.
  • Améliorez les capacités d’analyse des logs des utilisateurs pour repérer les problèmes potentiels.

#3 – Délai d’exécution

Le développement de produit est complexe. Complexe implique qu’il n’y a pas de relation directe entre la cause et l’action [Lire : Modèle Cynéfin]. En termes plus simples, il n’y a aucune garantie que les hypothèses que l’équipe produit fera lors de la construction du produit correspondront à la réalité. Par conséquent, plus tôt une organisation peut mettre en œuvre ses idées et mettre le produit entre les mains d’un utilisateur, plus tôt la valeur supposée du produit peut être validée.

La construction d’un produit est coûteuse et jusqu’à ce qu’un produit soit mis à la disposition de ses utilisateurs, le budget dépensé jusque-là pourrait être assimilé à un « stock d’invendus » comme dans le cas d’une entreprise traditionnelle.

Le délai d’exécution est le temps écoulé entre l’idée et le produit fonctionnel entre les mains du client.

Souvent, l’équipe produit trouve qu’il est plus facile de mesurer le temps de cycle, c’est-à-dire le temps écoulé entre le moment où une tâche est en cours et le produit entre les mains du client. Le temps de cycle peut être mesuré à la place du délai d’exécution, mais en fin de compte, l’équipe produit doit améliorer son système de management du backlog (l’arriéré de produit) pour calculer le délai d’exécution.

Il convient de souligner que l’effort visant à augmenter la fréquence de livraison devrait réduire le délai d’exécution. Cependant, la mesure et la visualisation du délai d’exécution apportent une valeur ajoutée à part entière.

Les facteurs qui améliorent les délais sont les suivants :

  • Réduire et, éventuellement, éliminer les temps d’attente dans le système.
  • Contribuer à limiter les travaux en cours.
  • Automatisation des tests et des déploiements.

#4 – Indice de satisfaction des employés

Dans notre travail avec les clients, nous avons observé que les leaders n’accordent pas suffisamment d’attention à une mesure très importante : Le niveau de satisfaction des personnes qui font réellement le travail. Il semble que les leaders supposent au fil du temps que les employés qui ne montrent pas de signes visibles d’insatisfaction doivent certainement être heureux et notre travail a montré que ce n’est certainement pas le cas

tristeLes employés qui ne sont pas satisfaits au travail et ont des niveaux de moral en baisse ne sont pas en mesure de fournir des produits de valeur que les utilisateurs adorent. Lors d’un récent engagement de transformation de l’organisation où nous avons remarqué que le moral des employés était en baisse, les leaders avaient demandé à l’équipe d’augmenter la fréquence des livraisons et de réduire le temps de cycle, mais les équipes ne pouvaient pas améliorer ces mesures sans l’adhésion des leaders à la prise de certaines décisions qui impliquaient d’investir dans l’automatisation et de restructurer les équipes. Les leaders ont également supposé qu’il était facile pour les équipes de s’améliorer. La seule façon d’obtenir l’engagement des leaders a été de mener une enquête sur la satisfaction des employés, qui a donné des résultats négatifs.

Nous avons pu cocréer un certain nombre d’initiatives avec les équipes produit, notamment :

  • Des méthodes de travail qui ont donné de l’autonomie et du sens aux équipes.
  • Le leader s’est engagé à financer des changements d’infrastructure afin de réduire la durée des cycles et d’augmenter la fréquence des livraisons.
  • Augmentation de la sécurité psychologique au sein de l’équipe.

Les employés engagés et heureux sont plus susceptibles d’accepter le changement, d’apporter des idées innovantes et de collaborer efficacement, alimentant ainsi l’agilité et le succès de votre organisation.

#5 – Satisfaction du client

Il faut beaucoup de travail pour créer des produits qui apportent continuellement de la valeur à leurs utilisateurs et les organisations capables de créer des produits de valeur peuvent s’attendre à ce que la satisfaction des clients s’améliore au fil du temps.

Les 4 indicateurs : Fréquence de livraison, Incidents par période, Délai d’exécution et Satisfaction des employés, contribuent tous à améliorer la satisfaction client.

Il existe un certain nombre de techniques qui ont été utilisées pour mesurer la satisfaction des clients, notamment le Net Promoter Score (NPS) et le taux d’attrition des clients.

L’équipe produit peut également envisager le déploiement de données de télémétrie qui fournissent des informations sur les comportements des utilisateurs au sein du produit.

Les mesures de satisfaction client fournissent des informations précieuses sur la façon dont le produit répond aux attentes des clients et va même plus loin. En écoutant activement vos clients et en adaptant vos produits, services et expériences en conséquence, votre équipe produit favorise la fidélité, établit des relations durables et garde une longueur d’avance sur un marché concurrentiel.

Sam Adesoga

Sam Adesoga

Coach Agile Principal et Formateur Principal at Valuehut, un cabinet de conseil en coaching et formation agile, qui aide les organisations à explorer les méthodes de travail agiles. Sam a beaucoup d’expérience dans le soutien aux dirigeants et à leurs équipes en matière d’agilité d’entreprise avec un objectif ambitieux :Aider les organisations à développer un état d’esprit agile nécessaire pour continuer à garder une longueur d’avance sur la concurrence et les marchés.

Toute augmentation des travaux en cours d’exécution dans votre projet Agile augmente automatiquement les délais !

Le par mopertodans agile, experience sharing1 commentaire

Connaissez-vous la loi de Little en management de projets Agile et en Management de Portefeuille de projets ?

La loi de Little porte le nom de son inventeur, John Little, qui a établi la théorie des files d’attente dans les années 1950s.

Au départ, la loi avait pour objectif de fournir une formule très simple pour juger de l’efficacité d’un système de gestion de file d’attente.

En 1961, Little a énoncé son théorème :

Le nombre de clients dans une file d’attente est égal au taux d’arrivée moyen des clients multiplié par le temps nécessaire pour les traiter.

Puis, cette loi fut souvent utilisée dans les approches Lean pour réduire les délais. Elle permet de calculer le temps moyen passé dans un système de production entre le début et la fin d’une tâche. L’objectif est bien sûr d’augmenter la capacité de production.

De nos jours, la loi de Little est utilisée dans les approches Agile, en particulier avec Kanban, car elle établit un lien très clair entre le WIP (Work In Progress – Travail en cours), le Lead Time LT (temps moyen pour exécuter une tâche) et le Taux de production T (le débit).

Cette formule est souvent exprimée ainsi :

WIP = T x LT

ou encore

LT = WIP / T

Toute augmentation des travaux en cours WIP augmente automatiquement les délais.

Dans les faits, certaines entreprises ont tendance à faire l’inverse. Elles augmentent les travaux en cours dans l’espoir d’augmenter la production et il en résulte souvent un total désastre en ce qui concerne le respect des délais.

De même, si une entreprise a du mal à exécuter tous les projets en cours, en lancer de nouveau a peu sinon aucune chance d’améliorer la situation. Or, c’est encore trop souvent ce qui se produit.

CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM

La loi de Little dans le cadre du management de projet

Nous pouvons utiliser cette loi pour mieux comprendre pourquoi nous avons de meilleures chances de les mener à bien en manageant plus efficacement les projets en cours plutôt qu’en lançant d’autres projets.

Cela correspond comme je l’ai mentionné précédemment aux objectifs recherchés par le management des flux avec Kanban dans les projets Agiles.

Lancer trop de projets engorge les processus, surcharge les horaires de travail des développeurs et allonge considérablement le temps de réalisation.

Prenez un exemple :

  • Si, à ressources constantes, vous lancez en parallèle 3 projets d’une durée moyenne de 1 an, il vous faudra 3 ans pour compléter chacun d’entre eux.
  • Alors que si vous lancez les projets 1 par 1, vous aurez le premier au bout d’une année, le second au bout de 2 et le troisième de 3.

Avec l’approche « séquentielle », vous pouvez donc commencer à récolter les bénéfices de votre premier projet 2 ans plus tôt qu’avec le lancement de tous les projets en parallèle et les avantages du second une année plus tôt.

Ces bénéfices peuvent être ce qui fera ou défera le succès de votre organisation tant vos capacités d’auto-financement sont de plus en plus importantes.

Bien sûr, tout n’est pas si linéaire…

En fait, si le premier projet est délivré après 12 mois, il vous faudra supporter sa mise en production, corriger les erreurs, écouter les retours des utilisateurs, effectuer quelques ajustements impératifs…

Même avec un plan de mise en production accompagné de ressources additionnelles dédiées au support en sus des développeurs, il y aura probablement des impacts non négligeables sur leur charge de travail.

Donc, en réalité, je ne pense pas que vous terminerez systématiquement le second projet 24 mois après la date de début. Et je suis quasiment certain que le troisième projet ne sera pas fini dans la période cible de 3 ans.

Mais, en revanche, il est certain que vous obtiendrez des bénéfices des projets numéros 1 et 2 beaucoup plus tôt que si vous lancez les 3 en parallèle.

Prenez aussi en compte les dégradations de performance dues au multi-tâches permanent.

Il est clair que plus vos employés ont de projets sur lesquels ils travaillent en parallèle, plus les délais d’exécution de chacun de ces projets seront longs.

Le temps de passage d’un projet à l’autre en cours de journée ou de semaine, le switching time, est à ajouter à vos délais. En effet, cela consomme du temps que de poser votre crayon sur un sujet, vous remettre dans le contexte de votre autre tâche ou projet, puis être à nouveau pleinement productif sur celui-ci. C’est l’une des raisons pour lesquelles le multi-tâches est fortement déconseillé en approche Agile où toute l’équipe doit travailler ensemble.

En limitant le nombre de projets en cours, les ressources nécessaires sont disponibles et davantage focalisées. Le résultat est un achèvement du projet bien plus tôt.

Et pour le management de Portefeuille de Projets (PPM) ?

Project Portfolio Management dimensionsLa loi de Little est un excellent principe à suivre dans le management des portefeuilles de projets (PPM) car elle vous permet de conserver une vue d’ensemble tout en optimisant la mise en œuvre opérationnelle.

Il vous reste cependant (encore et toujours) à bien travailler les business cases pour être certains de choisir le bon ordre de séquencement des projets !

Plus spécifiquement sur les projets Agiles

Que l’approche de développement soit Agile ou prédictive, il est critique dans chaque projet sélectionné de bien travailler sur la liste des fonctionnalités souhaitées et les prioriser en fonction des bénéfices attendus de chacune d’entre elles.

C’est en Agile en grande partie la responsabilité du Product Owner.

Et c’est, selon moi, aussi là qu’un intérêt majeur des approches Agiles va se matérialiser : Savoir quand s’arrêter !

En effet, en plus de livrer au plus tôt les fonctionnalités les plus critiques, en approche Agile vous pouvez et devez décider quand dire stop.

En arrêtant votre projet dès que les bénéfices additionnels ne justifient plus de mobiliser les ressources allouées, vous allez les libérer pour le projet suivant qui apportera davantage de bénéfices à l’entreprise.

Il y a là bien sûr un fort risque de ne jamais terminer un projet à 100% par rapport à son business case originel. Mais ceci est-il réellement un problème ?

J’ai vu dans tous les projets que j’ai suivi des fonctionnalités très prometteuses sur le papier n’être que faiblement voire jamais utilisées alors qu’elles nous avaient coûté un bras. C’était rarement dû à une pauvre qualité du livrable. Il s’agissait plutôt de besoins qui avaient évolués pendant la durée de développement du projet, ou bien dus à des changements dans les processus ou les organisations qui étaient parfois encore plus « Agiles » que nos développeurs.

Quelle est votre expérience de cette Loi de Little ?

Y-a-t-il des avantages à avoir un Product Owner sur un projet CRM ? par Mohamed Michael Kazak

Le par mopertodans agile, experience sharingLaisser un commentaire

La réponse courte est OUI !

Les projets CRM sont complexes et nécessitent un Product Owner dédié et compétent pour assurer leur succès. Un Product Owner est chargé de combler le fossé entre les besoins de l’entreprise et les équipes de développement, tout en optimisant le système pour réussir.

Laissez-moi vous parler des avantages à avoir un Product Owner sur un projet CRM.

Comprendre les besoins et les exigences de l’entreprise

Le Product Owner travaille en étroite collaboration avec les utilisateurs et les parties prenantes pour comprendre leurs besoins et leurs exigences. En cartographiant les processus métier et les parcours des utilisateurs, le Product Owner comprend mieux comment le CRM peut être adapté pour répondre aux besoins spécifiques de l’entreprise. Cela permet de s’assurer que le système est conçu et construit de manière à s’aligner sur les processus métier et les besoins des utilisateurs, tout en offrant une réelle valeur ajoutée.

Guider le processus de développement

Une fois les processus métier définis, le product owner collabore avec l’équipe de développement pour concevoir et mettre en œuvre la solution CRM. Cela implique de définir les histoires et les exigences des utilisateurs, de hiérarchiser les fonctionnalités en fonction de la valeur business et de travailler en étroite collaboration avec l’équipe de développement pour s’assurer que le système est conçu et construit d’une manière qui s’aligne sur les processus métier et les besoins des utilisateurs. Tout au long du processus de développement, le Product Owner fournit des conseils et des commentaires pour s’assurer que le système répond aux exigences qui ont été définies avec les utilisateurs et les parties prenantes.

Trouver l’équilibre entre les besoins de l’entreprise et la convivialité

Trouver le bon équilibre entre les besoins des uns et des autres.

L’un des rôles les plus importants du Product Owner est d’équilibrer les besoins de l’entreprise avec les besoins des utilisateurs. Bien que le Product Owner soit chargé de s’assurer que le système répond aux besoins de l’entreprise et apporte une réelle valeur ajoutée, il donne également la priorité à la facilité d’utilisation pour s’assurer que le système est intuitif et facile à utiliser pour les utilisateurs.

Cet équilibre entre les besoins de l’entreprise et la facilité d’utilisation peut parfois être un défi.

Par exemple, une entreprise peut exiger que certaines données soient saisies dans un certain format à des fins de reporting, tandis que les utilisateurs peuvent trouver ce format fastidieux et long à utiliser. Le product owner doit travailler à la fois avec l’entreprise et les utilisateurs pour trouver une solution qui réponde aux besoins de chacun. Il peut s’agir de trouver un compromis satisfaisant pour les deux parties, ou de trouver une solution de contournement qui répond aux exigences de l’entreprise tout en facilitant la saisie des données par les utilisateurs.

Communiquer avec les parties prenantes

En plus de travailler avec l’équipe de développement, le Product Owner communique régulièrement avec les parties prenantes de l’entreprise. Il s’agit notamment de fournir des mises à jour sur l’état d’avancement du projet, de solliciter des commentaires sur les conceptions et les fonctionnalités, et de s’assurer que le système répond aux besoins de toutes les parties prenantes. Cela permet de s’assurer que toutes les personnes impliquées dans le projet sont tenues au courant et ont leur mot à dire dans le processus de développement.

Assurer le succès du lancement et de l’adoption

Enfin, le Product Owner est responsable de s’assurer que le CRM est lancé et adopté avec succès par l’entreprise. Il s’agit de contribuer à des activités de formation et de soutien aux utilisateurs afin de s’assurer qu’ils sont à l’aise avec le nouveau système et qu’ils sont en mesure de tirer pleinement parti de ses capacités. En optimisant le système pour qu’il réussisse et en comblant le fossé entre les besoins de l’entreprise et le développement, le propriétaire du produit peut assurer le succès du projet CRM.

En conclusion, avoir un Product Owner sur un projet CRM offre de nombreux avantages.

Le Product Owner apporte la plus grande valeur possible, aussi rapidement que possible.

Un Product Owner s’assure que le système répond aux besoins de l’entreprise et apporte une réelle valeur, fournit des conseils et des commentaires tout au long du processus de développement, équilibre les besoins de l’entreprise avec les besoins des utilisateurs, communique régulièrement avec les parties prenantes et veille à ce que le système soit lancé et adopté avec succès par l’entreprise.

Si vous vous lancez dans un projet CRM, il est essentiel d’investir dans un Product Owner solide et expérimenté pour en assurer le succès.

Mohamed Michael Kazak

 

Mohamed Michael Kazak

Mohamed Michael Kazak dispose de plus d’une décennie d’expérience à travers diverses industries et plusieurs pays, avec un riche parcours en transformation technologique, gestion de projet, et excellence commerciale. Actuellement, Mohamed Michael occupe le poste de Salesforce Service Product Owner chez Imerys SA, où il dirige les initiatives liées à la digitalisation des activités Service Client Salesforce. Il a lancé plusieurs produits Service Cloud réussis qui ont nettement amélioré l’efficacité du service client et la satisfaction client. Ayant travaillé pour des organisations telles qu’EY et Deloitte, il a géré des équipes diverses et dirigé des projets de transformation avec un focus sur la création de valeur et la satisfaction des besoins des utilisateurs. En tant qu’Administrateur Certifié Salesforce, Mohamed Michael apporte une compréhension approfondie de la manière dont la technologie apporte des résultats commerciaux optimaux.

Précédents billets de Mohamed Michael Kazak

Discussions suite au billet « Comment maîtriser l’art de comprendre les besoins de l’entreprise dans un projet Agile de gestion de la relation client (CRM) ? » de Mohamed Michael Kazak

Le par mopertodans agile, best practicesLaisser un commentaire

« Merci pour votre commentaire Serge Amon. Vous soulignez un défi crucial dans la gestion Agile des projets CRM : L’engagement profond et la disponibilité des équipes métier, souvent compliqués par un manque d’acculturation au mode projet Agile. »

Réponse et suite au billet « Comment maîtriser l’art de comprendre les besoins de l’entreprise dans un projet Agile de gestion de la relation client (CRM) ? » de Mohamed Michael Kazak

Pour y faire face, voici quelques idées

Planification anticipée : Fixer les ateliers environ 6 semaines à l’avance améliore la participation et la préparation.

Objectifs clairs : Définir des buts précis pour chaque atelier afin de garantir une collaboration efficace et pertinente.

Implication dès le départ et communication régulière : Cruciales pour aligner les attentes et maintenir l’engagement.

Flexibilité et formation : Adapter les horaires pour les parties prenantes et les éduquer sur l’Agile pour faciliter leur adhésion.

Brièveté et concentration : La réduction de la durée des ateliers à 1h30 est une mesure parmi d’autres, visant à une efficacité maximale.

L’engagement et l’adaptation culturelle nécessitent une approche multi-facettes et un engagement réel de toutes les parties.

Vos réflexions enrichissent cette discussion, et j’aimerais beaucoup entendre d’autres idées ou stratégies que vous pourriez avoir.

 

Comment maîtriser l’art de comprendre les besoins de l’entreprise dans un projet Agile de gestion de la relation client (CRM) ? par Mohamed Michael Kazak

Le par mopertodans agileLaisser un commentaire

La réponse courte est qu’un Product Owner ne devrait jamais improviser dans ses activités.

https://www.linkedin.com/pulse/mastering-art-understanding-business-needs-salesforce-kazak/

Permettez-moi de partager avec vous le processus que je suis pour comprendre les besoins des entreprises et explorons les différents outils et techniques que j’utilise pour y parvenir.

N’oubliez pas qu’il s’agit surtout d’art dans un cadre de travail défini.

Interrogez les principales parties prenantes

La première étape pour comprendre les besoins et les exigences de l’entreprise consiste à interroger les principales parties prenantes. Il peut s’agir de chefs de service, d’utilisateurs finaux et de cadres exécutifs.

L’objectif de ces entretiens est de comprendre les processus métier, les flux de travail et les points faibles que votre projet Agile va résoudre.

Le Product Owner doit préparer une liste de questions à l’avance pour guider la discussion et s’assurer que tous les sujets pertinents sont couverts.

Faites vos devoirs

À la suite des entretiens avec les parties prenantes, une chasse aux informations supplémentaires commence. L’une des tâches clés du Product Owner est de bien connaître la situation actuelle et d’identifier les domaines à améliorer ou à optimiser.

Voici quelques-uns des éléments que le Product Owner examinera :

  • Cartes ou diagrammes des processus métier actuels
  • Manuels ou guides d’utilisation existants
  • Résultats de précédents sondages (ou lancement d’un nouveau)
  • Commentaires des utilisateurs ou tickets de demandes d’assistance
  • Données historiques ou rapports sur l’utilisation du système actuel et performances des processus

En examinant ces documents et ces données, et en recueillant les informations des parties prenantes, le Product Owner peut mieux comprendre l’état actuel des processus métier et identifier les domaines à améliorer ou à optimiser. Cela permettra au Product Owner de travailler plus efficacement dans la phase d’atelier et plus tard avec l’équipe de développement pour concevoir et mettre en œuvre de manière Agile des solutions qui répondent aux besoins spécifiques de l’entreprise.

Animez des ateliers

Une fois que les principales parties prenantes ont été interrogées et que le Product Owner s’est formé, il ou elle peut animer des ateliers pour approfondir les exigences. Les ateliers peuvent être utilisés pour identifier les lacunes dans les processus métier actuels, hiérarchiser les caractéristiques et les fonctionnalités nécessaires, et définir les histoires utilisateurs.

Voici quelques-unes des meilleures pratiques pour assurer le succès des ateliers :

  • Préparez-vous et soyez ouverts d’esprit,
  • Posez des questions ouvertes,
  • Les ateliers ne doivent pas durer plus de 1h30,
  • Permettez aux participants de discuter des désaccords, mais rappelez-leur aussi ce qu’ils ont en commun.

Voici une liste d’ateliers qui peuvent être réalisés avec une proposition d’ordre du jour. Veuillez noter que ces séances peuvent être ajustées en fonction des besoins et des objectifs spécifiques du projet, et que l’ordre du jour peut être affiné en fonction des retours des principaux intervenants.

Atelier 1 : Introduction et examen des processus métiers et business

L’objectif de cet atelier est de cartographier les processus métier et les flux de travail de l’organisation, et d’identifier les opportunités d’automatisation et d’optimisation à l’aide de votre nouvelle solution. Cela permettra de s’assurer que le nouveau système est adapté aux besoins spécifiques de l’organisation et qu’il apporte une réelle valeur ajoutée. Bien que le Product Owner ait recueilli pas mal d’informations à partir d’entretiens et de données existantes, la réalité est souvent différente de ce qui est sur papier.

  • Accueil et présentations (10 min)
  • But et objectifs de l’atelier (10 min)
  • Revue des processus métiers actuels (30 min)
  • Identification des principaux défis et points faibles de l’entreprise (20 min)
  • Discussion sur les améliorations potentielles des processus existants (20 min)
Atelier 2 : Cartographie du parcours utilisateur

L’objectif de cet atelier est de comprendre les besoins et les difficultés des utilisateurs, et de cartographier leur parcours tout au long des processus de l’organisation. Cela permettra de s’assurer que le nouveau système est conçu de manière intuitive et conviviale, améliorant ainsi l’adoption et l’efficacité par les utilisateurs.

  • Accueil et présentations (10 min)
  • Rappel des principaux points à retenir de l’atelier précédent (10 min)
  • Identification des personas d’utilisateurs clés (20 min)
  • Cartographie des parcours utilisateurs pour chaque persona (40 min)
  • Discussion sur les points faibles et les possibilités d’amélioration dans chaque parcours (20 min)
Atelier 3 : Hiérarchisation et définition des fonctionnalités

Cet atelier consiste à définir et à hiérarchiser les fonctionnalités et les exigences nécessaires à la nouvelle solution, en fonction de l’évaluation de l’état actuel, de la cartographie des processus métier et des exercices de cartographie du parcours utilisateur. L’objectif est de définir le Produit Minimum Viable (MVP) qui peut être livré aux utilisateurs le plus rapidement possible tout en répondant à leurs besoins. Cela permettra de s’assurer que le système est conçu et construit de manière à s’aligner sur les besoins de l’organisation et à apporter une réelle valeur ajoutée.

  • Accueil et présentations (10 min)
  • Rappel des principaux points à retenir de l’atelier précédent (10 min)
  • Hiérarchisation des fonctionnalités en fonction de la valeur business et des besoins des utilisateurs (20 min)
  • Définition des fonctionnalités clés et des exigences pour chaque fonctionnalité prioritaire (40 min)
  • Discussion sur les concessions et compromis potentiels (20 min)
Atelier 4 : Exigences techniques et récapitulatif
Les problèmes complexes ont souvent de multiples solutions et chemins pour les atteindre.

Cet atelier se concentre sur la définition des exigences techniques du produit en fonction des fonctionnalités prioritaires et des contraintes identifiées. L’objectif est d’identifier les défis techniques potentiels et les solutions qui doivent être prises en compte au cours du processus de développement. Les contraintes, telles que le budget, l’échéancier et la disponibilité des ressources, doivent être discutées, ainsi que les solutions potentielles pour y remédier. L’atelier se termine par un résumé du processus de collecte des exigences et un plan pour aller de l’avant avec le développement.

  • Accueil et présentations (10 min)
  • Rappel des principaux points à retenir de l’atelier précédent (10 min)
  • Identification des exigences ou contraintes techniques (30 min)
  • Discussion sur les solutions potentielles pour répondre aux contraintes techniques (30 min)
  • Récapitulatif des principaux points à retenir de la série d’ateliers (10 min)
  • Mesures à prendre et prochaines étapes (20 min)

Documentez les exigences

Comment décomposer les niveaux d’exigence Agile (précédent billet à relire)

Une fois les ateliers terminés, le Product Owner doit documenter les exigences. Cela inclut la création d’histoires utilisateur, la définition de critères d’acceptation et la création d’un arriéré de produit (product backlog). Le Product Owner doit travailler avec les parties prenantes pour s’assurer que les exigences sont exactes, complètes et alignées sur les besoins de l’entreprise.

Hiérarchisez les exigences

Une fois les exigences documentées, le Product Owner doit les hiérarchiser en fonction de la valeur business. Cela implique de travailler avec les parties prenantes pour comprendre le niveau d’effort requis pour chaque exigence et l’impact qu’elle aura sur l’entreprise. L’objectif est de s’assurer que les exigences les plus critiques sont traitées en premier et que le système apporte une réelle valeur ajoutée.

Affinez les exigences (Précisez les besoins)

Le Product Owner doit travailler en étroite collaboration avec l’équipe de développement pour s’assurer que les exigences sont correctement comprises. Le travail avec l’équipe de développement doit être anticipé le plus tôt possible. Tout changement ou mise à jour des exigences doit être communiqué aux intervenants afin de s’assurer que tout le monde est sur la même longueur d’onde.

Anticipez les difficultés auxquelles le product owner sera confronté

Imaginez une entreprise avec plusieurs divisions, chacune avec son propre processus de vente unique. L’équipe de vente de la division A a besoin d’un ensemble d’informations différent de celui de l’équipe de vente de la division B pour collecter un ensemble d’informations différent de celui de l’équipe de vente de la division B. Cependant, l’entreprise souhaite maintenir une instance de votre solution unifiée à des fins de reporting et d’analyse.

Dans ce cas, le propriétaire du produit peut travailler avec l’équipe de développement pour créer des flux personnalisés ou des pages dynamiques qui capturent les exigences uniques en matière de données pour chaque division. Ces personnalisations peuvent être conçues de manière à maintenir la cohérence des données, ce qui permet d’obtenir des rapports et des analyses précis tout en répondant aux besoins spécifiques de chaque équipe commerciale.

En tirant parti de cette flexibilité, le Product Owner peut combler efficacement le fossé entre les différents processus métier de chaque division et s’assurer que la solution globale est optimisée pour la réussite dans l’ensemble de l’entreprise.

La compréhension des besoins et des exigences de l’entreprise est essentielle à la réussite de votre projet quel qu’il soit.

Le Product Owner doit interviewer les principales parties prenantes, organiser des ateliers, documenter les exigences, hiérarchiser celles-ci, et examiner et affiner les besoins tout au long du processus de développement.

En suivant ces étapes, le Product Owner peut s’assurer que le système répond aux besoins de l’entreprise et des utilisateurs finaux et qu’il apporte une réelle valeur ajoutée.

Mohamed Michael Kazak

Mohamed Michael Kazak

Mohamed Michael Kazak dispose de plus d’une décennie d’expérience à travers diverses industries et plusieurs pays, avec un riche parcours en transformation technologique, gestion de projet, et excellence commerciale. Actuellement, Mohamed Michael occupe le poste de Salesforce Service Product Owner chez Imerys SA, où il dirige les initiatives liées à la digitalisation des activités Service Client Salesforce. Il a lancé plusieurs produits Service Cloud réussis qui ont nettement amélioré l’efficacité du service client et la satisfaction client. Ayant travaillé pour des organisations telles qu’EY et Deloitte, il a géré des équipes diverses et dirigé des projets de transformation avec un focus sur la création de valeur et la satisfaction des besoins des utilisateurs. En tant qu’Administrateur Certifié Salesforce, Mohamed Michael apporte une compréhension approfondie de la manière dont la technologie apporte des résultats commerciaux optimaux.

CertYou est partenaire de DantotsuPM, allez voir les formations et certifications Agile dont celles de Product Owner

Dans le développement de produit : Le produit est la variable.

Le par mopertodans experience sharing, outils et méthodesLaisser un commentaire

Avec le passage à DevOps, les systèmes que nous construisons ont acquis deux nouvelles qualités importantes : Ils ne finissent jamais et ils fournissent de continuelles rétroactions et  opportunités d’apprendre.

The Product is the Variable par Jeff Gothelf

https://jeffgothelf.com/blog/the-product-is-the-variable/

Il m’est apparu récemment qu’il y a une transformation radicale dans notre conversation sur le développement de produits numériques en raison du changement (certes lent) mais inévitable vers le management des résultats. Pendant des décennies, la composante « fixe » de nos conversations sur les produits était le produit lui-même. Bien sûr, nous nous sommes peut-être déportés vers les délais, la portée et/ou les choix de conception, mais la question de « allons-nous le livrer ? » n’a jamais été mise en doute. Le produit allait certainement arriver.

Le déploiement du produit n’est plus certain

Avec le passage aux systèmes de déploiement continu, de test et d’intégration continus (alias DevOps), les systèmes que nous construisons ont acquis deux nouvelles qualités importantes :

  1. Ils ne sont jamais finis – Nous travaillons sur nos produits, aujourd’hui, « pour toujours ». Il n’y a pas de date de fin fixe pour les fonctionnalités que nous construisons. Cela semble étrange ? Demandez-vous : « Quand Netflix sera-t-elle terminée ? » Remplacez « Netflix » par n’importe quelle autre entreprise moderne et il devient clair que nos produits et services vivent pour toujours. Il n’y a pas de date de fin explicite. À un moment donné, nous décidons qu’ils ne fournissent plus assez de valeur ou que l’investissement nécessaire pour en extraire plus de valeur n’en vaut pas la peine et nous passons à autre chose. D’ici là, nous devons maintenir et optimiser ces systèmes en permanence.
  2. Ils fournissent une rétroaction continue et une opportunité d’apprentissage – Parce que ces systèmes sont toujours en vol, offrant de la valeur (ou non) et fournissant un service aux clients, nous apprenons continuellement à quel point ils fonctionnent. Nous avons maintenant une opportunité incroyable de déterminer où concentrer au mieux nos efforts pour améliorer continuellement ces systèmes pour nos clients.
Apporter la plus grande valeur aux clients, aussi rapidement que possible.

Ces qualités nous obligent à considérer une mesure de la valeur différente de celle du passé. Nous n’avons plus besoin de nous concentrer sur le fait de savoir si nous avons livré ou non une fonctionnalité spécifique. Au lieu de cela, nous nous concentrons sur ce que nos clients font dans le système. Réussissent-ils ? L’utilisent-ils d’une manière qui leur profite ? Font-ils ce à quoi nous nous attendions ? Autre chose ? Notre obsession n’est plus de savoir si une capacité spécifique a été déployée ou non, mais plutôt de savoir si le système offre de la valeur. Une volonté de « simplement diffuser des fonctionnalités » n’a plus de sens dans ce nouveau contexte.

Le produit est la variable

La nature moderne des logiciels se concentre sur le déploiement de la plus petite quantité de code qui offre la plus grande quantité de valeur. Pourquoi ? Parce que nous devons vivre avec ce code pour toujours. Notre nouvelle mesure du succès est le comportement des clients (ou les résultats). Les comportements et les changements dans ces comportements que nous voulons voir chez nos clients sont nos nouvelles mesures du succès. La façon dont nous réalisons ces changements de comportement devient la variable. Le produit est la variable.

Il existe une combinaison infinie de code, de conception, de proposition de valeur et de modèle commercial qui peut apporter les changements de comportement souhaités. Nous mélangeons, associons et expérimentons différentes façons de rendre notre offre plus précieuse pour nos clients. L’objectif fixé est un changement dans le comportement de nos clients. Nous continuons à ajuster et (espérons-le) à améliorer le produit jusqu’à ce que nous atteignions le niveau souhaité de changement de comportement.

Cela nécessite un nouvel état d’esprit pour le développement de produits

Accepter ce changement dans la façon dont nous manageons nos équipes et nos organisations ne sera pas facile. C’est un profond changement de mentalité. Il est facile de considérer le produit comme l’objectif. Nous pouvons clairement écrire ce que nous croyons qu’il devrait faire, le concevoir pour le faire et le livrer. Malheureusement, cela ne garantit pas notre succès. Cela ne garantit que le déploiement du code (et la dette technique subséquente). La variabilité des produits peut effrayer les parties prenantes. « Qu’est-ce qu’on construit ? », demanderont-ils. En fin de compte, nous devons changer cette question en : « Comment tendons-nous vers les changements de comportement souhaités ? » Cela prendra du temps, mais c’est inévitable. Nos socles technologiques modernes l’exigent.

Vos clients détestent les MVPs (Minimum Viable Product), produisez plutôt un SLC (Simple, Lovable and Complete product).

Le par mopertodans agileLaisser un commentaire

J’ai trouvé ce billet très vrai par rapport à mon vécu personnel sur des projets Agiles qui se sont tellement concentrés sur produire un « Minimum » MVP que leurs premiers livrables n’étaient que très rarement utilisables / « Viables » en situation réelle.

Extraits du billet de  Jason Cohen: Your customers hate MVPs. Make a SLC instead.

Vos clients détestent les MVPs. Faites plutôt un SLC.

[…]

Les équipes produit ont répété le mantra du MVP (Minimum Viable Product) depuis toute une décennie sans réévaluer si c’est réellement la bonne façon de maximiser l’apprentissage tout en satisfaisant le client.

Eh bien, ce n’est pas le meilleur système !

Cette approche MVP est égoïste et fait mal aux clients.

[…]

La motivation qui dirige le MVP est toujours valable :

  1. Construisez quelque chose de petit, parce que les petites choses sont rapides et peu coûteuses à tester.
  2. Mettez-la rapidement sur le marché, car le véritable apprentissage ne se produit que lorsque de vrais clients utilisent un vrai produit.
  3. Jetez-la ou changez complètement de direction s’il s’agit d’un échec, ou investissez davantage s’il s’agit d’un semis avec du potentiel.

Les MVPs sont parfaits pour les startups et les équipes produit car ils maximisent le plus rapidement possible ce que l’on appelle « l’apprentissage validé ». Et, bien que  les entretiens avec les clients soient utiles, vous apprenez de nouvelles choses lorsqu’un client utilise réellement le produit. Mais les MVPs sont un acte égoïste.

Le problème est que les clients détestent les MVPs.

Les startups sont encouragées par le célèbre Reid Hoffman à « lancer le produit assez tôt pour que vous soyez embarrassé par votre version V1.0. ». Mais aucun client ne veut utiliser un produit inachevé qui embarrasse ses créateurs. Les clients veulent des produits géniaux qu’ils peuvent utiliser immédiatement.

Les MVPs sont trop M et rarement V.

Les clients le voient et détestent cela. C’est peut-être génial pour l’équipe produit, mais c’est mauvais pour les clients. Et en fin de compte, ce qui est mauvais pour les clients est mauvais pour l’entreprise.

[…]

Soyez « Slick » (habile et astucieux) !

À partir de ce raisonnement, il y a des années, j’ai nommé ce que je pense être la bonne alternative au MVP : Simple, Lovable/Aimable et Complet (SLC). Nous le prononçons « Slick ». Comme dans : « Quelle est la version (habile et astucieuse) ‘Slick’ de votre idée ? ».

Un autre avantage de SLC devient évident lorsque vous considérez la prochaine version du produit.

Un produit SLC ne nécessite pas de développement continu pour ajouter de la valeur. Il est possible que la V1 évolue pendant des années en une V4, mais vous avez également la possibilité de ne pas investir davantage dans le produit, tout en ajoutant de la valeur. Un MVP qui ne recevra jamais d’investissement supplémentaire n’est qu’un mauvais produit. Un SLC qui n’obtient jamais d’investissement supplémentaire est un bon produit, même s’il est modeste.

Henrik Kniberg, un coach agile et produit de longue date pour Spotify, a créé l’illustration populaire ci-dessus pour donner un exemple à suivre aux équipes produit lorsqu’elles envisagent de livrer un produit minimum viable, ou MVP, à leurs clients.

Une planche à roulettes est un produit SLC. C’est plus rapide que la marche, c’est simple, beaucoup de gens l’adorent, et c’est un produit complet qui n’a pas besoin d’ajouts pour être amusant ou pratique. En même temps, vous pouvez faire évoluer le skateboard en ajoutant une potence et un guidon, pour créer une trottinette (seulement un peu moins simple, et certainement appréciable et complet). Ensuite, vous pouvez faire grandir les roues, ajouter un siège et des pédales, et vous avez un vélo. Encore une fois, moins simple, mais vous avez maintenant un produit avec des avantages massifs de vitesse, de distance et d’efficacité énergétique…

[…]

Avec SLC, les résultats sont meilleurs et vos options pour les prochaines étapes sont meilleures.

Si le SLC échoue, ce n’est pas grave : C’est une expérience ratée. Les SLCs et les MVPs atteindront parfois ce résultat parce que le but est d’ expérimenter. Mais si un SLC réussit, vous avez déjà apporté une valeur réelle aux clients et vous avez plusieurs futurs possibles à votre disposition, dont aucun n’est urgent. Vous pourriez construire une V2, et parce que vous générez déjà de la valeur, vous avez plus de temps pour décider à quoi elle devrait ressembler. Vous pouvez même interroger les clients existants pour déterminer exactement ce que la V2 devrait impliquer, au lieu d’un groupe d’alpha-testeurs qui veulent juste savoir « Quand allez-vous réparer cette chose qui ne fonctionne pas ? »

Ou, vous pouvez décider de ne plus travailler dessus. Tous les produits ne doivent pas nécessairement devenir complexes. Tous les produits n’ont pas besoin de nouvelles versions majeures tous les deux trimestres.

Certaines choses peuvent juste rester Simples, aimables/Lovable et Complètes.

Demandez à vos clients. Ils seront d’accord.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

La folie coûteuse d’un arriéré de produit surdimensionné

Le par mopertodans agile, best practicesLaisser un commentaire

Certains propriétaires de produits (Product Owners) pensent qu’un arriéré de produit (Product Backlog) complet est le meilleur moyen d’atteindre l’objectif du produit et d’être en même temps totalement transparent .

The Expensive Folly of the Oversized Product Backlog par Stefan Wolpers

https://age-of-product.com/oversized-product-backlog/

Les coûts d’un arriéré de produit surdimensionné

Apprenez-en davantage sur l’impact négatif d’un Product Backlog surdimensionné sur l’innovation, la capacité de votre équipe Scrum à créer de la valeur et vos relations avec les parties prenantes.

Les effets secondaires coûteux d’un arriéré de produit surdimensionné

Certains Product Owners estiment en effet que tenir un Product Backlog surdimensionné est une stratégie optimale pour atteindre l’objectif du produit et maintenir une transparence totale, garantissant qu’aucune idée de valeur potentielle ne soit perdue. Cependant, construire à l’avance une liste complète de tous les éléments de travail imaginables n’est pas seulement une perte de temps pour une équipe Scrum, un Product Backlog surdimensionné est une erreur coûteuse à long terme.

Voici 8 effets secondaires critiques de cet anti-pattern (contre-modèle ou fausse bonne idée) du Product Backlog.

#1 – Encourage le gaspillage

Un Product Backlog surdimensionné favorise le gaspillage en investissant du temps dans des éléments qui ne seront peut-être jamais développés en raison de la découverte continue de tâches plus précieuses. C’est une violation claire des principes du Manifeste Agile. En particulier, la simplicité – l’art de maximiser le travail non fait – qui est essentielle.

#2 – Augmente les risques du piège des coûts irrécupérables

Les « sunk costs » sont des dépenses non récupérables quoi que l’on fasse ou décide maintenant. Relisez ce billet.

Un important Product Backlog peut favoriser le syndrome des coûts irrécupérables. Les équipes peuvent continuer à affiner et à prioriser des éléments parce qu’elles y ont déjà investi du temps plutôt que parce qu’ils ajoutent une valeur significative. Ce comportement contredit le principe d’amélioration continue et d’adaptation du Manifeste Agile.

#3 – Conduit à la paralysie d’analyse

Un énorme Product Backlog peut provoquer ce que l’on appelle la paralysie d’analyse, où le volume d’items devient écrasant, conduisant à l’indécision et aux retards. L’équipe peut passer trop de temps à évaluer, hiérarchiser et redéfinir les priorités, ce qui nuit à sa capacité à se concentrer sur le développement réel du produit. Cet excès de choix ralentit souvent les processus de prise de décision, ce qui rend difficile pour l’équipe de déterminer par où commencer ou sur quoi se concentrer ensuite. En fin de compte, cela ralentit l’ensemble du projet, détournant l’énergie de la création de valeur pour le client vers la gestion du Product Backlog lui-même.

#4 – Nuit à l’engagement des parties prenantes

Un Product Backlog gonflé présente un défi important en matière de communication efficace. Le grand nombre d’items peut rendre difficile pour les intervenants de comprendre le plan, les progrès et les priorités, ce qui peut entraîner un décalage dans les attentes. Les intervenants peuvent avoir du mal à trouver leurs intérêts spécifiques dans la longue liste, ce qui les rend confus et peut causer un sentiment de détachement.

#5 – Produit un effet d’éviction

Un Product Backlog complet et surdimensionné peut décourager sans le vouloir les parties prenantes et les membres de l’équipe de faire part de leurs réflexions et de leurs idées. L’exhaustivité perçue du Product Backlog pourrait donner l’impression qu’il n’y a pas de place ni de besoins supplémentaires à ajouter, ce qui pourrait faire perdre des idées précieuses.

#6 – Inhibe l’innovation

Un énorme Product Backlog peut involontairement étouffer l’énergie créative au sein de l’équipe Scrum. La longue liste de tâches peut créer une culture de « cocher les cases » où l’équipe se concentre davantage sur compléter des tâches plutôt que sur explorer et innover. L’équipe peut se sentir contrainte, percevant qu’il n’y a pas de place pour de nouvelles idées, ce qui peut limiter leurs compétences créatives en résolution de problèmes et les dissuader de trouver des solutions innovantes. Cet état d’esprit contredit la valeur Scrum de « l’ouverture » et le principe Agile d’exploiter le changement pour le bénéfice business du client.

#7 – Donne un faux sentiment de sécurité

Guide téléchargeable gratuitement

Un Product Backlog exhaustif peut donner un faux sentiment de sécurité, une illusion de contrôle. Il peut sembler que l’équipe Scrum a identifié tout le travail nécessaire, réduisant ainsi le besoin perçu de découverte et d’apprentissage. Ce décalage avec le Guide Scrum, qui préconise l’apprentissage itératif et la découverte, peut être nuisible.

#8 – Encourage l’optimisation précoce

Un Product Backlog enflé peut conduire à une optimisation prématurée. L’équipe peut se sentir forcée de concevoir des systèmes ou des flux de travail qui anticipent l’achèvement des futurs éléments du backlog, ce qui entraîne une complexité inutile, contribuant au gaspillage si ces tâches changent ou sont dépriorisées par la suite. Cette approche entre en conflit avec le principe agile de simplicité (l’art de maximiser la quantité de travail non effectué) et la valeur Scrum de focus, car elle encourage l’effort dirigé vers des besoins futurs incertains plutôt que vers les besoins présents les plus précieux.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Comment contrer au mieux les effets d’un Product Backlog surdimensionné

Heureusement, il existe de nombreuses façons d’éviter de créer un Product Backlog surdimensionné dès le départ. Mieux encore, c’est à l’équipe Scrum de les utiliser à bon escient. Voici 8 tactiques pour commencer :

#1 – Adoptez la simplicité

Tenez-vous-en au principe de simplicité du Manifeste Agile, qui implique de maximiser le travail non effectué. Concentrez-vous sur les articles les plus précieux pour offrir la plus grande valeur client et business.

#2 – Limitez les travaux en cours (Work in Progress : WiP)

Limitez le nombre d’éléments dans le Product Backlog à tout moment. La limite WiP peut éviter la surcharge et encourager l’équipe à terminer les objets avant d’en prendre de nouveaux.

#3 – Affinez régulièrement le Product Backlog

Gardez le Product Backlog gérable en organisant régulièrement des sessions d’affinement pour vous assurer que les éléments sont toujours pertinents, précieux et correctement hiérarchisés.

#4 – Affinez juste-à-temps

Évitez de trop affiner les éléments qui ne sont pas imminents pour le développement. Plus un élément est éloigné de la sélection pour un Sprint, moins il devrait être détaillé. L’équipe Scrum ajoute des détails lors des séances de raffinement juste à temps.

#5 – Hiérarchisez et dépriorisez

Acceptez le fait que tous les éléments du Product Backlog ne seront pas implémentés. Établissez régulièrement des priorités et, si nécessaire, supprimez les priorités ou supprimez les éléments du Product Backlog qui ne correspondent plus à l’objectif du produit.

#6 – Responsabilisez les équipes

Encouragez l’auto-organisation au sein de l’équipe Scrum. Donnez-leur les moyens de proposer et de négocier des éléments dans le Product Backlog, renforçant ainsi leur sentiment d’appartenance et d’engagement. Les meilleurs développeurs challengent toujours leurs Product Owners !

#7 – Faites la promotion un dialogue ouvert

Favorisez une culture de dialogue ouvert et de collaboration entre l’équipe Scrum, les parties prenantes et le Product Owner. Encouragez tout le monde à apporter des idées et à remettre en question celles qui existent déjà, en évitant l’effet d’éviction.

#8 – Favorisez l’apprentissage continu et l’adaptation

Adhérez au processus empirique de « transparence, inspection et adaptation » de Scrum. Apprenez de chaque Sprint, adaptez le Product Backlog en fonction des informations, par exemple, de la revue de Sprint (Sprint Review), et soyez ouvert aux changements.

Pour terminer

Le Product Backlog est un outil essentiel dans le développement de produits avec Scrum. Son efficacité est liée à la simplicité, à la limitation du travail en cours, au raffinement régulier, aux détails juste-à-temps, à la priorisation, à l’autonomisation des équipes, au dialogue ouvert et à l’apprentissage continu.

Tous ces principes fonctionnent ensemble pour garder le Product Backlog concentré, exploitable et aligné sur l’objectif du produit, améliorant ainsi la transparence et favorisant une culture de collaboration et d’amélioration continue.

Comment empêchez-vous un nouveau Product Backlog de devenir surdimensionné ?

Comment présenter les user stories à votre équipe ?

Le par mopertodans agile, best practicesLaisser un commentaire

Dans sa série de nouvelles en prévision de la rentrée, Mike Cohn de Mountain Goat Software a abordé un problème fréquent : « Comment présenter des user stories à votre équipe ? »

Astuce #1: Commencez par quelques définitions.

Une user story (ou histoire utilisateur) décrit quelque chose qu’un utilisateur veut. L’histoire suit généralement ce modèle: « En tant que [type d’utilisateur], je [veux, j’ai besoin ou je suis obligé de faire cette chose] afin que [je puisse atteindre cet objectif]. »

Une epic (ou épopée) est une grande user story. Voilà. Rien de plus, rien de moins.

Un thème est une collection d’histoires utilisateurs connectées entre elles. Certaines personnes ont introduit le terme de feature (fonctionnalité) pour désigner une histoire utilisateur suffisamment grande pour être livrée ou peut-être assez grande pour que les utilisateurs la remarquent et soient plus heureux.

Toutes ces définitions ne sont utiles que si elles simplifient la discussion sur le produit que vous développez. Pour en savoir plus sur comment et pourquoi utiliser ces termes (et pourquoi les outils ont ajouté à la confusion), consultez Epics, Features et User Stories.

Astuce #2: Ajoutez le bon niveau de détails au bon moment.

Comme Boucle d’or et les trois ours, nous ne voulons pas d’articles dans l’arriéré de produits avec trop peu ou trop de détails. Nous voulons juste le bon niveau de détails.

Si un Product Owner écrit une user story qui inclut trop peu de détails, les développeurs n’en sauront pas assez lors de la planification du sprint pour comprendre ce qu’il faut construire. Lorsque des détails excessifs sont inclus, le temps et l’argent dépensés à ajouter ces détails inutiles sont gaspillés.

Il est peu probable que le product backlog (l’arriéré de produit) d’une équipe soit parfaitement détaillé dès le départ. Cela signifie que l’équipe devra probablement itérer pour aller vers la bonne quantité de détails.

Je trouve qu’il est beaucoup plus facile pour les membres de l’équipe de trouver le bon équilibre lorsqu’ils commencent avec trop peu de détails. Commencez donc par remplir le modèle d’histoire utilisateur avec le strict minimum de fonctionnalités et de détails du produit, et partez de là.

Astuce #3: Apprenez la méthode SPIDR pour découper les histoires

SPIDR : Spike, Path, Interfaces, Data, and Rules. (Spike*, chemin, interfaces, données et règles). Vous pouvez lire sur chaque technique et obtenir une affiche SPIDR gratuite ici.

L’une des difficultés les plus courantes rencontrées par les équipes agiles est la nécessité de découper les histoires utilisateurs. Je parie que vous avez eu du mal avec cela, parce que je l’ai certainement connu au début. C’est pourquoi j’ai trouvé un acronyme facile à retenir pour détailler les cinq facteurs différents qui pourraient vous aider à diviser une histoire.

J’espère que ces conseils vous aideront, vous et votre équipe, à réussir avec agile,

P.S. Il ne vous reste que deux chances d’assister à un cours Better User Stories en direct avec Mike avant la fin de l’année. https://www.mountaingoatsoftware.com/training/courses/better-user-stories

* Spike : Les Spikes sont une invention de la méthode Extreme Programming (XP). C’est un type spécial d’histoire utilisateur qui est utilisé pour acquérir les connaissances nécessaires afin de réduire les risques sur un choix technique, de mieux comprendre une exigence, ou d’accroitre la fiabilité d’une estimation. Une spike a une taille maximale en durée car elle doit tenir dans le sprint qui la contient. À la fin du sprint, la spike sera déterminée comme done ou pas comme toute autre histoire utilisateur. Une spike est un excellent moyen de réduire rapidement les risques et elle permet à l’équipe d’obtenir des retours utilisateurs et de mieux appréhender la complexité.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Les parties prenantes insistent sur le fait qu’elles ont besoin d’une fonctionnalité ou histoire utilisateur MAINTENANT !

Le par mopertodans agileLaisser un commentaire

Vos clients ou parties prenantes viennent-ils parfois vous voir et font pression pour un changement immédiat ? Je suis sûr qu’au moins quelques-uns d’entre eux le font. Les miens l’ont toujours fait.

Publié par Mike Cohn dans la lettre hebdomadaire de Mountain Goat Software

J’ai remarqué quelque chose à ce sujet, cependant.

La plupart du temps, lorsque les gens insistent : « Nous avons besoin de cela maintenant », ils le font parce qu’ils ont appris que c’est la meilleure façon d’attirer notre attention. S’ils peuvent augmenter la gravité afin que nous agissions immédiatement à la demande, ils savent qu’ils obtiendront le changement.

Ces clients et parties prenantes ont appris au fil des ans que s’ils ne parviennent pas à obtenir notre attention immédiate, la demande disparaîtra dans le puits sans fond des demandes et ne sera jamais faite.

Un réel avantage de travailler de manière agile est que nous pouvons changer la conversation avec ces personnes. Au lieu de tout laisser tomber pour répondre à leur besoin immédiat, nous pouvons plutôt leur expliquer que notre équipe évite d’introduire des changements dans une itération, mais sera heureuse de planifier ce nouveau travail dans la prochaine itération.

J’ai eu beaucoup de succès en répondant quelque chose comme ceci

Cela semble important et j’aimerais que nous nous y mettions. Mais nous travaillons par blocs de temps de deux semaines que nous appelons itérations [ou sprints] et nous en sommes au milieu d’une itération en ce moment. Nous essayons vraiment d’éviter d’ajouter un nouveau travail à l’un de ces blocs de temps, car cela affecte notre capacité à tenir les promesses que nous avons pu faire aux autres parties prenantes. Nous avons une nouvelle itération qui commence la semaine prochaine. Que se passe-t-il si je m’engage à planifier cette demande dans cette itération et à vous la donner quelques jours après [ou à la fin de l’itération] ?

Faire comprendre aux utilisateurs et aux parties prenantes qu’ils n’ont plus besoin d’attirer notre attention en insistant sur le fait que tout est nécessaire « maintenant » peut représenter une énorme victoire.

Cela permet aux équipes de mieux planifier leurs itérations et d’avoir moins d’interruptions. Ceci vous aidera à réussir avec agile.

PS: Le management des parties prenantes est quelque chose que Mountain Goat Software couvre dans les cours CSM et CSPO. En tant que Scrum Master, vous apprendrez à minimiser les conflits et à éviter les perturbations lors de réunions clés telles que le daily scrum. Et en tant que Product Owner, vous apprendrez à communiquer efficacement entre les parties prenantes et l’équipe pour apporter constamment de la valeur. Vous pouvez trouver les détails des deux cours ici.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Pour une priorisation Agile optimale, concentrez-vous sur les bénéfices !

Le par mopertodans agileLaisser un commentaire

Pour de nombreux professionnels de projet, la gestion d’un arriéré d‘histoires utilisateurs dans un projet agile peut se faire sans nécessiter de profonde réflexion. Mais qu’est-ce qui détermine la priorité et comment cela contribue-t-il à produire les bénéfices escomptés ?

Prioritisation in Agile: Focus on the Benefits par Quay Consulting

https://www.quayconsulting.com.au/news/prioritisation-in-agile-focus-on-the-benefits/

L’un des principes clés de la livraison de projet agile est la flexibilité de permettre une approche plus itérative et acceptant le changement en ce qui concerne le contenu, garantissant que les éléments les plus à valeur ajoutée sont livrés en premier.

Ce n’est pas une approche exempte de contraintes, loin s’en faut. Les équipes de projet agiles adoptent une vision stricte du temps et des coûts, appelée time-boxing, et reconnaissent que les limites de ressources et de temps permettent à l’équipe de se concentrer sur la répartition et la priorisation du contenu pour s’assurer qu’un bénéfice est livré.

Relisez ce billet

Le rôle du propriétaire du projet est essentiel à la réussite, compte tenu des responsabilités qu’il assume dans la définition, la hiérarchisation et l’approbation ou le rejet du travail fourni par l’équipe. Faire un « bon travail » est rarement suffisant pour garantir un bon résultat, et le rôle que joue le propriétaire du produit est très difficile à bien faire.

Lorsque les processus agiles sont bien suivis et selon des normes élevées et alignées, une approche agile peut maximiser le potentiel de retour sur investissement et offrir les bénéfices recherchés par un projet. Lorsque ces processus sont moins bien exécutés, le risque de ne fournir aucune valeur est très réel.

Alors, quels sont les défis qu’un propriétaire de projet peut rencontrer et comment mettent-ils les avantages en péril ?

Contraintes de priorisation

Le time-boxing est une technique qui permet à un projet de disposer de ressources limitées pour fournir la liste de la portée souhaitée. Il est courant de démarrer un projet avec plus de portée qu’il n’y a de financement pour la réaliser, et même si cela ne commence pas avec cela comme défi initial, l’opportunité créée en construisant de plus petits morceaux de contenus dans les itérations permet à l’équipe d’identifier de nouveaux éléments avec des bénéfices potentiellement plus importants.

Le diagramme illustre l’incidence des contraintes sur l’arriéré de produit lorsqu’une ligne est tracée entre ce qui est prioritaire et qui entre dans l’enveloppe de financement et ce qui n’est pas prioritaire ou pas financé.

Le propriétaire du produit est responsable de la priorisation, en pratique, de décider ce qui est au-dessus ou au-dessous de la ligne. La capacité de prendre les bonnes décisions en matière de priorisation nécessite une compréhension approfondie des besoins, des préférences et des points faibles des clients, ainsi que des buts et objectifs de l’entreprise. Cela nécessite également d’avoir une vision claire du produit.

Mais comment prennent-ils les décisions concernant ce qu’il faut promouvoir et ce qu’il faut dé-prioriser ?

Facteurs de priorisation

Qu’un projet utilise l’agilité ou non, de nombreux facteurs doivent être pris en compte lorsqu’un propriétaire de produit choisit ce qu’il faut prioriser et ce qu’il ne faut pas prioriser.

Par exemple :

  • Impact utilisateur : Réfléchissez à l’impact de l’histoire utilisateur sur l’expérience de l’utilisateur final. Cela améliorera-t-il leur expérience ou résoudra-t-il un problème important ?
  • Complexité : Tenez compte de la complexité de l’histoire utilisateur. Est-ce une tâche simple, ou cela nécessite-t-il beaucoup d’efforts et de ressources de développement ? Ce facteur est plus utile lorsqu’il est considéré en conjonction avec la valeur business.
  • Dépendances : Tenez compte des dépendances de cette histoire utilisateur vis-à-vis d’autres histoires ou fonctionnalités. Sera-t-il plus facile de terminer cette histoire avant ou après une autre ? Cette histoire est-elle nécessaire dans le cadre d’un ensemble pour offrir une expérience significative ?
  • Risque : Tenez compte du niveau de risque associé à l’histoire utilisateur. Implique-t-elle des risques techniques ou business qui pourraient avoir une incidence sur la réussite du projet ? Y a-t-il des risques de remaniement ou d’utilisation excessive de temps et de ressources qui, si cela se produisait, diminuerait la valeur de l’histoire ?
  • Temps et coût : Tenez compte du temps et du coût nécessaires pour compléter l’histoire utilisateur. Peut-elle être achevée dans les délais et le budget impartis, et offre-t-elle un retour sur investissement significatif ?
  • Valeur business : Tenez compte de la valeur commerciale de l’histoire utilisateur. Apporte-t-elle une valeur significative au client ou à l’utilisateur final ? Répond-elle à un besoin ou à un problème critique ? Est-ce que le fait de la terminer rapproche le projet de son objectif ?

Comme la portée est divisée en de nombreux petits éléments de contenu dans les projets agiles, il peut devenir très difficile de déterminer dans quelle mesure chaque élément contribue aux bénéfices globaux que le projet cherche finalement à produire.

Le processus de priorisation et le contexte

Il existe une théorie autour du changement qui sous-tend un projet, y compris les projets agiles.  Les bénéfices sont un résultat positif obtenu en fournissant le contenu souhaité.

Il y a un peu plus…

Généralement, un projet commence par des buts et des objectifs, qui sont traduits en portée et livrables.  La relation entre les facteurs et le contexte fourni par les buts et objectifs du projet sont des ingrédients importants dans le processus de priorisation car ils aident à donner plus de sens à chaque histoire utilisateur.

Considérons ce que chaque composant représente :

  • Objectifs : Décrivez les résultats ou les avantages de haut niveau que le projet vise à atteindre ou à impacter; par exemple, un projet vise à améliorer l’expérience client globale de 10 %.
  • Cibles : Cibles précises, mesurables et limitées dans le temps qui doivent être atteintes pour atteindre les buts du projet. Elles sont souvent décomposées en étapes plus petites et réalisables. Par exemple, si l’objectif du projet est d’améliorer l’expérience de 10%, une cible pourrait être d’améliorer la vitesse de traitement des commandes et leur précision afin de réduire les plaintes des clients de 25%.
  • Portée : Établit les limites de ce que le projet inclura ou exclura. Elle définit les caractéristiques, les fonctions et les tâches qui feront partie du projet. Par exemple, la portée d’un projet de développement de site Web pourrait inclure la conception et la construction d’un site Web, mais exclure la création de matériel de marketing.
  • Livrables : Livrables ou résultats tangibles et mesurables qui sont produits à la suite de l’achèvement des travaux du projet. Les livrables peuvent être des produits, des services, des documents ou des rapports. Par exemple, les produits livrables du projet de développement de sites Web pourraient inclure un site Web fonctionnel, des formulaires clients, des articles de connaissances connexes et des services de chat.

Il existe de nombreuses considérations qu’un propriétaire de projet doit prendre en compte lorsqu’il décide de l’arriéré de produit d’un projet agile et celles-ci doivent être faites dans le contexte des buts et de la définition objective du projet. Ceci devrait permettre au propriétaire du projet de peser le mérite de chaque facteur et de déterminer la valeur de chaque histoire utilisateur et comment elle contribue aux bénéfices.

Maintenir un focus laser sur les bénéfices et le retour sur investissement

Les Product Owners doivent solliciter les commentaires, les retours et la collaboration des parties prenantes pour mieux comprendre l’impact ou les conséquences potentiels de la façon dont ils priorisent les histoires utilisateur ou les groupes d’histoires. Cela peut également fournir une perspective sur la complexité ou le coût de leur mise en œuvre et donner un aperçu du point de vue ou de la compréhension des parties prenantes de ce qui est attendu en termes de retour sur investissement.

La nature interdépendante de ces éléments démontre qu’il n’y a jamais de processus linéaire ou simple dans la hiérarchisation des priorités; Les histoires utilisateur et la façon dont elles sont priorisées ne peuvent pas être prises isolément sans effet sur les résultats. Des composants à valeur ajoutée pourraient être livrés, mais pas fusionnés dans une solution cohérente.

Il est essentiel que les propriétaires de produits soient en mesure de se concentrer sur les bénéfices et le retour sur investissement dans la façon dont ils prennent des décisions sur comment ils décomposent le contenu et décident quelles histoires d’utilisateurs sont incluses ou dé-priorisées.

Comment découpez-vous votre travail ?

Le par mopertodans agile, best practices, outils et méthodesLaisser un commentaire

Il existe une variété infinie de projets, cependant seulement 3 approches sont utilisées par la plupart des équipes qui développent des WBS.

 

How do you breakdown your work? par Kiron Bondale

https://kbondale.wordpress.com/2022/05/15/how-do-you-breakdown-your-work/

Le PMBOK V7 sur Amazon

La septième édition du Guide PMBOK® définit une structure de répartition du travail (WBS) comme une « décomposition hiérarchique de la portée totale du travail à effectuer par l’équipe projet pour atteindre les objectifs du projet et créer les livrables requis ».

Bien que cette définition permette de bien comprendre ce qu’est une WBS, elle ne fournit pas de conseils sur la façon d’organiser la structure d’une WBS. Ceci est utile car cela donne aux équipes la flexibilité nécessaire pour déterminer quel est le moyen le plus approprié de le faire dans le contexte de leur projet.

Bien qu’il existe une variété infinie de projets, j’ai trouvé 3 approches utilisées par la plupart des équipes qui développent des WBS.

  1. Axée sur les livrables – Chacun des composants de niveau supérieur de la WBS représente un livrable clé, et les niveaux suivants se concentrent sur la décomposition de ces livrables à un niveau de détail approprié.
  2. Axée sur les phases – Chacune des composantes de niveau supérieur de la WBS représente une phase ou une étape du cycle de vie du projet, et les niveaux suivants se concentrent sur la décomposition des extrants de chacune de ces phases ou étapes.
  3. Axée sur la responsabilité – Chacune des composantes de haut niveau de la WBS représente une partie prenante contribuant à l’exécution du projet, et les niveaux suivants se concentrent sur la décomposition des extrants produits par chacune de ces parties prenantes.

Une approche axée sur les livrables

Aide à concentrer l’équipe sur tout ce qui est nécessaire pour réaliser chaque livrable sans se soucier à ce stade de qui le fait ou quand cela serait fait. Cela peut bien fonctionner pour les projets où toute la portée d’un projet peut être décomposée dès le début, mais peut être difficile lorsqu’une approche par vagues (rolling waves) est adoptée, à moins qu’il n’y ait une identification claire des parties de planification qui doivent être élaborées à une date ultérieure.

Une approche axée sur les phases

Livre sur Amazon

Fonctionne bien avec une approche par vagues, car l’équipe n’a qu’à se concentrer sur ce qui sera achevé dans la phase à venir.

Cependant, il existe un risque que l’équipe manque des éléments clés de la portée pour des livrables spécifiques, car elle ne se concentrera pas sur la décomposition d’un seul livrable à la fois.

Une approche axée sur la responsabilité

Fonctionne bien lorsqu’il y a plusieurs parties prenantes et qu’il est nécessaire d’avoir une séparation claire des responsabilités en matière de planification et d’exécution. Elle présente le même risque que l’approche axée sur les phases, mais en plus grave, car il est possible que des livrables sous-composants soient assumés par chaque partie prenante comme étant la responsabilité d’une autre partie prenante.

Sondage auprès des professionnelles et professionnels du management de projet

J’ai mené un sondage dans le groupe PMI’s LinkedIn Project, Program and Portfolio discussion group ainsi que dans  la communauté ProjectManagement.com pour évaluer la répartition dans l’utilisation de ces 3 approches.

Sur les 141 réponses combinées :

  • 57 % utilisaient une ventilation axée sur les livrables
  • 28 % une approche axée sur les phases
  • 9 % une approche axée sur la responsabilité
  • Les 6 % restants ont indiqué qu’ils utilisaient une autre approche, mais lorsque j’ai examiné les commentaires que ces participants avaient soumis, il semble qu’ils utilisent simplement une combinaison de ces méthodes plutôt que quelque chose d’entièrement nouveau.

Bien que le WBS soit un outil couramment utilisé avec des projets suivant un cycle de vie prédictif, cela ne signifie pas que ceux qui suivent un cycle adaptatif ne peuvent pas en bénéficier. Si nous considérons une user story map*, il s’agit simplement d’une WBS limitée entre deux et quatre niveaux et élaborée de manière progressive. Avec une Story Map, la structure peut être orientée persona (rôle des utilisateurs) ou thème/capacité.

Quelle que soit la façon dont votre équipe choisit de décomposer la portée du travail sur ses projets, une WBS ou une variante de celle-ci doit être considérée comme un instrument précieux dans sa boîte à outils.

Partenaire de DantotsuPM, CERTyou est le spécialiste des formations certifiantes

* Une user story map est un outil puissant qui permet à une équipe agile de préparer son backlog de produit et de planifier plus efficacement les versions de produits. Une user story map capture le parcours d’un client avec le produit, y compris les activités et les tâches qu’il effectue avec le système.

Quelles sont les caractéristiques clés des Product Owners qui sont des CRACKs ?

Le par mopertodans agile, pmo et portofolioLaisser un commentaire

En 2003, Barry Boehm et Richard Turner ont inventé l’acronyme C.R.A.C.K. pour nous rappeler les caractéristiques clés d’un Product Owner efficace !

  • Collaboratif – Est-il capable et disposé à négocier avec les parties prenantes sur les besoins, les souhaits et les priorités afin de définir un contenu de produit optimal ?
  • Livre référence sur Amazon

    Représentatif – Est-il capable de « se mettre dans les chaussures » d’une partie prenante donnée pour aider les membres de l’équipe et d’autres personnes à comprendre le contexte derrière un besoin particulier ?

  • Autorisé – Est-il habilité à prendre la majorité des décisions de priorisation sur le produit sans avoir besoin de demander l’approbation de ses supérieurs ?
  • Comitted (engagé) – A-t-il pleinement adhéré à la vision du produit et a-t-il une capacité suffisante pour s’acquitter de ses responsabilités en tant que Product Owner ?
  • Knowledgeable (Connaissance) – Possède-t-il une connaissance suffisante du domaine du produit, mais aussi a-t-il le savoir-faire organisationnel pour savoir qui engager, influencer ou persuader ?

Merci à Kiron Bondale pour le pointeur sur « Balancing Agility and Discipline: a guide for the perplexed », publié par Addison-Wesley en 2004

Cet acronyme me semble s’appliquer également fort bien aux responsables de Project Management Office (PMO), les bureaux de projets, ainsi qu’aux portefeuilles de projets (PPM) !

Visitez le site de notre partenaire Virage Group

La controverse sur les Story Points : Quelle est leur réelle valeur ?

Le par mopertodans agileLaisser un commentaire

Voici un billet que j’ai trouvé très intéressant sur la réelle valeur des story points et les raisons pour lesquelles ils créent des conflits dans vos projets Agiles.

The Story Point Controversy par Natalie Barnes

https://resources.scrumalliance.org/Article/story-point-controversy

L’estimation du travail agile fait l’objet de débats dans les organisations depuis des années. Il existe plusieurs techniques d’estimation, mais les story points, en particulier, peuvent être un mystère pour beaucoup. Bien qu’il s’agisse d’une méthode couramment utilisée, certains peuvent questionner son efficacité. Cet article décrit le but des story points et pourquoi ils peuvent être sujets à controverse.

Qu’est-ce qu’un Story Point ?

Un story point est une unité de mesure d’une user story basée sur des facteurs tels que la complexité, l’effort, l’incertitude et le risque. Les story points peuvent être utilisés dans des approches agiles comme Scrum lors de la planification du sprint en attribuant une valeur en points à une user story.

Le story-pointing est un moyen rapide d’estimer le travail à l’aide d’outils tels que Planning Poker ou le modèle de Fibonacci. Par exemple, l’équipe peut attribuer un 1 ou un 2 à une histoire qu’elle considère comme nécessitant peu d’effort. L’objectif est d’aider les équipes Scrum à avoir un dialogue ouvert pour acquérir une compréhension commune du travail relatif à toutes les histoires utilisateurs dans l’arriéré de produit, le product backlog.

Relisez ce billet sur « pourquoi Fibonacci ? »

Toute l’équipe (ceux qui font le travail) discute des éléments et des composants impliqués dans le développement de l’histoire utilisateur et parvient à un consensus sur l’estimation en story points. Certaines équipes établissent une base de référence convenue pour l’histoire d’effort le plus faible avec le nombre de story points le plus bas. Si une user story a un nombre très élevé de points, l’équipe décompose l’histoire en histoires plus petites puis les estime.

Comment les story points sont-ils utilisés dans les sprints ?

Une fois que la planification du sprint est terminée et que l’équipe a décidé de ce à quoi elle peut s’engager dans le sprint, elle a alors son nombre total de points d’histoire, de story points, engagés. À la fin du sprint, l’équipe aura consommé tous les story points qui répondent à leur définition de terminé, done. Toutes les histoires qui ne sont pas complètes sont alors soit déplacées dans le backlog, peut-être affinées et ré-estimées, soit reportées au sprint suivant : c’est une décision d’équipe.

L’équipe répète ce processus pour chaque sprint. Au fil du temps, les membres développent leur vélocité, qui est une moyenne du nombre total de story points complétés à la fin de chaque sprint. Les story points terminés peuvent varier à chaque sprint en fonction de la capacité de l’équipe (temps disponible pour chaque sprint). Les facteurs qui pourraient avoir une incidence sur la capacité comprennent le nombre de membres de l’équipe travaillant dans le sprint en raison d’un congé personnel ou d’une maladie, d’une formation ou de conférences, d’événements imprévus, de distractions externes ou peut-être d’un sprint lourd en réunions (pensez aux réunions de département ou d’organisation).

Pourquoi les story points peuvent-ils être sujets à controverse ?

Étant donné que les story points sont une valeur nébuleuse et arbitraire, certaines organisations peuvent ne pas comprendre l’unité réelle de cette mesure des histoires utilisateur. Elles peuvent mal interpréter leur objectif, et il est difficile d’associer systématiquement les points d’histoire au délai de livraison. Prenons la vélocité, par exemple. Elle est considérée comme une mesure clé dans Agile, mais elle peut être utilisée à mauvais escient lors de la mesure de la productivité d’une équipe. Les dirigeants peuvent poser des questions sur la vélocité de l’équipe et vouloir savoir combien de points d’histoire ils achèvent à chaque sprint. Cet état d’esprit de la vélocité en tant que mesure de productivité utilisant des story points ne donne pas une bonne idée de la productivité ni du temps qu’il faudra à l’équipe pour livrer une fonctionnalité.

Disons que l’équipe prend en charge et complète 20 story points dans le sprint 1. Dans le sprint 2, ils prévoient 40 story points mais ne complètent que 30 story points. Dans le sprint 3, ils embarquent et complètent 30 points d’histoire. Cela ne signifie pas que l’équipe est plus ou moins productive de sprint en sprint. Cela fait partie du processus de planification de l’équipe pour déterminer ce qu’elle peut engager dans chaque sprint compte tenu de son expérience du dernier sprint. Étant donné que les user stories présentent différents degrés de complexité et d’incertitude, l’équipe a peut-être appris que ses estimations lors de la planification du sprint étaient trop élevées ou trop basses et s’ajuste en conséquence à chaque sprint.

La capacité de l’équipe est une autre raison pour laquelle les story points peuvent fluctuer. Peut-être qu’ils n’ont pas pu en terminer autant qu’ils l’avaient prévu en raison d’une personne malade dans l’équipe ou d’un autre événement inattendu.

Les story points sont également utilisés à mauvais escient comme métrique pour comparer une équipe à une autre. L’équipe A peut avoir une moyenne de 40 story points tandis que l’équipe B peut avoir une moyenne de 80 story points. Le management peut mal interpréter cela comme signifiant que l’équipe A est deux fois plus productive que l’équipe B. Il n’y a pas deux équipes égales. Leurs membres peuvent avoir des compétences différentes, la taille des équipes peut être différente et les définitions d’un story point peuvent varier. La comparaison des équipes nuit à leur processus d’estimation, crée des estimations gonflées et démoralise l’équipe.

Trouvez un équilibre

Il est compréhensible que les organisations aient besoin de savoir à quel point les équipes sont productives et elles ont besoin de quelque chose de tangible pour mesurer leur performance. Cependant, il est erroné de supposer que les story points et la vélocité sont des mesures d’évaluation de la productivité. Les story points sont utilisés par l’équipe Scrum à des fins de planification et ne doivent pas être considérés comme une unité de productivité par la direction. La vélocité en tant que métrique doit être utilisée par l’équipe Scrum comme point de référence pour les aider dans leur prise de décision pour les engagements de sprint.

Les apprentissages continus et l’expérience de l’équipe donnent la possibilité à l’équipe Agile d’améliorer ses estimations au fil du temps.

Grâce à l’inspection et à l’adaptation, les membres de l’équipe deviennent plus prédictifs et capables de prévoir les délais pour les fonctionnalités. Ce qui compte dans l’agilité, c’est un dialogue ouvert et productif sur le travail, la progression vers l’objectif du produit et la création fréquente de valeur pour les clients.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Comportements de leadership pour une culture de changement agile

Le par mopertodans agile, leadership, pmo et portofolio, pointeurs utilesLaisser un commentaire

L’agilité est un comportement et des attitudes, pas une méthodologie ni un ensemble de processus ou de techniques

Leadership behaviours for an Agile Change culture

https://agilechangemanagement.co.uk/leadership-behaviours-for-an-agile-change-culture deMelanie Franklin

Téléchargez le livre blanc en anglais

Nous savons que l’agilité n’est pas une méthodologie ni un ensemble de processus ou de techniques. L’agilité est le comportement et les attitudes qui permettent aux individus et aux organisations de se déplacer rapidement et facilement.

Au niveau individuel, cette capacité conduit à l’innovation, à la créativité, à l’adoption rapide de nouvelles méthodes de travail.

Au niveau organisationnel, ce comportement est démontré par des améliorations continues, la recherche de nouveaux apprentissages, la volonté d’adopter de nouvelles approches et, en fin de compte, une mise sur le marché de nouveaux produits et services aux clients plus rapide et plus créative.

Les comportements agiles sont soutenus par de nouvelles façons de planifier et de hiérarchiser le travail, mais ils ont besoin d’un environnement qui encourage et récompense leur utilisation.

Les leaders sont les principaux acteurs dans la création de cet environnement.

Les leaders ne sont pas limités à ceux qui ont un pouvoir hiérarchique au sein de leurs organisations.

Un leader est quelqu’un que les autres suivent volontiers.

Je travaille avec de nombreuses organisations à différentes étapes dans l’agilité, et j’ai observé un groupe central de comportements travaillant ensemble, qui permettent aux processus et techniques agiles de s’épanouir :

  1. Imaginez l’état futur
  2. Faites évoluer votre vision
  3. Identifiez les petites étapes
  4. Vivez dans l’incertitude
  5.  Prenez des décisions
  6. Sollicitez l’avis des autres
  7. Abandonnez le contrôle

Si vous occupez un poste de leadership, j’ai écrit un document qui vous donnera l’occasion de comparer votre propre comportement à l’excellence agile et d’identifier les domaines à améliorer.

Si vous êtes manager de projet/programme, PMO ou Product Owner, cela vous donnera beaucoup d’idées sur ce dont il faut discuter avec votre sponsor.

https://agilechangemanagement.co.uk/wp-content/uploads/2022/04/Leadership-behaviours-for-an-Agile-Change-culture.pdf

Téléchargez ce guide sur le site de notre partenaire Virage Group