Pour, notre premier GrowTogether de l'année ce sont nos deux de nos coachs : Pablo Pernot et Nils Lesieur qui nous ont accompagnés. Merci à eux pour leurs investissements sur la journée.
Au programme : beaucoup d'intervisions et des ateliers.
Intervision
Problématiques retenues :
1. Comment gérer les fortes personnalités ?
2. Comment travailler avec une équipe à distance et peu communicante ?
3. Comment avoir plus d’expression de besoins des métiers ?
Problématique 1 : Comment gérer les fortes personnalités ?
Contexte ( Quel est le problème ?)
lead UX dans le domaine produit
pas rattaché directement à nos équipes
une aisance hyper agaçant
il travail sur ses propres sujets qui ne sont pas les mêmes que nous
intervient en dehors de son périmètre
ses équipes sont écrasées par sa personnalité
pas dans l’écoute
travaille dans le futur
en presta puis en interne depuis peu
Si j'étais toi ...
je prendrais un café avec lui pour voir si la situation est si grave que ça ou si elle peut être améliorée
j’essaierais de comprendre ce qu’il veut, ce qu’il cherche
j’en parlerais avec mon PM
je travaillerais en direct avec l’UX sans lui
je ferais un point pour se mettre d’accord sur les rôles de chacun
le scrum master doit être neutre, ce n’est pas un lead Android (par exemple)
dire oui oui, en mettant ses sujets de son côté
je mettrais en évidence qu’il est nuisible
si le top management ne voit pas les problèmes alors il n’est pas bon
je ferais un atelier give and take
Problématique 2 : Comment travailler avec une équipe à distance et peu communicante ?
Contexte ( Quel est le problème ?)
deux équipes (back & front)
mise en place de quelques interactions avec les PO
une fois les développements commencés, il n’y a plus trop de communication
le scrum master n’est pas réellement scrum
besoin de repasser par la PO pour avoir de la communication
nouveau dev qui est arrivé dans l’équipe et qui veut devenir scrum master
une moitié de l’équipe en Roumanie et l’autre en France
ceux en Roumanie : pas très dispo
communication par Teams
pas de lead côté développeurs
pas de lead en Roumanie : simplement la QA et des développeurs
déplacement 2 fois par an
Si j'étais toi ...
j’essaierais de faire des rituels de synchronisation entre les équipes (back et front)
je ferais un “ménage” de ceux qui ne veulent pas communiquer, pas travailler ensemble
je consacrerais mon énergie à trouver le bon scum master, en phase avec les problèmes
j’essaierais d’avoir une personne référente en Roumanie pour superviser l’équipe
je mettrais en place des actions pour que l’équipe se connaisse mieux
j’enlèverais le scrum master
j’assumerais le rôle de PO
une demande = Teams
je demanderais à l’équipe de faire une liste de 14 choses pour réussir à ne pas communiquer
c’est au PO de présenter la review
j'aurais un management visuel
découpage vertical et non horizontal
Problématique 3 : Comment avoir plus d’expression de besoins des métiers ?
Contexte ( Quel est le problème ?)
il y a 6 mois, décision de faire de la méthode agile
pas de scrum
petite équipe : pour un site web = 1 développeurs
on arrive à livrer des choses
on ne respecte pas tous les rituels
toute la partie conception et besoin métier est oubliée dans la méthode scrum
personne au dessus pour aider et être dispo pour construire la vision produit, la roadmap
du mal à mobiliser les personnes du métier
pas de retours utilisateurs
pas d’objectifs à atteindre
pas d’UX en interne
pas de roadmap
pas de tests utilisateurs
Si j'étais toi ...
j’organiserais des ateliers de construction de vision du produit, la partager et sortir des choses dans ce sens
me rapprocherais des clients et de la relation client pour voir les demandes
je mesurerais constamment les choses que l’on sort
je ferais un plan de release pour montrer où est-ce qu’on sera dans 3/6/9 mois
je ne pas parlerais pas de méthode agile/informatique au métier : il s’en fiche
je ferais des tests utilisateurs
je ferais comme si le métier n’existait pas. S’ils ne reviennent pas vers toi sur leurs besoins c’est que ce n’est pas assez important
je connaîtrais le nombre de contact client auprès de la RC
je ferais une chaîne Teams/Slack où tout le monde se parle
Ateliers personnalisés
Atelier 1 : Plan de release (ou plan de livraison)
Lorsqu’on commence à travailler sur un produit, il existe plusieurs phases :
Phase d’idéation :
Questions : Quel problème je cherche à résoudre ? Qui sont mes utilisateurs etc
Atelier/outils : Lean canvas
Fréquence : À faire une fois tous les 3 ou 6 mois
Phase de stratégie :
Questions : Comment j’attaque ? par quoi je commence ? Qui dois-je impacter et comment ?
Atelier/outils : Impact mapping
Fréquence : À faire une fois tous les 3 mois
Phase tactique :
Questions : Qu’est ce que je fais ?
Atelier/outils : User story mapping
Fréquence : À faire une fois tous les 3 mois
Vient le Plan de release :
“Définition” : c’est le backlog représenté sous forme de cartouches d’itération de manière synthétique.
Son objectif :
outil de communication pour toutes les parties prenantes
permet de suivre l’évolution et la vision cible du produit
permet de faire apparaître les besoins et contradictions : si je dois passer une tâche, montrer que ça décale tout le reste et que donc ça à un impact final > permet donc aussi de prendre les bonnes décisions.
Il doit vivre sur toute la durée de vie du projet
Il est mis à jour par le PO
Qu’est ce qu’on y met ?
On y voit toutes les dates de fin d’itération.
Il est du plus précis au moins précis (puisqu’on ne sait pas comment travailler sur les sujets qui peuvent venir 3 mois plus tard)
Il faut y montrer le build et le run
Noter les estimations
Le temps passé (les sprints d’avant), où on se situe maintenant et les projections futurs
Atelier 2 : Intervision
Problématique 1 : Comment s'organiser dans une refonte d’une application ? Comment apporter mon savoir pour limiter le travail à faire en fonction des retours utilisateurs ?
Contexte ( Quel est le problème ?)
Il s’agit d’une app monitoring utilisée en interne
40 utilisateurs
objectif de la refonte est juste d’apporter un coup de “relooking”
l’app actuelle leur convient ; “elle fait le job”. Ophélie a dû creuser pour y trouver des approches fonctionnelles
Ophélie est la seule UX design de l’équipe et tout le monde ne comprend pas trop son rôle
Pour Ophélie, c’est exécuter sans apporter de valeurs : elle ne comprend donc pas sa place
Si j'étais toi ...
Je serais transparente avec tes managers sur l’objectif derrière de cette refonte
Je me poserais pour savoir “ce que je veux vraiment moi ? “
je serais à la fois transparente sur cette refonte mais venir aussi avec d’autres idées
je dirais haut et fort que tu veux faire partie de nouveaux projets
j'exprimerais clairement ce que tu veux toi et montrer que ta place à de la valeur
Je travaillerais sur ma confiance
je regarderais l’outil de la fenêtre de Johari
Problématique 2 : Comment rendre le sprint planning interactif ?
Contexte ( Quel est le problème ?)
Le sprint goal est fait à la fin du sprint planning mais ne sert à rien
il y a très peu d’interactivité
Trop douloureux pour eux : ils sont sur leur téléphone
Conviction de Justine de faire ensemble
Pas d’engagement de l’équipe
la vélocité n’est pas fiable donc pas pris en compte`
les sprints sont sur deux semaines
il y a deux groomings par sprint
Pour eux trop de réunions
le sprint planning a lieu en plein après midi
Si j'étais toi ...
Ne pas en faire et voir l’impact que cela a de juste laisser le grooming
Je réduis le nombre de réunion et transformer le grooming en sprint planning
Je communiquerais le sprint planning à toutes les parties prenantes pour montrer que c’est important de bien s’engager
je clarifierais les attentes et les objectifs de chacun
je ferais l’engagement en 10 min
je ferais un format de retro avec le SM type back to the future avec les événements des deux dernières semaines
Je killerais les groomings
Ne pas faire à 16h30
Se poser la question sur le sprint goal qui ne sert à rien
Je ferais du scrumban
J’essayerais de se focaliser sur nos responsabilités à nous : qu’est ce que tu peux faire pour influencer ?
je ferais un plan de release avec eux : le défaire ou le refaire avec toutes les prios
je ferais des sprints d’une semaine
Problématique 3 : Comment travailler en équipe avec la MOA et le métier ?
Contexte ( Quel est le problème ?)
Il y a plusieurs équipes réparties à 3 endroits différents.
métier
moa
équipe de réalisation
La team dédiée à tous les besoins est situé à Lyon.
La MOA elle est en lien avec le métier de TER
L’équipe de Camille est mal perçue car, toutes les demandes ne sont pas forcément prises
Pour Camille, ils sont de “simples exécutant” car le métier explique le besoin à la MOA et après ça va chez Camille
Les demandes arrivent plutôt bien spécifiés même si Camille doit retravailler sur le besoin / demande pour que ça soit plus claire
Or le métier aimerait / demande à co-construire avec l’équipe de réalisation
Si j'étais toi ...
je prendrais un périmètre différent et faire monter en compétence la moa dans le PO / et prendre le rôle de facilitatrice, conseil
Que toi Camille tu intègres l’équipe MOA
j’utiliserais mon peps pour trouver le bon sponsor pour redéfinir le rôle de chacun pour parler de tout ça
Je ferais un point hebdo avec tout le monde afin que chacun découvre le besoin / demande en même temps
J’essayerais d’identifier un rôle de PPO dans la moa pour prémâcher le travail et toi tu portes les sujets avec les équipes
Je ritualiserais des rencontres : à la défense, gare de Lyon, Lyon …
je ferais un atelier sur les rôles et responsabilités de chacun
Savoir : ce que je peux vous donner et de quoi ai-je besoin ?
Atelier 3 : Example mapping
Pour qui : PO et développeurs ensemble ou seulement PO pour bien structurer sa pensée
Objectifs de l’atelier : Travailler sur la qualité des users stories
Quand ? A faire avant le début d’un sprint planning / en backlog refinement par exemple
L’example mapping permet de bien spécifier une story puisqu’on va fournir toutes les règles + des exemples pour valider la user-story.
Si les règles ne sont pas validés alors la user-story n’est pas correcte.
Quels sont les étapes ?
Sur un post-it jaune on y met la user-story
Sur un post-il bleu on définit les règles que devra respecter votre user-story
Sur des post-its vert on définit des exemples pour chacune des règles énoncées
Facultatif : si les questions émergent on les pose sur des post-it rouges
Il permet également de prioriser les tâches à l’intérieur de la user-story et de la découper si besoin voir d’en ajouter.