#Meetup – Introduction au Design Thinking

Qu’est-ce que le Design Thinking et comment s’en servir ?
Nous avons expérimenté plusieurs étapes de ce processus lors du dernier Meetup de SchoolOfPO.

quote-512Le Design Thinking est le terme utilisé pour désigner l’ensemble des méthodes et des outils qui aident, face à un problème ou un projet d’innovation, à appliquer la même démarche que celle qu’aurait un designer. C’est une approche de l’innovation et de son management qui se veut une synthèse entre la pensée analytique et la pensée intuitive. Il s’appuie beaucoup sur un processus de co-créativité impliquant des retours de l’utilisateur final.

La méthode de Design Thinking se déroule en 5 étapes clés:

  1. EMPATHISE : Identifier un problème dans sa globalité. Se mettre à la place des personnes qui pourraient y être confrontées. Imaginer leurs caractéristiques. Comprendre leurs expériences et leurs motivations.S’immerger dans leur environnement.
  2. DEFINE : Rassembler les données collectées. Analyser et synthétiser les informations pour définir le cœur du problème rencontré. Définir le(s) problème(s) du point de vue de l’utilisateur. L’exprimer avec ses mots. Rassembler des idées qui pourraient permettre d’apporter une solution, ou qui pourraient permettre aux utilisateur de résoudre eux-mêmes ce problème.
  3. IDEATE : “Think outside the box“. Après avoir rassemblé un grand nombre d’informations dans les deux étapes précédentes, il est plus facile de concrétiser des solutions susceptibles d’apporter une réelle valeur ajoutée. Imaginer des alternatives.
  4. PROTOTYPE : Imaginer des premières versions minimalistes du produit ou de l’application qui pourra répondre au problème. Donner vie au produit dans les grandes lignes. Réaliser le(s) prototype(s) du produit sur une simple feuille blanche, par exemple. Tester ces premières versions auprès de l’équipe, ou une population représentative des utilisateurs auquel il s’adresse.
  5. TEST : Une fois le prototype affiné, une première version du produit peut être développée pour être testée dans des conditions réelles, ou le prototype lui-même peut être abouti pour être testé auprès d’une population plus large.Les 3 dernières étapes du processus pourraient être répétées au fur et à mesure des développements, pour s’assurer que le développement du produit s’oriente vers une solution qui répond réellement aux besoins des utilisateurs. Test & learn.

LucyInTheScrum_DesignThinkingLe processus de Design Thinking pourrait être assimilé à deux entonnoirs successifs.
Collecte d’informations/Brainstorming > Synthèse des éléments/Affinage
> Ré-ouverture sur des questions pour imaginer une solutions > Ré-affiner en développant un prototype
> Tester la solution > Optimiser.
 

Lors du dernier Meetup “School Of Product Owners”, animé par Lucie Teyssou et Samuel Retiere, nous nous sommes concentrés sur les deux premières étapes du processus, en s’attardant sur 2 outils pratiques pour les mettre en oeuvre.

1. “EMPATHY MAP

Cet outil permet de se mettre plus facilement à la place de l’utilisateur par rapport au problème rencontré: Qui est-il ? Que pense ou ressent-il ?  Qu’entends t-il ? Que voit-il ? Que fait ou dit-il ?
Chaque case de la grille peut être complétée dans le cadre d’un Brainstorming. On notera ensuite les points de douleurs et les objectifs de l’utilisateur en question : Quelles sont ses frustrations ? / Que souhaite-t-il ?

Dans le cadre de ce Meetup, nous n’avons pu nous exercer que sur une seule carte, par manque de temps, mais cela nous a permis de confirmer qu’on peut très rapidement se mettre à la place de l’utilisateur si on se pose les bonnes questions.

Plusieurs cartes de ce type permettront d’avoir une vue globale, et de se positionner selon les attentes de différents utilisateurs, avec des profils différents.

Empathy-MapCliquez sur l’image pour l’agrandir

 

2. “CUSTOMER JOURNEY MAP

Cette représentation a pour objectif de schématiser le parcours de l’utilisateur sur plusieurs étapes, en mettant en exergue son niveau de satisfaction à chaque étape. Les différentes étapes peuvent représenter un processus d’achat sur Internet, un voyage… ou autre.

Une fois le parcours synthétisé, on notera les points de douleurs et les interactions de l’utilisateur pour chaque moment clé. Par exemple, dans le cadre d’un achat sur Internet, l’utilisateur peut rencontrer des problèmes au moment du paiement en ligne. On notera également ses besoins : “A ce moment là, quelles sont ses attentes ?”

Ainsi, on peut plus facilement en dégager des axes d’optimisations concrets.

Customer Journey Map TemplateCliquez sur l’image pour l’agrandir

 

Le processus de Design Thinking peut prendre du temps. D’après Lucie et Samuel, on peut compter environ 2 mois entre le moment où on concrétise l’identification d’un problème à résoudre et la finalisation des prototypes.
Evidemment, la durée du processus dépend de l’investissement qu’on souhaite y mettre et du “Time to Market” visé. Dans un secteur très concurrentiel ou dans une startup, on envisagerait un processus accéléré afin de tester très rapidement des hypothèses. Dans une entreprise de grande ampleur, les étapes de validation prendraient sans doute plus de temps.

Quoi qu’il en soit, le processus global et les deux outils présentés restent relativement simples et peu coûteux à mettre en place. A l’image du Lean Startup, le Design Thinking permet de valider des hypothèses au plus tôt et d’éviter de s’attarder dans des conceptions “hors sujet”.

 

SchoolOfProductOwners_DesignThinking

 

Sources :
● Les Cahiers de l’Innovation – Qu’est-ce que le Design Thinking ?
● Interaction Design Foundation – 5 Stages in the Design Thinking Process
Customer Journey Map Template
En savoir plus :
Découvrir SchoolOfPO
● S’inscrire aux prochains #Meetups
● Suivre les Live Tweet : #SchoolofPO / @SchoolOfPO

#Meetup – Intervision / Solution Focus

Le dernier #Meetup de SchoolOfPO avait pour sujet “L’intervision du Product Owner“.

quote-512L’intervision est un dispositif particulier de rencontres entre pairs, des professionnels sociaux, médico-sociaux, éducatifs et judiciaires.
Objectif : Echanger sur leurs expériences, Réfléchir collectivement sur leurs conduites professionnelles.
Déroulement : Mise en commun de la pratique d’un des membres du groupe, voire de ses difficultés à faire face à des situations complexes ou à des résultats insatisfaisants dans l’accomplissement de ses missions.

Pablo et Dragos nous ont aidé à mettre en pratique ce concept, en l’adaptant au rôle de Product Owner et en utilisant plusieurs méthodes.
D’abord, nous avons divisé le groupe en deux. D’un côté, les participants qui joueraient le rôle de Coach. De l’autre, les Product Owners qui prendraient le rôle de “patients”.
A travers 4 sessions de 15 minutes, sous plusieurs formats, les Products Owners ont pu exposer un ou plusieurs problèmes à leurs binômes (les binômes changent à chaque session, c’est aussi l’occasion d’échanger avec de nouvelles personnes :)).

Exemple de problèmes soulevés :
▪ Comment valoriser une démo Mobile quand les fonctionnalités sont les mêmes sur iOS et Android ?
▪ Comment faire lorsque les parties prenantes de mon projet ne valident rien ?

Première session : Perfection Game

  1. Le Product Owner raconte son histoire, son problème ou un retour d’expérience.
  2. Il complète par ce qu’il a mis en place ou ce qu’il compte faire pour répondre à ce problème.
  3. Son binôme (le coach) lui donne une note sur 10.
  4. Il lui explique les bons points de sa solution ou de sa proposition et lui fait part des axes d’améliorations qui, selon lui, aurait pu permettre au Product Owner de gagner quelques points de plus.

Deuxième Session : Appreciative Inquiry (en savoir plus)
Adaptation pour le Meetup :

  1. Definition : Cadrer la zone de l’exploration. Raconter / Partager une expérience positive.
  2. Discovery : Identifier ce qui fonctionne, ce qui semble fonctionner à partir du récit du Product Owner. Se focaliser sur le positif.
  3. Dream : Imaginer des possibilités. “En se basant sur les expériences positives du passé, les gens commencent à rêver de possibilités pour l’avenir. En fondant le processus dans la réalité d’une expérience positive, les gens voient leurs rêves comme plus accessibles.”
  4. Design : Construire de manière concrète la mise en oeuvre de la phase “DREAM”. En énonçant des actions concrètes.
  5. Destiny : Planifier ces actions.

Troisième session : Solution Focus

  1. Le Product Owner énonce un problème à son binôme
  2. Il se projette ensuite dans un futur où le problème n’existe plus, en le décrivant d’une manière la plus concrète possible.
  3. Sur une échelle de 1 à 10, il se positionne ensuite par rapport à sa solution.
  4. Il identifie les étapes déjà franchies pour parvenir à cette solution (ce qui l’éloigne du stade “1”).
  5. Enfin, il se projette dans les étapes restantes pour arriver progressivement à “10”. Il imagine autant de petites étapes qu’il y a de chiffres pour arriver à 10.

Quatrième session : Freestyle

Echange en binôme ou en groupe, successivement sur un ou plusieurs problèmes rencontrés. Un participant expose son problème, les autres lui permettent de l’affiner et l’aide à imaginer des solutions.

Conclusion : Un meetup agréable pour échanger, discuter avec des personnes nouvelles, d’horizons différents.
On constate également qu’il est difficile de rester sur les rails de ces méthodes et qu’on a tendance à se lancer dans de simples discussions, qui ne suivent plus les différentes étapes.
Malgré tout, s’il est difficile de faire émerger des solutions en 15 minutes, l’entraide de ces méthodes permettent surtout de se recentrer sur les bonnes questions.

Intervision PO

Quel PO de M*rde !

#PODM

“Encore une idée farfelue du métier !” – […] – “Non mais c’est pas vrai, les développeurs ont codé ça avec leurs pieds, non ?” – […] – “De toutes manières, si on trouve des anomalies en production, c’est à cause des testeurs !” […]

Stooop. Mercredi on a parlé des bêtises du Product Owner. Elles sont légion. Mais personne n’est parfait. Et si c’était le cas, on n’aurait plus rien à raconter pendant nos Meetups. 😉
L’idée d’Alex : redécouvrir les atouts d’un bon Product Owner en partant de son contraire.
Sous forme de jeu, nous avons raconté des annecdotes de la vie d’une équipe de développement, à l’image du site VieDeMerde.
Au fur et à mesure que nous enoncions les annecdotes, les participants ont dressé une liste de 5 erreurs à ne pas commettre lorsqu’on est Product Owner. A la fin, chaque équipe a partagé ses 5 commandements au reste du groupe. Résultat : on a bien rit, on s’est reconnu et on a décerné un paquet de Schokobons au meilleur #PODM de la soirée.

Esprit fermé, manque de leadership, égoïsme, inefficacité ou négiociation malsaine… voici notre liste de #PODM.

Aujourd’hui, lors d’un Backlog Grooming, le Product Owner s’accroche à son choix fonctionnel malgré les énormes risques et obstacles techniques. Son argument : “Ben la technique, ça ne me concerne pas…”. #PODM.

Aujourd’hui, en Sprint Planning, le PO se plaint : << Le développement de cette fonctionnalité sur iOS engendre 5 points de complexité alors qu’elle en fait 13 sur Android, c’est n’importe quoi ! >> #PODM

Aujourd’hui, étant donné les limites techniques, la faisabilité d’une des stories demandée par le PO était impossible. La réponse implacable à cette contrainte ? “Oui mais sur [un concurrent] ils le font”. #PODM

Aujourd’hui, après un long débat, notre Product Owner a terminé la conversation par la remarque la plus constructive qui soit : “De toute façon, vous devrez le faire comme ça, vous n’êtes tous que des pions”. #PODM

Aujourd’hui, mon PO a lui même macro-estimé le backlog de la prochaine release: “Pour pouvoir montrer [au chef] que ça tient dans le planning”. #PODM

Aujourd’hui, lors de la démo et devant nos hiérarchies, le Product Owner a nié ses PROPRES décisions en accusant “une mauvaise surprise côté dev”. #PODM

Aujourd’hui, nous développons encore une fonctionnalité inutilisée et inutile (selon le PO aussi) demandée par le chef d’un autre département, parce que : “Je n’osais pas refuser sur le moment”. #PODM

Aujourd’hui, nous n’avons pas de vision produit. Le PO nous demande ”Faites des efforts pour garantir la date de release, c’est la seule chose qui compte”. #PODM

Aujourd’hui, les développeurs et les graphistes ont un désaccord sur la meilleure solution de Design sur Android. Le PO est intervenu pour arbitrer ”Démerdez vous, j’en ai marre”. #PODM

Aujourd’hui, ma PO a trouvé une technique verbale pour modifier régulièrement le sprint : Commencer toutes ses phrases par “C’est juste un petit truc…” #PODM

Aujourd’hui, je suis UI Designer. Aujourd’hui, notre PO nous demande des créations graphiques, “c’est les derniers pour ce ticket et après c’est fini”. Sauf que ça n’en finit jamais… #PODM

Quelle est la priorité de ce ticket ? “C’est urgent !”
Et de celui-ci ? “C’est urgent !!”
De [n’importe quel autre] ? “C’est urgent !!!”
Lequel est prioritaire ? “C’est urgent !!!!”
#PODM

Aujourd’hui, il y a bien plus souvent d’urgences qui viennent parasiter le sprint que de contenu prêt pour le Sprint Planning. Notre Product Owner confond “en mode agile” et “à l’arrache”. #PODM

Aujourd’hui, le Product Owner débarque en urgence : “Y’a plus rien qui marche !”
Je lui demande des détails pour investiguer : “Ben y’a tout qui bug !” #PODM

Aujourd’hui, je suis responsable d’une équipe de Product Owners. Aujourd’hui, je demande à mon PO l’objectif du prochain sprint “Aucun objectif en particulier, on va juste occuper les dev”. #PODM

La soirée s’est poursuivie par une session d’Open Space (30 min) suivant les thématiques abordées précédemment (esprit fermé(1), manque de leadership(2), égoïsme(3), inefficacité(4) ou négiociation malsaine(5)). Sur le thème qui les intéressait, les participants ont échangé en groupes sur leur vécu et leurs bonnes pratiques. Ils ont ensuite restitué au groupe les points où la discussion convergeait, leurs points de désaccord et des idées d’approfondissement du sujet.

Décalé et ludique, ce #Meetup a pris une forme différente des deux précédents en étant encore plus participatif. On en retiendra quelques points clés : esprit d’équipe, investissement, rigueur, écoute… quelques bières et beaucop de fun !

PODM_Lucyinthescrum© Romain Calix’s photo 

 

En savoir plus sur SchoolOfPO
Découvrir les prochains #Meetups
E
n savoir plus sur Alexandre Quach (ici ou ici)
En savoir plus sur Thomas Benard (ici)

Savoir lâcher prise

Comment être un Product Owner très impliqué, qui tire son équipe vers le haut, la fait adhérer aux valeurs de son produit, l’encourage et la motive pour atteindre ensemble un objectif commun ?
Et comment être à la fois un Product Owner capable de lâcher prise parfois et d’accepter que l’équipe “se plante” une bonne fois pour toutes, pour mieux progresser ?

F.A.I.L = First Attempt In Learning ?
Vraiment ? Savoir qu’on va potentiellement se planter et y aller quand même ? Et à fond en plus ?

Mon équipe et moi rencontrons des difficultés au quotidien. C’est un euphémisme.
Dépendances applicatives, dette technique, plateformes instables qui ne sont pas à l’image de la production, aucun test automatisé, manque d’autonomie sur la gestion des déploiements… La liste est longue. Et pourtant nous sommes aujourd’hui capables de réaliser un déploiement en production toutes les deux semaines pour apporter de la valeurs aux utilisateurs en continu.
Mais non sans y laisser quelques plumes.
Et si c’est en étant en difficulté qu’on apprend le plus, alors nous serons probablement des petits génies d’ici quelques semaines… (joking). La bonne ambiance dans l’équipe nous permet d’affronter ces difficultés. Malgré tout, je commence à sentir une démotivation progressive et je ne sais pas toujours comment y remédier.

“Arrête de vouloir jouer à Superman” me dit-on.
“Arrête de vouloir être parfaite” me dit Pablo.
“Tout ne dépend pas de toi : tu ne peux pas construire une tour avec un tournevis !”

“On ne demande pas à Usain Bolt d’être à sa vitesse maximale sur 100 km : en Scrum c’est pareil. Il faut forcément des temps morts.”

On m’a dit un jour que la principale différence entre un Chef de Projet “traditionnel” et un Product Owner résidait dans l’implication. Le Chef de Projet livre une expression de besoin, suit les développements de loin, effectue quelques tests et valide le bon fonctionnement. Si cela ne fonctionne pas, ce sera… “la faute des développeurs“. 😉
Le Product Owner s’implique réellement, de la définition du besoin à la supervision en production. Il y met ses tripes. C’est lui qui donne le rythme à son équipe, définit le timing et sera responsable de la qualité du produit. Comment, en ayant participé à l’évolution des conceptions et des développements du matin au soir, pourrait-il ne pas être impliqué à 100% ?

En étant un malin stratège, sans doute. En faisant des choix et des paris. En acceptant que tout ne sera jamais parfait. Parce que si on attend la perfection on ne fera rien. Et au delà de la priorisation du backlog, en faisant du tri dans sa propre to-do-list.

Alors non : on ne va pas complètement lâcher prise. On va faire notre maximum. Tout donner. Et accepter que si on se plante malgré tout, et bien on aura tout tenté.
Et on se dira qu’on fera mieux la prochaine fois…

first-attempt-in-learning

My very first #Meetup

C’est extrêmement bien entourée que j’ai animé mon tout premier Meet-up le mois dernier, aux côtés de Pablo et Dragos dans le cadre de @SchoolOfPO. Intimidée mais très motivée, j’étais curieuse d’éprouver ma capacité à prendre la parole en public. “Les personnes qui vont venir seront sans doute très expérimentées, comment vais-je réussir à capter leur attention ?” – “Et si ce que je dis n’est pas intéressant ?” – “Je vais oublier mon texte, c’est sûr… mais si je l’apprend par cœur, j’aurais l’air de réciter une poésie… 😉 ?”

Passée la timidité des premiers instants, j’ai vraiment adoré l’expérience et le challenge.

Dès le début, j’ai été agréablement surprise de découvrir que j’avais une vision trop étriquée des Meet-ups en général. Un meet-up n’est pas forcément l’intervention de quelqu’un qui parle pendant une heure sur un sujet donné, pendant que les autres l’écoutent. Les deux derniers Meet-ups de SchoolOfPO étaient extrêmement interactifs, y compris pendant l’introduction et la partie “Talk”.
Ensuite, le format intègre deux sessions de 25 minutes sur le format “Open Space“. Les participants se répartissent selon plusieurs thèmes d’échanges, issus de la présentation. A la fin, ils restituent une synthèse de ce qui en ressort et de ce qu’ils ont appris.

En plus du sujet en lui-même, j’ai été particulièrement intéressée par les rencontres et la richesse des échanges qui sont sortis de cette soirée. La “tête dans le guidon” au quotidien, il est parfois difficile de s’en extraire pour réellement prendre du recul sur ses actions ou trouver des pistes d’optimisations.
SchoolOfPO, c’est un concentré de personnes d’horizons très différents, rassemblées autour rôle du Product Owner et ayant une volonté commune de partage et d’amélioration.


Cool Stuff :
 What is a meet-up and why should I care ? – Oleg Podsechin
Bibliothèque du #Meetup SchoolofPo :
Le Pouvoir de dire Non

lucie_lesage

lucie-lesage_2

life-is-about-the-people-you-meet

L’école des Product Owners

Le rôle du Product Owner ne s’apprend pas à l’école, ou si peu. Alors à quoi sert-il ? Quelle posture doit-il adopter ? Quelles sont ses interactions avec l’équipe de développement ? Avec les parties prenantes de l’entreprise ? Quels sont ses outils et ses facteurs clés de succès ? Que fait-il au quotidien ? Quelles sont ses priorités ? A quoi reconnaît-on un “bon” Product Owner ? Peut-il y avoir des “mauvais” Product Owners ? Comment peut-il s’améliorer ?

Il y a quelques semaines, Pablo nous a parlé d’une idée : il voulait créer une “School Of PO”.
Une belle opportunité, au vu de ces questions autour desquelles nous aimerions partager des réponses.
D’abord parce que les entreprises oublient parfois de prioriser la concrétisation de leurs idées par la valeur ajoutée apportée aux utilisateurs. D’où l’importance pour elles de s’entourer de Product Owners capables de les remettre dans le droit chemin.
Ensuite, parce que le besoin d’échange et de partage autour du Product Ownership est réel.
Et enfin, parce qu’on aime bien faire de belles rencontres !

Au fil d’un brainstorming avec les beNexters, le projet d’une série de Meetups était né : 30 minutes de présentation, un Open-Space pour ouvrir la discussion et s’enrichir des avis de tous les participants, et bien sûr une clôture de la soirée avec pizzas/bières.

Le premier Meetup de “School of PO” aura lieu le 16 novembre dans les locaux de beNext.
Pablo et Dragos relèveront le défi du PechaKucha pour nous aider à répondre à la question : “A quoi sert un Product Owner ?”.

Et parce que nous restons dans une démarche d’optimisation continue, n’hésitez pas à nous donner votre avis !

 

✎ Plus d’informations sur InfoQ, SchoolOfPO ou Twitter !
Contactez-nous

schoolofpo

L’importance du Backlog Grooming

Lorsque j’ai intégré un nouveau projet il y a un mois, j’ai découvert que l’équipe que je rejoignais ne connaissait pas et donc n’organisait pas de “Backlog Grooming”.

Le premier Sprint Planning auquel j’ai participé a duré 3 heures. C’est long. C’est barbant. Les participants se sont rapidement désintéréssés. L’atelier a rapidement empiété sur la pause déjeuner. Au secours.
En sortant de la salle (enfin!), je leur ai demandé “mais comment vous faîtes pour supporter ça ?”. L’un d’entre eux m’a répondu “et encore, avant ça nous prenait la journée entière…”. #Help!

Au delà d’être une corvée pour tout le monde, un Sprint Planning où les débats sont sans fin entraîne le risque d’embarquer dans le sprint des User Stories qui ne sont pas prêtes. Ou de passer à côté de certaines subtilités. Un autre exemple : je me suis rendue compte que l’équipe ne rédigeait pas de scénarios de tests pour chaque Story. Une fois la fonctionnalité développée, le testeur demandait donc au développeur “comment tester” avant de suivre ses consignes à la lettre et passer la tâche en “Done”. La probabilité de passer à côté de certains cas fonctionnels et d’engendrer des régressions était donc décuplée.

Je leur ai donc proposé de mettre en place 2 ateliers de Backlog Grooming par sprint, pour partager les sujets du backlog, échanger sur les prochaines fonctionnalités à développer, découper les User Stories, et surtout, en finir avec les discussions interminables au moment de démarrer un nouveau sprint.

Oui, mais si on fait 2 backlog grooming d’une heure et un sprint planning d’environ une heure et demie, au final ça revient au même qu’un sprint planning de 3 heures ?”. Non ! Parce qu’on échelonne les discussions sur plusieurs jours. On prend le temps de laisser décanter nos réflexions. Et on peut aller chercher des informations supplémentaires auprès des interlocuteurs qui ne participent pas à nos cérémonies, pour affiner les sujets. Bref, on gagne en qualité.

La mise en place d’un Backlog grooming récurrent, d’une heure pas plus, c’est la garantie de démarrer un nouveau sprint avec des User Stories qui sont d’avantage formalisées et partagées. L’ensemble des membres de l’équipe sait concrètement ce qu’il faudra faire pour chaque Story. Les estimations de chaque tâche sont affinées. Et le risque de surcharger le sprint parce que tous les impacts n’ont pas été étudiés est diminué.

Quel résultat ?
4 ou 5 Backlog Grooming et 2 sprints de développements plus tard, l’équipe est satisfaite de ce nouveau mode de fonctionnement. Le bénéfice de cet atelier est ressorti plusieurs fois comme un point positif au moment de la rétrospective.
Et bien que le fruit de ces ateliers n’ait pas engendré une amélioration nette de la vélocité de l’équipe, nous constatons clairement d’avantage de sérénité dans le déroulement des sprints.
A long terme, l’équipe pourra également avoir une meilleure visibilité du Backlog du Produit, notamment sur les sujets à venir dans 2 ou 3 mois
Et surtout, l’équipe ne sacrifie plus ses pauses déjeuner !

D’autres articles utiles sur le sujet :
● Pour que les Backlog Grooming ne soient plus une corvée ! ▫TheObserverself
● Backlog Refinement, la clé pour une Agilité réussie ▫QualityStreet

Pitchopoly Time ! Let’s Pitch !

Il y a quelques semaines chez beNext, on a joué à un super jeu : Le Ptichopoly !

Alex (c’est lui) est arrivé avec une idée, ou plutôt avec un problème : imaginer des concepts et des applications mobile, c’est simple. D’autant que chez beNext, les idées foisonnent ! Mais comment tester nos concepts ? Comment vérifier que les applications qu’on imagine sont réalistes et seraient sources de revenus dans la vie réelle ?

Alors, il a imaginé un jeu : le Pitchopoly. La règle du jeu est simple : vous venez avec une idée de nouvelle application mobile, autour de laquelle vous allez jouer, et pitcher !
Le jeu se présente comme un Monopoly : vous lancez le dé pour avancer, faîtes plusieurs fois le tour du plateau de jeu… Mais les billets de banque sont remplacés par du temps que vous pouvez gagner et dépenser en effectuant des tâches, en vue de travailler votre concept et affiner votre idée de départ. L’objectif final est de pitcher le mieux possible face à vos adversaires qui défendent leurs propres idées d’applications.

IMG_20160709_215805

Au fil du jeu, chaque tour de plateau entraîne un nouveau pitch.
A chaque fois, vos adversaires qui endossent le rôle d’investisseurs, à qui vous présentez votre idée, votent “+” ou “-” , en fonction de s’ils sont convaincus ou non par la capacité de votre produit à “tenir la route” dans la vie réelle.

L’idée est-elle réaliste ? Quelle serait la source de revenus ?
Le ROI de l’application serait-il satisfaisant ?
Y aurait-t-il un marché/une demande pour utiliser le produit ou être intéressés par le concept ?

Vous investissez du temps au fil du jeu pour effectuer des recherches, établir un business plan, définir un Lean Canvas ou observer la concurrence sur le Play Store… Puis, quelques tours de plateau et quelques pitchs plus tard, vous êtes fixés !

Au delà de placer les joueurs dans une position réelle d’entrepreneurs, et tout en restant “fun”, ce jeu leur permet de travailler leur capacité à convaincre et leur aisance à prendre la parole en public.
Les beNexters l’ont adopté ! 🙂

Le secret du PO : Savoir dire “Non”

Le Product Owner est un acteur clé dans l’organisation d’une équipe Scrum et dans la réussite d’un projet Agile. Il est le responsable du produit. Son rôle principal est de définir et de porter la vision du produit dont il a la charge, de déterminer dans quel ordre le produit sera construit, en priorisant avant tout les fonctionnalités ayant une plus forte valeur pour l’utilisateur et un ROI important pour l’entreprise.

Il travaille en coordination étroite avec son équipe (Développeurs, Testeurs, ScrumMaster, UX Designers, Exploitants) et fait le lien avec toutes les parties prenantes impliquées dans le projet.
Son objectif premier est de faire adhérer les personnes aux objectifs du projet, partager une vision unifiée du produit et insuffler une dynamique.

Sa principale difficulté ? L’équipe de développement, les stakeholders ou encore les partenaires ont tous des besoins et des objectifs différents. Le secret du Product Owner pour créer un produit à forte valeur ajoutée ? Savoir dire « non » quand c’est nécessaire pour toujours garantir un produit centré sur les besoins des utilisateurs et le ROI.

« Non, nous ne pourrons pas tout livrer d’un coup »
Afin que le coût de revient du projet soit le plus faible possible, l’équipe doit montrer une première version du produit aux utilisateurs le plus tôt possible (“MVP). Développer les fonctionnalités primordiales et soumettre une première version du produit aux utilisateurs permettra à l’équipe de récolter rapidement des feedbacks et des axes d’amélioration de la part des utilisateurs. Le Product Owner pourra alors s’assurer de la pertinence du produit et de la présence d’un marché réceptif. Il adaptera ensuite la trajectoire du produit pour s’assurer qu’il répond réellement aux besoins et par conséquent maximiser le ROI. Mais cela implique d’assumer la sortie d’un produit qui n’est pas encore complètement terminé.

« Non, toutes ces demandes ne tiendront pas dans un seul sprint »
Le Product Owner insuffle une dynamique au sein de son équipe pour créer un maximum de valeur en un minimum de temps. Malgré tout, son objectif est de s’assurer que l’équipe reste investie et motivée sur toute la durée du projet. Que tous les membres restent occupés sans pour autant être surchargés. En résumé : il doit privilégier l’endurance de l’équipe et non la vitesse maximale envisageable. Le Product Owner doit donc savoir dire « non » quand les exigences des parties prenantes sont décorrelées de la capacité de l’équipe.

« Non, nous ne pouvons pas modifier le périmètre du sprint en cours »
La rédaction des User Stories à développer doit être réalisée en amont du début du sprint. Une fois qu’une User Story est découpée, partagée et intégrée dans un sprint, il n’est plus possible de modifier le périmètre de la fonctionnalité souhaitée. En effet, des perturbations incessantes nuiraient au bon déroulement des développements, à la « santé » de l’équipe et à la vision du produit. C’est pourquoi le PO doit savoir dire « non » lorsqu’on lui demande de modifier le périmètre ou le contenu du sprint en cours. Les adaptations nécessaires pourront en revanche intervenir dès le début du sprint suivant.

« Non, cette fonctionnalité ne pourra être déployée en production telle quelle »
Le Product Owner a la capacité de refuser le déploiement d’une fonctionnalité développée par son équipe à un instant T, s’il estime qu’elle apporte un bug bloquant ou une dégradation de la qualité du produit. En tant que « responsable du produit », le PO doit s’assurer que l’expérience utilisateur reste optimale.

Cette liste (non exhaustive) peut sembler dresser un tableau assez noir du rôle du Product Owner. Malgré tout, sa posture est essentielle pour la réussite du projet. Sans la capacité de dire « non », le Product Owner entraînerait le développement d’un produit qui n’a plus de sens ou qui ne correspond plus à la vision partagée. Enfin, la posture du Product Owner ne doit pas faire oublier que la gestion d’un projet Scrum est un sport collectif !
Le PO doit savoir s’appuyer sur son équipe et tous les interlocuteurs investis.
S’il est souvent amené à prendre des décisions, le Product Owner ne décide jamais complètement seul.

UPDATE : Ce sujet a fait l’objet d’un des #Meetup de @SchoolOfPO. Pour en savoir plus, rendez-vous sur la bibliothèque dédiée.

Hi, I’m a Product Owner !

J’ai découvert le rôle de Product Owner, en octobre 2014, lorsque je travaillais chez Voyages-SNCF.com.
Chef de Produit depuis 3 ans, mon rôle était alors de mettre en place des actions commerciales sur le site pour développer les ventes et coordonner des projets pour permettre au site de bénéficier de nouveaux leviers de croissance.

Dans un contexte concurrentiel de plus en plus dynamique, l’objectif pour Voyages-SNCF était de réduire considérablement son « Time to Market », pour garantir une optimisation de ses parcours de vente en continu. Covoiturage, compagnies aériennes low cost, et désormais compagnies de bus se partagent le marché du transport de personnes en France. Pour rester leader, l’entreprise devait s’assurer de rester à la pointe de l’innovation et toujours plus à l’écoute des utilisateurs.

L’enjeu du projet sur lequel j’ai travaillé en tant que Product Owner était la refonte fonctionnelle et technique de la page de résultats de recherches de trajets en train, qui accueille plus de 300 000 visiteurs uniques chaque jour. Fonctionnellement, il s’agissait de garantir une expérience utilisateur optimisée. Techniquement, il s’agissait de s’affranchir du Legacy applicatif qui rendait tardive la sortie de nouvelles fonctionnalités.

Alors, plutôt que de reprendre une par une les fonctionnalités sur un applicatif vieillissant, ce qui aurait été long et coûteux, il a été décidé de repartir de zéro : créer une base applicative neuve, dédiée à la recherche de trajets en train. Aux commandes de ce projet ? Une équipe 100% dédiée, qui se décloisonnerait complètement des cycles de Delivery/Release traditionnels de Voyages-SNCF.

La première Feature Team était alors lancée chez Voyages-SNCF : 2 Product Owners, 1 Scrummaster, 4 développeurs, 1 testeur, 2 UX designers et 1 exploitant. L’ensemble des compétences nécessaires pour mener le projet de bout en bout, depuis l’expression des besoins jusqu’à la mise en production, étaient réunies au sein d’une même équipe, dans un même espace.
Un modèle d’organisation idéal pour un Product Owner : voir en temps réel la réalisation des fonctionnalités imaginées et pouvoir en mesurer l’impact sur l’expérience utilisateur tout aussi rapidement.

D’un besoin primaire, nous avons étoffé une vision du produit que nous avons partagé à l’ensemble des parties prenantes. Pour proposer une première version aux utilisateurs le plus rapidement possible, nous avons défini un « MVP » (Minimum Viable Product). Il s’agissait de définir le périmètre de fonctionnalités le plus petit à partir duquel nous pourrions présenter le produit aux utilisateurs. Il permettrait aux premiers clients de bénéficier d’une expérience complète avant que toutes les fonctionnalités ne soient encore développées.
Pour l’équipe, ce MVP était la garantie de pouvoir adapter son cap le plus tôt possible, en fonction des retours des utilisateurs et des performances.

Peu à peu, nous avons également établi un « Road to Prod » qui nous a permis de définir et de réaliser l’ensemble des actions nécessaires à la mise en production du « Lot zéro ».

En 3 mois, nous avions livré un premier lot « à blanc » de l’applicatif, qui validerait notre capacité à aller en production rapidement, en toute autonomie.
En 6 mois, nous livrions une première version « Beta » de la page, accessible via une URL détachée du reste du site. Nous l’avons soumise aux meilleurs clients de Voyages-SNCF, aux bloggeurs et sur les réseaux sociaux. Nous avons alors récolté près de 3 000 feedbacks, directement depuis la page via l’outil Usabilla, dont une grande majorité d’avis positifs.
Nous avons également reçus de nombreux axes d’amélioration de la part des internautes, dont nous avons tenu compte pour nous assurer que la vision cible du projet répondrait aux besoins réels des utilisateurs finaux.

Voyages_SNCF_Tweet

Après quelques optimisations, nous étions prêts à « rebrancher » la nouvelle page de résultats au moteur de recherche de voyages-sncf. Nous avons alors procédé à un AB test, afin de vérifier que les performances en termes de conversion restaient satisfaisantes. Sur la base de certains critères de recherches éligibles, 50% des internautes qui lançaient une recherche depuis la page d’accueil étaient redirigés vers la nouvelle page et 50% vers l’ancienne.
Une fois l’AB test terminé et les KPI de succès vérifiés, nous poursuivions l’industrialisation de la nouvelle page de résultats. Nous avons alors élargi le périmètre d’éligibilité des internautes à la nouvelle page, au fur et à mesure des sprints et des mises en production.

A partir de mai 2015, chacun de nos sprints de développements donnait lieu à une nouvelle mise en production par l’équipe (toutes les 2 semaines) : c’était alors une nouveauté pour Voyages-SNCF.com.
A chaque mise en production, la Feature Team s’assure elle-même que les indicateurs business sont au rendez-vous (audience, ventes, conversion) et que les KPI techniques ne sont pas dégradés (temps de chargement, temps de réponse…).
En cas de problème majeur rencontré, nous avions l’autonomie suffisante pour revenir en arrière et ne pas livrer la nouvelle version. L’objectif clé de la Feature Team étant de garantir la création de valeur pour l’utilisateur.

En août 2015, 85% des internautes effectuant une recherche depuis la page d’accueil étaient redirigés vers la nouvelle page de résultats.
Aujourd’hui, cette nouvelle page est déployée sur l’ensemble des versions européennes de Voyages-SNCF.com (8 marchés, 7 langues) et l’équipe de développement poursuit le travail jusqu’au décommissionnement complet de l’ancienne page de résultats.

Feature Team - Voyages-SNCF