Audrey Pedro
Transcription
Bonjour à tous, merci d'être là pour écouter ma présentation sur l'agilité dans un département marketing.
J'ai assisté à pas mal de présentations depuis ce matin. C'est vrai que l'agilité, c'est quelque chose qui vient beaucoup dans le monde de l'IT. Alors, la société de conseil dans laquelle j'ai mis en place la JIT au marketing est une société qui fait du développement logiciel, mais c'est vrai qu'on s'est attaché à appliquer ça au niveau d'un département qui gère des événements, la publication de différents livres blancs, etc., qui gère du marketing communication, des relations presse, etc.
Tout d'abord, l'écran est gigantesque, donc ça fait une photo de moi en très très grand. Audrey Pedro, je suis Product Owner, Product Manager aujourd'hui chez Tiga. J'ai une formation d'ingénieur et j'ai été très rapidement dans le métier du Product Ownership.
Et je vous réexpliquerai par la suite, mais j'ai été amenée à devenir la responsable marketing de la société Xebia. Et donc à déployer un peu toute la stratégie du marketing digital d'une société de conseil.
Alors un petit mot sur Tiga. Tiga, c'est une société qui fait du product ownership, du product management et du coaching produit. Donc ça reprend un peu les thématiques qui ont été abordées par exemple ce matin pendant la session Outcomes over Outputs. Donc l'idée, c'est vraiment de construire le bon produit de manière agile et pertinente.
Tiga fait partie de l'alliance Xebia. Donc ça va permettre de raccrocher les wagons du pourquoi le marketing de Xebia. Donc l'alliance Xebia, en fait, c'est une alliance de plusieurs entreprises qui ont un ADN commun, à savoir l'excellence. Donc dans différents domaines, Xebia, Software Development on Right. Donc les Xebians sont des développeurs passionnés. Qui ont pour mission de faire des applications d'une qualité exceptionnelle. Xebia Labs qui propose l'outil Diploïd. Donc, ah, pardon, petit problème du micro. Je vais éviter de bouger les bras.
UX Republic qui propose de l'expérience utilisateur et donc Tiga sur le product management.
Donc venons-en au sujet de cet après-midi. Il était une fois un département marketing dans une société de conseil nommée Xebia. Qui était assez balbutiement. Xebia existe depuis 2004 en France et le département marketing a été créé en 2012 avec comme objectif d'améliorer la communication institutionnelle de l'entreprise puisqu'elle avait un marketing viral assez important mais peu de présence dans la presse, dans des grands événements, etc.
Donc en janvier 2012, une personne prend la tête du département et se rend compte au bout de quelques mois que finalement, on ne sait pas ce qu'elle a envie de faire, mais a quand même lancé un certain nombre de chantiers. À ce moment-là, on me propose de reprendre le poste à mi-temps, en plus du product ownership que j'avais à l'époque chez SFR. Donc j'arrive, et on avait commencé à construire, mais on avait un peu laissé les choses telles quelles. C'est-à-dire qu'il y avait 4 ou 5 chantiers d'envergure, notamment la refonte globale de toute l'identité visuelle de la société, la refonte du site web, du contenu, des offres, etc. Ou encore le Tech Trends. Le Tech Trends, c'est un magazine sur les tendances technologiques et agiles à venir. Il y a eu un Tech Trends Agilité qui est sorti à l'époque du Scrum Day l'année dernière. L'idée, c'est que l'exébient prenne position sur ce qui sera pour eux l'avenir de l'agilité, du big data, du cloud, etc. Les différentes expertises de la société. Donc tous ces chantiers ont été commencés en parallèle, mais ça s'est un peu arrêté là.
Une fois arrivé ici, j'ai un mi-temps pour avancer sur ces sujets et on se pose clairement la question de maintenir ce département marketing communication du fait du peu de résultats qu'il a donné en un an.
Donc un petit plan d'action par rapport à ça. Il faut allier le marketing, la com et pourquoi pas l'agilité. Je suis product owner de métier, je suis encore en mission d'ailleurs pour SFR, et je me dis, au final, ok, une feature, ce n'est pas un événement, mais pourquoi ne pas tirer parti des principes de l'agilité pour sortir des livrables marketing? Donc, pour reprendre un peu les principes agiles, c'est de se dire, on veut apporter le plus de valeur marketing à l'entreprise, comment on fait pour l'apporter très rapidement? Comment on fait pour essayer de s'améliorer en permanence dans nos process et pour être réactif? Parce que c'est vrai qu'un consultant qui a une super idée d'un article, d'un petit événement, etc., s'il sait qu'il faut un an avant que le marketing ait la force de l'accompagner dans son événement, Il va se dire, OK, j'ai moins envie de contribuer. Alors que s'il voit que le département peut être réactif et agir avec lui très rapidement,
Ça va créer de l'émulation au sein de la société et ça va permettre aussi au marketing de s'appuyer beaucoup plus sur l'ensemble des consultants.
Donc voilà, là j'ai repris les trois principes agiles qui m'ont semblé les plus importants au moment où j'ai commencé à me poser des questions sur ce département marketing. Donc satisfaire le client en livrant rapidement des fonctionnalités, ça va être en produisant rapidement les livrables qui permettent d'avoir une forte valeur ajoutée pour les commerciaux auprès des clients, pour le recrutement auprès des candidats.
Les changements de besoins, oui, il se peut que les commerciaux, finalement, n'aient plus envie que l'événement soit spécifiquement dédié aux décideurs, mais que ce soit un événement plus ouvert. Il se peut qu'il y ait une nouvelle méthode qui soit sortie la semaine dernière et qu'on ait tout préparé autour de SAFE et que finalement, on a un nouveau framework qui sort. Il faut être réactif. Et enfin, l'équipe, au départ, moi toute seule, mais c'est déjà un début d'équipe, réfléchit à comment améliorer la façon de travailler pour être toujours plus efficace. Donc une fois que j'avais un... un peu extrait les principes qui me semblaient entre guillemets applicables à du marketing. La deuxième étape consistait à essayer de les mettre en place. Donc on avait un ensemble de chantiers existants et tous déjà en WIP.
La première chose a été de faire table rase de tout ça et de se dire« Ok, je veux constituer un backlog de chantier marketing priorisé. » Le point le plus compliqué, ça a été de prioriser.
On s'est réunis autour de la table avec l'ensemble des parties prenantes de Xebia, donc le président, le directeur des opérations, le chef des coachs, le porteur des offres cloud, etc. Enfin, l'ensemble des personnes qui avaient des attentes envers ce département. Et on s'est dit, OK, on priorise, on essaye de vraiment se dire, ce chantier-là est le plus important, etc. Donc, on en est venu. Un début de backlog priorisé. Alors on s'est arrêté là parce qu'en fait au bout de deux heures on n'avait arrivé plus trop à prioriser et tout le monde avait mal à la tête. En vrai il restait plein d'actions mais bon comme on le sait en Kanban on n'est pas obligé d'avoir un backlog infini, ce qui compte c'est d'avoir de quoi avancer. Donc le plus important c'était bien sûr la refonte du site web et de l'identité visuelle de la société. Qui avait été commencé. Et puis il y avait des petites actions qui se sont retrouvées à remonter. On avait le score. Scrum Day, alors, je reviendrai sur le point plus tard. C'est vrai que la priorité d'un événement, c'est aussi une question de date. Le Scrum Day, c'est en avril. Bon, ce n'est pas une question que c'est prioritaire par rapport aux offres, mais c'est aussi qu'on a une deadline qui ne peut pas être décalée. Enfin, diminuer le time to market n'a pas forcément de sens. A l'inverse, si on est prêt trois semaines après le Scrum Day, on a un peu raté l'objectif du chantier. Je reviendrai un peu sur cette notion de date fixe, VS, cycle time et ce genre de choses. Le premier point, ça permet un peu de resituer Xebia pour ceux qui ne connaissent pas.
c'était de sortir un site web, puisque le site web de Xebia avait à l'époque 4-5 ans. Et il faut savoir que 4-5 ans dans le monde numérique, c'est très très long. Du coup, le site reflétait plus forcément l'image de la société. Et il n'avait pas été changé depuis longtemps. Par exemple, il a été rechangé à la rentrée, un an et demi après, ce qui est un cycle un peu plus classique. Donc ce premier chantier était un peu l'occasion de mettre en pratique le côté très facile que je connaissais de l'agilité, à savoir gérer le développement logiciel, puisqu'il y avait deux développeurs qui ont travaillé sur le site et moi-même qui avais le rôle. de Product Owner, et un designer également.
Donc on a avancé sur ce premier chantier. Ça a été une bonne entrée en matière. Donc c'est vrai que pour un département marketing, si des PO ont l'occasion, ou des développeurs ont l'occasion de travailler pour aider l'équipe, se raccrocher à des chantiers IT. C'est quelque chose qui permet aussi de montrer tous les intérêts de la méthode O, puisqu'on a sorti ce site au final en un mois et demi, alors que ça faisait plus d'un an qu'ils essayaient de faire avancer le sujet.
Donc une fois qu'on a réussi une première chose en général, l'attente augmente, ce qui est plutôt normal. Et il faut commencer justement à se poser la question de s'améliorer et voir comment peut évoluer le département. Donc ne pas s'arrêter à cette première victoire et ne pas se reposer sur ses lauriers.
Donc là, tout doux, il y avait un... Donc le site web, c'est fini. J'aurais pu le mettre là, d'ailleurs.
J'étais un peu pessimiste en oubliant le travail accompli. On avait donc un certain nombre de sujets à aborder. On était en mi-février 2013, avec le Scrum Day qui approchait. Et donc, j'avais un mi-temps.
Et comme je ne suis pas superman, malheureusement, on a décidé d'embaucher des gens pour renforcer le département marketing, de sorte à pouvoir... adresser un peu tous ces chantiers qu'on avait identifiés ensemble. Donc, deux personnes arrivent et je passe à temps plein, on est trois. Et là, on se dit, youpi, on va tout faire en même temps. Comme ça, on va avancer vite.
Donc forcément, pour tous ceux qui connaissent bien les préceptes de Kanban, ça ne marche pas. Quand on commence à tout faire en même temps, on se disperse un peu. Et donc, comme ça a été longtemps répété aujourd'hui, il faut limiter le work in progress. Mais à l'époque, je n'étais pas du tout une experte de Kanban, mais je ne le suis toujours pas, mais j'ai un petit peu appris un chemin. Et donc, ça a été un peu la première fois où je me suis dit, OK, limiter le WIP, ça a du sens.
Revenons en arrière et prenons sujet par sujet. Tant donné qu'on était trois, puis qu'on a été quatre, puis qu'on a été cinq, puis qu'on a été six,
On a mis en place un système assez simple pour limiter le work in progress. C'était juste un système de gommettes par personne. Et il n'y avait pas plus d'une gommette de chaque couleur dans le WIP. C'est-à-dire que chacun des membres de l'équipe ne pouvait pas travailler sur plus d'une tâche à la fois.
Je sais qu'il existe plein de façons de calculer des limites de WIP. Étant donné que je ne suis pas une experte, j'ai préféré rester à la méthode simple. Et ça a très bien fonctionné. Aujourd'hui, je crois que ça fonctionne toujours comme ça dans le département. Donc voilà.
Alors, l'autre sujet qui a fini par poser problème, donc on limitait le WIP, tout allait bien. Par contre, les gens ont commencé à voir que le département marketing existait et qu'il produisait des choses. Donc, tout le monde a commencé à avoir plein de bonnes idées. Ce qui est hyper positif puisque l'entreprise nous permettait d'avoir une matière phénoménale pour marketer la marque. Le problème, c'est que quand une première personne vient vous voir en disant« il faut faire ça pour demain, et puis ça, il fallait le faire pour hier, et ça, il fallait le faire pour avant-hier», bon, on commence un peu à paniquer et à se dire« ok, on a quand même des limites de WIP, on fait comment? » Et donc là,
On met en place des lignes de neige. Donc deuxième apprentissage par l'expérience de comment ça peut s'améliorer. On a créé une fast line. Par la suite, on a créé différents niveaux de priorité. La fast line, on avait une place. Tout le monde venait nous voir en nous disant« c'est le truc le plus enjeu». On se met autour de la table, on réfléchit. Il y a une place pour ajouter un truc en express maintenant qui est pour avant-hier.
Donc, c'était un peu les premiers apprentissages de l'équipe. Et ça nous a permis de rentrer dans un cycle un peu plus tranquille, où on était moins dans l'urgence permanente.
Mais on se posait toujours la question de comment on s'améliore. Et donc, comme le dirait Renaud, pour s'améliorer, il faut mesurer. Mesurer l'état actuel pour savoir vers où aller et qu'est-ce qu'il faut améliorer.
Donc, on a mis en place des KPI. Alors, est-ce que quelqu'un a des idées de KPI pour suivre un chantier événementiel, par exemple? Presse maintenant, qui est pour avant-hier.
Donc, c'était un peu les premiers apprentissages de l'équipe. Et ça nous a permis de rentrer dans un cycle un peu plus tranquille, où on était moins dans l'urgence permanente.
Mais on se posait toujours la question de comment on s'améliore. Et donc, comme le dirait Renaud, pour s'améliorer, il faut mesurer.
Mesurer l'état actuel pour savoir vers où aller et qu'est-ce qu'il faut améliorer. Donc, on a mis en place des KPI. Alors, est-ce que quelqu'un a des idées de KPI pour suivre un chantier événementiel, par exemple?
Le nombre de participants, tout à fait. Le nombre de participants.
La qualité des adresses, ce genre de choses. Donc il y a le nombre de participants, le taux de nos shows. Par exemple, sur un événement qu'on organise nous, c'est quelque chose qu'on suit très près, parce que les événements gratuits, c'est facile de s'inscrire. Par contre, venir, il faut quand même avoir la motivation de se déplacer. Les adresses mail récoltées, la qualité des adresses mail aussi, adresses perso, adresses pro, etc.
Pour la publication d'un Tech Trends, ça va être le nombre de clics sur télécharger. Ça peut être un suivi un peu plus qualitatif, mais le suivi sur Twitter par rapport à un événement, quelles ont été les mentions positives, négatives de notre événement, qui a mentionné l'événement.
Ce genre de choses. Donc on a commencé à lister un petit peu des indicateurs qui nous permettraient de suivre les différents chantiers.
Et on a également mis en place des rétrospectives systématiques pour chacun des chantiers. Par exemple, on organise un événement ou pour le Tech Trends, on sort le Tech Trends Agile, l'ensemble des auteurs qui ont contribué.
Viennent au bureau et on va passer deux heures à se dire, OK, qu'est-ce qui a bien fonctionné, qu'est-ce qui a moins bien fonctionné?
Pour la rétrospective du Tech Trends Agile, c'est facile. On avait plein de coachs pour animer la rétrospective. Donc on a fait des rétrospectives dans des schémas variés. Et l'idée, c'est justement de prendre ces actions d'amélioration vues depuis les personnes qui travaillaient avec nous pour essayer d'être... meilleure. Donc, des actions qui ont fonctionné, d'autres moins. En tout cas, on se posait toujours la question de comment faire mieux.
Jusque-là, rien d'exceptionnellement nouveau.
C'est du Kanban, de l'agilité, appliqué à un contexte un peu différent. Du coup, j'ai voulu un peu faire un focus sur qu'est-ce que ça change d'avoir affaire à des chantiers marketing versus un produit numérique. Quels sont vraiment les points d'attention si vous voulez changer un département marketing?
J'ai listé ce qui m'a le plus impactée de mon expérience. Je pense qu'il y a plein d'autres points qui peuvent être mis en avant et que ça dépend clairement des sociétés, du vécu de la personne qui va mettre en place ça.
Quand on parle de logiciel, souvent on parle de produit. Il faut qu'on sorte un produit qui répond à un problème utilisateur. Quand on parle du marketing d'une société de conseil, on va parler d'une marque. On va vouloir faire en sorte que la marque de notre société ait une belle image, que les événements, les publications soient de qualité. Donc on va essayer d'expliquer aux clients qu'on peut répondre à un problème.
Alors, un autre point très important sur lequel je vais vraiment pas mal me... Me focusser parce que je connais des débats sur on peut toujours prioriser. Il y a des fois dans le marketing, on ne peut pas. Il y a deux événements le même jour ou en tout cas la même semaine. Il faut être aux deux événements parce que c'est le cœur de métier de la société. On ne peut pas prioriser. Comment on fait?
Le côté dépendance-adhérence, c'est vrai que dans des équipes de développement, pour être product owner sur des sociétés, par exemple aujourd'hui dans une équipe qui ne fait que le back-end, on a pas mal d'adhérence avec l'équipe qui fait le front.
Dans une équipe marketing, on a des dépendances dans le sens où le contenu est rédigé par des gens qui ne sont pas dans l'équipe. Le contenu est fourni par des gens extérieurs. Donc c'est vraiment une dépendance très forte, dans le sens où le département marketing ne vit pas sans ces gens-là.
Et enfin, il y a des parties de process qui ne sont pas du tout agilisables. Alors, dans le développement logiciel, ça peut aussi être vrai, avoir des testeurs qui sont un peu réticents, un métier très cyclanvé, etc. Mais on sait, on l'a vu dans certaines sociétés, c'est possible d'agiliser toute la chaîne. Chez Spotify, etc. On arrive à faire du DevOps, comme on l'a vu tout à l'heure chez les Furets, ils font du continuous delivery, etc. C'est possible.
Sur du département marketing, quand on travaille avec un imprimeur, l'imprimeur, il allume sa machine, pour 500 impressions. Il n'allume pas sa machine pour deux impressions et pour vous dire, est-ce que ça vous va? Et ensuite, on fait des loops. Une fois que c'est rentré chez l'imprimeur, ça sortira 500 exemplaires, que ça a été bon ou pas. Donc il y a des parties entières du processus qui ne peuvent pas être agilisées. Et du coup, la question c'est, dans ce cas-là, qu'est-ce que je fais?
Donc, tout d'abord, produit VS Mark. J'ai pris un exemple qui n'a rien à voir avec le développement logiciel, justement pour un peu mettre en avant la différence entre les deux sujets. Un produit, par exemple un déodorant, qu'est-ce qui fait qu'il va résoudre votre problème? Le déodorant va vous permettre de ne pas sentir mauvais, de vous sentir à l'aise, de vous sentir bien quand vous faites un talk devant 50 personnes. Et du coup, vous allez le racheter parce qu'il a répondu à votre problème. Après, est-ce que vous reprenez cette marque-là ou une autre marque? Ça va plutôt être dans l'affect, dans l'humeur aussi potentiellement. Mais en tout cas, vous savez qu'il y a plusieurs marques qui peuvent répondre à ce même problème.
De la même manière, Apple, j'ai un Mac, parce que je sais que j'ai besoin d'un ordinateur pour travailler. Après, pourquoi je prends Apple? Parce que j'ai un lien à la marque qui est que je considère que c'est des produits faciles à utiliser, que je ne vais pas avoir trop de virus, etc. J'aurais pu prendre un PC. Donc la différence entre le problème à résoudre et le fait qu'on est... et plusieurs sociétés à résoudre le même problème.
Enfin, Xebia a un certain nombre de concurrents sur le marché. Et l'idée, c'est d'expliquer aux clients qu'on est les meilleurs pour résoudre ces problèmes-là, même si on n'est pas les seuls à les résoudre.
Donc le sujet Release VS Événements, qui rejoint un peu aussi ce produit VS... VS Mark, en fait, je voulais faire le focus sur un point précis. Donc, une release. Alors j'ai pris directement le triangle des agilistes, je n'ai pas pris le triangle du fou. Donc la qualité n'est pas négociable, par contre on peut jouer sur le périmètre, les coûts ou les délais.
Quand on parle d'un événement, le délai n'est pas négociable. Après, ça dépend, vous avez peut-être beaucoup d'influence, mais personnellement, j'ai du mal à expliquer à Devox que finalement, cette année, ça serait bien qu'il le décale de deux semaines parce que j'ai d'autres chantiers à gérer et que ça serait bien pratique. Donc le délai n'est pas négociable, par contre on peut gérer coût, contenu, animation, enfin en vrai je pense que c'est plus qu'un triangle, il y a plein de choses qui rentrent en compte, mais c'est une différence fondamentale. Dans le sens où, si on n'est pas prêt, l'événement a lieu quand même.
Si on n'a pas réfléchi par rapport à cette date-là, on a raté, enfin on peut d'office considérer que l'événement est un échec. Donc l'indicateur principal, pour un événement, c'est vraiment cette notion de temps. Et on va plutôt réfléchir en rétro-planning. Après, dans la mesure où on va avoir par exemple plusieurs événements, il va falloir caler le multitasking, mais on reviendra là-dessus après. On va plutôt réfléchir en termes de rétro-planning que vraiment de se dire« je commence aujourd'hui et l'idée c'est que j'ai fini demain ou après-demain, en tout cas le plus vite possible». On ne va pas chercher cette notion de temps réduit entre le début et la fin d'un chantier.
Donc, exemple concret. En avril 2014, aux Grandes Joies, trois événements la même semaine. Sinon, c'est trop simple. Des Vox, grande conférence Java parisienne. Java est le cœur de métier de Xébien. Le Scrum Day, grande conférence agile parisienne. L'agilité fait partie de l'ADN de Xébien. Et French Tech Safari, alors ça peut paraître un peu plus exotique, la French Tech organisait un safari où l'idée c'était de proposer aux gens qui avaient participé à un challenge de start-up de rencontrer des sociétés qui techniquement pouvaient les aider à réaliser leurs produits. Donc on a été contacté par la French Tech pour que Xebia soit parmi ces entreprises qui potentiellement pouvaient aider des gens à bootstrapper leurs projets, à sortir un MVP, etc.
Alors la première question, c'est est-ce qu'on fait les trois? Question légitime. Quand on réfléchit priorisation, il faudrait se dire non, on en choisit un et on le fait bien, plutôt que de faire les trois un peu n'importe comment. Le problème, c'est que, alors autant le French Tech Safari, on aurait pu ne pas le faire, Ça se discute. Autant des Vox et Scrum Day, c'était... Comme de dire, je coupe une des deux jambes. C'est un peu les deux piliers de Xébia, et on ne pouvait pas ne pas être présent.
Donc une fois que les longues discussions autour de... Entre en plus coach et développeur qui se tapent dessus à dire« Non, non, c'est mon événement le plus important, non, c'est le mien! » et qu'on en arrive à« Bon, les deux sont importants. » Qu'est-ce qu'on fait?
Qu'est-ce qu'on fait? Alors, soit on prend toute l'équipe, donc à l'époque, on était quatre, et on travaille un peu sur les deux sujets. Soit, option 2 que nous avons choisie, on dédie un responsable pour chacun des deux projets, qui est garant de faire avancer la chose. Et les autres se renseignent quand même un petit peu, mais restent quand même focalisés sur leur projet. Alors ça crée des silos, parce que du coup on était deux à travailler sur DevOps, deux à travailler sur le Scrum Day, et au final on n'a plus vraiment l'impression d'être une équipe. Mais ça rejoint un principe que je suis en train de revivre en ce moment même en mission, où j'ai une même équipe qui travaille sur deux produits, Ça ne marche pas. Il vaut mieux séparer l'équipe le temps de sortir, de réaliser le projet, que d'essayer de faire tous tout en même temps.
Donc on peut se rattacher aux bonnes pratiques agiles sur des sujets comme la gestion de deux événements en parallèle.
Le sujet des adhérences.
Donc, comme je vous le disais, 80% du contenu,
qu'on utilise dans un département marketing, ce n'est pas nous qui le produisons. Parce qu'on n'a pas la compétence de connaître tout le métier d'exibia, parce que techniquement, c'est des métiers assez complexes, il faut rentrer en profondeur. On a un vernis qui nous permet de comprendre de quoi nous parlent les consultants, mais je ne vais pas être capable de rentrer dans le détail de l'offre Big Data aujourd'hui et pourquoi Hadoop est mieux que Couchbase ou que MongoDB.
À partir de là, il faut qu'on arrive à impliquer ces gens qui ont eux en plus un vrai métier, c'est-à-dire qu'ils sont en mission pour qu'ils produisent ce contenu permettant de marketer la marque Xebia.
Alors, au premier abord, ça a été vraiment le point le plus dur de mon point de vue.
Puisque ces gens-là, quand ils vous aident, ils vous aident entre deux comites sur leur mission. Du coup, il faut arriver à les impliquer. Et donc la solution, c'est justement une implication forte des personnes dans l'équipe pour qu'au final, elles fassent partie d'une sorte d'équipe étendue. De la même manière que quand vous voulez faire du DevOps, il faut arriver à faire en sorte que les devs... et les ops, et l'impression de faire partie de la même équipe et fasse partie de la même équipe, il faut arriver à faire en sorte que vos consultants qui contribuent se sentent partie de l'équipe marketing. Et un indice de réussite par rapport à ça, c'est que quand je suis partie du département marketing de Xebia, un des consultants m'a dit« Ah, tu sors de l'équipe». Donc, il n'était pas physiquement avec nous, mais il se sentait vraiment partie intégrante de l'équipe. De sorte à transformer justement les dépendances très fortes en adhérence, puisqu'on ne peut pas complètement effacer ça. Par exemple, on a régulièrement besoin de créa. Du coup, il y a une personne qui fait de la créa qui est là deux jours par semaine.
On a besoin d'imprimeurs, etc. Donc, on va avoir des adhérences avec des gens externes à l'équipe, mais on ne va plus être complètement bloqués. Et en fait, c'est ça le gros risque d'un département marketing pour une société du type de Xebia, c'est de se retrouver avec aucun contenu. Donc une belle machine qui tourne, mais rien à produire. En tout cas, pas de fonds pertinents. Et ça peut vraiment, c'est ce qui peut mettre vos chantiers en échec.
Et enfin, le sujet du cycle en V de certaines parties du process. J'ai repris l'image de l'imprimante pour le print de livre, parce que c'est le premier sujet auquel j'ai été vraiment confrontée. On a sorti pour le Scrum Day justement le Tech Trends Agile. Et quand on sort un bouquin, il faut rédiger le contenu, évidemment.
Il faut le mettre en forme et puis il faut le faire imprimer.
Et donc voilà ce qu'on vous explique.
On fait une phase de rédaction de contenu. Ensuite, on fait une phase de mise en forme par un studio de créa et une phase d'impression. Donc on retrouve un beau cycle en V. En même temps,
C'est normal, je ne connais pas d'imprimeur qui est prêt à lancer des imprimantes qui leur coûtent un bras, etc. Pour cinq exemplaires. C'est le modem même du taylorisme et de tout ce qui est industrie. C'est de se dire que c'est des machines qui coûtent énormément, qui sont amorties sur des années et des années. Ce ne sont pas des milieux changeants. Donc l'agilité, elle n'a pas de sens là-dedans.
C'est juste une aberration. Eux, on leur dit, oui, mais moi, j'ai envie de voir d'abord. Ben non, tu me fournis un truc et puis tu verras bien ce que ça donne.
Mais ça n'oblige pas à faire toute cette partie-là. En cyclant V.
Et la reco de mon expérience, c'est vraiment de limiter ces bouts de cycle en V au bout qui est vraiment obligatoire du fait de l'industrie, de votre fournisseur, etc. Et en fait, ce qu'on a fait, c'est que cette partie-là, on l'a fait de manière itérative. On a rédigé le contenu, on l'a mis en forme, on a recorrige le contenu, on a remis en forme. Pour les illustrations, pareil, on s'est vraiment ici fait une énorme boucle de feedback. On a fait relire par le recrutement, on a fait relire par des consultants, etc. De sorte à ce qu'ici, au final,
on n'est plus peur du petit cycle en V. En tout cas, moins peur. J'ai toujours très peur quand j'en vois quelque chose à printer, malgré les risques qu'on diminue. C'est toujours le moment où on se dit« bon, j'ai laissé une faute d'orthographe, je suis foutue». Mais en tout cas, on a vraiment récupéré un maximum de feedback ici. Et on a limité cette zone. Donc tout ça pour dire que ce n'est pas une fatalité. Oui, il y a des choses qui ne sont pas légalisables. Et à un moment, il faut en prendre acte et ne pas essayer de forcer les choses. Par contre, ça ne veut pas dire qu'il faut baisser les bras sur le reste.
Donc aujourd'hui, l'amélioration continue et en marche. En tout cas, je l'espère. Maintenant, je suis partie depuis quelques mois. Je vois quand même les échanges sur Twitter, etc.
Le département est réactif dans le sens où quand on a une demande qui arrive d'un consultant, du département commercial, etc., on est capable de traiter la demande vite et les gens n'ont pas l'impression d'avoir affaire à un mur.
À continuer maintenant à la personne qui a pris la main. Mais c'était en tout cas une superbe expérience de se poser les questions justement par rapport aux spécificités de ce métier et de pouvoir réfléchir à une autre façon, une autre forme d'agilité qui n'est du coup pas celle du développement d'un produit.
Merci beaucoup. Il reste un peu de temps pour les questions.
Et pour plus d'informations,