Marketing Agile : Scrum, Kanban et organisation matricielle
The Agile philosophy and its Marketing variant foster openness to change by rethinking the way work is organized. Having read the excellent book “
La philosophie agile et sa déclinaison marketing prônent une ouverture aux changements en reconsidérant l’organisation du travail. À la suite de la lecture de l’excellent livre “Hacking Marketing”, nous avons tenté une approche simplifiée de notre façon de faire, afin de voir si ce ne serait pas plus adapté que Scrum, la méthodologie que nous utilisions pour les projets marketing depuis maintenant trois ans. Cet article est un bref retour sur notre toute jeune expérience.
La nouvelle approche proposée par Hacking Marketing est largement basée sur un tableau Kanban, que voici :
Migration vers une équipe matricielle
Nous avons également fait d’une pierre deux coups. Auparavant, le travail était séparé entre trois équipes : équipes de design, d’intégration et de marketing. Les équipes ont été fusionnées pour ne former qu’une seule, l’équipe marketing.
Vélocité
Le calcul classique de la vélocité par points propre à Scrum est remplacé pour le moment par un nombre d’heures de disponibilité par semaine. Probablement que le système par “points” serait adapté dans un contexte où l’équipe travaillerait de manière dédiée au projet, mais ce n’est pas notre cas. L’équipe et la disponibilité des personnes changeant de façon assez régulière, le système par points ne s’avérait pas très adapté à la situation, n’était pas représentatif de la réalité.
Communications
Les échanges entre graphistes, intégrateurs et clients sont plus fréquents avec Kanban : la continuité que représente la “story” facilite les échanges. Rien ne remplace la rencontre en personne, mais dans un contexte où le travail s’effectue parfois à distance, il est difficile d’effectuer constamment des échanges face à face, particulièrement lorsqu’il y a plusieurs équipes. L’utilisation accrue d’un logiciel de gestion commun comme point central a facilité les communications, et permet de garder une trace des échanges précédents. Cela a également facilité les passations d’informations entre design et intégration, les documents nécessaires se trouvant tous en pièces jointes à la carte de la story.
“Get Sh*t Done”
L’utilisation de Kanban a accéléré la cadence de livraison. Auparavant, le temps de livraison était long… au minimum d’un mois : un “sprint design” et un “sprint intégration”. Un mois est souvent un délai beaucoup trop long pour un projet marketing. Avec Kanban, ou plutôt l’utilisation de Kanban telle que proposée par Hacking Marketing, il est possible de livrer en quelques jours, même si la story passera par plusieurs étapes de “review”. Réduire les sprints sous la barre des deux semaines a en quelque sorte transformé notre vie en un meeting continu.
Coût de l’organisation matricielle
Il est souvent associé l’étiquette de “plus cher” à |'équipe matricielle. De notre côté, nous avons observé la même chose que ce que soulève cet article du Harvard Business Review : le temps consacré à la recherche du laissez-passer A38 a diminué. Dans ce cas-ci, nous parlons d’une diminution de 30 % du temps consacré à l’administration des projets.
Logiciel de gestion
Nous utilisions Jira pour Scrum. L’outil est particulièrement optimisé pour la chose. Cependant, vu l’utilisation que nous faisons actuellement du Kanban, Jira semble moins adapté. Des limitations concernant l’expérience utilisateurs se font ressentir, ce qui est un des principaux problèmes auquel nous avons dû faire face.
D’autres logiciels (qui sont nombreux) sont à recommander : Trello, Wekan, Restya, Leankit, etc.
Comparaison
| Scrum | Kanban |
|---|---|
| Avantages | Avantages |
| Calcul de la vélocité par points de l’équipe facilité. | Fluidifie le travail : plus facile de réaliser des tâches rapidement. |
| Adapté dans un contexte où le nombre d’intervenants est élevé/l’implication est élevée. | Plus adapté à un contexte de disponibilités variables. |
| Simplifie/favorise la communication dans une équipe matricielle. | |
| Meilleure continuité dans la production. | |
| Désavantages | Désavantages |
| Rigidité des concepts Scrum, quelquefois contradictoire avec la flexibilité prônée par la philosophie Agile. | Vélocité par points plus difficile à suivre. |
| Dans un environnement non matriciel, la communication entre les équipes est complexifiée. | Dans notre cas, l’inflexibilité de Jira est un problème. |
Nos particularités qui différencient peut-être notre situation de la vôtre :
- Le nombre de contributeurs est élevé, mais le temps consacré par chacun est extrêmement variable ;
- Pour une partie de l’équipe, les projets marketing sont secondaires à côté d’autres projets clients ;
- L’entreprise fonctionne, en majorité, en mode Scrum ;
- Jira est utilisé par l’entreprise dans toutes ses sphères ;
- Nous sommes passés au même moment d’une équipe scindée à une équipe matricielle ;
- Les tâches à effectuer sont variées : intégration, infolettres, design…
