Méthode Agile en communication, pas si bête…

Je sais. Il suffit d’associer méthode agile et agence de communication pour entendre les puristes hurler au scandale ! Comment ? De la communication agile ? Sans lien avec le dev de logiciels ? Quelle hérésie !!! Pourtant, n’en déplaise aux informaticiens, cette méthode de travail est applicable et déjà appliquée dans de nombreux secteurs en dehors du développement web.

La méthode agile : d’abord des valeurs

Avant de se lancer tête baissée dans la méthode agile, il faut se poser une question : A-t-on ce qu’il faut pour travailler dans ce genre de méthode de gestion agile en communication ? Parce qu’il ne s’agit pas d’ajouter une couche de « trendy attitude » à son travail pour évoluer en agilité. En réalité, cette méthode est une mentalité assez éloignée de ce qu’on a l’habitude de pratiquer en milieu professionnel.

La conception de « l’agil method » est surtout basée sur des valeurs qui ne sont pas typiquement françaises, il faut le reconnaître. J’oserais même dire qu’elles vont à l’encontre de la vision classique de l’organisation du travail.

Ces valeurs sont :

• Travail en équipe
• Communication accrue
• Aucune hiérarchie
• Implication
• Collaboration
• Acceptation du changement

Vous constaterez comme moi qu’on a du chemin à faire dans certaines entreprises de l’Hexagone.

Placer le client au cœur du projet agile

Maintenant qu’on est conscient qu’il faudra plus d’horizontalité dans sa structure de travail et qu’on a mis ses équipes au parfum sur la façon d’aborder la méthode agile, voyons un peu ce qu’on en fait.

Au commencement était le client…

Ça vous paraîtra logique. Mais force est de constater qu’au fur et à mesure de l’avancement d’un projet, le client peut vite devenir une abstraction, presque un obstacle (allez, avouez-le…) ! Alors que bon, ne l’oublions pas, c’est accessoirement un tout petit peu pour lui qu’on travaille.

Pour bien démarrer un projet en version agile, il faut une bonne dose de communication. Entre les membres des équipes mais également avec le client.

Le chef de projet, qu’on rebaptisera ici Product Owner, circonscrit le produit en collaboration avec le client. Ils établissent ensemble une vision globale du produit, ses grandes lignes. On comprend que la demande du client s’élabore donc de façon accompagnée. Ce n’est pas un cahier des charges figé mais un travail de collaboration entre l’agence et le client. Une définition conjointe de ce que doit être le produit à partir du besoin identifié avec l’aide de l’agence.

Inspiré du développement informatique, ce projet sera alors découpé en plusieurs séquences appelées Users Stories. Dans le dev, on utilisera la formule :

• En tant que « rôle »,
• je dois pouvoir « action »
• pour obtenir « résultat ».

En fait, il s’agit de décortiquer le produit jusqu’à en obtenir une série de séquences de travail gérées par l’équipe.

Ok, je vous l’accorde, on imagine plus facilement cette façon de faire dans le cadre du développement d’un logiciel que dans d’autres secteurs. Mais avec un peu d’imagination et surtout de la bonne volonté, on peut facilement adapter cette formule à toutes sortes de projets, et donc penser communication agile.

Une fois la liste des séquences établie, les équipes se penchent sur les priorités et la faisabilité des séquences. C’est notamment à ce niveau que la confiance en ses équipes est primordiale. Parce que ce n’est pas le chef de projet qui fixe les délais et l’ordre des actions à poser mais les membres des équipes. Quand je vous disais que ça bouscule l’organisation classique d’une gestion de projet !

Le Product Owner, ses collaborateurs et le client se mettent d’accord pour définir ce qui sera considéré comme un produit fini. En effet, avec ce genre de processus de création, les allers-retours de correction peuvent être infinis. D’où l’importance de se fixer des balises pour ne pas s’embourber dans un mécanisme qui finirait par être contre productif.

Vous prendrez bien un peu de Scrum dans votre méthode agile

On ne peut parler de méthode agile sans parler de scrum. Les amateurs de rugby seront déçus. Après le babyfoot et le ping pong, je ne suis pas en train de vous proposer de vous faire des mêlées dans vos bureaux pour renforcer l’esprit d’équipe (quoi que…!). Si l’expression vient bien du monde du ballon ovale, dans les faits, l’expression scrum fixe le cadre de la méthode agile.

Le scrum se résumerait en 5 R :

1. Règles du jeu
2. Rôles
3. Réunion
4. Rythme
5. Rendu

Les règles

Si de loin la méthode agile semble anarchique, elle est au contraire régie par des règles importantes à respecter pour le bon déroulement du processus. Ces règles concernent davantage l’attitude de chacun qu’une obéissance aveugle aux règles imposées par la hiérarchie. L’attitude doit être ouverte, à l’écoute, elle doit accepter le changement.

Les rôles de chacun

En plus du Product Owner et du client, un autre joueur s’invite dans la mêlée : le Scrum Master. Ce dernier s’assure entre autres du bon déroulé des multiples réunions et du respect des règles. Il est le garant du cadre de la méthode scrum. Ne le voyez pas comme le chef d’équipe, mais comme un coach qui motivera ou réorientera ses joueurs, il les poussera à donner le meilleur d’eux-mêmes.

Ces fameuses réunions

Si je vous dis 1 réunion par jour, vous risquez de partir en courant, n’est-ce pas ? Maintenant, si je vous dis qu’elles doivent être limitées dans le temps (souvent pas plus de 15 mins), qu’elles déroulent debout et qu’elles se résument en 3 points, ça va mieux ?

• Ce que j’ai fait hier
• Quels ont été mes points bloquants
• Ce que je ferai aujourd’hui

Tout le monde sait où on en est, ce qui a posé problème et ce qui doit être fait lors de la prochaine étape. Et chacun repart travailler… Rapide, efficace, « straight to the point » comme diraient les Américains !

Rythme des cycles

Parce qu’une image vaut mille mots, je vous propose ce schéma qui résume ce qu’on entend par cycles. Parce que le principe même de la méthode agile est itératif et donc est fondé sur un certain nombre d’aller-retours, avec les équipes et avec le client.

Le rendu

Comme nous l’avons vu précédemment, le rendu ou produit doit être défini dans ses grandes lignes au début du processus. Les protagonistes doivent se mettre d’accord pour fixer les critères qui feront du produit un projet terminé. Tant que ces critères ne sont pas atteints, le produit peut être en constante évolution pour répondre aux demandes du client au cours du projet. Le cahier des charges n’est donc pas une bible à suivre à la lettre mais un point de départ pour amener le produit plus loin, le faire évoluer, le modifier jusqu’à obtenir la pleine satisfaction du client.

Avouez maintenant que ce n’est pas si insensé de proposer une méthode de gestion de projet agile pour une communication agile !

Alors, convaincus ? Croyez-moi, ça vaut le coup d’essayer…

Note sur l’auteur : cet article a été rédigé par Naima Luche. Cette personne a quitté ma société. Pour des motifs de sécurité évidents, je n’ai pas souhaité conserver son compte auteur, ce qui explique l’attribution de la paternité de son article à cet endroit.