C'est d'abord une culture. Quand on est en DevOps, on prend tout le monde.
DevOps et agile font effectivement partie de la même famille.
Sa virtualisation applicative, c'est très bien.
Aujourd'hui, ça nous prend 10 minutes et un café.
Ce n'est ni être dev, ni être DevOps. C'est avant tout de la communication.
Ce mouvement DevOps, c'est tout simplement drivé par la communauté et endorsé par les entreprises.
J'ai adopté une démarche DevOps.
Le développement agile, on a accéléré des poignements.
Ça amène une clarté sur le travail de...
Être dans une démarche d'amélioration contient votre trou face à des...
Ça, oui, naturellement ensemble, ça donne des résultats contre...
DevOps.
L'objectif individuel, ça s'atteint.
Alors que l'une ambition, ça se partage.
Bonjour à tous et à toutes. Et bienvenue dans un nouveau numéro de DevOps.
Aujourd'hui, consacré aux scrums.
Et donc avec moi, j'ai 2 nouvelles personnes, ce qui est vraiment très cool.
J'ai Maxime.
Salut.
Et si tu peux le présenter un peu.
Donc je suis un développeur principalement gauche IS.
J'ai 29 ans.
J'ai à Lille.
Et j'ai fait 3 ans du coup à Epitech que j'ai terminé en 2015.
Et depuis, j'ai globalement oscillé entre des petites start-ups où on était jusqu'à 10 max.
Et des activités de friands de mon côté.
Je suis passé aussi très rapidement par des grosses boîtes,
mais à chaque fois, ça s'est mal passé et ça s'est très vite terminé.
Donc je crois que fondamentalement, je dois être quelqu'un qui n'aime pas trop l'ambiance trop pro, trop protocolaire des grosses boîtes.
Donc je...
Je ne mets pas nous y très bien dans un petit univers un peu à la rache.
Ah mais cool, ça fait partie des...
Ce qu'on a besoin aussi. Et donc on a aussi Maxime, avec nous.
Bonjour, enchanté.
Donc Maxime, je suis VP of Engineering dans une boîte qui s'appelle Formance.
Une très jeune start-up d'une dième de personnes.
Je suis manager aujourd'hui techniquement.
Et dans le passé, je suis passé par des sociétés de conseils, donc ESN, pour l'autre petit nom.
Et puis voilà, grosso modo, ce que j'ai fait ces dernières années.
Dans le monde de l'infra à chaque fois.
Voilà, voilà. Dans le monde de l'infra. Et si tu dois vite représenter ta boîte, parce que ça pourrait peut-être intéresser les gens.
Ouais, nous, globalement, on est une fin-take. On permet de builder et de voir vos flux financiers en version très courte.
Ok, cool. Et moi, qui aime le tronc?
Bon, alors là, pour le coup, mon expérience, donc moi je suis aussi orienté plus infras.
Mais j'ai toujours travaillé dans le monde des devs en tant que DevOps, je vais mettre des gros guillemets à DevOps, c'est tout un sujet.
J'ai été freelance et dernièrement, ça vient un peu de changer.
Donc peut-être que j'en parlerai plutôt dans un prochain podcast pour être exactement, avoir exactement tous les détails.
Donc voilà, je fais du teasing, même si j'en ai déjà un peu parlé sur Twitter.
Et donc aujourd'hui, ce qui nous ramène tous les trois dans ce podcast, on va parler de Scrum.
Donc Scrum, vraiment, la méthodologie agile qui vient avec.
Il faut raconter, définir tout ça, bien sûr, à un moment.
Et le pourquoi du comment on en parle aujourd'hui, c'est deux choses.
C'est déjà qu'il y a de ça quelques temps, donc c'est bien, ça a laissé un peu le sujet un peu se décanter.
On a eu tout un sujet à propos, vraiment, d'un thread que Maxime a fait justement Twitter.
Donc on pourra aussi en discuter, sans doute, à la fin, de tout l'emballement qui a eu autour de ce thread-là.
Pour parler un peu de comment c'était perçu et comment ça pouvait être vécu de l'intérieur, le fait que Scrum n'était pas forcément adapté.
On va en discuter de tout cette méthodologie-là et de ce qui est son impact.
Et pourquoi dans DevOps, me direz-vous, clairement, c'est parce que DevOps, c'est l'agilité pour l'infrastructure, à la base de la base.
Et donc toutes ces méthodes mises en place, elles font partie un peu de l'écosystème qu'on a autour de nous.
Quand on fait du DevOps, on est souvent lié à de l'agilité et donc lié à du Scrum.
Et je pense que tous les gens qui écoutent ce podcast ont déjà dû, même s'ils ne le font pas forcément aujourd'hui,
ils n'ont pas beaucoup fait, ont dû être dans une équipe qui le faisait de prendre l'aéroport de loin
ou être en lien avec des développeurs qui le savent.
Et donc c'est pour ça que c'est cool d'en parler, puisque ça va permettre de nous apercevoir un peu des liens qu'on peut avoir avec le DevOps
et surtout de la communication et du travail qu'on peut avoir dans des équipes ensemble dessus.
Et donc pour commencer, je ne sais pas si vous pouvez me donner un peu vos définitions du Scrum,
pas telle que vous l'avez forcément vu appliqué pour l'instant,
mais de manière globale, je ne sais pas, Maxence, si tu veux.
C'est compliqué si on entend beaucoup de choses sur Scrum.
Mais globalement, pour moi, le premier but, c'est principalement de faire des cycles iteratifs plus ou moins courts.
Je l'ai vu principalement implémenté en cycle de deux semaines.
Aujourd'hui, j'expérimente la version plutôt courte de une semaine.
Et après, on met beaucoup de choses derrière, mais moi je vais rester sur cette définition très courte, très simple de cycle iteratif,
qui est pour moi peut-être la partie la plus importante et tout le reste des cools de ça, en tout cas pour moi.
Ouais. Et pour toi Maxime, comment tu définirais ?
J'aime bien la définition de Maxence avec les cycles iteratifs, mais bon, pour ne pas répéter exactement la même chose.
Moi, je le vois surtout comme un cadre de travail, une manière de travailler ensemble pour faire de l'agilité,
pour qu'on s'entende tous sur une même manière de faire et que même du coup dès l'entrée,
c'est marqué sur la fiche de poste Scrum, on se voit s'un idée de comment les gens travaillent à l'intérieur.
Bien, j'ai bien cette définition du cadre à l'entrée, au moment de l'embauche. Je trouve que c'est un bon pattern.
Pour être tout à fait encore plus explicite là-dessus, il ne faut pas mélanger agilité et Scrum,
c'est-à-dire qu'un point qui est souvent relevé par certaines personnes qui parlent de Scrum, c'est que dans le manifest Scrum,
c'est pas d'ailleurs un manifest, c'est un guide, je crois, le guide du Scrum, je me suis impuie exactement des termes,
on va avoir tous les coaches qui vont venir nous tomber dessus, mais c'est pas ça le point important,
mais en tout cas il n'est jamais précisé le mot agile dedans.
Il y a le manifesto agile d'un côté qui parle justement de ces cycles littératifs,
de comment on travaille ensemble à un moment donné sur ces cycles littératifs d'apporter de la valeur,
on peut aussi en discuter là-dessus, et le Scrum de l'autre côté qui est donc la méthodologie de travail.
C'est-à-dire comment on fait, maintenant qu'on a dit qu'il nous fallait ces cycles littératifs pour travailler ensemble.
On a des rituels de communication, on a des listes stand-up meetings, par exemple, des DSM qui se passent normalement tous les matins, etc.
C'est encore un autre pattern, c'est une manière d'implementer l'agilité.
Et vous, comment vous l'avez vu appliquer ? Parce que là, on parle un peu, c'est très théorique,
mais on va essayer de rentrer très vite dans le détail et voir après la divergence par rapport à la théorie.
Comment toi, Maxime, justement, tu l'as vu appliquer le Scrum ?
Ah, mal !
Alors, mal, justement, tiens, mal commence, c'est-à-dire mal, dans le sens où ils n'appliquaient pas le bouc ou c'était pénible.
Bah, les deux à la fois, parce que, bon, de ce qui a été révélé par le Scrum,
parce que je ne suis pas un grand connaisseur de Scrum, si tu veux, moi, je l'ai plus subi que étudié.
Donc, pour moi, si tu veux, j'ai découvert des modalités de Scrum avec le Scrum.
J'ai découvert, par exemple, que beaucoup de gens disaient, mais ils faisaient des estimations, Scrum, il n'y a jamais eu des estimations.
Et, globalement, c'était le cas dans la boîte ou je bossais.
C'était qu'il y avait des story points, mais dans leur tête, c'était clair,
un story point, égal à une demi-journée de travail.
Ce qui fait qu'on avait des estimations sur toutes les issues qu'on avait.
Bon, il y avait ça, il y avait aussi le fait que c'était une manière de faire du flicage.
Les délits qui sont censés normalement être là pour s'entraider,
c'était une manière un petit peu de contrôler, de faire le pointage du matin.
Il y avait tout un tas de règles qui étaient perverties, justement,
pour que le Scrum Master devienne plus un chef de projet avec une grosse emprison sur les devs.
Je pense que tu as tué, on a eu à peu près la même expérience.
Je vais parler vite fait de mon expérience, et après, comme ça m'accent, je vais pouvoir m'en dire.
Le Scrum, on l'avait appliqué en...
Déjà, l'agilité, j'en ai entendu parler, on l'a commencé à le faire en 2011, on avait commencé là-dessus.
C'était assez drôle, c'était dans une ESN à ce moment-là,
et en fait, on décidait de faire de l'agilité ou du méthode en V classique en fonction du client.
C'est-à-dire, le client décidait s'il voulait de l'agilité ou du Scrum,
sans jamais parler des équipes, en fait.
C'était pas comment les équipes arrivent à travailler ensemble,
comment elles arrivent à travailler le plus efficacement,
c'était les clients, ils veulent de l'agilité, on leur vend de l'agilité.
Ça, c'était en 2011 là-dessus.
Et en fait, très vite, dès 2012, je suis allé, pour le coup, maintenant,
passer dans des startups pour le faire.
Et là, on a essayé un peu de le faire by the book, c'est-à-dire Blameless,
les DSM, on les faisait debout dans l'endroit le plus pénible de la compagnie,
donc vraiment sous les toits où ils faisaient chaud, le but étant que ça ne dure pas.
Et surtout, c'était accéder le fait de dire, hier rien.
Hier, je n'ai pas eu de problème, parce que vraiment, un DSM, c'était le but,
c'était vraiment de faciliter les échanges au niveau,
surtout, de la pénibilité qu'on avait pu rencontrer,
pas de parler justement de tout ce qu'on avait fait à la veille et nos vacances.
Et en effet, c'était ce qui est arrivé au fur et à mesure que j'ai vu,
au fur et à mesure des entreprises qui est, en tout cas, si on prend vraiment,
si on va essayer de se focusser là, par exemple, sur le DSM,
c'est devenu du flicage, complet.
Le flicage étant devenu le truc de, qu'est-ce qu'on a fait à la veille ?
Et je me souviens même, dans certaines boîtes, de me dire,
le DSM est à 10h30, je fais semblant de faire 2-3 trucs sur un ticket
entre 9h30 et 10h30, et comme ça, je parlerais de ça au DSM
pour résumer tout ce que j'ai fait à la veille, donc je me souvenais pas.
Et donc, en fait, il y avait des espèces de méthodes de contournement comme ça
où on essayait de réfléchir à comment remplir un DSM
sans être pris pour un bon branleur de ce qu'il s'était passé.
Je ne sais pas tout le même sens.
Avant de répondre, j'aurais une toute petite question.
Pour vous, le DSM, il est pour qui ?
C'est j'ai l'impression que dans les deux cas que vous aviez eu,
il y avait un manager ou un PO ou un PM, peu importe, qui était présent.
Et donc, en fait, c'était une façon de reporter ce que vous aviez fait,
du flicage, mais c'était une façon de reporter,
alors que pour moi, je pose une question et j'y réponds même temps.
Donc, je vous laisserai juste après.
Pour moi, le délit, c'est vraiment...
En fait, je n'ai pas à y être en tant que manager,
ce n'est pas pour moi qu'il est fait.
Nous, pour exemple, aujourd'hui, chez Formance, on le fait à l'écrit.
Donc, c'est un bot slack qui passe à 11h30, un truc comme ça.
La personne peut répondre n'importe quand dans la journée,
il n'y a pas de zéro pression sur ça.
Et en fait, ça pose dans un genel slack public.
Et le but, c'est juste que tous les devs soient au courant
de ce sur quoi boss chacun, en plus des tickets,
sur quoi ils ont été bloqués, sur quoi ils ont besoin d'aide.
Mais moi, je réagis jamais, en fait,
si j'ai besoin de savoir sur quoi boss les gens.
J'ai un outil Ticketing pour ça.
C'est censé être là où moi, je ne mets pas de nuit,
mais pas du tout dans le délit.
Et j'ai l'impression que...
En tout cas, moi, c'est comme ça que je l'ai vécu avant,
pareil avec vous sur le flicage, etc.
C'était toujours, il fallait être là, à 9h50,
parce que sinon, ça a empêché que les gens arrivent
à 10h, 10h30 et 11h.
C'est qui arrive assez souvent dans la tech quand même,
en attendant, ça a été plutôt d'arriver tard.
Mais c'était en effet, pour moi, probablement,
totalement un flicage.
Mais c'est là où, pour moi, en fait,
c'est juste que les gens ont pas compris
à qui s'adresse le délit
et à quelle question les gens doivent répondre.
Et je pense que c'est là où
des petites rappelles devraient être faites de temps en temps.
Ouais, moi, je suis entièrement d'accord avec toi.
Si jamais on revient, ce que t'as dit,
à l'heure littérative,
si on revient même à la base du pourquoi c'est DSM,
parce que c'était ça, la question à se poser.
Pourquoi on fait de l'agilité ?
Alors, déjà, pourquoi on fait de l'agilité ?
En fait, je dis souvent,
l'agilité, c'est quelque chose qui devrait pas marcher.
C'est-à-dire, dans la théorie, c'est inefficace.
Parce qu'en fait, on ne sait pas où est-ce qu'on va
et on n'a pas de guide, on n'a pas de plan, on n'a rien.
Il va complètement à poil avec notre couteau,
sans être du tout sexiste,
et on y va juste complètement à poil dedans.
Et à la fin, ça arrive à fonctionner.
Là où, dans une méthode traditionnelle,
on va faire un plan, on va essayer de rester dans le plan
et les 3,5 du temps, on ne tape à côté.
Et donc après, ce qu'il a juste fallu se dire un moment,
c'est que, ok, c'est cool, l'agilité.
Et d'ailleurs, un truc dont on n'a pas parlé,
et c'est d'ailleurs symptomatique du scrum,
c'est que tout est basé normalement sur la rétrospective.
C'est-à-dire, comment on fait pour améliorer
le cycle en cycle, c'est en se demandant
ce qu'on a fait le cycle d'avant.
Et donc en se disant, le cycle d'avant,
on a fait des choses bien ou pas.
Et comment on fait pour améliorer cette chose-là ?
Donc normalement, le nerf, le truc le plus important,
vraiment la cérémonie qui devrait être
l'apothéose de l'agilité,
ça devrait être la rétrospective.
Et ça pour le coup, on la crème,
on peut la faire de plein de façons différentes, c'est cool.
Et d'ailleurs, c'est normalement un point important.
Dans une rétrospective, on fait la rétrospective de la rétrospective.
En se disant, est-ce que cette rétrospective,
c'est bien passé, non, on la change.
C'est un truc vraiment de mouvement permanent
qui devrait exister.
Et en fait, historiquement,
le DSM servait
à avoir juste le chemin de l'aide,
de l'aide rapide, de faire en sorte de pas attendre 2 semaines
pour se dire, on va attendre la rétrospective
pour avoir une amélioration.
Et juste, on se dit, si jamais tu as un coin de blocage,
on doit en parler le plus vite possible
pour le traiter le plus tôt possible.
Et oui, malheureusement,
c'est devenu du process lundan.
Je pense que Maxime, tu...
C'est la réflexion que je me fais par rapport au Daily.
C'est que
nous, déjà, on avait une bord gira.
Donc, je pense que vous avez eu les mêmes,
soit avec Trello, soit avec n'importe quoi.
Donc, la bord classique est qu'étiquée,
on voit ce à signer à qui, on voit ce qui est en course,
qui est en review, ce qui est en validation et compagnie.
Donc, savoir
qui fait quoi à un instant T, on le sait.
Savoir qui a fait quoi aussi en le passé,
au bout d'un moment, on le sait aussi.
Et...
Du coup, mon avis là-dessus, surtout qu'on est outils
et on a des slacks, on a tout ça,
c'est que la Daily, si j'ai un problème, par exemple,
dans mon code, j'ai envoyé un message
sur Slack avec mon problème à la personne
qui, je sais, sera la plus efficace
pour répondre à mon problème.
Et comme c'est de la synchrone,
la personne, une fois qu'elle a le temps de me répondre,
elle me répond.
Moi, pendant ce temps-là, je vais bosser sur un attiquet,
faire avancer le truc d'une autre manière.
Mais, à aucun moment,
je me dis qu'on a l'obligation
de devoir avoir un rendez-vous
à Aurair Fix
pour parler des problèmes,
sachant qu'on peut le faire
en continu durant la journée.
Normalement,
il faut...
Enfin, il faut que ce soit prévu,
il faut qu'on soit tous d'accord qu'il y a un accord testique
pour qu'on se dise.
On a toujours
une période de notre journée
où on va...
J'ai vu un tweet il n'y a pas longtemps
où quelqu'un parlait
de faire de la glu.
J'ai amené à cette expression.
Il faut qu'il y ait un moment dans la journée
où on va faire de la glu pour aller aider les autres
à résoudre quelques problèmes
qui peuvent être mineurs et compagnies,
mais qu'on le fasse tous à un moment.
Pour moi, il n'y a pas forcément besoin
d'une réunion pour le faire.
Je suis assez d'accord.
En fait, je dis d'accord et pas d'accord.
Ça dépend, je pense, énormément
de ton équipe et de la typologie d'équipe que tu as.
Typiquement, quand tu as des profils
plutôt junior ou des personnes
qui sont très introverties,
ça peut être compliqué pour elles d'aller
demander de l'aide comme ça sur Slack
ou alors ils vont plutôt le faire en one-to-one.
Et ça permet d'avoir un moment
qui est un peu sacralisé et qui permet
vraiment de demander de l'aide
ou tout du moins de dire qu'on a eu un problème, etc.
Et donc quelqu'un,
typiquement enjuniant, va pas demander de l'aide directement
souvent, il va juste dire, j'ai ça qui ne marche pas aujourd'hui.
Et si tu vois que ça fait 2 jours qu'il est sur ça,
peut-être que quelqu'un de l'équipe va aller de lui-même
tu vas l'aider,
essayer de régler son problème.
Donc je pense que c'est important de le garder.
Après, c'est plus le format
et l'attention qui est derrière.
Pour moi, c'est ce que je disais tout à l'heure,
dans ce que j'ai vu par des managers
et des PO,
qui ne devraient même pas être invités
parce que ce n'est pas un moment de reporting,
c'est un moment vraiment juste d'échange
dans l'équipe. Et à la rigueur,
moi ça me plairait même que c'est un moment
d'échange même informel,
qu'on raconte notre week-end,
machin, etc.
Moi, ça me mirait dans l'idée, tu vois.
C'est juste un moment informel pour que l'équipe,
que tout le monde puisse dire qu'il a un problème
et on passe sur chacune des personnes
pour être sûr que tout le monde a dit
ce qu'il avait à dire.
Et le moment dans la journée
ne devrait pas être important.
C'est pour ça que j'aime beaucoup le format écrit
par rapport au format présentiel.
C'est que le format écrit, en fait,
empêche le flickage, tu le fais une fois par jour,
que tu me le fasses à 2h du matin,
à 6h de l'après-midi ou à midi.
C'est pareil pour moi, je m'en fiche,
il n'y a pas d'importance alors que dès que tu vas mettre une horaire,
l'horaire, tu vas plutôt le mettre en début de journée
ou en fin de journée.
En fin de journée, c'est-à-dire que tu flics les gens
pour pas qu'ils partent à 15h,
mais ça c'est encore un autre débat
où on sort de ce qu'il y a de l'agilité.
Et si tu le mets le matin, c'est pareil.
Si tu le mets à midi, tu casses la journée en deux.
En fait, je trouve que tu...
En fait, au moment où c'est un moment vraiment
ritualisé tous les jours, et que ça détient
ta lorale, etc., j'ai l'impression que tu casses
dans tous les cas la journée des gens
et que tu ne trouveras jamais un horaire
qui conviendra globalement à tout le monde.
D'où, pour moi, le format écrit qui est beaucoup plus intéressant
et qui permet en plus de remonter
dans les messages, pour voir, ben ouais,
mais là, ça fait deux jours que tu es bloqué, et machin, etc.
Est-ce que tu n'as pas forcément à l'oral ?
Typiquement, quand t'es un frais
quand je faisais des délits avec les devs,
c'est pas que ça m'intéressait pas beaucoup,
mais quand chacun parle pendant
7 minutes, 10 minutes, que t'es 6 personnes,
et qu'en plus, ils parlent
de leurs problèmes de devs qui ne sont pas
toujours des problèmes que moi, je peux faire quelque chose,
ben c'est vrai que...
Tu t'ennuies un peu, quoi.
Donc t'écoutes globalement pas, et t'es déjà en train
de penser à ce que tu vas faire dans le reste.
Et quand, en plus, t'es multi-équipe,
et donc que tu fais plusieurs délits dans la journée,
t'as juste l'impression de perdre du temps, quoi.
Ouais, ça c'est vrai que c'est un point
qu'on n'a pas évoqué, et c'est pour ça
que là, on raccroche un peu le DevOps, là, en fait,
là, tu viens de complètement raccrocher l'un de l'autre,
qui est comment ça se passe,
parce que le Scrum a été prévu pour être
dans une équipe monodisciplinaire.
Tu n'as que des personnes qui peuvent s'entraider.
C'est d'ailleurs, normalement, tout le principe
de faire une user story.
La user story peut être prise par normalement
n'importe quelle personne qui est présente à l'intérieur.
Si elle ne l'est pas, c'est qu'il y a un problème,
et c'est qu'il faut faire de la formation pour aider les gens.
Mais normalement, elle est monodisciplinaire,
et en fait, c'est un one-size-fit all.
D'ailleurs, j'ai peut-être donné aussi un peu de contexte
qui est important à avoir l'agilité.
Ça a été fait par des gens qui avaient l'habitude
d'être en ESN aux États-Unis, en équivalent d'ESN,
en tout cas en projet.
Et en fait, leur difficulté, c'était comment ils parlaient
avec des clients.
Ils avaient besoin d'une méthodologie
pour pouvoir parler régulièrement avec le client
et s'apercevoir des problèmes avant que ce soit tout à la fin.
C'est assez marrant de savoir que l'agilité
a été faite pour les projets
de vente en Régis, globalement.
C'est une méthode de facturation.
C'est une méthode de... Il y a tout ce qui vient avec.
Je facture sur deux semaines.
Je m'engage sur deux semaines.
Deux semaines d'ailleurs, n'importe quel cycle.
Et en fait, très vite, quand on arrive
à ce pattern de...
On a intégré des SRE, on a intégré des
gens de la qualité, on a intégré des gens
du produit. Là, tu as dit, il y a des PO
qui m'insommentent maintenant dedans.
Moi, le PO, des fois...
En fait, à part fliquer, je ne veux pas trop ce qu'il pouvait faire d'autre.
Il va nous parler de certaines choses.
Et c'est con, parce qu'il y avait
un moment où on avait besoin de son information.
Savoir qu'il était allé voir un client,
que le client n'était pas content,
c'est une super information. C'est juste que là,
elle se retrouvait à être noyée,
donc il y a des gens qui allaient perdre 10 minutes de leur temps
tous les jours, 10, si jamais c'était pas plus.
Noyée dans plein de choses.
En fait, en effet, le rétuel de communication
n'est peut-être pas bon.
Ou peut-être qu'il n'est pas adapté.
Ce rétuel-là, il doit être...
Même dans une équipe, on a plusieurs DSM en se disant
vous, vous décidez quand est-ce que vous le faites aujourd'hui
avec un vote, j'en sais rien.
Les devs, vous le faites dans votre coin.
Je ne sais pas.
Mais c'est un problème aussi.
Moi, je vais aller dans l'autre sens par rapport à toi.
Moi, j'adorerais être dans le DSM
des devs.
Même si je n'y bitais rien, parce que en fait,
les 3 quarts du temps, je disais, je suis dans un coin,
je ne parle pas, mais si vous avez besoin, je suis là.
Et en fait, le fait qu'il soit ritualisé,
qu'il soit un moment précis,
pour le coup, là, c'était en présentiel,
me permettait moi d'aller à cet endroit-là.
Pour l'instant, là, j'étais sur mon téléphone, je faisais d'autres choses,
même des fois, je t'étais sur mon PC.
Mais juste de dire, au moins à ce moment-là, vous êtes tous là.
Il n'y en a pas qui sont barrés en réunion, qui ne sont pas là, etc.
Et si vous avez besoin de moi,
sur un problème d'infra,
parce que vous avez eu des problèmes de déploiement
dans la journée, et quoi que ce soit, je suis là.
Et ça, c'est un truc qui était quand même
assez intéressant.
Et moi, j'ai débloqué pas mal de projets en étant,
en étant, on se role là.
Pour moi, tu vois cette posture-là, dont tu parles,
c'est celle que j'aime avoir, à ce moment-là,
quand je fais des délits en physique.
Mais c'est celle que pour moi,
devrais aussi avoir toutes les personnes autour,
c'est-à-dire que le PO, s'il doit venir,
en soi, il doit venir, s'il pourrait répondre
et débloquer la situation, juste en reprécisant
une spake ou autre.
Mais en fait, il faut pas le voir,
enfin, il faut pas que les gens le voient comme un quelqu'un
qui doit reporter, c'est plutôt quelqu'un qui est
à l'arrière de la salle, qui écoute, et qui vient
de te débloquer
quand on a besoin, quoi.
En fait, c'est ça, en fait,
moi, je me présente en tant que support pas en tant que genre,
genre, oh là là, attendez,
vous avez dit que vous avez fait ça
sur le même cache, c'est pas bien
« voyous de devs », c'était genre
en mode, si vous avez un problème,
venez me voir. En fait, c'est un positionnement,
je me positionnais en tant que support,
en tant que être là pour les aider pas
en tant là pour être le gatekeeper
et les empêcher de...
c'était ça la différence. Je t'ai pas obligé
à être attentif à tous les mots en mode, attention,
il y a peut-être un moment, les devs, ils vont faire n'importe quoi.
Et c'est peut-être ça, en effet, la position dont tu dis
« ok, je suis là pour vous aider ». Le centre,
c'est les développeurs, au sens très large,
d'ailleurs, du terme, un développeur, pas juste les gens qui codent.
Mais c'est eux qui créent la valeur, en fait,
en gros, je suis un support des gens qui créent de la valeur.
Donc, le but, c'est la valeur.
Mais dès que t'as pu ce rituel,
comment tu fais ? C'est ça ma question.
C'est encore une plus grosse rituelle.
Ne plus avoir en physique ou tu ne le faisais pas écrit ?
Tu le faisais pas écrit,
mais il n'y a pas ce moment où tout le monde est là
à un moment donné, tu vois, genre, c'est ça...
Enfin, je sais pas, c'est une question, en fait.
C'est vrai ?
Enfin, fondamentalement, c'est vrai, hein.
Il n'y a pas tout le monde qui est là
à un moment dans une pièce, mais est-ce que c'est
fondamentalement grave
quand tu peux avoir d'autres meetings,
d'autres choses, d'autres rituelles
importées, mais
je sais pas, il faut reposer la question
à mes équipes, pour quoi.
Alors, peut-être t'as un autre truc, tu vois,
genre, t'as en amélioration continue, moi, dans ton cas,
ce que je ferais, alors après, c'est peut-être un biais personnel,
c'est je demanderais aux gens de le faire à l'écrit
pour qu'ils soient déjà tous faits.
Et après, je mets tout le monde dans un truc
et je fais, ok, vous voulez commenter un truc ?
Oui, non, non, bah, fin du meeting.
Pourquoi pas ?
Un truc qui me...
Et par contre, à un moment qui ne soit pas
un moment de flickage, en effet, tu vois, genre, c'est...
Et si les gens ne sont pas là, c'est pas grave.
Le truc, c'est que
après, là, on parle dans le cas où la team, elle est que
sur des contraintes horaires identiques.
Dès que tu commences à avoir des teams qui sont
répartis sur plusieurs plaques géographiques,
normalement, on essaie d'éviter, on essaie
d'éviter de construire une team
qui a plusieurs time zones différentes.
Mais bon, on sait tout ce que ça peut arriver.
Là, tu rentres dans un cas où
si tu as un mec à San Francisco,
bah, à part faire ton délit
à minuit pour toi, heure française,
ou minuit pour lui, heure
à San Francisco, globalement,
tu n'as pas beaucoup de moments
où tu vas te recaler.
Et c'est là où ça peut
globalement devenir compliqué. Mais sur le principe,
ce n'est pas censé exister, donc...
Je pense qu'il faudrait poser la question aux gens
qui font que par écrit
pour voir est-ce qu'ils aimeraient un moment
plus live pour en discuter ?
Et toi, Maxime, je crois que tu avais eu
cette expérience, justement, en off-short.
C'est pour ça que c'est une bonne expérience.
Justement, on a testé
les deux formules.
On a testé avec
les réunions
en
visio, du coup, à un instant T.
Il y avait un gros décalage horaire, donc
c'était toujours très compliqué. En général, ça ne faisait que
pour nous,
c'était 21h et pour les autres,
c'était, je crois, 8h
ou 9h du matin. Donc
c'était pas idéal
ni pour l'un ni pour l'autre, mais
c'était compatible. Mais c'est un modèle
qu'on a décidé
d'abandonner assez rapidement, au moins
pour les Daily,
où on est passé sur un mode
du coup asynchrone et par écrit,
donc on avait plus sur les tuels du Daily.
Néanmoins,
le rapport
asynchrone qu'on devait
produire, c'était pas
est-ce que j'ai eu un problème aujourd'hui, c'était qu'est-ce que j'ai fait hier.
Et ça, c'est un autre problème.
Oui, ça c'est le reportage
dont on parlait.
Et d'ailleurs, quand on parle de reportage,
de ce que j'ai fait, moi un autre problème
que les DSM
que j'ai vécu, on a un peu parlé,
c'est les points.
C'est vraiment les points de complexité. Déjà,
on va prendre les UserStories.
On va prendre déjà un premier
point d'un moment. La UserStory,
je n'ai jamais rarement vu en tant que UserStory.
C'est-à-dire que j'ai vu quelque chose
en mode, il faut changer la version d'Apache.
Ou je n'en sais rien, enfin,
il faut avoir
tel truc. En fait, j'ai rarement vu
quelque chose où je vais donner de la matière
à
enfin, je vais apporter de la valeur
à un client. C'est ça une UserStory.
Je vais apporter de la valeur. Un User a besoin
de faire ceci, je vais apporter de la valeur.
En fait, c'est quasiment
jamais vu. Je ne sais pas, vous...
Côté
infra, en fait, c'est compliqué.
En fait, ton client, c'est
Tedef, globalement.
C'est rarement le client final de la boîte.
Donc, ça va plutôt être...
Dans UserStory, ça serait plutôt
l'équipe Bato a besoin
d'un nouveau Ré10
en version 7 pour répondre
à tel et tel et tel et tel problématique.
Mais souvent, ça se traduit plutôt en
un Ré10.
T'as pas le contexte, t'as pas tout ça.
Et la UserStory, c'est fait normalement
plus pour donner du contexte. Je l'ai vu plutôt
côté Dev. Mais souvent, c'est pareil.
C'est que c'est long à écrire, c'est long à rédiger.
Donc, globalement, les gens vont
souvent au plus court par manque
de temps, en fait.
Et donc, c'est pas souvent respecté
le principe de la UserStory en est
même. Je l'ai rarement vu respecté
en tout cas longtemps.
Ouais, je sais pas. Moi aussi, mais me me laissais
même pas sur le temps. Tu vois, c'est vraiment...
En fait, là par exemple, ton Ré10,
moi, j'aurais commencé par la fin.
J'ai fait pour pouvoir
scalez l'application X,
ils ont besoin d'un Ré10 à la version.
La UserStory, en fait, elle s'écrit dans l'autre sens.
En fait, c'est ça, le principe de la UserStory,
c'est de dire d'abord, je mets en valeur.
Et c'est juste de la mise en valeur. Ça peut être juste dans le titre.
Une UserStory, c'est pas
en tant que je dois faire ceci et j'ai un
template de trucs que j'ai sur Gira et que
personne n'a jamais utilisé. Au final,
tu mets 3 lignes au début.
Non, tu vois, c'est vraiment juste le positionnement.
Je donne de la valeur.
Et surtout, je me posie
en tant qu'un produit. Et ça, on en fera.
On sait pas faire, mais en vrai, on pourrait le faire.
Une équipe de Ré10 à
ce service, enfin,
de n'importe quoi, des BAS de service,
installation à la service,
n'importe quoi. C'est juste, tu es dans une notion
de service avec une notion de client.
Et tes clients,
le client est roi, j'aime pas du tout cette expression
là, mais c'est un peu ça.
Or, si aujourd'hui, tu écoutes une équipe
d'ailleurs, de n'importe quoi,
une équipe d'Obs, elle va détester les devs,
une équipe de devs, elle déteste les clients, etc.
Et tu as un truc qui a un rapport d'amour N
en permanence, enfin,
dépendance N en permanence.
Et ça, pour le coup, je l'ai rarement vu.
Et donc, ça inclut le fait que
si jamais personne, il voit de la valeur,
parce que tu me dis,
ok, il faut mettre à jour le Ré10,
clairement, pour quelqu'un du produit, il va être là
en mode, en fait, tu me les casses les Q,
il y a avec ton Ré10, donc fais le VIT.
Dis-moi quand est-ce qu'il est fini pour qu'on passe à de la vraie valeur.
Tu vois, c'est ça, en fait, l'endalement, souvent,
que j'ai vu.
Côté Infra, tu as déjà rencontré
une vraie vision produit de l'infra.
Moi, la plupart des cas que...
où j'ai été, en tout cas,
l'infra était plutôt toujours en réaction,
qu'en mode, on a une vraie vision produit
d'une plateforme avec des services qu'on délivre, etc.
Moi, ça a toujours été plutôt en mode.
Au fait, l'équipe 2,
elle a créé un nouveau produit
en ODE,
et ça serait bien quand même que
pour la fin de semaine, soit demain,
elle soit dispose
sur le cluster cube,
avec telle version de PostgreS,
et c'était plutôt comme ça, en mode réactif
pompier, que en mode
vraiment produit avec une vraie vision,
avec la création d'une plateforme, etc.
Et je pense que ça, c'est de là le fait
que les user stories ont pas beaucoup de sens,
en tout cas, le côté infra de ce que moi j'ai vu,
parce qu'en fait, on est en mode réactif
et pas en mode construction d'un produit, d'une plateforme, etc.
Alors, je vais répondre, j'essaye d'aller vite pour pas
te mettre dehors, Maxime,
de la discussion.
C'est...
Moi, j'ai vu apparaître, j'ai essayé de faire ça,
notamment, j'ai fait une plateforme de Kubernetes as a service
chez Tales.
Et en fait,
on a poussé le bouchon assez loin, on n'était que 3.
On a poussé le truc assez loin, c'est que déjà un,
on a donné un nom, un nom qui n'est pas un acronyme
merdique, mais on l'a appelé
armateur,
donc c'était le projet armateur, parce qu'en fait, on prenait
des porte-conteneurs qui...
Enfin, en fait, on gérait des porte-conteneurs qui avaient des compteurs qu'on connaît pas.
Notre métier, c'était d'être un armateur
de porte-conteneurs,
qui sont les Kubernetes qui portent des conteneurs.
Et on a créé un logo.
On a créé les stickers
qui vont avec. On a créé
les... On a créé vraiment
tout le branding, etc. qui allait avec tout ça.
Une user expérience
qui allait. On avait
des rituels
avec notre PO.
Tous les gens qui utilisaient notre plateforme, on les invitait
une fois par mois, dans une salle
pour qu'on fasse le reporting de
qu'est-ce qu'on a fait,
qu'est-ce qu'on a fait, qu'est-ce sont les choses qui ont été
apportées à la plateforme, qu'est-ce que AKS
a fait, etc. Et que les gens puissent discuter après pour nous
donner leurs feedbacks instantanés.
On était allés jusque là.
Et alors après, dans un
autre point qui souvent revient dans les
problématiques qu'on a en scrum, dans l'infrastructure
et donc ça doit être des fois la même chose
pour le dev, c'est
on n'a pas le temps. C'est-à-dire que un cycle de
deux semaines n'est pas assez long. On n'arrive pas
à gérer les bugs,
gérer les choses comme ça et gérer le
le...
gérer le délit en fait. On a vraiment
une décorélation là-dedans.
Moi déjà, ce qu'on avait fait, je dis, on
est vraiment tous les tips qu'on a fait dans cette
expérience là parce qu'elle est vraiment symptomatique.
Déjà, moi ce que j'ai dit, c'est que
la charge des user stories,
enfin la charge de l'implémentation de
nouvelles fonctionnalités ne doit pas dépasser
50% du temps total de l'équipe.
50% doit rester sur
le run, etc.
On ne peut pas m'en vouloir si jamais
j'ai délivré que 50% du temps. Enfin, c'est pas
un problème. Je ne dois pas remplir
le temps de tout le monde en user stories
permanentes. Si quelqu'un arrive en délit et dit
ben non, mais hier j'étais sur du
correction de petits bugs, correction
de choses comme ça, etc.
C'est tout à fait valide.
La deuxième chose qu'on a fait, c'est qu'on a
supprimé tous les points d'estimation.
On avait un truc où la boîte,
l'équipe, elle estimait des points, genre
à 35, 37, un truc comme ça. On était
à une moyenne de 37 points. Et en fait,
à chaque fois, on délivrait genre 20.
Et en fait, c'était vraiment, il y avait les managers
au-dessus qui étaient dans une frustration
totale parce qu'ils avaient l'impression qu'on ne bossait pas.
On disait qu'on allait faire X
et en fait, on se retrouvait à faire moins.
Ce que j'ai fait, c'est que j'ai dit, non, non,
ce qu'on va faire, c'est qu'on va prendre les user stories
et on va prendre que 5. Quel que soit la taille
de la user story, c'est 5.
Et toutes les user stories ont 5 points.
Comme ça, on délivre 25.
Et tous les sprints, on délivre 25.
Donc en fait, j'avais complètement pété le modèle, en disant, vous voulez des
estimations, ok, c'est 5. Vous avez le choix
de la couleur du monde que... voilà.
Et en fait, ils étaient super contents. D'un coup, ils étaient là,
on va dire, oh putain, votre burn d'orne,
enfin, votre
votre résumé à la fin du sprint,
c'est super cool.
Et après, en plus,
pour pouvoir gérer un problème
qui est souvent, comment on fait
de la
perspective, comment on fait pour...
parce qu'en fait, on arrive au début du sprint et on nous dit, voilà,
il va falloir faire un nouveau système d'orchestration.
Comment tu t'engages là-dessus alors que t'as pas commencé ?
Donc en fait, comment tu fais cette phase
de perspective sur les
sur les
sur les évolutions. Et en fait, nous,
on a... j'ai appliqué un système
qui vient de... un peu de Intel
ou avec ces processeurs, ce qu'ils font toujours,
c'est qu'ils font une phase d'amélioration
de l'architecture, mais en gardant la finesse
et ensuite, ils améliorent la finesse.
Donc en fait, une architecture Intel, c'est ça, c'est un système
de TicToc, ils appellent ça comme ça, alors c'est plus le cas
maintenant, mais à l'époque, c'était comme ça.
Où on fait une phase de... de
nouvelle technologie
de fondries, donc on est en Tic
et là, c'est un nouveau processeur, mais avec la même archi qu'avant
et une phase où on garde la finesse,
mais on change l'archi. Et donc, comment on a
fait ça, nous, en place, c'est qu'on avait...
on avait dévisé le sprint en 2 semaines
et
je vais commencer par la 2e semaine. La 2e semaine
était de la prospéctif, c'est-à-dire que là,
dans la 2e semaine, on se mettait à
à chercher les sujets
pour la prochaine. En fait, on était vraiment en train
de tester des solutions, en train de les expérimenter,
etc. Comme ça, on arrivait au moment
du sprint planning, en se disant
OK, maintenant, qu'est-ce qu'on peut faire ?
Bah, ça tombe bien, on l'a déjà fait avant,
voire on a déjà expérimenté.
Donc, ça, à peu près, on peut s'engager.
Ou alors, on dit non, non, là, c'est pas sec.
On continuera la semaine d'après.
Donc là, on fait un engagement
directement comme on a déjà bossé dessus, en fait,
en 1 semaine, c'est torché.
Donc, pendant la 1re semaine, on torche tout.
La plupart du temps, d'ailleurs, c'est écrire de la doc,
déployer en production, etc.
Et après, on a la 2e semaine,
qui revient un cycle d'iterration,
où là, on peut soit fixer
les problèmes qu'on a intégrés
à la semaine d'avant, soit faire la prospective
pour le sprint d'après.
Et en fait, on divisait notre semaine, mais vraiment,
il y avait des fois, en plein milieu d'un poc,
on pouvait arrêter le vendredi en disant
le lundi prochain, on le reprendra pas,
parce qu'on se va se mettre sur
mettre en place des fonctionnalités.
Et donc, on faisait un système de TikTok, comme ça, en permanence,
dans notre sprint de 2 semaines.
Ça se voyait pas de l'extérieur, mais on avait ça.
Et ça nous faisait d'ailleurs un burn chart génial,
parce que quasiment, au milieu du sprint,
on avait déjà fixé toutes nos your stories.
Ou alors, il restait à le faire valider
par le PO, ou un truc comme ça.
Mais en fait, on avait une phase de genre
ultrasynchron de la première semaine,
on délivrait à fond de la première semaine,
et après, on était dans de la seconde semaine.
Mais on faisait un système comme ça.
Je te donne un exemple de comment c'est possible de faire.
On a été viré pour avoir fait ça, donc,
au final, ça n'a pas marché, mais
c'est comme ça qu'on peut le faire, en tout cas.
En tout cas, ça marchait, nos clients étaient cool,
on a été viré pour d'autres raisons.
Donc voilà, je ne sais pas si ça répond
en partie à une possibilité, là-dedans.
Toi, je ne sais pas toi, Maxime,
t'es plus orienté, Dave, donc peut-être
tu vas peut-être pouvoir nous donner tes feedbacks
là-dessus, de comment t'es orienté
en tes sprints, tes user stories ?
Nous, au final, on était
plus...
On était plus
à consommer
l'éthiqué
sans avoir de responsabilité
sur la manière dont c'était fait,
coachoz. Mais
nous, ce qui s'est passé d'un point de du dév
c'est que
ils étaient aussi très contents
de voir un beau
burn down chart, et ils n'en avaient rien à foutre du reste
ce qu'ils voulaient, c'était voir de l'évolution, de voir
que... on faisait
tous les story points qui étaient prévus
et qu'on
n'accumulait pas de retard.
Mais
d'un point de vue Dave,
nous, on était dans une frustration totale
de voir que
la qualité du code baissait au fur et à mesure
que la dette technique est l'augmenté
que malgré nos
plaintes, à dire il faut
faire quelque chose, là il faut arrêter de délivrer
de nouvelles features, parce que
les pieds d'argile, ils vont bientôt s'effondrer
on a une base de code
de plus de 100 000 lignes de code
qu'on n'arrive plus à maintenir, chactiqués
de plus en plus long, parce qu'il faut refoutre
les mains dans le caca
et c'est pas très agréable
à chaque fois.
Et ce qui fait que
sur la fin, le moindre fixe
de 10 lignes de code prenait une journée
entière, parce qu'il fallait déjà trouver
l'endroit où il fallait intervenir
et
essayer de maintenir un peu tout ce qui
pété en tous les sens dès qu'on touchait
à la moindre ligne de code.
Mais
côté PO, côté SCOM,
c'était content parce qu'ils avaient des beaux tableaux
avec des titres qui avancent.
Tu mets un point là-dessus
plus que ça, c'est la métrique
en fait. C'est à dire que par exemple
une dette technique, personne sait mettre une mesure
sur une dette technique. Alors qu'il y a un burnchart, c'est
une métrique. Et le grevette c'est
on ne peut changer que tout ce qu'on mesure
et en fait le problème, tête
de l'agilité, enfin en tout cas du scrum
c'est ce qui a marché d'ailleurs, c'est qu'on a
su mesurer l'avancée d'une équipe
bah cool. Et donc
en fait, comme on ne mesurait pas
certains points, on ne pouvait pas les améliorer.
On ne peut pas les améliorer. Et le scum, pour le coup, parle pas de ça.
Il ne te dit pas la fatigue de l'équipe,
il ne te dit pas
le moral de l'équipe, il ne te donne pas tout ça
en fait. Donc si c'est pas mesurable,
c'est pas quelque chose sur lequel tu peux
influer. Et c'est peut-être ça
le problème de ce qui a paru
l'un de l'autre.
Et je ne sais pas s'il y avait d'autres points
que tu avais soulevés lors de ton shred
dessus.
Alors on va faire comme ça, tu pourras
plus t'expliquer plus longtemps que
seulement sur Twitter.
Je pense qu'un gros sujet c'est
les estimations.
H-tag, ça ne devrait pas exister, il devrait y avoir
que de la complexité.
Ouais, bah c'est
là-dessus. Bah c'est pour ça d'ailleurs qu'il y a
des comptes Twitter, noestimate
avec que du bashing de l'estimation
des tickets, tellement c'est
ça. Mais je ne sais pas d'ailleurs comment vous l'avez vécu
ça, qu'est-ce que vous perles un peu, de ce que vous avez
vécu dans les estimations.
Moi, c'est le cas
classique de, on est convié
à venir un, je ne sais plus comment
s'appelle la cérémonie des
estimations. Pocher planning.
Ouais, sauf qu'on ne l'appelait pas Pocher planning, mais c'est
exactement ça dans la définition
de Scram. C'est qu'on était invité du coup
à cette cérémonie, mais on découvrait
du coup
le ticket
à ce moment-là.
Et on me demandait, bah voilà, du coup
toi, combien de temps tu penses que ça prend.
Alors que c'est une fonctionnalité qu'on
découvre, on a
une idée, parce que avec l'expérience, on sait
à quoi ressemble le code, on a une expérience de
on a une idée de
où ça va devoir se brancher, lorsqu'il va falloir
faire pour le faire les compagnies, mais
sans avoir directement le néant le code
c'est un petit peu du petit faux maître
d'une journée et cinq.
Il va falloir faire des refactos
et compagnies.
Mais du coup, on se retrouvait
tous
un peu
interloqué à chaque cérémonie
à dire, bah c'est qui là,
allez disons, trois.
Mais c'était à chaque fois du pif, seulement
c'était
ce qu'on a compris plus tard, c'est que
ce chiffre qu'on donnait là, c'était un engagement.
Parce que plus tard, on allait nous dire, mais t'avais dit
trois, pourquoi ça fait quatre ?
Pourquoi ça a pris cinq jours, au lieu que t'avais dit
que en un, ça serait possible que ça passe ?
C'est ça, c'est exactement ça.
Et bah, pour répondre à ça
enfin
nous, on peut juste
relever le problème en disant, bah
on a découvert le ticket, forcément
une fois qu'on est dans le code, on se rend compte
qu'il y a d'autres choses à faire. À chaque fois, on pouvait
justifier sur le, bah j'ai dû refacte tout ça
euh
c'était
c'était pas évident, parce que c'était du code complexe
du vieux code qui avait été fait il y a
un an et où il a fallu
retravailler dessus
parce que c'est même plus au standard de ce qu'on fait
maintenant. À chaque fois, on avait
moyen de justifier
nos retards
qui était plus, le temps
qu'il fallait pour le faire qu'un retard
mais c'était pas forcément
écouté pour les
les gens qui nous écoutaient, c'était plus du blabla
d'heves pour se justifier d'un retard
alors que
juste c'était ce qu'il avait à faire.
Dans ce cas là, enfin j'ai vécu par rien
comme toi, l'estimation pure
et jusqu'au jour où je suis arrivé
quelque part, où on faisait du no-estimate
ce qui pour moi était une érésie
au début, monsieur quand tu connais pas, tu dis bah
si j'estime pas, comment je sais
si je suis bon ou pas bon, quoi, entre guillemets
et j'ai oublié de là où je voulais en venir
mais c'est pas vrai que je rattrape sur un autre
morceau. C'est pour moi l'estimation
je l'ai dit un peu tout à l'heure mais ça devrait pas
exister en fait, comme tu dis Maxime
se projeter sur combien de temps on va
prendre une tâche, tu dis la tâche
les meilleurs arrivent à peu près
à dire ça va prendre
extents, mais en fait déjà c'est un truc
très personnel, parce que chaque développeur a
une capacité à délivrer qui est complètement
différente, ce qu'on est censé
appeler la vélocité personnelle
puis après la vélocité de l'équipe
mais c'est le mot que je préfère, la complexité
d'une tâche, c'est
une tâche très peu complexe
veut pas dire qu'elle sera très rapide à faire
parce que typiquement je te demande de changer
le nom d'une variable dans toutes tes bases de code
ça peut être très long, bon on est d'accord
qu'un search in retrace peut certainement
faire le taf sur une grande partie
mais dans l'idée, quelque chose de très simple
peut être très long à faire et inversement
mais c'est où je préfère
plus en fait parler en termes de complexité
en termes de taille de t-shirt ou de choses comme ça
mais
si je me place de l'autre côté, du côté manager
manager slash chef de projet
c'est pratique de savoir que
dans le sprint j'ai
12 tickets, c'est 12 tickets
on va dire ils sont tous calibrés à une journée
de travail, je sais que j'ai besoin
de 12 OTP
pour livrer mon sprint
sur les deux semaines
et c'est bien, c'est facile
ça permet de savoir est-ce que l'équipe est bonne
je comprends les points
d'un point de vue chef de projet, suivi de projet
manager etc
mais en fait ça marche pas
les estimations seront toujours fausses
c'est comme ça qu'on arrive après
à des moments où on dit tu prends
l'estimation d'un dev, tu fais x3
et tu t'approches de la réalité
mais est-ce que c'est une bonne solution
en fait j'ai pas l'impression qu'il y ait une bonne solution
sur les estimations slash complexité
qui permettent réellement d'avoir
que tout le monde soit contenté
même la question que je me demande à chaque fois
tu comprends d'un point de vue manager
en fait c'est la compréhension
d'un point de vue manager qui a besoin de manager
mais genre quel est l'apport pour l'entreprise
quel est l'apport pour le projet, quel est l'apport pour le produit
dans la valeur, en fait en gros
le point de vue historique de l'agilité
du scrum c'est de se dire on va essayer
de maximiser
l'apport de valeur pour le projet
et en fait aujourd'hui on en est vu
à un truc où on a des gens, des rôles
qui reviennent
à leur vieux démon on va dire
qui est de faire du report pour du report
genre quel est l'apport pour le projet
que le manager sache qu'il faut 4otp
pour telle fonctionnalité
tu vois c'est sur
à part
enfin et en plus il y a un point aussi important là dedans
et peut-être ça c'est le problème qui a eu dans les organisations
c'est qu'en fait souvent
moi j'ai vu des gens qui faisaient des rétrospectives
d'agilité
en disant ce qu'elles allaient faire dans le sprint d'après
elles parlaient jamais de ce qu'elles avaient fait
on avait quelque chose où on était alors
dans les deux prochains mois on va bosser sur
Tartampion et Tartampion dans les deux semaines
on va voir apparaître ça etc etc
et c'était les managers en fait qui disaient ça
les PO en fait adorent parler de
ce qu'ils vont faire pas de ce qu'ils ont fait
c'est un truc
vraiment ça permet de
d'envoyer du rêve etc etc
et clairement
en fait quand on a commencé à envoyer du rêve
il faut derrière que les équipes elles fassent
et donc c'est pour ça que les gars ils te sortent à chaque coin un gant
ils ont tout le temps un gant
soit dans leur tête ou mis dans un papier
sur leur poste là dedans
mais ils ont un gant ils disent alors
à tel moment un gant ou une roadmap
mais c'est pareil si tu as une roadmap
tu peux pas faire de l'agilité
parce qu'en fait c'est à dire que à n'importe quel moment
tu as déjà mis dans le marbe, tu t'es engagé en mettant des dates
des chiffres, des estimations
à un endroit et en fait eux ce qu'ils veulent
c'est retomber là dessus en fait c'est des gens qui c'est des procsis
agilité
méthode en v
c'est ça leur truc en fait et en fait ce qu'ils font c'est de l'interprétation
en permanente de ce qui est dit pour dire
ok dans mon gant ou est-ce que j'en suis dans ma petite barre
est-ce que je serai en retard sur leur roadmap que j'avais dit qui serait
et il est là le problème
en fait pour moi le problème c'est que l'organisation peut-être l'équipe est passée agile
mais l'organisation au sens très large
même l'organisation et les mentalités
n'y sont pas passés
c'est à dire que personne n'est capable d'assumer
le fait que tu ne sais pas
quand est-ce que va pas sortir une fonctionnalité mais tu sais qu'elle va sortir
et tu sais qu'elle sera bien et tu sais qu'elle sera sortie
le plus tôt possible
ça aurait pas eu pu être avant
c'est là ou...
non j'allais dire
c'est bien que tu souviens de ce point
parce que c'est un truc dont j'avais très peu effleuré
le sujet dans le thread
c'est que
les roadmap existent parce que
t'as tout dans une team de commercial qui vend des
features à des clients et des clients qui attendent du coup leurs features
et le problème
c'est que souvent on les contrats, t'as une date
des fois
c'est une fourchette, ça va être dans 3 à 6 mois
mais du coup
dans la roadmap est ajoutée
support de machin ou
truc, voilà dans 6 mois il faut que ce soit fait
et forcément
ça redescend jusqu'au niveau du dev
où on te dit
tu ne vas pas pouvoir t'occuper de ça parce que
il y a cette fonctionnalité qui a été vendue
qui doit sortir dans les 3 mois
donc maintenant faut la faire et puis après
il faut qu'elle passe en test
il faut qu'elle passe en prod
mais
oui en fait fondamentalement
de base
il faudrait vendre au client comme tu dis
un truc, il y a une fonctionnalité qui va arriver
on ne te dit pas quand, tu peux déjà payer pour
et tu l'auras quand elle sera prête
et nous on s'engage juste sur le fait que ce sera
le plus rapidement possible
si vous inversez le
problème, là
c'est dans le monde un peu idéal
si vous vous placez vous en tant que client
vous n'avez pas envie
d'entendre que la feature sera
disponible un jour
et que en attendant je vais payer pour
cette fonctionnalité, je vais avoir un jour
ce que je veux en tant que client c'est que tu me dises
cette fonctionnalité je l'ai à telle date
et puis je reviendrai de voir ce jour-là
à telle date en disant bah elle est où ma feature
et c'est là où
ce n'est pas que commerce
c'est produit, c'est un peu toute la boîte
la roadmap je pense
et je trouve aujourd'hui
importante pour donner la
vision, après
une roadmap, il y a une différence entre dire
je vais te livrer le 28 janvier
et je vais te livrer Q1
bah c'est Q1, ça te laisse un delta
de 3 mois
pour livrer ta feature
là où quand tu donnes une date fixe
bah c'est une date fixe, tu ne peux pas avoir du retard
et après je pense que ce qui
est malheureusement pas assez nul en avant
c'est que le produit
réfléchit à sa feature
dans une version idéale
mais après quand tu as des contraintes
fortes de date
rien ne t'empêche
de quitter des features
dans ta feature pour justement
sortir un MVP le plus tôt possible
de ta feature et c'est souvent ce qui est oublié
c'est que on veut tout de suite
une feature complète qui fait
tout
alors que au final
juste un tout petit besoin simple
de base un MVP
aurait suffi
et souvent ces MVP là tu es capable de les sortir
très très rapidement
en quelques jours voire quelques semaines
tu es capable de poquer un petit truc
qui aura peut-être plein de problèmes, qui ne marchera pas
il faudra recoder complètement dans quelques mois
mais les learnings que tu auras eu sur ça
ont une valeur inestimable en fait
et je pense que c'est là
où en fait les équipes sont globalement désalignées
et les besoins sont désalignés entre
le produit
l'atech
qui est souvent un des gros alignements
puis après on voit les commerciaux qui vendent des choses
mais les commerciaux ils n'invendent pas des choses à vendre
c'est qu'on leur a dit
quelqu'un a dit quelque part que
dans la round map il y avait telle feature
tel nouveau produit qui serait disponible à telle date
donc forcément les commerciaux
ont besoin de faire plus de chiffres
et donc ils vont se mettre à vendre cette feature là
et après en fait
c'est un manque de communication entre tout le monde
tu souligne aussi un point
là dedans
c'est comme ça souvent
que je le décrivais
la différence entre la vision américaine
et française d'un produit
c'est qu'en France on considère
qu'un produit est sortable
c'est à dire qu'on peut
le présenter à des clients quand
toutes les fonctionnalités sont là
clairement un truc où tu ne peux pas
présenter quelque chose si il n'y a pas tout ça
j'ai déjà vu des projets où en fait en permanence
il y avait toujours une nouvelle chose qu'il fallait rajouter
on disait on peut pas sortir ça
regardez là vous bosser dans le prochain sprint
vous rajoutez tel truc et regardez après
c'est bon on pourra le sortir on pourra le sortir
donc en fait tu en trouves avoir des retards permanents
juste parce qu'il manque toujours un truc
il y a toujours un PO qui a une idée
de rajouter un truc magique en disant non non
mais voilà quand on va le sortir vous allez voir
avec ça c'est bon
on découvre le monde
on va devenir type jobs
enfin on va devenir le nouveau apple
là où aux états unis
le but c'est de sortir quelque chose qui est par contre
qualitatif et c'est l'exact opposé
c'est à dire une fonctionnalité
avec rien ou quasiment rien
mais par contre une expérience utilisateur
qui est magnifique, expérience utilisateur
dans la limite des fonctionnalités
disponibles à ce moment-là
et en se disant qu'on va dans
une grille en fait qualité fonctionnalité
en France on va être dans très peu de qualité
un MVP ça va être très peu de qualité
beaucoup de fonctionnalité, au St-Unis ça va être
une grosse qualité très peu de fonctionnalité
et la différence qui va se jouer ensuite
c'est l'évolution, c'est à dire comment on va évoluer
à partir de ça
et en fait si jamais on a déjà plein de fonctionnalité
avec une très basse qualité
ça veut dire beaucoup de techniques, des intérêts de connexion
entre les produits qui sont compliqués
des choses qui ont été fait entre eux dont on n'a pas forcément besoin
tu l'as dit on n'a pas eu de retour utilisateur
et nous on se retrouve dans un principe
où et je l'ai vu dans beaucoup d'équipes
avec un backlog long comme un bras
enfin vraiment avec un truc où
le backlog est gigantesque
avec à chaque fois que quelqu'un rajoute quelque chose on est en mode papap
on a un backlog énorme, on sait même plus pourquoi il était dans le backlog
on sait même plus pourquoi quelqu'un en avait besoin
et on se retrouve à voir quelque chose où
il y a une chape de plomb permanente sur l'équipe
qui est la taille du backlog, c'est vraiment
un truc gigantesque
là où quand on a fait de la qualité
et qu'on a très peu de fonctionnalité
en fait on a un backlog assez léger, c'est à dire qu'on a peut-être
un peu de choses comme ça et en fait on va réfléchir
seulement au moment au début
en fait c'est zéro backlog, en fait tu vois plus que nos estimats
moi chez nos estimats il y a une no backlog
pas de backlog, je me fout de ton backlog
ce que je veux c'est qu'au moment où on se lance
là on réfléchit à ce qu'on a besoin pour le sprint d'après
qu'est-ce qu'on va rajouter dedans
qu'est-ce qu'on a besoin tout de suite
pas y a 6 mois pour dans 2 jours
c'est aujourd'hui de quoi on a besoin
et en fait comme ça ça permet d'avoir
une chape beaucoup plus légère
même sur l'équipe
ça met moins de pression je trouve là-dessus
et en fait c'est vraiment une vision de qu'est-ce que ton MVP
comment tu le vois, comment tu le perçois
je sais pas
je pense que Claude Ballon
c'est quand on a les boîtes grossisses
elle oublie ce que c'est qu'un MVP
et elle oublie que un MVP
c'est pas juste quand tu es une boîte secret
et que c'est en fait
toute nouvelle feature
ou tout nouveau produit on peut peut-être
élargir un petit peu, tout nouveau produit
qu'une boîte veut proposer
devrait commencer par un MVP
avec ce que tu disais
de la vision américaine, je suis plus dans cette vision là
dire une feature
peut-être deux features
mais avec une UX, une expérience
de fou
mais je suis d'accord avec toi
que c'est pas ce qu'on fait forcément aujourd'hui en France
même si ça change, tu regardes les startups
qui se lancent ces dernières années
elles ont quand même une culture produit qui est beaucoup plus présente
que ce qu'on peut voir dans les grands groupes français
après c'est pareil
un grand groupe français a pas les mêmes choses
ce que tu vas refaire dans des sujets de budget
dans des sujets de
roadmap, de vision
sur 5 ans, de mouvement, de qu'est ce qu'ils vont faire
de machin et là tout de suite en fait
tu te tires une complexité qui est énorme
et qui ne peut pas disparaître
en rajoutant 20 millions de couches de manager
ça ne fait que ça
ça m'a augmenté
et c'est là où je pense dissocier aussi les deux
c'est que
tu as des choses que tu pourras avoir dans une petite boîte
et que tu auras beaucoup plus de mal à retrouver dans une grosse boîte
parce que tu as l'actionarien qui veut des choses
tu as l'actionarien qui veut une vision
sur des chiffres pour savoir que
l'année prochaine tu feras plus de 20% de croissance
parce que si tu ne fais pas de chiffres minimum
c'est pas bien
etc etc et donc forcément
derrière quand tu sais que tu veux faire une croissance à 2 chiffres
que tu fais déjà des milliards de chiffres
c'est pas facile de faire 2 chiffres de croissance
et donc pour le coup
derrière oui tes devs ils vont être sous pression
parce que tu vas leur demander
une feature et en fait ta feature
c'est pas une feature
c'est un truc énorme tout de suite
et c'est là où tu te retrouves avec des équipes de 100 def
pour développer ce nouveau projet
etc etc et ce cas là en fait
tu ne le retrouves pas ou peu
dans les startups bah si elles sont
j'en reviens à mon point de tout début mais
beaucoup plus iteratifs dans leur approche
avec une recherche de boucle
de feedback qui est beaucoup plus courte
c'est vraiment un mode tenait on a fait ça
dites nous si vous en pensez
ok en fait les gens
c'était pas exactement ça qu'ils voulaient
et ils y ternt, ils y ternt, ils y ternt
jusqu'à trouver le produit
qui correspond au marché qui est la cible
là où des groupes plus important
en fait ne sont pas du tout dans cette vision là
tu le vois de façon avec
le site de ta banque par exemple
le site de ta banque à aucun moment il est 8x
il a été pensé par quelqu'un
quelque part dans un coin
ils ont mis 2 ans ou voire 4 ans à développer
ce truc là ils l'ont poussé en prod
enfin je sais pas si vous avez suivi
c'était
le credit agricole qui a poussé
une nouvelle version des applications mobiles par exemple
ou tu voyais toujours
la même message c'était
il y avait des features qui avaient disparu
complètement de l'application mobile
et les gens en fait c'était la feature
qui s'utilisait
donc typiquement c'est que l'équipe produit
n'a pas compris pourquoi les gens
utilisent une application mobile aujourd'hui
et donc en fait à partir de ce moment là
c'était pas dans un cycle iteratif
c'était pas dans tout ça donc
forcément en fait
t'as ton back-lop qui se construit
et t'arrives à des moments où
t'as un ticket qui a été créé il y a 6 mois
tu sais plus pourquoi il a été créé
tout ce que tu sais c'est qu'il doit être fait
mais en fait il n'a plus aucun sens
parce que ta base de code a complètement changé
en plus avec un peu de chance il a été estimé il y a 6 mois
donc tu te retrouves avec une estimation
qui n'a plus rien à voir et qui est plus bonne du tout
et ça m'est déjà arrivé
d'arriver et dire ce ticket là
le projet à quel est le ticket
n'existe plus
et pourtant le ticket avait été review
on l'avait estimé on avait tout ce que tu voulais
mais au moment de le faire je ne retrouvais plus le repo-guide
parce qu'en fait juste le projet avait été kill
et qu'au moment de faire l'estimation
il y a 6 mois le projet existait
etc etc
sauf que 6 mois après le projet a été kill
il n'y avait plus rien à voir et c'était juste
plus possible dans les tickets là et là quand tu dois expliquer
à ton PO que maintenant cette fétur là
c'est pas possible et là il fait
ah ouais
ah bah prends-en un autre
ça montre juste qu'il n'y a pas de vision produit
outre-méziore quoi
et c'est ce qui pour moi manque dans beaucoup de boîtes
et surtout dans les grosses boîtes
j'ai moins rencontré ce problème là en start-up
c'est la vision produit en fait
qui est complètement décorée du terrain
toi Maxime tu disais tout à l'heure que t'étais plus passé
par les petites structures justement
c'était quoi justement cette expérience
par rapport à toi parce que à la base
c'était quand même un thread que tu as fait
sur ce plein de...
la pénibilité que tu avais su faire là dedans donc
hum...
disons que le...
plus la boîte était grosse
plus il avait une montée en charge de la pénibilité
liée au management
ah...
au plus bas les plus petites structures
on se contentait de juste une toute liste
voilà on a ça à faire
on n'a pas d'estimation
on sait qu'on doit le faire on le fait
et...
niveau vision produit c'était assez smart
parce que on essayait au minimum
de pas donner de délais de juste dire
voilà on le fait
on vous communique sur l'avancement des choses
pour pas vous mettre en angoisse
de ne jamais rien avoir
mais... voilà on avance
on y va en mode best effort
et on avance
hum...
attends je me suis complètement perdu
dans la petite boîte est-ce que dans la petite boîte
c'était si tu pouvais voir avec quelque chose de différent
oui mais dans...
dans...
dans d'autres expériences
il y avait quand même plus une vision
produit parce qu'il y avait des
levettes fonds
et donc forcément il y a des
rendez-vous avec les investisseurs
où il faut montrer bah voilà votre argent
il sert à ça
et en start-up c'est souvent le
modèle qui va
tu parles des actionnaires
Maxence tout à l'heure ça va être un peu la même chose
avec les investisseurs
les fonds
il y a les rendez-vous de bord régulièrement
ou tu dois leur montrer pas de blanche
voilà votre argent il sert à ça
dans les 3 prochains mois on va faire ça
etc etc
et c'est
je pense ce qui
ce qui va
commencer à mettre des gravions
en gronnage de la start-up
et plus les fonds vont être conséquents
plus ils vont avoir des parts dans la boîte
plus ça va être compliqué justement d'avoir
une belle boucle littérative avec
des p'tits Mvp pour chaque future
et
être directement avec le client
plus ça vient
plus le fond
met son nez dans les affaires de la boîte
et je pense qu'aujourd'hui
surtout en France un très peu de fonds
qui vont avoir
cette vision produit de faire
des merdes-vous de toute façon c'est votre produit
vous le comprenez mieux que nous
nous ce qu'on veut voir à la fin
c'est juste de la croissance mais vous vous démerdez
pour
faire quelque chose de notre argent
en France
je connais pas cette histoire
je l'ai jamais entendu
je n'avais jamais pensé à ça mais c'est vrai que
c'est vrai les fonds ont besoin
de rendement aussi
après il y a quelque chose qu'on oublie
on change un peu de sujet mais sur les start-ups
c'est que la start-up choisit aussi
les fonds qui a fait rentrer
et tous les fonds pas forcément
la même qualité et la même vision
et c'est des points qu'il faut éclaircer avec eux
mais je suis d'accord qu'à un moment il y a des questions de rendement
surtout quand tu arrives à des séries importantes
ou tu sais que pour avoir
une nouvelle série si tu as besoin encore d'argent
il faut faire
toujours des meilleurs chiffres etc
et donc oui tu as une pression qui va arriver
intrinsèquement au fait que tu as besoin
de croissance
après les boîtes américaines
ont montré qu'elles sont capables
d'avoir cette pression
tout en gardant une vision produit
et d'être proche de leurs clients
et pour moi
c'est juste une question de volonté
aussi bien des gérants
de la boîte
qui produisent
de pas s'éloigner et de pas partir
dans un espèce de cyclanvé
pour moi on arrive souvent dans des projets
qui sont en fait des cyclanvés
parce que pour moi
tant que tu as pas mis
ton produit dans les mains du client
en fait tu es dans un cyclanvé
tu peux l'appeler itératif
tu peux faire des sprints de deux semaines
si à la fin des deux semaines il s'est pas déployé
c'est pas million prode, c'est pas utilisé par quelqu'un
en fait c'est juste un cyclanvé
que tu es en train de créer
que tu caches par une boucle itératif
mais c'est là
où vous en parliez
typiquement Guillaume dans le dernier podcast
sur les features flag
c'est ça qui est intéressant c'est de pouvoir délivrer vite
pour pouvoir justement
vite rentrer dans un cyclitératif
et le cyclitératif est aussi pour les clients
leur proposer rapidement des features
pour qu'ils puissent tester rapidement
et c'est là où pour moi c'est important de découper les features
à leur substra le plus petit
et vraiment avoir un truc tout petit tout petit tout petit
tout petit
qui demande pas beaucoup de développement
qui permet d'avoir vite des feedbacks
de faire du fake it, you make it
sur certaines parties
voilà il y a toute cette culture là
mais c'est une culture produite en fait
à avoir de
pas attendre toujours le diamant
parfait
etc etc c'est pas toujours possible
c'est peut-être même jamais possible
réellement de
finir un projet comme ça parce que quand tu le mets au moins de tes clients
c'est quand même extrêmement disséptif
peut-être qu'en fait
les choses qui rejoignent et qui rejoignent un peu
la notion même qu'on a dans le DevOps
c'est la notion de confiance en fait
c'est à quel moment ton client
a confiance dans le fait que tu vas le faire
à quel moment ton client a confiance dans le commercial
à quel moment le commercial a confiance dans le PO
à quel moment le PO a confiance dans les équipes pour le réaliser
et en fait je pense qu'il y a une boucle
qui se crée régulièrement, qui est une boucle
vraiment
extrêmement nocive
où on n'a pas réussi à sortir une fictionnité
qui fait qu'on veut rajouter plus de contrôle
pour se dire grâce au contrôle je vais faire sortir plus vite
ces choses là parce que
c'est moi
si jamais c'est pas sorti c'est parce que j'avais pas fait moi à cette contrôle
c'est moi qui vais sauver la boîte
tout le monde le sait
donc je vais mettre un peu plus de contrôle
qui fait que ceci, etc etc
et donc en fait il y a cette boucle
d'inconfort
où plus personne se fait confiance
qui fait que tu vas tomber dans cette travers là
très souvent en disant non non mais
pourquoi je ne veux pas sortir avec toutes les fonctionnalités
parce que j'ai peur que quelqu'un me tape sur les doigts
parce que c'est pas bien
j'ai peur que le client me dise que c'est pas bon
et en fait tout le monde est dans une peur permanente
et donc tout le monde se blinde
se blinde en disant attendez moi je vous ai sorti le truc avec toutes les fonctionnalités
si maintenant c'est pas qualitatif c'est la faute des devs
et puis les devs etc
tu vois il y a ce truc de waterfall
vraiment de cette chute de responsabilité permanente
où je me dégage sur toi
de toutes les mers et de toutes mes peurs
que je vais avoir et en fait on est dans un symptôme
d'accumulation de peur
et d'amplification des peurs
pour ça là pour ça on est très centrés
autour des développeurs mais en fait si jamais tu le mets
sur la production
tu l'as fait fou à deux
c'est genre en fait toute la merde de peur qui est descendue
du commercial du client jusqu'au commercial
jusqu'au PO jusqu'au dev
il se retrouve à la fin sur les ops
et c'est une chaîne comme ça
de confiance en fait qu'il faut recréer
et qu'il faut remettre à un bon niveau
mais en fait pour avoir cette chaîne de confiance
il faut que tout le monde ait cette vision produite
il faut pas que t'en aies un dans toute cette chaîne qui se dise
hop hop hop hop
moi je fais de la rétention
quand on les appelle déjà les kamikaz
du projet en disant
non non mais moi allez vous faire foutre je le ferai pas
genre vos projets
vos trucs vos bidules vos clients
moi je m'en fous genre je le ferai pas
et ça existe
il y a eu des équipes de développeurs qui l'ont fait à des moments
et il y a des équipes d'ops qui l'ont fait
aussi à d'autres moments
et donc c'est un peu ça le truc où tout le monde
tu sens que tout le monde est un peu tendu
là dessus
c'est un peu des mots tabou
et d'ailleurs c'est un peu ce qui s'est passé sur ton thread
en parlant de scrum c'est qu'il y a aussi beaucoup de gens
qui se sont sentis visés
et sentis très mal à l'aise
par rapport à ça moi ma question c'est
est ce que les problèmes c'est le scrum
ou est ce que le problème c'est
c'est l'application du scrum
c'est à dire qu'il y en a beaucoup de gens qui sont comme ça et qui ont pu dire
ah mais non mais les problèmes dont vous parlez
c'est juste parce que
le scrum n'a pas bien été appliqué
le scrum il ne dit pas ça
le scrum ceci le scrum cela
il y a question je dis même pas que c'est faux hein
c'est genre comment on fait par rapport à ça
quelle est la réponse qu'on peut avoir
quelle est la vision qu'on peut avoir par rapport à ça
je vous ai pris de cour
non
pour moi en fait
scrum il n'est jamais responsable
parce que c'est qu'une méthodologie
à toi d'implémenter ce que tu veux dans cette méthodologie
là la gil c'est pareil
c'est un fray mort tu prends ce que tu veux
il n'y a aucun moment qu'on te dit
ou tu dois implémenter tout à 100%
pour être parfait etc
enfin c'est pas tout ce qu'il a dit
c'est prends ce que l'équipe a besoin
et je pense que c'est là où c'est plus important
c'est prendre ce que l'équipe a besoin
et pas prendre ce que l'organisation a besoin
et c'est souvent là où je vois que
les gens se plaignent de scrum
c'est que en fait scrum n'a pas de
sens pour eux c'est à dire qu'ils ont l'impression
que c'est du flicage c'est ce qu'on disait tout à l'heure
c'est du flicage, du reporting, du machin
et qu'ils y voient pas les potentiels bénéfices
et c'est là où je trouve que c'est important
c'est que le manager, le PO etc
doivent dire aux leurs équipes
en fait globalement implémenter
ce que vous sentez que vous avez besoin
et puis on y terra dessus, on essaiera
de trouver le meilleur compromis
mais dans tous les cas ne le faites pas
pour votre manager ou pour votre organisation
c'est vraiment penser de base
pour une équipe et pas pour le reste
et tu peux très bien avoir plusieurs équipes
et une équipe en scrum, une équipe en agi
une équipe en camp-ban
une équipe en cyclant V s'ils veulent
enfin, il n'y a aucun problème
tant que la culture produit est partagée
avec la vision commune de là où on veut aller
est partagée
normalement il n'y a pas de problème
parce que chaque équipe s'organise complètement
comme elle veut
et surtout si ça marche
et voilà, adapter aux expériences et aux besoins
de chacune des équipes
c'est là où le rôle du manager
c'est de suivre que tout le monde s'épanouit
dans cette organisation
et que personne n'est laissé pour compte
sur le côté et que globalement
ça fonctionne
c'est bien de se faire un monde merveilleux
mais si derrière il y a personne qui est délivre
et ça ne marchera pas
ça ne marchera pas dans le long terme non plus
mais pour moi ça doit être penser
si l'équipe doit implémenter et demander
ce qu'elle veut et non pas quelque chose
qui doit être imposé ou un CTO arrive
et dit, ah bah maintenant toutes les équipes
c'est des cycles de deux semaines
avec des sprints de review, des poker planning
des machins d'habitul, pour moi
ce n'est pas comme ça en tout cas
qui a été présenté et pensé
la solution apportée par Scrum et Agile
Et toi justement Maxime, c'est quoi un peu les retours que t'as eu
par rapport à ça les gens qui te disaient
que c'est pas comme ça le Scrum
Ouais, il y a eu
c'est une assez bonne part au final
des retours, je pense qu'on est
entre 30 et 40 % des retours
c'était vraiment ça
c'était
non mais en fait
ce que tu dénomces
c'est pas Scrum, c'est l'implémentation de Scrum
Mais
il y a des gens pour qui Scrum
ça se passe bien donc il y a
des implémentations où manifestement
ça marche
par contre
ces gens ont
une certitude assez forte
qui montre que Scrum
marche
que la méthode
si elle est bien implémentée
fondamentalement va fonctionner
Oui c'est tout écarre
à la méthode, c'est ça qui rend les problèmes
c'est ça
c'est qu'on peut pas
on peut pas proposer d'objections
à Scrum
Scrum le modèle est
fondamentalement bon et fonctionne
si
tu as des choses à dire c'est parce que
tu fais mal du Scrum mais si tu le faisais bien
tu vas voir ça marche
mais je pense qu'il y a quand même des objections
à faire sur Scrum tel qu'il est écrit
je suis pas forcément la personne la plus indiquée
pour le faire mais je pense que le modèle
en lui-même est quand même critiqueable
Je pense, typiquement
ce qu'est dit Maxence avant est déjà une critique
en disant en fait on va s'adapter
et on va faire en fonction de ce qu'on veut
et je crois d'ailleurs que dans Scrum c'est pas vraiment écrit comme ça
c'est comme ça qu'on le fait
si jamais on est agile on se dit
bah pff c'est une boîte à outils
je pioche dans le Scrum, je pioche dans le can ban
je pioche dans quoi que ce soit etc
agile te dit ça parce qu'agile te dit rien
il te dit démerdez-vous c'est juste la
philosophie derrière
mais Scrum pour le coup il y a beaucoup plus
il y a des certifications, il y a des choses comme ça
il y a des choses où tu peux être tamponné Scrum
tu peux être
enfin en fin il y a quelque chose
où vraiment il y a des gens aujourd'hui en effet
qui investissent dans Scrum
et les gens pour qui c'est leur business
c'est leur gameplan c'est comme ça
qui emmène leurs enfants à l'école tous les jours
c'est grâce à Scrum et grâce
à ce tampon Scrum
et c'est vrai que là-dessus
moi personnellement j'ai un problème avec ça
me dire je suis
coach agile et
j'ai fait du Scrum, fait du can ban
mon expérience et on Scrum
mon expérience c'est en can ban
mon expérience et en ceci-ce-là donc je vais pouvoir
vous aider sur plein de choses je trouve ça bien
mais en effet
j'aurais du mal à imaginer
enfin je suis assez d'accord avec toi
de dire
can ban c'est même pas qu'il peut être critiqué c'est qu'il doit être
d'ailleurs il va pas être adapté à tous les contextes
il y a des contextes où Scrum
va pas marcher, c'est par nature
même du concept
et en fait quasiment l'inverse il faudrait demander
quels sont les contextes où Scrum va marcher
est-ce que vous imaginez un contexte
où Scrum vraiment buys a book
fonctionnerait tel quel
non, je vois pas comment
n'importe quelle méthode qui a été posée sur un papier
peut marcher quelque part
parce que t'as trop de paramètres
qui peuvent influer
sur le modèle à la fin
enfin c'est comme dans la phrase
je peux pas juste appliquer un nom de cibol
dire hop ça marche parce que quelqu'un l'a écrit
non faut vérifier, faut être sûr que ça fasse bien ce que tu veux
et faut prendre que ce que t'as besoin
en fait
et pour moi c'est le truc qu'on oublie à chaque fois
c'est prendre juste ce que j'ai dit a l'air
prendre ce qu'on a besoin
et laisser de côté ce qui n'est peut-être pas bon
aujourd'hui pour l'équipe mais qui le devra
et c'est quelque chose pour moi à remettre en cause
à chaque fois qu'il y a un départ
où il n'a arrivé dans une équipe
après quelques mois que la personne se soit
acclimaté à la façon de travailler etc
c'est remettre en fait en cause tout
parce que potentiellement le départ
ou l'arrivée de quelqu'un peut rebattre complètement
les cartes et ne plus avoir besoin de certaines choses
ou avoir besoin de nouvelles choses
pour que tout le monde et c'est important que tout le monde
se sente à l'aise dans cette équipe
et c'est souvent ce qu'est oublié
en fait c'est ce qu'on dit plus de tout à l'heure
mais c'est globalement c'est souvent ce qu'est oublié
c'est que c'est l'équipe en fait en premier
et c'est un rôle, vraiment il y a un rôle
que j'aime pas du tout dans Scrum c'est le principe du Scrum Master
moi je n'ai jamais compris
c'est quoi son rôle
pour moi le Scrum Master c'est un facilitateur en fait
c'est quelqu'un
sur lequel je viens appuyer pour dire
j'ai un problème de communication avec telle personne
j'ai un problème de communication avec telle autre équipe
j'ai un problème de ci j'ai un problème de ça
et il est là pour me faciliter la vie
faciliter la vie à l'équipe
mais le rôle de Scrum Master j'ai l'impression
que voir un rôle de manager en fait
tel quel il est implémenté souvent
c'est en fait le manager qui est le Scrum Master
et à ce moment là en fait t'as tout cassé
parce que face au moment où tu mets un manager dans la boucle
les gens se comportent pas pareil quand t'es avec un manager
en face de toi
ou quand tu n'as pas de manager en face dans la pièce
tu le vois par exemple en rétrospective
tu mets un micro dans une salle de rétrospective
tu mets un manager dans la pièce
t'enlèves le manager dans la pièce
c'est bizarre la rétrospective elle est complètement différente
et les choses ressorties sont complètement différentes
ça montre bien pour moi que
un manager ne doit à aucun moment
être lié à tout ça
c'est assez marrant le rôle du Scrum Master
au tout début
au tout début de ma carrière
c'est vraiment il y a longtemps
justement je voulais devenir Scrum Master
parce que j'aime la méthodologie
enfin tu vois j'aime le fait la pensée agile
enfin vraiment ce truc de cycle iteratif
enfin vraiment en terme de conceptuellement
philosophiquement je le trouve cool
et donc je mettais dit je vais devenir Scrum Master
mais alors by the book c'est à dire
le Scrum Master est là pour appliquer la méthode
c'est à dire de se dire juste c'est même pas un facilitateur
de communication parce que le Scrum Master normalement
ça peut même mettre un freelance externe
il vient juste il regarde ta rétrospective
de la merde parce qu'il y a le manager dedans
et vous parlez pas
ou c'est de la merde
vous êtes en délit en fait vous racontez votre vie
enfin vous racontez ce que vous avez fait la veille
c'est pas bien, bam
nous on avait des Scrum Master vraiment qui étaient ultra vénères
comme ça vraiment qui coupaient en permanence
en disant non non mais là vous le faites pas comme il faut
vous racontez votre vie
et ils pouvaient le dire au manager
au PO ou quoi que ce soit
et moi je trouvais ça cool et en fait je voulais devenir
et en fait j'avais demandé à une boîte
qui cherchait un Scrum Master
et en fait ce qu'ils m'ont dit, m'ont dit non on va pas te prendre
pas parce que t'es pas bon, pas parce que
tu ferais pas la fin
pas parce que tu as pas ces idées là chevillées au corps
c'est parce que t'es trop technique
et en fait malheureusement tu risques d'avoir un avis
sur le projet
c'est à dire en fait tu vas pas avoir un avis vraiment
ultra au niveau c'est que en fait tu risques
beaucoup trop d'être jugé parti
et donc on ne veut pas que tu sois
parce que ce qu'il faut c'est évaluer le projet
tel qu'il est et pas tel que tu penses qu'il pourrait être
ou tel que tu imagines qu'ils auraient pu faire etc
et donc il m'avait pas pris pour ça parce que j'étais trop technique
et qu'il voulait des gens quasiment
sans niveau d'études sans rien, qu'il y avait juste un peu
de jugeottes qui le but étant pas
de comprendre ce que les équipes faisaient mais vraiment
juste d'appliquer la méda
de simplifier la méthode en fait
en parvain c'est de trancher
parce qu'il faut que c'est un policier justice
la loi c'est Scrum
les délinquants
c'est les gens qui l'exécutent
et le Scrum master est là pour punir tout le monde
mais moi je déteste cette vision
typiquement c'est rien qu'à l'entendre
ça m'aurie pillé, je comprends
je peux comprendre le principe etc mais
je vois pas pourquoi si j'ai envie
pendant ma délit j'ai 2 minutes de parole
et que j'ai envie de partager
un truc un peu perso etc
pourquoi ça devrait être interdit tu vois
c'est après tu racontes pas du tout
ce que t'as fait, ce que machin a expliqué
tu respectes pas le format et tu fais que parler perso
c'est un problème mais pourquoi on n'aurait pas le droit
d'ériver
le but c'est de construire une équipe
elle a besoin de lien, d'être soudée
et si tu casses en permanence
toutes les petites phrases
qui permettent de créer du lien
tu crées pas une équipe, tu prends juste des personnels
pour des individus de contributeurs
tu les mets les uns à côté des autres
tu leur mets un casque
surtout pas qu'ils entendent le reste du monde
et tu leur demandes de juste faire du ticketing
et enfin
tu construis pas une équipe comme ça
et tu te rends dans le temps
mais en fait ce que je chassais d'accord
c'est que maintenant j'en suis plus comme ça
mais à l'époque je n'étais pas exactement dans ce genre de temps
et c'est marrant comment j'en suis revenu avec l'expérience
et c'est un point aussi qui est assez important
c'est que j'ai l'impression qu'il y a une phase
dans l'agilité où tu commences à bosser
tu détestes l'agilité
puis il y a un moment, enfin le scrum
puis il y a un moment, ça y est
tu en as bavé, tu en as chier début
ça y est c'est devenu ton alpha et ton omega
et qu'après au bout d'un moment
avec un peu d'expérience, tu te remets
à te redemander
si c'était vraiment une bonne chose
et en fait quand on parle avec des gens
on sait jamais à quel niveau
d'expérience ils en sont dans cette chaîne
est-ce qu'ils sont au début
ça veut dire qu'ils sont tout genoux
et en fait ils ont pas d'idées de ce qu'ils font
ou est-ce qu'ils sont très vieux
et ça veut dire qu'ils ont déjà eu de l'expérience avec du scrum
c'est un peu ça
parce que j'ai l'impression parfois en tout cas
je sais pas
ce que vous en pensez mais bon c'est ce genre de choses
et je pense qu'on a un peu
déjà tourné un peu autour de tout ça
moi ce que je voulais peut-être pour finir un peu
c'est avoir un peu toi les retours que t'as eu
à la fin de ton tweet Maxime
un peu en méta par rapport à ça
justement si on revient aux réactions que t'as eu
comment tu l'as vécu, ce qu'on t'as
pu dire, ce que t'as vu comme profil
de gens qui ont réagi et comment ils ont réagi
tu peux faire certains portraits type quand même
des réponses
t'as d'un côté
une part des gens qui comme moi l'ont très mal vécu
et c'est plus en mode
oui merci de le dire moi aussi
moi aussi j'en ai chier je me reconnais en ton thread
t'as les gens qui vont être
un peu ce qu'on disait tout à l'heure
le problème c'est pas la méthode
c'est son implementation
globalement j'ai été assez surpris
parce que c'est un truc qui me faisait très peur
quand j'ai vu que le nombre d'impression
du thread commençaient à s'envoler
j'avais peur que ça tourne
en shitstorm d'un sens ou de l'autre
que ça s'engueule
que il y ait des insultes
que ça dégénère, tu vois que ça drift
globalement tout le monde s'est tenu
et ça j'ai trouvé ça trop bien
il y a juste eu deux fois
où j'ai fait
quand même respectez-vous
parce que ça commença à drift
mais globalement
il n'y a pas eu de gros débordement
j'ai quand même, tu sais j'ai deux comptes
j'ai ce compte là que je réserve au pro
et puis un compte perso
durant la durée du thread mon compte perso je l'ai mis en privé
je voulais pas que les gens
débordent là dessus
je voulais que le pro reste côté pro
globalement
ce qui est, il y a un avantage du truc
c'est que ça m'a ouvert une porte
par contre pour pouvoir parler un peu
j'en ai pas encore fait grand chose actuellement
mais je pense que ça va m'amener
à parler d'autres choses sur le milieu du dev
ça c'est une bonne chose
mais sinon sur le thread en lui-même
je regarde un peu mais les
ce que je suis content aussi
c'est qu'il y a personne qui a dit
qui est venu avec des gros sabots
en mode ce que tu dis c'est des grosses conneries
en oubliant le fait que
j'avais mis l'accent sur un vécu
t'as des gens qui ont quand même dit
ton vécu c'est pas scram
mais t'as personne qui a remis en cause le vécu
oui c'est ça fouta toi
j'ai trouvé que c'était assez respectueux
dans l'ensemble que tout le monde est quand même
compris le fait que je parlais
d'une douleur passée
que je parlais pas
je parlais pas d'autre chose
je tapais pas bouler rouge sur la méthode
en mode c'est de la merde
faut arrêter, faut faire autre chose
c'était juste de mon ressenti personnel
et de la douleur que ça avait causé
et ça globalement tout le monde l'a compris
c'est au final une bonne chose
c'est cool c'est plutôt sympa
je sais pas si vous avez d'autres choses dont vous aimeriez exprimer
là dessus
on a fait le tour moi en tout cas de ce que je voyais
mais vous peut-être que vous avez encore autre chose
on pourra toujours en rediscuter
c'est un débat assez important
et même des autres méthodes
on n'a pas parlé du kanban, de l'extrême programming
on n'a pas parlé de tout ça
c'était pas le propos là
déjà ça fait déjà un petit moment qu'on parle
mais je parle à Sour Scrum
est-ce que vous avez quelque chose d'autre
qu'on aurait pu oublier
pour moi je pense que le tour est fait
pour une première fois en tout cas
cool, bah super
merci à vous deux d'être venus
merci
donc là on était en distanciel
pour ceux qui l'écoutent
on enregistre ça en ligne
n'hésitez pas à réagir
bien sûr courtoisement
même à donner votre opposition
ou à donner des précisions
peut-être pas été très précis
peut-être même d'ailleurs on va changer d'avis grâce à vos commentaires
donc c'est bien de le faire
pas besoin de nous insulter
les gens peuvent changer d'avis c'est assez bien
n'hésitez pas à commenter sur twitter
à revoir le thread, j'essaierai de mettre sans doute les liens
pour que vous ayez un peu plus le contexte
et à venir si vous voulez
sur le discord de DevOps
on sera toujours ravi d'avoir des expériences
même pas que sur le DevOps
des gens qui sont dans toute cette chaîne
on aimerait bien avoir des gens du produit
j'adorerais à part ça
et voilà, merci à vous deux
bah merci à toi de nous avoir invité
merci beaucoup
c'était super
super, bah merci
salut