Return to site

GrowTogether Septembre 2019

By beNext

· product-vision

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)

All Posts
×

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OKSubscriptions powered by Strikingly