Programme:
Les RFC et l’agilité
Problématiques actuelles
Les outils de l’épisode
Mais pour commencer, intéressons nous au principe Agile du mois de
Principe Agile du mois d’Octobre
https://agilemanifesto.org/iso/fr/principles.html (https://agilemanifesto.org/iso/fr/principles.html)
“Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.”
Pierre:
Comment créer cet échange/collaboration?
Scrum review
User’s surveys
NPS
Comment intégrer les utilisateurs dans le cycle de production?
Utilisant LogRocket - est ce que les replays des sessions des utilisateurs comptent autant que les feedbacks direct des utilisateurs?
Comment scaler ses reviews?
Julien:
La relation entre Product Owner / Product Manager et l’équipe ingénierie est clée dans la bonne conduite d’un projet
Le PO donne les priorités et se fait la voix des utilisateurs / stakeholders, les ingénieurs sont responsables de l’excellence technique de la solution
Produit dit le “quoi” et l’Ingénierie le “comment”
Produit veut que ça aille vite, Ingénierie veut que ça aille bien
Il y a une balance de pouvoir naturelle qui se crée entre Produit et Ingénierie qu’il est bon d’entretenir: c’est sain.
Communication claire et honnête
Savoir où l’influence de chacun comment et termine, tout en sachant quand prendre des initiatives
Ca demande une grande confiance mutuelle et beaucoup de professionnalisme
Sujet principal
Les RFC et l’agilité
Intro Julien:
On grossi vite et dans notre hiérarchie très horizontale c’est parfois difficile pour les nouveaux de se faire entendre ou d’oser proposer de nouvelles solutions.
On s’est dit que les RFC (Request For Comments) pouvaient être une bonne façon de prendre des décisions techniques de façon collégiale, sans avoir besoin d’ajouter de la hiérarchie.
Je sais que vous utilisez les RFC au boulot donc je voulais avoir ton opinion dessus, savoir comment vous les utilisez et comment ça s’insère dans vos process agiles?
Pierre:
Qu’est-ce qu’une RFC?
Bénéfices d’une RFC? → Condensé d’une réunion technique. Les arguments ne sont pas échangés à l’oral mais par écrit, gain de temps énorme si beaucoup d’inputs de différents développeurs!
Julien:
Devrait nous permettre d’avoir un feedback de l’Ingénierie vers le backlog produit pour les taches techniques qui sont trop grosses ou importantes ou complexes pour être faites de manière ad-hoc
Et peut-être de faire émerger de nouveaux leader techniques, est-ce que c’est quelque chose que tu as pu remarquer de ton côté?
Problématiques actuelles
Pierre:
Comment continuer le développement quand les fonctions de support ne sont pas disponibles (eg. pas de designer pendant plusieurs mois)?
Julien:
à l’aube dans changement dans les process:
fusion de deux équipes, nouveau board Jira, nouvelles bonnes habitudes (Epic -> US), nouveau process Produit, etc
c’est beaucoup de changement en même temps avec beaucoup de personnes à synchroniser (2 EM et 2 PM). On arrive toujours pas à trouver le bon moment où tlm est prêt pour appuyer sur le bouton et tout changer d’un coup, mais on arrive pas non plus à découper tout ça en petits changements.
Le fait que la charge de travail soit très élevée à côté n’aide pas à prendre du recul et se synchroniser sur ça.
Mais faire évoluer nos process est obligatoire si on veut continuer à grossir comme on le fait (en moyenne 4 nouvelles personnes par mois, 12 en septembre, l’équipe grandi de 76% cette année).
D’un point de vue micro c’est ça mon problème actuel, d’un point de vue macro il va falloir que je lise quelques livres sur comment survivre une mise à l’échelle de cette ampleur.
Outils de l’épisode
Pierre:
OKRs (Objectives and Key Results) + sli.do
Julien:
Agile Coffee (http://agile.coffee (http://agile.coffee))
Simplement un tableau à trois colonnes:
Discussion items (sujets à discuter)
Current being discussed...
