Tech Rōnins

Programme:Agilité: la théorie vs la pratique

L’outils de l’invité

InterviewEst-ce que c’est une chose à laquelle tu as été confrontée?

Agile coaching VS manager skills (est-ce la meme chose?)

À quel point faut-il se forcer à suivre les principes d’une méthodo?

À quel moment ça devient contre-productif?

Est-ce qu’il y a des principes sur lesquels on ne peux pas faire de concession?

Fausse dualité entre les textes et la pratique

L’agilité en dehors de l'engineering

Comment amener l’agilité dans le top management?

Outils de l’invitéThe Sprint Book

Programme:Kanban

Les outils de l’épisode

Mais pour commencer, intéressons nous au principe Agile du mois de Juin

Principe Agile du mois de Juinhttps://agilemanifesto.org/iso/fr/principles.html (https://agilemanifesto.org/iso/fr/principles.html)

Les meilleures architectures, spécifications et conceptions émergent d'équipes autoorganisées.

Steve’s quote: “It doesn't make sense to hire smart people and tell them what to do; we hire smart people so they can tell us what to do.”

Très vrai, pinch of salt pour les jeunes recrues (peu/pas d’exp pro)

Donner l’ownership: “ce que je construit, c’est à moi de m’en occuper demain, mais aussi dans 10 ans”

Pourquoi?

Liberté de choisir

Liberté d’échouer → Ownership

Responsabilisation

Liberté de choisir sa méthodo, sa composition d’équipe

Sujet principalKaizen: “le changement pour le mieux”

“commencer avec ce que vous avez”

Beaucoup d’outils dans Kanban: pas besoin de tous les sortir en même temps

Toyota

Carte de signal (heure de début, heure de fin, numéro, etc)

Cycle de vie d’un pare-chocs (amène une pile, traite la pile, carte de signal à l’avant-dernier, nouvelle pile au bon moment)

Pulling system: toujours la fin du système qui demande de nouvelles taches

Board

Etapes nécessaires à créer de la valeur

Double colonnes (nécessaire pour avoir un système de tirage)

On ne force pas l’étape suivante

WIP limits

Stop Starting, Start Finishing

Classes de Services (cout de retard, swim lanes)

Inception

Metrics

Lead time (temps passé dans le board après le commitment)

Cycle time (vélocité; ratio: nombre de taches par unité de temps)

Loi de Little (Lead time = WIP * Cycle time)

Prévision probabiliste

Book: Essential Kanban Condensed (30 pages)

Définition claire (DoD), Definition of Ready peut etre utile aussi: EXIT CRITERIA

Laisser du temps au temps (Kaizen approach)

Très important de piloter grace aux metrics

Board haut niveau: Réflexion ; Validation ; Prêt ; Production ; Confirmation ; Inspection ; Terminé

Board produit: Discussion ; Test utilisateur ; Raffinage ; Prêt ; En cours ; Confirmation ; Terminé

Board ingénierie: Prêt ; En cours ; Prêt à être testé ; Test en cours ; En production ; Terminé

Outils de l’épisodehttps://www.leancoffeetable.com/ (https://www.leancoffeetable.com/)

Demander à quelqu’un ce qu’on fait là, quelle est la mission

Programme:Réflexions sur le full remote

Les outils de l’épisode

Principe Agile du mois de Mai

Principe Agile du mois de Maihttps://agilemanifesto.org/iso/fr/principles.html (https://agilemanifesto.org/iso/fr/principles.html)

FR: “La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.”

EN: “Simplicity — the art of maximising the amount of work not done — is essential.”

“La meilleure ligne de code est celle qu’on a jamais écrite”

Fonctionne partout

Dans un projet tech (WIP limit, backlog)

Dans la vie du tous les jours (organisation, matrice d’Eisenhower (déléguer, supprimer))

Sujet principalEst-ce qu’on se serait pas un peu trompés sur le full remote?

Définition: Quand le télétravail est le mode par défaut, avec des collaborateurs dispersés dans une multitude de pays.

Full remote, si bien que ca?

Bureau et sérendipité

Plus de temps aside

Retraite: deux conclusions possibles:

Soit “Il faut se voir plus souvent”

Soit “Il faut émuler mieux à distance”

Communication non-verbal numérique: points de vies sur la webcam

Plus d’asynchrone

Préparer les rendez-vous

Board Miro systématique

Se lever, faire des pauses, rester actifs

Oui c’est si bien que ça

Retraites régulières

Transparence

Outils de l’épisodeKanbanize

OBS Studio

Communication non-verbale numérique

Points de vie

Programme:DevKan, l’outil Kanban ultime... qui n’existe pas

Problématiques actuelles

Les outils de l’épisode

Principe Agile du mois d’Avrilhttps://agilemanifesto.org/iso/fr/principles.html (https://agilemanifesto.org/iso/fr/principles.html)

“Une attention continue à l'excellence technique et à une bonne conception renforce l’Agilité.”

Excellence technique = architecture aux petits oignons + tests IMO

Bonne conception = pas seulement technique, mais en amont aussi (LEAN approach)

Peu de bugs = moins d’unplanned work

S’il faut pas tout réinventer à chaque feature, on va plus vite

Sujet principalDevKan, l’outil Kanban ultime... qui n’existe pas

Historique:

Artos, 2020, certif Kanban

Jira pas ouf

Concept: respecter la méthode Kanban (double colonnes, WIP, swimlanes, metrics) et les dev sans faire changer toute la boite à ça. Par des devs pour des devs.

On interview des amis, ca nous prouve qu’il y a pas de marché mais on y va quand même

MVP prêt assez rapidement

Contracting not so easy

Pierre à GetGround

Blog, OAuth

Julien à SwissBorg

No motivation, no traction, stop

Start Agilistes

Outils de l’épisodeMind42 - Mindmap tool collaboratif GRATUIT

Slack Clip Feature

Toujours pas fait mon How to Julien

Programme:Scrum: by the book or not by the book?

Problématiques actuelles

Les outils de l’épisode

Principe Agile du mois de Mars

Principe Agile du mois de Marshttps://agilemanifesto.org/iso/fr/principles.html (https://agilemanifesto.org/iso/fr/principles.html)

“Les processus Agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant.”

Julien:

Constant mais aussi raisonné: 80% en croisière pour pouvoir spike à 120% quand nécessaire

Quels outils nous offrent les méthodes agiles pour respecter ce principe?

Pierre:

Les devs sont garants de ce qui rentre dans le Sprint

Sujet principalScrum: by the book or not by the book?

Julien:

Oui, mais.

Learn the rule, apply the rule, break the rule.

https://www.amazon.fr/dp/B09W7FTN5P (How I planned my wedding with Scrum)

Pierre:

Scrum is a framework, Kanban is a method (”start with what you have”)

Problématiques actuellesJulien:

Manager des non ingénieurs

Sélectionnés sur d’autres critères

Autre vision des méthodes agiles et processes d’industrialisation

Adaptation pour tout le monde

Bienfaits de cette diversité déjà visibles

Team topologies

Outils de l’épisodeNotion (https://www.youtube.com/channel/UCLKx4-_XO5sR0AO0j8ye7zQ (Shubham SHARMA))

https://www.youtube.com/watch?v=m-2BFuYUjmYandlist=PL8iMj9kx_ykSqcV7ro9VJDvE6FsQSMg2Nandindex=2andab_channel=Sharethrough (“How to Rands”) - https://github.com/randsleadershipslack/documents-and-resources/blob/main/howtorands.md (README example)

Programme:Cédric retour d’expérience sur un lancement de projet en mode garage

L’outils de l’invité

InterviewPrésentation de l’invité

Qui es-tu?

Que fais-tu?

Lancement de projet en mode hackathon / garage offsite dans une villa

Parle-nous un peu de ça

Place de l’agilité dans ce processus

La place de l'agilité

Perception par l’équipe / feedback

Point de vue interpersonnel

Deep Work

Résultat

Balance boulot / fun

Qui?

Skills?

Outils de l’invitéMiro

Programme:Bonnes résolutions: les méthodes Agiles dans le quotidien

Problématiques actuelles

Les outils de l’épisode

Mais pour commencer, intéressons nous au principe Agile du mois de Janvier

Principe Agile du mois de Janvier

https://agilemanifesto.org/iso/fr/principles.html (https://agilemanifesto.org/iso/fr/principles.html)

“Un logiciel opérationnel est la principale mesure d’avancement.”

Pierre:

Ligne rouge = tant que le logiciel est opérationnel, on peut continuer à avancer (si problème, pause, résolution, et reprise d’activité)

Julien:

Au moins deux lectures:

Concervatrice: il faut toujours que ça marche, donc petits pas

Produit: il faut toujours déployer un incrément qui apporte de la valeur à l’utilisateur

Sujet principalLes méthodes Agiles dans le quotidien

Pierre:

“WIP Todo”

Todo list with a 3 active tasks columns with a twist = all 3 tasks needs to be done before taking 3 more in batch ( j’essaye de prendre 2 facile/rapide et 1 plus contraignante (longue ou difficile) )

Julien:

Bullet Journal:

Permet de faire du “just in time”

Le calendrier se densifie à mesure qu’il est proche dans le temps (comme un backlog)

Kanban adapté à l’organisation personnelle

Apprendre à se focaliser sur un objectif à la fois (= sprint Scrum)

Eviter de faire du multi taches

Se laisser 3 à 6 mois de focus avec des objectifs (ou livrables) intermédiaires

Voir sa vie comme un projet Scrum

https://lescastcodeurs.com/2016/07/27/lcc-152-interview-sur-la-productivite-personnelle-avec-guillaume-lours/ (Les Cast Codeurs: Interview sur la productivité personnelle)

Problématiques actuellesPierre:

Réflexion sur le passage sur Kanban (depuis Scrum)

pourquoi? quels avantages? quels inconvénients? comment?

Julien:

Regain situation awareness (conscience de la situation) après les vacances

Jira: difficile de voir le delta, savoir si c’est à jour, trop de tickets

Solution: messages sur Slack

1 message / epic

demander une réaction (emoji “main qui fait coucou”) pour ceux qui travaillent dessus

une phrase dans le thread du message pour donner une idée du status

Même quand on est manager, c’est ok de poser des questions et demander où on en est

Asynchrone: donc ceux qui rentrent de vacances dans les prochains jours auront de la donnée fraiche, une photographie de l’état d’avancement global

Outils de l’épisodePierre:

https://www.cassetteapp.com/ (cassetteapp.com)

Julien:

Bote en touche:

Diviser un message sur Slack / Teams en plusieurs petits morceaux pour permettre aux gens de réagir dans des threads individuels

Evite le bruits pour ceux qui ne sont pas concernés

Permet de mieux visualiser l’information et les personnes impliquées

À utiliser dans ces cas particuliers, sinon tout packer dans un seul message évite le bruit et permet justement de réagir dans un seul thread…

Programme:

Épisode “fourre-tout”

Debrief

1:1

Comment prendre soin de ses ingénieurs

Stand-up asynchrones

Problématiques actuelles

Les outils de l’épisode

Principe Agile du mois de Décembre

https://agilemanifesto.org/iso/fr/principles.html (https://agilemanifesto.org/iso/fr/principles.html)

“La méthode la plus simple et la plus efficace pour transmettre de l’information à l'équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face.”

Julien:

Je commence pour une fois

Comme souvent un peu désuet

Il y a 15 ans: chaine d’emails > humains

Maintenant: messagerie instantanées adaptées à l’entreprise

De + en + dans l’asynchrone

À nous d’adapter le medium de communication à la situation sans négliger ni l’un ni l’autre

Pierre:

Comment faire avec le remote working?

Remettre au goût du jour (principe vieux de 20ans)

“transmettre” != garder une trace (point of order + minutes?)

Sujets principaux

Pierre:

Comment prendre soin de ses développeurs?

Growth framework (objectifs clairs, PdP pour les atteindre)

1:1s

Questions / concerns / PdP update

Julien:

Debriefs

Stand-up asynchrones

Problématiques actuelles

Pierre:

Galvaniser les troupes pour une année où l'équipe ingénieur sera multiplié par 2 (au moins)

Julien:

Comment être un manager un peu plus pushy sans être un sale con?

Utilise les processes pour que tout roule sans mon intervention

Mais parfois il faut remettre l’église au centre du village

“On est dans un système chaotique à peu près maitrisé, mais comme l’entropie augmente il faut parfois ajouter un peu d’énergie. Et c’est là qu’on intervient en tant que managers.”

Ma solution: Kaamelott: Cesar à Arturus: “On devient pas chef parce qu’on le mérite, andouille ! On devient chef par un concours de circonstances. On le mérite après. Moi il m’a peut-être fallu dix ans pour mériter mon grade. Si pas vingt. Tous les jours j’ai travaillé, pour pas nager dans mon uniforme. Eh, y’a pas 36 solutions, Arthurus, hein. Fais semblant. Fais semblant d’être Dux. Fais semblant de mériter ton grade. Fais semblant d’être un grand Chef de Guerre. Si tu fais bien semblant, un jour tu verras, t’auras plus besoin.”

Outils de l’épisode

Pierre:

Questionnaire (outil générique, pleins d’options qui se valent)

Julien:

Google Calendar: notes de réunion

Geekbot

Programme:

Les challenges et bénéfices du full remote

Problématiques actuelles

Les outils de l’épisode

Principe Agile du mois de Novembre

Principe Agile du mois de Novembre

https://agilemanifesto.org/iso/fr/principles.html (https://agilemanifesto.org/iso/fr/principles.html)

Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés.Comment motiver ces personnes?

Comment ne pas se faire “avoir” par des mauvais acteurs dans le système?

Ancré (trop?) dans mon style de management

Dans une équipe de 5-7 personnes il suffit d’une brebis galeuse

Sujet principal

Les challenges et bénéfices du full remoteDéfinition: entreprise distribué géographiquement où aucun bureau central n’est nécessaire

Spectre:

No remote: il faut être présent

Remote autorisé: autorisé selon certaines conditions

Hybrid autorisé: certains sont full remote, d’autres à plein temps au bureau

All-remote: pas de bureau, tout est organisé autour de ça

...above

“Remote +” full remote dans le pays “rattaché”, sinon quelques jours à quelques mois dans un/des autres pays (tant que la loi l’autorise)

Bénéfices:

Plus de talents disponibles géographiquement

“standard” pour les demandes des devs = environ 20% à 40% refuse le poste car non remote

Plus de temps “perdu” dans les transports = devs plus enclin à “pousser” un peu plus

fléxibilité d’organisation personnelle (53%), trajets (38%), famille (34%)

ouverts 24h par jour

impose une forte culture des processes

Challenges:

communication asynchrone par design

documentation au coeur de l’entreprise

sensibiliser au burnout

salaire

communication

Pour creuser le sujet je recommande le cours Coursera fait par GitLab (~6 heures)

Problématiques actuelles

cohésion et adhésion des nouveaux employés (surtout les jeunes développeurs)

Outils de l’épisode

Pomofocus

https://pomofocus.io/app (https://pomofocus.io/app)

Enregistrer les meetings

permet d’être plus async

distribué

moins de personnes juste là pour écouter ou “au cas où”

ne remplace pas un compte rendu de réunion

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