Un GrowTogether riche en apprentissage pour la rentrée ! Merci à Pablo de nous avoir accompagné pendant cette journée, centrée sur le partage.
Intervision
Problématiques retenues
1. Comment obtenir/délivrer plus de la part des développeurs ?
2. Comment faire pour que les devs soient force de proposition quant à la co-conception à venir du produit ?
3. Comment co-construire une fonction avec les UX ?
Problématique 1 : Comment obtenir/délivrer plus de la part des développeurs ?
Quel est le problème ?
Contexte en pleine transformation agile ou il y a beaucoup de personnes externes sauf le PO. L'équipe s'autogère mais il y a un sentiment que l'équipe n'est pas impliquée. Les sujets peuvent prendre beaucoup de retards car il y a quelques dépendances et une mauvaise maitrise et le feedback est négatif : "on attends plus du delivery". Comment donc obtenir plus de la part des développeurs ?
As-tu essayé...
- de faire une rétro avec maximum 2 actions (avec un owner des actions et un suivi)
- de faire partir les personnes les moins impliquées
- de faire venir des utilisateurs / faire des tests utilisateurs avec des développeurs pour voir la valeur réelle
- d'avancer la date de mise en production et donc revoir le scope
- de nourrir les développeurs avec des KPIs
- de dire à l'équipe que ce sont des "gentils glandeurs"
- de faire une rétro basée sur la personne : avec un objectifs de chaque personne pour dire avec bienveillance ce qu'il y a à améliorer chez chaque personne
- de voir la valeur du travail effectué
- de découper plus finalement les US
- d'avoir un lead tech : pour résoudre les problèmes plus vite et pouvoir trancher
- de faire un travail ensemble sur "une version qui fait mal mais qui marche"
- d'inverser les PO
- de partager la pression des dates et s'engager ensemble en tant qu'équipe
Si j’étais toi …
- je pousserais les développeurs à présenter les US
- je présenterais les US avec les développeurs
- J'impliquerais les développeurs dès le début du projet
- je mets le PO en vacances pour mettre directement les développeurs en contact avec le métier
- je demanderais au développeur d'animer la rétro
- je ferais en sorte que tout soit prêt avant le sprint planning
- je mettrais en place une boucle de feedback (analytics, verbatimes...)
- je donnerais un feedback positif et négatif à l'équipe
- je ferais intervenir le top management pour expliquer la valeur du projet
- je demanderais aux développeurs ce qui leur manque pour être plus motivés
- je ferais des objectifs de sprint
- le top management doit passer plus de temps avec les équipes
Problématique 2 : Comment faire pour que les devs soient force de proposition quant à la co-conception à venir du produit ?
Quel est le problème ?
Seul le PO est en contact avec le métier. Il fait la demande aux développeurs en essayant de les intégrer dans la co-construction. Cependant, les développeurs ne sont pas impliqués dans le sens ou le delivery est niquel, mais sans aller plus loin. Ce n'est pas seulement à la charge du PO de réfléchir à ce que l'on veut faire et amener de la valeur à l'utilisateur. Comment faire pour que les devs soient plus dans la co-conception à venir du produit ?
As-tu essayé...
- de faire un sprint d'innovation (une fois tous les 3 sprints, tout le monde peut faire des propositions, choix collégial de ce qu'on réalise finalement) : bugs + innovation
- un atelier pour brainstormer, juste l’équipe, faire venir les idées, être force de proposition
- de faire un atelier avec devs et utilisateurs finaux pour que chacun apporte sa créativité
- de parler de l’expérience passée où devs pas impliqués ont remonté le fait en rétro, et ensuite + d’implication.
- de demander leur avis aux devs / Est-ce que ça les intéresse ? Challenger, défier. Gamifier, présenter les choses différemment
- De mettre en avant les axes d’amélioration du produit. Pourquoi pas de mécanismes pour provoquer cette réflexion ?
- De revenir à l’objectif. Quelles sont les bonnes solutions pour résoudre notre problème ? Quels leviers à aller actionner ? Comment résoudre les besoins des utilisateurs ?
- De profiter des fins de sprint pour faire boucle de feedback sur ce qui vient d’être développé : ce que les devs en pensent ? Comment on pourrait aller plus loin ?
- De sensibiliser les devs au métier. Devs ne sont pas que devs, peuvent donner leurs idées
- De ritualiser l’événement
Si j’étais toi …
- je ferais un Hack Day : Une demi-journée toutes les deux semaines. Ou la "semaine heureuse" tous les trois mois > à faire hors du product board qui fait peur.
- je ferais une présentation très précise du produit
- je réfléchirais avec l’équipe à l’impact de ce que leur implication dans le produit : ce que cela peut leur apporter, ce que cela peut apporter au produit, aux utilisateurs. Difficile d’avoir des idées, de bonnes idées, mais fait grandir
- je ferais un atelier d’idéation liés aux objectifs stratégiques
- je serais plus clair sur ce qui est bien fait d’une part et sur ce qui est attendu en plus d’autre part
- j'attendrais que cela devienne un problème
- j'essayerais de mettre rapprocher les gens : vis ma vie de PO, d’UX, d’utilisateur. Exposer un problème complexe, une situation utilisateur à résoudre
- j'initierais une notion d’invitation : espace mis à disposition tous les vendredis après-midi. Ok si les devs ne prennent pas l’espace, mais ne doivent alors pas se plaindre
Problématique 3 : Comment co-construire une fonction avec les UX ?
Quel est le problème ?
Je fais parti d'une équipe ou il y a beaucoup de turn over et ou nous avons deux roadmap différentes. On a un top management commun ou on demande aux UX de réfléchir à un nouveau parcours user et à côté on demande au produit de sortir pleins de nouvelles features. Or les UX ont une vision qu'ils ne partagent pas avec les PO : cependant, il y a un besoin de travailler ensemble pour avoir une cohérence. Comment donc co-construire une équipe avec les UX ?
Si j’étais toi …
- je fairais parti du produit : une seule et même équipe
- j'aurais une seule roadmap partagé
- j'intégrerais les UX/UI aux équipes : car déconnectés de la réalité du delivery
- j'aurais une vision commune : la construire ensemble
- je validerais les “hypothèses” qui vont partir en prod
- je suivrais l’avant et l’après du projet avec KPI
- je ferais de l’AB test pour valider les hypothèses et comparer avec l’actuel
- j'interviendrais dans l’équipe quand les développements sont en cours
- j'initierais 1jour/semaine avec les autres UX/UI pour mettre en commun et donner une cohérence
- l’UX peut avoir une itération en avance mais pas deux
- je ferais un atelier “give and take” au lieu d’un RACI (colonne de gauche qu’est-ce qu’elle attend de la colonne de droite)
- je créerais des événements commun
- je mettrais en place un point de synchro tous les 2/3 mois avec toutes les équipes
- je ferais le macro chiffrage tous ensemble
- j'aurais des règles et objectifs clairs
- je ferais des sorties ensemble, dej…
- j'aurais les mêmes objectifs pour aller dans le même sens
- je ferais un “delegation board” pour savoir qui décide
- je serais plus en mode “pull” : que les PO aillent demander au UX
- je partagerais le problème de façon plus visible
- je demanderais aux UX de les mettre dans les idées entrantes
Atelier personnalisé
Atelier 1 : Lean Coffee
Format de l'atelier :
Passer 15 minutes sur un sujet puis on vote :
je veux continuer à parler de ce sujet
peu m’importe
je veux parler d’un autre sujet ?
Comment gérer les gros sujets de refonte avec l'agile ?
- essayer de sortir une feature plus petite avant d'arriver à la vision cible
- construisez le MVP et basculer les utilisateurs peu à peu
- prendre le temps de faire du refactoring
Quels sont les éléments que devrait apporter le PO à une équipe pour trouver des solutions ?
donner les moyens aux PO de pouvoir formaliser, quantifier et qualifier les problèmes
intéressant de faire un impact mapping entre le PO, PM + équipe
Atelier 2 : Impact mapping
Type de facilitation : La meilleure façon de dire non est de dire oui (mais plus tard).
Format de l'atelier :
Chacun choisit un sujet en rapport avec son entreprise.
Définir un objectif + des mesures de succès. Donner une durée, qui n’excède pas 6 mois, au mieux faire pour 3 mois.
Toujours fabriquer un impact mapping de gauche à droite mais possible de le restituer de droite à gauche : on fait ça pour avoir cet impact auprès de ces personnes afin de…
Exemple choisit : Combler le manque de concerts
Pour faire une roadmap et aussi trouver des solutions : Remember the futur
Pour choisir le WHO : possibilité de le faire avec des billets Monopoly
Par exemple la personne la plus haute dans le codir a plus de jetons que le PM.
Besoin de le faire en plusieurs fois.
(+ d’influence : qui influence ce que doit être ton produit (prescripteur) ou tu penses à lui pour créer ton produit ; + d’impacts : cible finale)