Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
Aujourd'hui je suis encore avec J.P. Lambert et c'est la suite de l'épisode d'hier.
Si tu n'as pas encore écouté celui d'hier, viens sur le podcast écouter celui d'hier qui est celui-là et la suite.
Bonjour J.P.
Salut.
On était en train de discuter du passage de feature team
et je te demandais comment est-ce que tu définis les frontières dans une feature team.
Parce que finalement, tu résous en enlevant des frontières comme on le disait, tu en crées d'autres
et notamment sur le produit, comment tu le découpes ce fichu produit
pour arriver à construire des features team qui arrivent à travailler ensemble.
Je pense qu'on arrive dans la série de fameuses phrases de magie
quand on sort à peu près à toutes les sauces qu'on parle d'agilité,
ça dépend de votre contexte.
C'est un peu...
Non, il faut encore t'engager un peu plus que ça, là, J.P. aujourd'hui.
Non, mais en fait, il y a vraiment de ça.
Justement, en raison de Spotify, ce qui nous dit,
il y a un peu tout le monde entier qui s'est emballé en disant
« Ah, le modèle Spotify, c'est génial, c'est super, c'est ce qu'on doit faire.
Il y a le pauvre Henryk Niberg qui est là en mode. Mais attendez, moi,
j'ai juste fait un retour d'expérience sur ce qu'on fait.
Et vous, vous l'avez pris, c'est un modèle et vous l'appliquiez tel quel.
Non, nous, et aujourd'hui, on fait déjà autre chose.
Le vrai modèle, c'est l'entreprise apprenante qui se remet en question,
on peut remercer. Donc, en fait, il faut essayer des trucs et s'ajuster.
Donc après, on peut quand même parler de différents modèles qui existent
et des conséquences que ça.
On peut parler de ce que propose Les, par exemple.
En Les, on est vraiment sur l'idée de...
Les feature teams sont interchangeables.
Donc, typiquement, avant avoir une composition similaire
et sont toutes capables de prendre n'importe quel sujet.
Et en fait, elles fonctionnent de concert comme une seule grosse équipe.
C'est-à-dire qu'on va avoir un seul PO pour ces X équipes.
Et on fait un sprint planning ensemble et ensuite, c'est redispatché
dans chacune de ces équipes. Il y a la fin, on aura une revue d'intérations communes
et même un deuxième niveau de rétrospectif commun,
avec juste des émissaires.
Et là, du coup...
Donc, en gros, si tu as une équipe de...
je sais pas, tu as 4 features teams de 5 personnes,
tu fais un sprint planning avant.
En fait, la première partie de sprint planning avant.
C'est-à-dire que finalement, en gros, le sprint planning, au lieu d'avoir
juste deux phases avec c'est quoi le périmètre et quelles sont les tâches techniques,
on a une troisième phase encore en amont, c'est
qu'est-ce qu'on veut faire tous collectivement de manière macro.
Et du coup, comment se le répartit entre les équipes
et après, chaque équipe veut un peu plus dans le détail, etc.
Donc, je pense que le framework est quand même assez bien fichu.
Il détaille ça assez bien.
Mais donc, on est vraiment sur ce t-il est là,
il n'y a pas de périmètre figé et les équipes sont interchangeables.
Par contre, on a une seule vision et on y va tous en même temps.
Donc ça, c'est un exemple de modèle.
Un autre modèle, c'est plus de se dire,
on va figer les périmètes fonctionnelles.
Donc, il y a une partie, c'est la facturation,
il y a une partie, c'est les mises en avant sur le site, etc.
Et donc là, les équipes sont dédiées sur ces sujets-là,
qui va avoir l'intérêt que tout l'aspect grooming va se faire assez naturellement.
Ah, on a un grooming à faire sur la facturation.
C'est l'équipe facturation qui va se changer.
Donc, on connaît, on a tout de suite un PO,
une équipe de développement qui sont identifiées avec qui
on peut échanger ou ils peuvent creuser de backlog en amont.
Parce qu'effectivement, quand il y a des équipes qui sont interchangeables
et qu'on se retrouve sur des sujets assez compliqués,
qui faut préparer plusieurs itérations en avance,
il y a des SDK à valider, je ne sais pas quoi,
ben c'est vrai, on fait quoi ?
C'est qui qui s'en occupe quand on a juste X équipes interchangeables ?
Il n'y a pas de personne à titrer où c'est logique,
puisqu'on ne sait pas qui s'en occupera.
Par contre, le risque dans cette organisation-là,
c'est que du coup, tu deviennes dépendant de l'équipe
et qu'on reconstruise des zones de propriété par...
par team, en fait.
Dans quelle mesure est-ce que ça ne va pas...
ça pourrait aller à l'encontre de la notion de responsabilité collective, tu vois.
En gros, est-ce qu'un mec qui est hors facture
a le droit de venir modifier le module facture
s'il ne fait pas partie de la team ?
C'est ça, il y a aussi ces problématiques-là.
Et là, ça fait écho sur le fameux alignement,
les communautés de pratique.
C'est qu'effectivement, si une équipe reste en charge
d'une feature en particulier,
est-ce que les autres touchent le voie, cela proprit ?
Donc après, je pense que même entre ces deux extrêmes,
on a des pyramides figés et il n'y a que ces personnes-là
qui y touchent et d'autres où on est complètement interchangeable.
Il y a tout un ensemble de nuances qu'on peut aussi peindre.
Et encore une fois, je pense que ça dépend vraiment
des contraintes de la botte
et des contraintes que nous donnent le produit simplement,
puisqu'il y en a des produits qui vont être plus stables,
et d'autres qui vont évoluer très vite, etc.
Donc voilà, je ne sais pas, je botte en touch,
à part dire, il faut essayer, ça dépend de vous.
Et pour quelqu'un qui botte en touch,
tu amènes déjà des lignes directrices
qui sont super intéressantes.
Parce que ça revient encore,
on revient à poser la question,
ça fait deux fois qu'on mentionne ces notions
de communautés de pratique.
Comment...
T'as vu que moi, je travaille essentiellement dans des startups,
donc je n'ai jamais pu trop vivre ce genre de choses.
Et quand je l'ai vu dans les quelques missions
que j'ai faites dans des grands groupes,
très honnêtement, moi ce que j'avais vu,
c'était une cellule architecte,
mais globalement, c'est la même chose,
c'est-à-dire une cellule,
des gens qui sont missionnés
avec entre 50% et 100% de leur temps
à contribuer, voire même zéro,
c'est-à-dire en plus de leur affectation quotidienne,
mais certains ont commencé à leur déléguer du temps pour ça,
ils sont missionnés pour guider un peu
les lignes directrices du développement
et sont un peu les garants
de la cohérence du code et de la diffusion des bonnes pratiques.
Je t'avoue que je n'ai pas eu la...
Dans ce que j'ai vu,
je n'ai pas perçu ça comme quelque chose de très efficace.
Mais maintenant que j'y pense,
c'était peut-être juste le contexte
qui était globalement inefficace,
puisque cette pratique-là,
comment tu le vois,
comment ça peut bien fonctionner, ces trucs-là,
comme est-ce qu'il faut une personne qui est attitrée,
tu t'appuies sur la motivation et la passion des gens,
à quel moment est-ce que tu décides
de dialoguer spécifiquement de l'énergie
en tant qu'entreprise
et plus jouer sur la bonne volonté des gens
et leur motivation, comment tu vois les choses-là ?
En ce moment, ça fait...
Moi déjà, ce que tu dis, je fais le parallèle
avec la gestion produit.
C'est-à-dire que c'est pareil.
Est-ce qu'on a une UX,
c'est une cellule UX
qui est dédiée pour tout le monde ?
Ou est-ce qu'elle est partagée dans les équipes ?
Est-ce qu'on a un product manager
qui, pareil, gère cette partie-là
en amont,
qui est différent des productoneurs, ou pas ?
Pour moi, je le mets un peu dans le même cas,
est-ce qu'on a une cellule d'architecture
qui prévoit les choses un peu en amont ?
Ou est-ce que c'est le travail des équipes ?
Pour moi, c'est tout une problématique
de passage à l'échelle.
C'est-à-dire qu'on a une équipe,
on fait l'équipe scrum canonique,
la question ne se pose pas.
C'est les développeurs de l'équipe scrum
qui vont faire l'archi, et c'est le productoneur
de l'équipe qui fait le product manager.
Et c'est cette équipe qui gère tout.
Souvent, on fait un peu le distingue
entre le délivrer
et le découvrir.
Le délivrer, on sait ce qu'on va faire,
on y va et on livre un package, etc.
Que le découvrir,
on ne sait pas trop où on va,
on va peut-être faire des expériences,
faire des tests usateurs.
Et effectivement,
quand on a une équipe scrum,
idéalement, c'est l'équipe qui le gère et point barre.
Mais quand là, par contre, on fait du passage
à l'échelle,
la question servait un peu à savoir
combien on est prêt à payer sur la table.
Parce que d'avoir des équipes, effectivement,
à la Spotify qui sont capables
de tout gérer, de bout en bout.
Alors quand je dis à Spotify, encore une fois,
c'est à l'époque où on savait ce qu'ils aient,
ils ont évolué depuis.
Ça coûte quand même super cher, d'avoir
des équipes capables de toucher
n'importe quoi dans le code,
capables d'avoir une vision produite,
de tester tout ça, de gérer leur architecture,
tout en étant cohérent avec le reste de la boîte.
C'est quand même assez
possible, mais ça demande
énormément d'avoir monté assez haut
en termes de maturité, de capacité,
d'autonomie, d'auto-organisation, etc.
Il y a un moment,
on n'a peut-être pas envie de payer ça,
on a peut-être juste envie de
« OK, on a une cellule, Product Management,
on a une cellule, Architect, on a une cellule UX.
Ils font ces sujets-là,
et après, ils le chouteront
dans des équipes qui ne font que le délivrer.
Voilà, ils connaissent
la solution technique à peu près,
ils connaissent fonctionnellement ce que ça va faire.
Et hop, on y va.
Donc voilà, moi je ne suis pas très fan de ça,
parce qu'effectivement, quand tu peux imaginer
l'auto-organisation, l'autonomie, l'agilité, tout ça,
je suis quand même assez fan de ça.
Maintenant, je comprends, c'est la réalité du terrain.
Il y a un moment,
on passe à l'échelle, et la boîte,
elle n'a pas envie de payer énormément pour
avoir des gens, et quand on dit ça, c'est aussi que parfois,
on tourne à base de Presta qui change tous les six mois.
Bon, il y a sûrement plein d'autres choses derrière,
du style, un projet pas très glamour, etc.
Mais, voilà,
effectivement, typiquement en safe,
la recommandation, c'est plutôt d'avoir
un architecte qui s'occupe de ça,
c'est une soumission assez classique,
et qui fait du sens, quand on préfère
avoir des référents,
parce que derrière,
ça coûte cher, effectivement, d'avoir des équipes
vraiment autonomes, qui n'a pas le droit de gérer ça,
et qui en plus se synchronisent entre elles.
Oui, on renvoie
la notion, là, en fait,
très clairement, on renvoie tout ce qui est
gestion des connaissances, de l'edge management,
et
passage à l'échelle
de la capacité de l'entreprise, enfin,
on parle de sa résilience quelque part.
Oui,
capacité, et donc ça,
c'est un centre, c'est un investissement.
C'est pas un coût, c'est un investissement,
mais il faut savoir l'apprécier
et savoir le
problème de cet investissement, c'est qu'il se voit
peu, il est difficile à voir.
Tu le vois quand il y a un mec, ou une équipe
qui part en vacances, mais tu ne le vois pas
le reste de l'année, et
je trouve que c'est facile de,
malheureusement, d'être pris
dans les urgences du quotidien,
et ça tend à masquer
cette nécessité-là.
Dans le passé, je me suis souvent
retrouvé dans des
projets où on se rendait compte, la veille,
où je schématise un peu, mais
que le fait qu'il y ait des vacances pose un problème
et on se rend compte quelques jours avant.
Ça,
c'est pour moi le signe qui a eu
zéro investissement en amont
sur ce
partage de connaissance, en fait.
Ok, bah écoute,
JP, je te propose que ce soit le mot de la fin.
Merci d'être venu.
Avec plaisir.
Quant à toi, chère auditeur, je t'invite
à venir découvrir la chaîne de JP
sur Youtube, tu tapes JP Lambert,
et tu vas trouver, on en est à l'épisode 35,
je te recommande vraiment si tu ne connais pas.
Et si tu n'es pas encore abonné
à artisandeveloppeur.fr,
eh bien, bien vite le faire. Je te dis à demain.