Bienvenue sur le podcast Artisan Developer, l'émission qui combine technique et agilité
pour partager la passion du code.
Thierry, hier dans notre échange d'hier, tu as mentionné SAFE et c'est vraiment un
sujet qui m'intéresse si tu es ok pour qu'on explore ça parce que moi, j'ai vu pas mal
de gens faire du safe bashing et je t'avoue que quand j'ai ouvert la page d'accueil
de SAFE, j'ai pris un peu peur et je me suis dit bon sang, on avait réussi à faire
un truc à peu près simple, est-ce qu'on n'est pas en train de refaire une usine à gaz
avec du matériau agil ? Et du coup d'échanger avec toi et que tu me dises bah non, c'est
vachement intéressant SAFE, ça m'a fait hilté, ça m'a donné envie d'aller plus loin que
le diagramme qui m'a fait fermer la page au bout de 5 secondes.
Du coup, j'ai envie de te poser la question, c'est quoi SAFE ?
Alors, ben écoute, déjà merci de me donner l'occasion de pouvoir évoquer comme ce sujet
qui aujourd'hui me semble vraiment très très important dans la communauté agile.
Je sais pas, ça peut te rassurer mais j'ai eu la même réaction, si tu veux, il y a quelques
années quand j'ai ouvert le cité que j'ai vu, cette espèce d'usine à gaz, j'ai eu
exactement la même réaction que toi, je me suis demandé ce que c'était.
Alors, pour répondre à ta question, après je pense que c'est quand même important de
resituer SAFE dans l'histoire disons de l'agile et plus particulièrement dans la question aujourd'hui
de l'agile à l'échelle. SAFE, c'est ce qu'on appelle un framework, un cadre donc qui est basé
essentiellement sur l'IN et puis évidemment également sur l'agile, que ce soit Scrum ou même
l'extrême programmée et donc c'est un cadre qui va permettre à une organisation et une DSI par
exemple de gérer un ou plusieurs portfolios d'application et c'est un cadre en fait qui
propose disons tout un tas de rôles, de pratiques etc qui s'adresse depuis les thèmes stratégiques
d'une organisation qui s'adresse donc aux équipes qui développent et maintiennent ce portfolio
d'application. Ok, donc est-ce que tu dirais que c'est réservé à un certain type d'entreprise,
c'est quoi les critères ? C'est un critère de portefeuille, en gros si tu n'as qu'un produit,
tu n'as pas besoin de SAFE ou est-ce que c'est une question de taille ? C'est quoi les critères ?
Alors effectivement, disons que SAFE, alors je pense qu'en fait il y a plusieurs choses,
c'est-à-dire que SAFE en tant que tel effectivement s'adresse à disons une ou plusieurs équipes
mais à minima on considère dans SAFE ce que c'est 50-60 personnes qui gèrent,
qui tiennent, sont en responsabilité d'un ou plusieurs produits. Ceci étant, j'avais eu l'occasion
d'ailleurs il y a quelques temps d'écrire justement un cours article sur le sujet qui est que même pour
une équipe disons de 7-8 personnes, une équipe par exemple qui fait du scrum, je pense qu'il peut
être tout à fait intéressant de considérer SAFE, évidemment pas pour appliquer tout SAFE parce que
ça n'a pas de sens mais simplement pour rappeler malgré tout quand même que la base de la gile
c'est un pilotage par la valeur, c'est ce qu'on trouve dans SAFE avec des chaînes de valeur et même
si je suis développeur dans une équipe où nous sommes 7-8 développeurs, nous nous inscrivons quand
même dans une chaîne de valeur, dans le développement de produits qui contribuent à une chaîne de
valeur pour nos utilisateurs et SAFE va aussi rappeler au travers de sa première valeur qui est
justement qualité intrinsèque, built-in quality, va rappeler que dans le monde du logiciel et bien
aujourd'hui nous avons quand même des pratiques professionnelles comme l'intégration continue
etc. Je dis ça parce que en particulier pour un scrumien étant donné que scrum et c'est la force
de scrum est relativement universelle puisque si on considère le scrum guy, la finalité, le propos
de scrum c'est maîtriser le développement de produits complexes et donc scrum au départ
n'est pas en tout cas dans sa définition, n'est pas spécifiquement logiciel et donc scrum ne va pas
proposer directement des pratiques. Alors effectivement dans scrum on va dire qu'on a
cette fameuse définition of dawn qui t'apparu je crois début des années 2000 bon mais cette
fameuse DOD elle est bien sympathique ce cas c'est que en tant que développeur si je sais pas ce
qui est le TDD si je sais pas ce qui est le clean code etc. je vais considérer que ma définition
of dawn grosso modo c'est la validation du product owner et puis peut-être vaguement une
gestion de comf et encore quoi alors que que ce soit dans l'extrême programming que l'on a déjà
évoqué aujourd'hui dans safe et je t'engage vraiment dans safe à aller regarder tout ce qui est
donc qualité intrinsèque et bien on va vraiment retrouver en termes de pratique de développement
de logiciel l'intégration continue les pratiques de type test for programming le refactoring le
per programming collective ownership enfin voilà c'est à dire des choses qui existaient initialement
dans dans l'extrême programming ok donc ils ont absorbé ces pratiques là après j'ai vu aussi
des débuts de diagrammes qui ressemblaient à des à des descriptions de scrums notamment avec les
espèces de deux si des deux cercles là avec les flèches qui représentent les cycles
ouais les scargos scrums là donc ça m'a donné l'impression qu'ils prenaient donc en fait ce que
tu dis c'est quelque part ce que j'entends c'est que ils prennent les bonnes pratiques du scrim de
l'extrême programming donc ils y injectent de la technicité dedans et on se pose la question de ok
comment on fait passer ça à l'échelle d'une équipe d'au moins 50 personnes quoi voilà c'est ça alors
quand même si tu veux pour comment dire je pour rendre à ces arts ce qui est assez rare ou en tout cas
pour être un peu plus un peu plus correct quoi dans le point de vue historique et même dans le point
du vue actuel si on regarde aujourd'hui dans safe quand tu cliques dans un safe tu sais quand tu
cliques donc le fameux la fameuse usinaga quand on clique sur justement le fameux escargot scrum en
fait safe utilise donc utilise le terme scrum xp et scrum xp entre nous étant donné que l'expert
d'ailleurs initialement c'est appuyé sur l'in mais c'était aussi appuyé sur scrum donc sur
l'aspect éteratif bien que l'aspect éteratif était beaucoup plus serré déjà dans l'extrême
programming à l'époque mais si tu veux scrum xp concrètement ça s'appelle xp quoi c'est-à-dire
si je reprends finalement la définition de l'époque avec des itérations courtes avec un client
sur site avec des tests d'acceptation avec des user story tout cela c'était en fait l'iterratif
de l'extrême programme alors que aujourd'hui pour faire passer le message et que parce qu'effectivement
scrum existe on parle de scrum xp mais en fait non en réalité quand on regarde de près safe
se base sur l'extrême programming en fait ok pas je pense pas je suis pas intéressant et du coup
comment tu expliques le safe bashing pour je pense que effectivement je constate pour rebondir sur
ta question je constate ce fameux safe bashing qui qui honnêtement prend parfois des tournures de
guerre de religion quoi avec effectivement des rejets on va dire parfois relativement violents bon
je pense que comment il faut faut vraiment se poser la question qui est la question de l'agile à l'échelle
c'est à dire que aujourd'hui le succès de l'agile on pourrait d'ailleurs revenir sur ce succès sur
ce succès de l'agile je pense que au travers de son côté empirique de son côté et quand même
aussi disons au joueur tu vois qu'ils agilent autour bon le fêter quand même bien joué on aime bien
la musique on aime bien ça nous est dans la communauté agile et donc tout cela évidemment ça
ça contribue je pense au succès de l'agile et du coup c'est une supposition mais j'imagine
que les organisations voient dans dans les approches agile une solution à beaucoup de problèmes par
exemple un problème qui est indirect mais qui est tout à fait réel qui est comment est ce qu'on
intègre on fidélise au manage des générations yx c'est des questions tout à fait préniante
aujourd'hui dans les organisations bon et j'ai la sensation que l'agile est perçu de façon plus ou
moins conscientisée de façon plus ou moins exprimée de façon plus ou moins réaliste d'ailleurs
comme une solution à ces questions disons une nouvelle façon de travailler disons le disons
comment tu fais le lien avec les détracteurs justement voilà on est bien d'accord je garde
ta question donc je pense que le le la question est celle ci la question de l'agile à l'échelle bon
à mon sens il n'y a pas d'unique bonne réponse aujourd'hui on est dans beaucoup de complexité
quand même et je pense que la moindre des choses c'est déjà naturellement je dirais de s'appliquer
à nous-mêmes quand je dis nous même communauté agile parce que l'on préconise par exemple le
set base design donc concurrent engineering etc c'est à dire pouvoir mener plusieurs
plusieurs possibilités plusieurs solutions etc et c'est ce qui existe aujourd'hui et tant mieux
je pense que ce besoin d'agile à l'échelle suivant les cas suivant les situations suivant les
équipes suivant les tailles d'équipe suivant les cultures etc il peut être on va dire
régler enfin solutionner une solution peut être par exemple de types spotify mais entre nous toutes
les boîtes ne sont pas spotify enfin voilà chaque boîte à sa culture son historique etc et je
crois que dans dans dans dans dans cette question pour pas dire ce problème ce besoin qu'ont les
organisations je crois qu'aujourd'hui il existe plusieurs types de réponses avec bon si tu veux
là je vais caricaturer un petit peu mais avec une réponse très structurée qui s'adresse à un certain
type de boîte on pourra y revenir un petit peu safe et puis presque à l'opposé entre guillemets et
je dis je dis pas d'ailleurs qu'en réalité son au moins ils ont posé mais c'est un petit peu dans
la perception des choses une autre possibilité qui serait bon bah ok on réunit tout le monde et
tu vois j'ai un entreprise libéré on organise un grand forum ouvert avec éventuellement des
centaines de personnes revient voir ce qui émerge etc etc bon moi si tu veux par rapport à ça
j'ai pas de comment dire je suis pas je pense que je fais un comment dire je je vois pas toutes
ces solutions en termes de bien et de mal je considère qu'il y a des solutions qui sont pertinentes
qui sont adaptées à une situation donnée et d'autres qui ne sont pas adaptées ce que je peux
dire quand même concrètement mon expérience parce que honnêtement au départ quand j'ai
découvert safe dont il y a quelques années 4 5 ans maintenant c'était les toutes premières versions
franchement j'ai eu quand même une réaction un petit peu fin de rejet en tout cas je me suis dit bon
c'est quoi cette usine à gaz il trouve que à l'époque je travaillais donc j'intervenais chez
un client où il y avait plusieurs grosses équipes et nous nous posions la question justement alors
de ce qu'on pourrait appeler l'agile à l'échelle en fait c'est à dire qu'il y avait un portfolio
déjà qui existait de demande d'évolution justement des applis etc et donc on était en train
d'ailleurs d'inventer enfin d'utiliser de mettre en place un camp banc justement à ce niveau bon
et quand j'ai commencé à évoquer safe mais tu vois d'un style du style tient au fait il existe
ce machin là et honnêtement chaque fois que je présente safe à des managers à des personnes et
donc en charge de portfolios etc franchement ces personnes là il y avait des étoiles dans les yeux
quand même et donc je me suis dit bon mais là il y a quand même quelque chose quoi il y a quand
même quelque chose donc donc voilà je crois que je dis pas que c'est adapté à toutes les
tailles de boîte à toutes les cultures etc je dis simplement qu'un monome la vie aujourd'hui
safe effectivement est adapté à des boîtes qui sont plutôt des boîtes disons avec une forte
culture de de process avec des hiérarchies en place etc et je pense que safe du coup peut jouer
un petit peu alors j'allais dire de façon un peu provoque le rôle de cheval de trois c'est à
dire que du un peu comme le scrum d'ailleurs donc on arrive avec somme avec safe puis après
petit à petit c'est le terrain de jeu qui permet vraiment de faire de la gilet je pense que cela
s'appose vraiment à la question d'ailleurs du rôle du développeur dans ce cadre là je crois
quand même pour terminer pour pour terminer ma réponse à ta question sur le fameux sake
bashing je pense qu'à partir de là honnêtement j'ai quand même la sensation qu'il y a en réalité
une certaine méconnéciance une certaine ignorance de ce qui est vraiment safe je pense que là il
faut quand même comprendre que lorsque on propose un cadre qui s'adresse à des centaines de personnes
bien entendu ça peut pas être aussi aussi simple pour pas dire simpliste que le fameux
escargot de scrum c'est quand même un petit peu évident je j'invite vraiment pour découvrir
scrum vraiment de regarder par exemple ce qui est le cost of délais ce qui est le wjf c'est à
dire le pilotage par la valeur la plus rapide qui sont vraiment mais alors typiquement de la gilet
enfin j'ai vraiment la l'imp c'est pas une impression en fait je retrouve dans safe des
des éléments de planification de fonctionnement qui existaient donc à l'échelle d'une équipe
dans l'extrême programmée à l'époque voilà dans le sake bashing je pense qu'en résumé c'est
je pense qu'il faut il faut comprendre que ça n'est pas adapté à tout le monde mais est une
possibilité que je vois pas très bien pourquoi safe serait moins agile que scrum par exemple
en mon sens safe est beaucoup plus agile que scrum puisque safe met en place donc un pilotage par la
valeur met l'accent sur la qualité intrinsèque etc bon donc donc voilà je crois qu'il faut quand
déjà au moins savoir de quoi on parle et comprendre que ben voilà il ya plusieurs bonnes
solutions qui peuvent exister en main donné en fonction justement des clients
et bah écoutez merci ce sera le mot de la fin pour cet épisode je te remercie d'avoir d'être
venu parler de safe et de partager tout ça merci à toi merci à toi de m'avoir donné
l'occasion justement d'évoquer ces sujets qui me qui me tiennent à coeur parce que là on est vraiment
on est vraiment sur sur l'actualité de la communauté à vie et d'ailleurs justement si on veut en savoir
plus je crois que tu tu es crié un peu sur le sujet tu as un blog vers où est-ce qu'on peut aller
j'ai un c'est alors bon en ce qui concerne safe je ne peux que recommander d'aller d'aller visiter
le site de sec dans ce cas de la framework de cliquer par exemple sur core value sur qualité
intrinsèque et puis de voir de voir ce qui est raconté sinon ben ce qui me concerne donc je
gère un site web sur lequel je publie parfois des billets donc qui est tolltech agile.com
ça marche je te remercie merci à toi merci beaucoup cher auditeur merci j'espère que ce
podcast j'espère que ce podcast t'a plu si c'est le cas je t'invite en tout cas même si c'est
pas le cas à aller t'en renseigner un petit peu plus sur ce qui est safe et je vais moi même le
faire puisque ça m'a donné envie d'aller plus loin que ce schéma un peu compliqué et puis
je te souhaite une bonne journée à demain.