Revenir au site

GrowTogether Février 2020

by benext

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

broken image

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 ?

  1. Sur un post-it jaune on y met la user-story

  2. Sur un post-il bleu on définit les règles que devra respecter votre user-story

  3. Sur des post-its vert on définit des exemples pour chacune des règles énoncées

  4. 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.