Agile Marketing : comment commencer à appliquer la méthodologie

Profitant du fait que la semaine dernière j’ai publié un tutoriel sur Trello, je me suis dit qu’il pourrait être utile d’expliquer comment j’applique la méthodologie Agile dans mes projets.

Peut-être que les méthodologies agiles ne te disent pas grand-chose.

Ou peut-être penses-tu qu’elles sont réservées au développement logiciel et aux produits numériques.

Rien n’est plus faux : elles peuvent en réalité s’appliquer à n’importe quel processus, projet ou département.

Et cet article comporte deux parties très distinctes :

• Dans la première, je te parlerai un peu de ce que sont les méthodologies agiles et de la façon dont tout a commencé. La théorie qui les sous-tend et leurs concepts.
• Dans la seconde partie, je vais t’expliquer comment je mets en pratique les éléments de cette méthodologie que j’aime dans les équipes marketing, afin que, si cela t’intéresse, tu puisses commencer à les appliquer à la tienne dès maintenant. La partie pratique et opérationnelle.

Si tu connais déjà la première partie, tu peux aller directement ici.

Commençons par le commencement.

Partie 1 : En quoi consiste la méthodologie Agile

C’est une approche de la prise de décision en gestion de projet qui met l’accent sur le développement de fonctionnalités de manière incrémentale et itérative, en apportant davantage de valeur à l’utilisateur / client à chaque cycle.

Elle apparaît d’abord dans le développement logiciel puis s’étend rapidement à d’autres domaines, comme la gestion de projets de tout type (pas seulement logiciels), la création de produits, l’UX ou le marketing.

Elle s’oppose aux modèles en cascade -où il faut avoir terminé une partie du projet avant de commencer la suivante- car ils sont jugés trop bureaucratiques, et met fortement l’accent sur la communication entre les parties, plutôt que sur la documentation.

Ça paraît bien, non ? Mais tu te demandes peut-être comment tout cela est né.

Eh bien, tu vas le voir.

Histoire de la méthodologie Agile

Au milieu des années 90 est apparu un courant de rejet de la gestion de projet structurée, qui a abouti à une convention en 2001 à Snowbird, dans l’Utah.

C’est là que le terme « Agile Methodology » a été employé pour la première fois, que l’« Agile Alliance » a été créée et que l’« Agile Manifesto », qui rassemble les principes de la méthodologie, a été publié.

Le Manifeste Agile

Tu peux lire le document original ici :

http://agilemanifesto.org/

Les quatre valeurs du Manifeste

Comme tu as pu le voir dans le lien ci-dessus, le document indique que :

« Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire. Ces expériences nous ont amenés à valoriser :

• Les individus et leurs interactions plus que les processus et les outils
• Des logiciels opérationnels plus qu’une documentation exhaustive
• La collaboration avec les clients plus que la négociation contractuelle
• L’adaptation au changement plus que le suivi d’un plan

C’est-à-dire que, même s’il y a de la valeur dans les éléments à droite, nous accordons plus de valeur aux éléments à gauche. »

Et ces quatre valeurs se déclinent en ces douze principes.

Les douze principes du Manifeste Agile

Tu les trouveras ici :

http://agilemanifesto.org/principles.html

Mais je te les recopie :

1. “Satisfaction du client. C’est la base de tout. Elle s’obtient en livrant des produits de valeur qui répondent à un besoin.
2. Accueillir favorablement les nouveaux besoins. Changer en cours de route n’est pas faire marche arrière. Toute suggestion ou solution est bienvenue si elle améliore le produit.
3. Livraisons hebdomadaires. Diviser le travail en phases productives est au cœur de la méthodologie. Dans la mesure du possible, en réaliser une chaque semaine.
4. Les progrès peuvent être mesurés. L’évolution des processus n’est pas subjective. Elle peut être mesurée à l’aide d’indicateurs concrets.
5. Développement durable. La manière d’exécuter les projets doit garantir leur continuité. Il ne s’agit pas de faire pour faire.
6. Travail de proximité. Les responsables de projet doivent exercer leur rôle là où les tâches sont réalisées, et non depuis leurs bureaux.
7. Conversation en face à face. Le responsable doit communiquer efficacement ses messages, de préférence en présentiel. Des réunions régulières avec le client comme avec les collaborateurs sont recommandées.
8. Motivation et confiance. Les processus ne réussiront que si ceux qui les mettent en œuvre sont motivés et évoluent dans un climat de confiance et de solidarité.
9. Excellence technique et bonne conception. La forme ne doit jamais se perdre, pas plus que la qualité du travail. Tout forme un ensemble.
10. Simplicité. Les tâches doivent être aussi simples que possible. Si l’une d’elles ne peut pas être exécutée ainsi, elle doit être divisée en itérations jusqu’à réduire son niveau de complexité.
11. Autogestion des équipes. Même s’il doit exister une personne chargée de suivre les équipes, celles-ci doivent être capables de s’organiser seules. Un excès de hiérarchie crée de la dépendance entre les collaborateurs.
12. Adaptation aux circonstances changeantes. Les projets ne se terminent généralement pas comme ils ont commencé. Il est indispensable que ceux qui les exécutent puissent s’adapter aux différentes circonstances qui peuvent survenir. »

Je ne sais pas ce que tu en penses, mais si tu as déjà participé au développement de produits numériques, il est difficile de ne pas être d’accord avec absolument tous ces points.

Très difficile.

À tel point qu’aujourd’hui, vu son utilité dans son domaine d’origine, cette méthodologie a, comme je le disais, été transposée à la gestion de toutes sortes de projets, voire de secteurs.

On parle de « Conception de produit Agile », d’« Agile Marketing » et d’« Agile Management », avec toujours l’objectif de mettre l’accent sur :

• Communication en face à face.
• Transparence.
• Satisfaction du client.
• Simplicité.
• Développement incrémental et amélioration continue.

Tu commences à voir l’intérêt de la méthodologie ?

Passons aux éléments indispensables.

Éléments et concepts de base de la méthodologie Agile

Bien. Tout ce qui a été expliqué jusqu’ici est très joli, mais pour commencer il faut ramener la théorie sur terre et expliquer les différents éléments qui rendront possible sa conception et son exécution.

Le framework

Même si toutes les méthodologies agiles reprennent les mêmes principes et valeurs, chacune les applique différemment.

Et ces différentes façons de faire correspondent aux différents frameworks ou cadres de référence.

Il en existe plusieurs, chacun avec ses règles, ses avantages, ses recommandations et ses inconvénients. Les deux plus courants et les plus connus sont Kanban et Scrum.

Kanban

Il apparaît au Japon après la Seconde Guerre mondiale, qui a plongé le pays dans un désastre économique et technologique.

Dans les années 50, Toyota a conçu un système de production « just in time » (JIT) dans lequel chaque pièce était fabriquée exactement au bon moment, ni avant ni après, et qu’elle a qualifié de « très efficace et efficient ».

Pour le mettre en œuvre, on s’appuyait sur des cartes qui identifiaient les besoins en matériaux dans la chaîne de production.

Cette méthodologie reprend donc l’idée des cartes et assimile chacune d’elles à une tâche.

On crée un tableau avec une colonne pour chaque état par lequel une tâche doit passer, par exemple :

• Définie.
• En cours.
• Terminée.
• Révisée.

Voici un exemple de tableau simple, mais il peut être rendu aussi complexe que le projet l’exige. Un exemple de tableau plus complexe pourrait être :

• Définition.
• Analyse.
• Développement
• Tests.
• Mise en production.
• Documentation.

Le tableau sera différent pour chaque entreprise ou équipe selon ses besoins, et il s’applique aussi bien aux projets de nouveau développement (« lancer le blog », « ouvrir une chaîne TikTok ») qu’aux tâches de maintenance (« révision des bannières du site ») ou récurrentes (« révision des commissions d’affiliation », « reporting ecommerce hebdomadaire »).

Le tableau peut être physique (c’est ce qui est recommandé pour qu’il soit visible et transparent pour toute l’équipe) ou numérique, et c’est là que Trello entre en jeu.

Scrum

Il ressemble au précédent puisque, comme je te le disais, les principes et la philosophie sur lesquels ils reposent sont les mêmes.

Le nom pourrait se traduire par « mêlée » et vient du rugby, lorsque toute l’équipe se regroupe.

Ils se distinguent par de petites nuances, peut-être parce que Scrum est considéré comme plus restrictif et, d’après mon expérience, davantage orienté vers le développement de produits numériques :

• Recommande des équipes interdisciplinaires. Kanban autorise les équipes spécialisées.
• Rôles précis: Scrum Master, Product Owner et équipe de développement sont obligatoires en Scrum ; en Kanban, tu peux les avoir ou non
• Itérations de durée déterminée (entre 1 et 4 semaines) : les sprints (on insiste beaucoup là-dessus).
• Les changements : ce qui entre dans un sprint est immuable et les changements souhaités sont reportés au sprint suivant afin de pouvoir mesurer le processus de combustion ou Burndown (ce n’est pas tout à fait aussi simple). Avec Kanban, les changements sont plus faciles à exécuter, car on peut remplacer une fonctionnalité moins prioritaire par la nouvelle souhaitée.
• Cérémonies précises à durée fixe.
• Nouveau tableau à chaque sprint, contre le tableau persistant de Kanban.

Pour toutes ces raisons, personnellement je préfère Kanban pour l’Agile Marketing, et c’est cette méthode que je vais t’expliquer dans cet article.

En fait, même si ce n’est pas le plus courant, j’ai vu et utilisé des modèles hybrides :

• Utilisation de Scrum pour les nouveaux développements et de Kanban pour les tâches récurrentes au sein de la même équipe. C’est ce que nous avions chez Lowi.
• La méthodologie « Scrumban », qui emprunte des éléments aux deux.

User stories

Peut-être le cœur de la méthodologie.

Il s’agit d’une façon simple de décrire une tâche concise qui apporte de la valeur à l’utilisateur ou au client.

Elles sont généralement rédigées sur des cartes (à la main sur des post-it ou numériquement) et comprennent :

1. Titre : bref, pour pouvoir y faire référence.
2. Description : En tant que [rôle de l’utilisateur] Je veux [fonctionnalité] Afin de [Objectif de la story]. Exemple : "En tant qu’utilisateur du blog, je veux voir des articles associés à la fin de l’article afin de continuer à lire des sujets qui m’intéressent« .

En outre, elles doivent posséder ces caractéristiques :

1. Indépendantes : les unes des autres. Elles doivent pouvoir être traitées séparément, même si elles sont liées. Par exemple, dans une campagne publicitaire, la tâche de design sera séparée de celle de copywriting, même si les deux doivent évidemment être liées.
2. Négociables : la portée et les détails sont convenus entre les deux parties et renégociés si nécessaire, par exemple en divisant la tâche en deux parties.
3. À valeur ajoutée : elles doivent apporter une valeur réelle au client, quelque chose de tangible.
4. Estimables : c’est-à-dire que l’effort requis pour leur exécution peut être analysé. En temps ou en points de développement.
5. Petites : si elles sont trop grandes et ne peuvent pas être estimées, elles doivent être subdivisées.
6. Vérifiables : testables, avec des critères d’acceptation binaires (ça passe ou ça ne passe pas).

Une fois rédigée, la tâche est placée dans la colonne initiale du tableau puis déplacée d’une colonne à l’autre au fur et à mesure que son état change.

Le Backlog

Il s’agit de l’ensemble des tâches du projet déjà rédigées et restant à traiter.

L’Équipe

Selon la méthodologie, il est indispensable ou non de disposer de certains rôles dans l’équipe.

Par exemple, en Scrum, on trouve habituellement :

• Product Owner : responsable métier du produit.
• Scrum Master : personne qui résout les problèmes et facilite le développement. Elle peut être ou non le leader de l’équipe.
• Équipe de développement / spécialistes (UX, designers, SEO…) : concrètement, les personnes qui exécuteront la majorité des tâches.
• Tech lead : responsable technique de l’équipe. Il peut s’agir de la même personne qui joue le rôle de Scrum Master.
• QA : tests.

En Kanban, ces rôles ne sont pas nécessaires, même s’il est vrai que plus le rôle de chaque membre de l’équipe est clairement défini, plus il lui sera facile d’évaluer la tâche puis de la réaliser.

Sprints

Durée d’une itération, d’un cycle ou d’une livraison pendant laquelle une ou plusieurs nouvelles fonctionnalités ou améliorations prioritaires (features) d’un produit numérique seront livrées, ou les tâches correspondantes du cycle seront réalisées (« créer les contenus Instagram »).

Ils durent généralement entre une et quatre semaines. Dans le développement de produits numériques, ils durent souvent deux ou trois semaines, tandis qu’ en marketing ils peuvent parfaitement durer une semaine.

L’objectif du Sprint

Dans le développement de produit, ils ont un objectif du Sprint, qui regroupe la plupart des fonctionnalités que l’on souhaite traiter.

Dans d’autres types de projets, cet objectif n’est pas toujours nécessaire.

Cérémonies

C’est ainsi que l’on appelle les réunions d’équipe propres à la méthodologie.

Voici les plus courantes, chacune ayant sa durée, sa fréquence et ses objectifs :

Elles servent à analyser puis à améliorer de manière itérative le développement et les processus

• Daily : chaque jour, les membres de l’équipe expliquent très brièvement ce qu’ils vont faire ce jour-là et si quelque chose bloque une tâche précédente, afin de discuter des étapes à suivre pour lever le blocage. Cela devrait durer environ cinq minutes.
• Sprint plan : à la fin du sprint en cours, l’équipe se réunit pour discuter de la façon d’aborder le sprint suivant et estimer les tâches.
• Refinement : c’est l’étape précédant la cérémonie précédente. Lors du refinement, il s’agit de faire en sorte que chaque story soit suffisamment claire et compréhensible pour l’équipe et que sa portée soit définie afin de pouvoir être estimée lors du Sprint plan.
• Retrospective : après la clôture du sprint, on analyse comment les choses se sont passées, les problèmes rencontrés et les pistes d’amélioration à envisager pour les prochains sprints.

Si l’on parle de marketing, toutes ces cérémonies sont-elles indispensables ?

Je te donnerai ma réponse plus loin, car la théorie s’arrête ici.

Je vais maintenant t’expliquer comment je l’ai appliquée à partir de zéro dans différentes équipes et différents projets.

Tu verras aussi que l’approche est très simple et qu’il n’est pas nécessaire de procéder à des changements radicaux ni d’adopter de nouveaux outils pour commencer à appliquer les principes agiles.

Partie 2 : Le processus de mise en œuvre de la méthodologie Agile en Marketing

Si tu n’as jamais eu d’expérience avec les méthodologies agiles, la première chose que je veux que tu fasses est de lire plusieurs fois le manifeste et ses principes, car, en réalité, cela suffit pour comprendre et appliquer certains concepts.

Il s’agit d’un changement d’état d’esprit où je dirais que l’essentiel est de parler et parvenir à des accords entre les parties (responsables, ta propre équipe, équipes externes…) en sachant que tu cherches tous le bien commun.

Deuxièmement, être flexibles. Comprendre que les changements vont arriver et qu’il faut les accepter. Même si ça nous agace. Cela ne signifie pas toujours « céder », mais revenir au point précédent : parler et se mettre d’accord.

Troisièmement et enfin, mesurer. Parce que mesurer est la seule façon de savoir à quel point notre performance est optimale, celle de notre équipe, et si toutes les actions que nous menons valent réellement la peine.

Très bien, une fois que tu as bien intégré cela, passons au système.

Le système de l’Agile Marketing

L’idée est que ton équipe est capable d’exécuter un nombre limité de tâches dans un temps donné.

Nous allons appeler cette période un sprint et, pour commencer, le plus simple est qu’il dure une semaine.

Tu devras donc organiser un système afin que chaque semaine (sprint), le bon nombre de tâches soit réalisé.

Combien de tâches ? Au début, tu ne le sais pas, car tu n’as pas d’historique. Donc, lors des premiers sprints, le mieux que tu puisses faire est d’ estimer avec une certaine marge d’erreur, qui diminuera à mesure que ton équipe et toi gagnerez de l’expérience.

En plus, tu n’as pas encore l’habitude de rédiger les tâches, ce qui ajoute une difficulté supplémentaire à l’estimation.

Mais rassure-toi, ce manque de certitude ne durera pas longtemps : après plusieurs sprints, une fois que tu auras mesuré et appris à rédiger correctement les tâches, tu disposeras de données pour bien mieux estimer chacune d’elles.

En sachant donc comment cela va évoluer, la première chose à faire est de trouver un outil où créer le backlog et noter toutes les tâches du sprint.

Les outils de l’Agile Marketing

Tu en as plusieurs, selon que tu les préfères en ligne ou hors ligne.

Les avantages de chaque type ?

Je te dirais que les outils en ligne sont plus immédiats et peuvent coûter très peu, tandis que les solutions hors ligne, qui consistent essentiellement en un tableau et des post-it, rendent très clair pour toute l’équipe ce sur quoi elle travaille et mettent ce travail en valeur auprès de l’entreprise.

Ma recommandation ?

Sauf dans les cas où il est indispensable de rendre parfaitement visible tout ce qui est en cours, commence avec un outil en ligne.

Je t’en recommande deux, selon ton degré de conviction : Excel si tu veux tester et Trello si tu es convaincu que ce système est fait pour toi.

Agile Marketing avec Excel

Je dis Excel parce que c’est le plus répandu, mais n’importe quel tableur (Google Sheets, LibreOffice…) fera l’affaire.

L’idée ici n’est pas tant de parler de Kanban et de tableaux que de commencer dès maintenant à appliquer les principes agiles.

Pour cela, tu vas créer un document dans lequel tu ajouteras toutes les tâches à réaliser, les unes sous les autres. Ce sera ton Backlog.

Tu créeras aussi une série de colonnes pour t’aider à définir chaque tâche, planifier et mesurer la performance de l’équipe ainsi que l’effort demandé par chaque type de tâche :

Dans ce cas, les colonnes que nous avons sont :

• Priorité : même si l’on pourrait placer les tâches les plus prioritaires du sprint en haut, cela nous empêcherait de filtrer, donc nous ajoutons une colonne.
• Marque : si tu travailles avec plusieurs clients ou marques, cela te permettra de segmenter par chacun d’eux.
• Tâches : ici, nous ajoutons uniquement le titre car, en général, ce sont des tâches que nous connaissons déjà et qui ne nécessitent pas de descriptions plus détaillées.
• Commentaire : dans tous les cas, si nous avions besoin de plus de détails, nous les ajouterions ici.
• Type de tâche : cela va nous permettre de savoir combien de temps nous consacrons à chaque activité différente et d’analyser :
• Si le temps investi en vaut la peine.
• Si le temps d’exécution diminue à mesure que la personne gagne en expérience sur le même type de tâche.
• Personne : tout simplement, qui va la réaliser.
• État de la tâche : Non commencée, Commencée ou Terminée.
• Date d’entrée : la date de début du sprint, qui nous permettra de filtrer ce qui est réalisé dans chaque sprint.
• Début : date à laquelle la tâche passe de l’état Non commencée à Commencée.
• Heure de début : l’heure à laquelle une tâche commence.
• Heure de fin : l’heure à laquelle une tâche se termine.
• Effort en heures : la différence entre l’Heure de début et l’Heure de fin.
• Semaine : pour connaître la semaine de l’année et pouvoir comparer plus tard ou créer des graphiques.

À chaque sprint, les nouvelles tâches seraient ajoutées avec leur Date d’entrée, et un filtre sur cette date nous permettrait d’avoir le nouveau sprint.

Bien sûr, s’il reste des tâches en attente d’autres sprints, nous ajoutons au filtre la date du sprint précédent afin d’afficher les tâches des deux.

Cette méthode est valable tant que nous n’avons pas de tâches qui s’étendent sur plus de 2 sprints ; sinon elles s’accumuleraient trop et il faudrait chercher un autre système, par exemple créer une nouvelle tâche dans le nouveau sprint pour remplacer celle restée inachevée dans le sprint précédent.

Bien, avec un modèle comme celui-ci, c’est largement suffisant pour commencer à planifier et à appliquer les trois piliers de l’agilité : se mettre d’accord, être flexible et mesurer.

Puis, après quelque temps -et si tu vois que cela fonctionne-, tu auras peut-être envie d’aller plus loin. Ce sera le moment de changer d’outil…

Agile Marketing avec Trello

Tout d’abord, voici un tutoriel pour débuter avec l’outil.

Une fois que tu l’auras lu et que tu auras créé ton compte, sache que j’ai aussi publié cet article sur comment utiliser Trello pour appliquer la méthodologie Kanban en marketing, où j’entre davantage dans le détail, mais voici quand même quelques indications :

1. Crée un seul tableau pour commencer. C’est beaucoup plus simple à gérer quand on débute.
2. Dans ce tableau, crée 3 ou 4 colonnes, pas plus, qui pourraient être :
• Backlog : le backlog avec toutes les tâches, celles du sprint en cours et toutes celles qui seront ajoutées pour les prochains sprints.
• To do : déplace de Backlog vers cette colonne les tâches qui seront exécutées pendant ce sprint. Les tâches les plus prioritaires seront placées en haut.
• Doing : une fois le sprint commencé, la personne responsable de chaque tâche, lorsqu’elle en démarre une nouvelle, la déplacera de la colonne To do vers celle-ci.
• Done : une fois une tâche terminée, elle sera déplacée de la colonne Doing vers celle-ci.
3. Si la tâche devait être validée par une personne différente de celle qui l’a exécutée, nous ajouterions une cinquième colonne « Validated ».
4. Une fois le sprint clôturé, toutes les tâches terminées seraient archivées et nous commencerions à placer dans To do les tâches du nouveau sprint.

Facile, non ?

Il ne resterait plus qu’à ajouter la couche d’analyse : voir ce qui s’est passé si une tâche n’a pas été terminée, si le problème venait de l’analyse de capacité de l’équipe, de la rédaction de la tâche, de son estimation…

Et une façon d’aborder la question passe par les cérémonies.

Cérémonies de l’Agile Marketing

Dans la partie théorique, nous avons parlé de quatre cérémonies :

• Daily.
• Sprint plan.
• Refinement.
• Retrospective.

Chacune est menée avec des objectifs très clairs, mais je pense qu’elles sont très orientées vers le développement de produits numériques et qu’en marketing elles ne sont pas toutes indispensables.

En réalité, cela dépend aussi de la taille de l’équipe : plus elle est grande, plus il est nécessaire de mettre de l’ordre et d’écouter.

Cela étant précisé, voici mon avis sur chacune :

La daily est indispensable. Et elle l’est parce qu’elle aide beaucoup au bon fonctionnement de l’équipe et permet de débloquer des situations, tout en faisant en sorte que chacun sache où nous en sommes.

Le sprint plan est utile, même s’il n’est pas indispensable si l’équipe est petite (jusqu’à 3-4 personnes).

Et le refinement, est encore plus dispensable : si l’équipe travaille ensemble depuis un certain temps, il n’est pas nécessaire d’organiser une session pour clarifier des choses qui peuvent se résoudre par un message Slack ou un appel de 30 secondes entre les deux parties.

Les retrospectives sont surtout utiles lorsqu’un problème important s’est produit pendant le sprint. Écouter l’avis de chaque membre nous aidera à prendre de bonnes décisions d’amélioration.

Cela dit, je ne pense pas qu’il soit indispensable d’en faire après chaque sprint (surtout s’il s’agit de sprints hebdomadaires), mais oui périodiquement et aussi, comme je le disais, chaque fois qu’un problème d’une certaine importance est survenu.

Pour conclure, disons que je considère que les cérémonies doivent être un moyen d’atteindre une fin, et non une fin en soi, comme j’ai parfois pu le constater.

Taille de l’équipe

Même si j’ai utilisé le système expliqué jusqu’ici dans des équipes de 10 personnes, je pense qu’avec cette taille quelques ajustements seraient nécessaires.

En revanche, je pense qu’il est parfait pour des équipes plus modestes de 3 à 6 personnes.

Si ton équipe est plus petite, je ne pense même pas que Trello soit nécessaire. Excel et Slack (ou Telegram) peuvent largement suffire.

Avantages de l’Agile Marketing

Le principal avantage, pour moi, est de pouvoir disposer d’ une vue de toutes les tâches à réaliser dans chaque sprint, afin de savoir clairement lesquelles nous pouvons traiter et lesquelles doivent être reportées. Il est très facile de les prioriser et de les attribuer aux différentes personnes.

Côté organisation, c’est royal, surtout parce que l’équipe sait ce qu’elle doit faire et peut se concentrer dessus.

L’avantage suivant est qu’une fois le système mis en place, nous serons capables de mesurer et analyser chaque type de tâche. Si tu compares l’effort fourni à l’apport pour l’entreprise, tu pourrais être surpris et arrêter de réaliser des tâches que tu fais depuis des années (« publications Facebook »).

Ou de découvrir à quelle personne de l’équipe il vaut mieux attribuer chaque tâche.

Autre avantage : si tu utilises Trello plutôt qu’Excel, tout reste documenté, ce qui met à notre portée un véritable dépôt d’informations.

Enfin, si nécessaire, comme je l’ai indiqué plus haut, disposer d’un tableau ou d’un backlog bien rempli met en valeur le travail réalisé par l’équipe.

Enfin, le coût de tout cela est faible :

• En argent, parce que les outils sont gratuits ou peu coûteux.
• En temps, car même s’il y a une légère hausse de la charge de travail, j’espère t’avoir montré que cela en vaut largement la peine.

Conclusions

Même si l’article est assez long, je n’ai fait qu’effleurer la surface de la méthodologie Agile.

C’est une introduction pour que tu puisses voir si cela peut te convenir ou si ton système actuel te correspond davantage.

Quoi qu’il en soit, au-delà des systèmes, j’aimerais que tu retiennes ce qui constitue pour moi ses trois valeurs principales:

• Parler et se mettre d’accord entre les parties.
• Flexibilité.
• Mesure.

En partant du principe que nous avons bien compris que tout cela consiste à faire avancer le travail / projet.

Cela dit, j’espère avoir réussi à t’expliquer la valeur qu’apporte l’application de la méthodologie Agile dans les équipes Marketing car, lorsqu’elle est bien exécutée, elle apporte réellement beaucoup de valeur. Je te le dis par expérience.

Alors fais-moi plaisir et donne-lui sa chance.

Quoi qu’il en soit, même si je suis loin d’être Scrum Master, si tu penses avoir besoin d’aide pour organiser ton équipe sur des projets numériques, il te suffit de m’écrire.