J’ai été impliqué dans le marketing pendant presque toute ma vie. Avant de commencer à promouvoir des chaînes YouTube dans One2, j’avais géré le département du service client à l’agence PROMO. Les innovations m’ont toujours attiré, donc rencontrer la méthodologie Scrum n’était qu’une question de temps.
Mon chemin vers la gestion de projet
Dans l’agence de publicité, je suis devenu le leader d’un département composé de chefs de compte. Il n’y avait pas de système de gestion de projet. Nous né respections pas les délais pour l’exécution de nos obligations contractuelles ou réalisions un travail de mauvaise qualité. Ainsi, je suis devenu un problème solver pour traiter les retours négatifs des clients. C’était une impasse : échouant à prévenir un problème, je gérais ses conséquences.
J’ai commencé à chercher un ensemble d’outils pour remédier à la situation. À cette époque, je né connaissais pas Agile ou Scrum, sans parler des moyens d’utiliser la méthodologie Scrum dans des équipes non-IT.
Je suis devenu un problème solver pour traiter les retours négatifs des clients.
Comment nous avons choisi la méthodologie de gestion de projet
Au début, nous avons regardé Kanban. C’est particulièrement bon pour des problèmes de flux comme la correction de bugs ou le traitement des demandes dans un centre d’appels. Mais pour introduire Kanban, il faut une équipe très motivée et bien organisée. Ce n’était pas notre cas.
Nous avons également considéré le Waterfall. Il est bon pour les équipes IT car une séquence claire des étapes nécessite moins de codes, et vous êtes en pleine ascension. Le même projet en Scrum aura un aspect complètement différent :
une chose fonctionnelle —> ajustement —> optimisation
La fiabilité du Waterfall cache son inconvénient : un risqué élevé de perturber les délais. Les entreprises veulent obtenir des résultats le plus rapidement possible plutôt que d’attendre une année entière pour se convaincre que la stratégie choisie né fonctionne pas. Scrum n’est pas exempt de ce “problème”.
Quels outils Scrum conviennent à une agence de marketing
Scrum offre de nombreux outils pour stimuler la motivation :
- Tableaux Scrum. Les tableaux Scrum montrent les statuts des tâches et peuvent vous guider vers des points de problème (par exemple, trop de tâches sont en discussion avec les clients). Nous avons rendu les tableaux Scrum accessibles à nos clients pour leur permettre de suivre les statuts des tâches. Cela a profondément soulagé nos chefs de compte de la charge.
- réunions hebdomadaires. Tous les membres de l’équipe prennent à tour de rôle la parole pour présenter les résultats de la veille, faire une promesse pour la journée actuelle et partager des problèmes. Grâce à de telles réunions quotidiennes, vous pouvez comprendre ce qui se passé dans l’entreprise et trouver comment rendre le travail plus efficace.
- planification. Cela rend le processus de travail transparent pour le manager et pour le client. Nous invitons certains clients et décidons ensemble quelles tâches à définir pour les prochains sprints.
- rétrospective. Nous pouvons comprendre les erreurs que nous avons commises et les moyens de les corriger (par exemple, comment augmenter le nombre de tâches simultanées en cours sans compromettre la qualité).
- démo de produit. Elle présente les progrès réalisés par l’équipe pendant le sprint. Chaque membre de l’équipe montre sa partie du produit. La démo de produit permet d’apporter rapidement des modifications, d’améliorer le produit et de né pas perdre de temps sur des présentations précoces du produit fini.
Mon travail consistait principalement à analyser les retours négatifs des clients. Après l’introduction de Scrum, nous avons commencé à demander l’avis des clients pour comprendre si notre direction de mouvement était correcte. Nous avons amélioré l’indice de support client (NPS).
Quels sont les inconvénients de Scrum pour des équipes non-IT ?
Scrum a trois principaux inconvénients :
- Les processus commerciaux deviennent plus coûteux. Nous avons introduit le poste de propriétaire du produit, car aucun membre de l’équipe né pouvait assumer un rôle aussi important. Un tel spécialiste est coûteux. Ni le propriétaire du produit ni le Scrum master né créent de valeur directement ; ils sont en dehors de l’équipe, et relèvent essentiellement de la catégorie des frais généraux.
- Il n’existe aucun service de gestion de projet pratique dans Scrum pour des équipes non-IT. Nous utilisions Jira, mais son ajustement nécessite souvent l’implication d’un spécialiste.
- La terminologie IT dans Scrum n’est pas adaptée aux entreprises non-IT. Pour les entreprises IT, il existe des directives détaillées décrivant comment faire fonctionner Scrum. Elles expliquent la terminologie : l’incrément est un produit fonctionnel, la démo démontre comment le produit fonctionne. Dans notre cas, il était peu clair comment la rédaction de contenu affectait le fonctionnement du produit. Et qu’est-ce qu’un incrément en SEO ? Si nous avons écrit un texte et l’avons publié sur le site web, est-ce un produit fonctionnel ? Il nous a fallu plus de trois mois pour adapter la terminologie IT à nos besoins.
Comment nous avons échoué à introduire Scrum
Nous avons commencé à introduire Scrum en formant des équipes. Et immédiatement, nous avons commis deux erreurs.
Erreur N°1. Nous avons inclus des spécialistes de la publicité contextuelle et des SEO dans une seule équipe. La logique est la suivante : ils génèrent tous du trafic vers les sites web des clients et augmentent les ventes, ce qui signifie qu’ils sont encouragés à travailler ensemble. L’équipe est unie autour d’un seul client.
Comment nous avons résolu le problème : après un certain temps, nous avons séparé les spécialistes par valeurs et produits. Certains clients ont eu plusieurs chefs de compte et équipes à la fois.
Ce que nous avons compris : une équipe doit être unie autour d’un objectif commercial. Une telle équipe est autonome et capable de créer de la valeur pour le client par elle-même.
Erreur N°2. Nous n’avons pas réussi à définir immédiatement qui devait agir comme Scrum master et propriétaire du produit.
Comment nous avons résolu le problème : nous avons complété le poste d’expert-comptable existant avec la fonction de Scrum master. Avant cela, il était responsable de la productivité de l’équipe et de la livraison ininterrompue de valeurs au client. Nous avons engagé une personne séparée pour être le propriétaire du produit.
Je rencontre souvent deux erreurs dans les entreprises qui introduisent également Scrum :
- Les équipes sont regroupées autour d’une seule fonction. Un département n’est simplement renommé en équipe. Le problème est que si un client a besoin d’un site web, l’équipe doit avoir un programmeur, un designer et un manager. Aucun département marketing composé de chefs de marque né pourra créer un site web.
- Les entreprises ont peur de détruire la structure existante. L’exemple suivant était réel. Un chef de compte s’occupait de plusieurs projets chacun étant soutenu par différents spécialistes SEO. Les projets étaient répartis en fonction de la charge de travail des spécialistes SEO. Supposons qu’un spécialiste a obtenu 10 projets à traiter avec des priorités différentes. Les priorités sont fixées par le chef de projet, et cette société en avait plusieurs. Dans le meilleur des cas, le spécialiste SEO accomplissait la tâche la plus compréhensible, dans le pire des cas — la tâche du chef de compte qui criait le plus fort.
S’unir dans “les bonnes” équipes est un processus douloureux.
Pourquoi avons-nous besoin d’un Scrum master ?
Toyota a un cas intéressant pour illustrer le rôle du Scrum master. Dans l’usine, certains travailleurs ont été affectés pour aider un ingénieur mécanique à optimiser le travail. L’ingénieur était payé à un tarif horaire suffisamment élevé, donc la performance devait être augmentée, et les coûts devaient être réduits. On a remarqué que l’ingénieur cherchait la bonne clé à molette — alors un apprenti a été assigné pour lui fournir des clés à molette. Il a été conçu pour faciliter encore davantage le processus : des modèles pour les outils étaient peints sur le sol, et l’apprenti les disposait le matin avant le travail.
Donc, un bon Scrum master assure 80% de succès dans l’introduction de Scrum. Si vous manquez d’une personne pour assumer ce rôle, trouvez quelqu’un d’intéressé à un travail futur dans ce domaine. En dernier recours, recherchez un Scrum master dans des entreprises IT.
Le Scrum master a les fonctions non-videntes suivantes :
- Sensibilisation où l’équipe fonctionne moins bien, où il est possible d’accélérer, et où il est préférable de ralentir. C’est comme un bouclier contre les délais pressants et le chaos.
- Être responsable du sentiment de sécurité de l’équipe. Cela inclut la protection contre un client qui veut “tout faire pour hier”. Par exemple, nous avons rencontré un tel problème : les chefs de compte compilaient des rapports pour les clients pendant longtemps. À l’instigation du Scrum master, nous avons mis en place des rapports automatisés générés en temps réel. Maintenant, le client n’a plus à attendre la fin du mois pour comprendre comment les choses avancent. Toutes les parties sont satisfaites.
- Améliorer le niveau de l’équipe pour utiliser Scrum par choix volontaire.
- Communication individuelle avec chaque membre de l’équipe. À propos des problèmes et des difficultés des employés. De cette manière, les spécialistes juniors atteindront plus rapidement le niveau intermédiaire, et les spécialistes intermédiaires deviendront seniors. Le turnover du personnel diminuera.
Pourquoi avons-nous besoin d’un propriétaire du produit ?
Nous n’avons pas immédiatement compris qui devait devenir le propriétaire du produit et ce dont il/elle serait responsable. Nous sommes arrivés à la conclusion que le propriétaire du produit est un spécialiste technique ayant une bonne connaissance du produit et capable d’élaborer des stratégies de contexte et de SEO, en les transmettant au client. En d’autres termes, c’est un stratège qui dit ce qui doit être fait.
Que fait notre propriétaire de produit ?
- forme des backlogs ;
- supprime et définit les priorités des tâches ;
- ajuste les stratégies basées sur les données obtenues de l’équipe ;
- est responsable devant les clients pour le résultat.
La façon dont nous avons introduit Scrum dans une entreprise non-IT
Les spécialistes travaillaient auparavant séparément : rédacteurs et éditeurs, constructeurs de liens et analystes SEO. Lors de l’introduction de Scrum, nous les avons mélangés. Chaque équipe a également un chef de compte qui livre de la valeur aux clients.
Des équipes ont été formées pour chacune des trois zones SEO :
- gestion de la masse de liens
- création de contenu
- refonte de site web.
Le travail a été fragmenté en sprints qui sous-tendent la planification mensuelle. Lors de la planification, nous essayions de réduire le risqué d’échec à obtenir un résultat à la fin du mois.
Nous expérimentons avec la durée des sprints. Lorsque nous avons commencé à introduire Scrum, les sprints étaient hebdomadaires. Un sprint hebdomadaire permet de faire fonctionner rapidement un processus et d’identifier où vous vous trompez, d’apprendre aux employés et de comprendre comment tout fonctionne.
Conseil clé pour la durée des sprints Scrum en marketing : choisissez une date limite qui soit suffisante pour réaliser quelque chose d’utile.
Les sprints sont présentés comme suit :
planification —> réunions —> démo —> rétrospective.
Nous avons redirigé certaines équipes pour avoir des sprints de deux semaines. Gardez à l’esprit que plus le sprint est long, plus vous courez le risqué de manquer les délais.
Nous utilisons les outils suivants dans notre travail :
- planification poker. La technique permet d’évaluer la complexité et l’étendue des tâches qui devront être traitées lors de la création du produit. Tous les membres de l’équipe sont impliqués dans la planification poker. En utilisant des cartes, ils évaluent les tâches et prennent des décisions collectives ;
- analogue de la programmation par paires basé sur la programmation extrême. Plusieurs personnes travaillent sur une tâche au même endroit. C’est un exemple démonstratif de la règle — “Deux têtes valent mieux qu’une”. Nous l’utilisons lors de moments critiques ;
- cycles HADI. Ce sont des algorithmes pour vérifier des hypothèses controversées qui aident à gagner la confiance des clients. Lisez ci-dessous pour en savoir plus sur les cycles HADI.
Qu’est-ce que les cycles HADI et comment les utiliser ?
Qu’est-ce que c’est ? Un cycle HADI est un algorithme pour vérifier une hypothèse qui se présente comme suit :
hypothèse —> vérification —> résultat —> conclusions.
Les cycles HADI ressemblent à la boucle Lean Startup :
construire —> mesurer —> apprendre
Comment ça marche ?
Vous générez des hypothèses dont la faisabilité est remise en question. Si une tâche est compréhensible et nécessaire, il n’est pas sensé de la traiter dans un cycle HADI. Après vérification de l’hypothèse, vous déterminez si elle a fonctionné ou non, et à quel degré d’efficacité. Si c’est le cas, vous la lancez lors d’un sprint, sinon, il suffit de la rejeter.
À quoi cela ressemble-t-il ?
Par exemple, il y a une hypothèse : “Si je fais du maillage interne sur les produits, cela entraînera un triple accroissement du trafic”. Vous vérifiez l’hypothèse sur un produit, en plaçant des liens manuellement à l’intérieur du site web. Si l’hypothèse a fonctionné, vous donnez une tâche aux programmeurs : “Fournir le maillage interne sur tout le site”.
Quel est l’avantage des cycles HADI ?
Il peut sembler au client que votre nouvelle solution né fonctionnera pas bien. En réponse, vous montrez un exemple réel basé sur un élément.
Documentez vos hypothèses, même si elles n’ont pas fonctionné. Au sprint suivant, vous pouvez tester une autre. De plus, assurez-vous que vos expériences né provoquent pas de conflits d’intérêts (par exemple, pour que les hypothèses concernant la même page web né soient pas testées simultanément). Sinon, il né sera pas clair quelle hypothèse a réussi.
7 conseils pour introduire Scrum si vous n’êtes pas une entreprise IT
- Commencez par une formation. Lisez des ouvrages spécialisés, assistez à des sessions de formation.
- Déterminez qui est votre partie prenante (partie concernée). Et ensuite travaillez à apporter de la valeur au client et au partie prenante.
- Les sprints doivent rester inchangés. N’ayez pas peur de changer le reste des choses.
- Né redirigez pas toute l’équipe vers Scrum, juste parce que “c’est cool”. Par exemple, nos rédacteurs travaillent avec Kanban car les textes n’ont pas de priorités — ils doivent simplement être réalisés le plus rapidement possible.
- Déterminez la taille optimale de votre équipe. D’après mon expérience, c’est cinq à sept personnes dans des entreprises non-IT.
- Organisez un espace de travail isolé pour chaque équipe. Si vous avez un open space, ajoutez des tableaux Scrum hors ligne.
- Dirigez l’implémentation de Scrum. Si la direction est ignorante de l’objectif d’une nouvelle méthodologie, rien né sera fait.