Publié le 3 novembre 2016

Pas si simple l’agilité en agence web

Intéressant cet article ?

[Total : 4    Moyenne : 4.8/5]

« Tiens, si on travaillait en méthode agile ? »

Comme beaucoup d’agences web, nous avons voulu aborder nos projets en agilité alors nous avons appliqué SCRUM à la lettre et… Ça n’a pas fonctionné. Du moins pas tout de suite, c’est pourquoi nous vous proposons de partager notre retour sur cette expérience pour vous éviter certains écueils.

L’agilité prescrite à la va-vite

Depuis quelques années, la taille des projets web a considérablement augmenté. Aucune manipulation transgénique là-dessous, cette évolution est liée aux besoins des consommateurs qui sont de plus en plus pointus. Il faut donc développer un tas de fonctionnalités pour les satisfaire. En parallèle, les sites doivent être interfacés avec le système d’information de l’entreprise, toujours plus complexe, et bon nombre de services tiers.

Sauf que plus les projets étaient importants, plus nous avions des difficultés à les gérer sereinement : livraison en retard, dépassement de budget, recettes interminables… Même si nous finissions toujours par y arriver, on en avait gros.

Gif-Kaamelott-le-top-20-9

Le miracle de l’agilité ?

Nous cherchions une solution et… l’agilité était partout ! Tout le monde en parlait, notamment des collaborateurs qui avaient eu l’occasion de les tester dans d’autres entreprises. Ça a fait un gros « tilt » et on s’est dit « voilà, c’est ça, il faut faire des méthodes agiles ».

Nous avons donc pris un gros projet.
Quelqu’un a été désigné Scrum Master.
Le chef de projet a découvert qu’il avait été rebaptisé Product Owner.
Nous avons déguisé un fichier excel en semblant de backlog.
Nous avons commencé à nous réunir tous les matins pour se dire ce que nous avions fait la veille et ce que nous allions faire le jour même.
Nous avons commencé à travailler en “sprint”, n’en déplaise à Usain Bolt.
Nous avons régulièrement montré à notre client ce que nous faisions.
La rétrospective, nous n’avions pas bien compris à quoi elle servait alors elle n’a pas été faite…
Donc, on s’est pris les pieds dans le tapis (de souris).
Mais pourquoi ?

Why (2)

L’erreur de diagnostic

En réalité, nous nous posions les mauvaises questions. Tellement concentrés sur la méthode, le comment, nous en avions oublié le pourquoi. Or, appliquer une méthode sans en comprendre la philosophie sous-jacente et sans contextualiser son application a toutes les chances de mener à l’échec.

Grâce à Alfred (notre super consultant, pas le majordome de Bruce), nous avons identifié un problème systémique : l’ensemble de notre production était en surchauffe et l’application d’une méthode sur un seul projet n’y changerait rien.

Nous avons donc déterminé les actions isolées que nous pouvions mener pour obtenir des réactions en chaîne.  Et nous avons repris une dose de principes fondateurs, matin, midi et soir en infusion dans les équipes.

Le retour aux fondamentaux du manifeste agile

Le manifeste agile est à l’agilité ce que le serment d’Hippocrate est aux médecins : rédigé en 2001 par 17 experts en informatique, il pose les bases de la méthodologie agile à travers 4 valeurs et 12 principes fondateurs.

L’équipe : « Les individus et leurs interactions, plus que les processus et les outils »

Faire de l’équipe une des valeurs fondamentales permet de la replacer au centre du projet. L’objectif est qu’elle soit soudée, qu’elle communique, qu’elle soit engagée, responsable et qu’elle s’organise d’elle-même. Pour cela, il faut qu’elle s’épanouisse et qu’on lui fasse confiance. Le passage d’une équipe multi-projets au management très directif à une équipe autonome et engagée autour du projet est loin d’être immédiat et il a fallu mettre en place un accompagnement individuel adapté à chaque membre de l’équipe.

Le produit : « Des logiciels opérationnels, plus qu’une documentation exhaustive »

Parler de produit “opérationnel” revient à dire qu’il permet d’atteindre les objectifs que les utilisateurs de notre client souhaitent atteindre, ce qui conduit indirectement  à plus de satisfaction client. Plutôt intéressant quand on sait que, selon le premier principe du manifeste agile, « la plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à forte valeur ajoutée ”. L’important n’est donc pas de se focaliser sur ce qui était prévu au départ mais bien de construire au fur et à mesure du projet, un produit final qui réponde au mieux aux attentes de l’utilisateur final.

Vous vous souvenez du pourquoi qui nous manquait lors de notre première tentative ? On le tient là ! Nous ne devions pas changer de méthode pour le plaisir / parce que l’ancienne ne fonctionnait plus / pour faire comme tout le monde mais bien pour nous inscrire dans une démarche de production de valeur pour notre client, afin de mieux le satisfaire et d’accroître son ROI.

La collaboration : « La collaboration avec les clients, plus que la négociation contractuelle »

Cette troisième valeur est peut-être la plus difficile à mettre en œuvre car par définition, elle ne dépend pas que de nous. Aujourd’hui, les agences web travaillent principalement au forfait dans la lignée de ce qui se fait dans le monde du print et de la communication traditionnelle. Si cela était parfaitement justifié sur des projets de petite taille ou au périmètre parfaitement clair, cette approche forfaitaire rigidifie les projets en agence digitale. Or, le périmètre fonctionnel de ceux-ci est par essence incertain et voué à évoluer. Cette particularité créée invariablement de la tension avec le client sur des points d’ombres ou les fameux “ça me paraît logique” ou “c’est sous-entendu». Or, non, rien n’est implicite. De plus, difficile de présenter un projet à un client sur un budget mouvant sans qu’il ait la sensation de laisser la CB sur le coin de la table.

En clair, remiser la négociation contractuelle pour aller vers la collaboration nécessite un changement de notre part envers nos clients et nos prospects mais pas que. Afin de produire de la valeur et de donner satisfaction à notre marché, il faut également que celui adopte cette approche collaborative. Et c’est ce qu’il fait… Pas à pas.

BabySteps

L’acceptation du changement : « L‘adaptation au changement, plus que le suivi d’un plan »

Cette dernière valeur dépasse largement le cadre du changement durant le projet.

Il s’agit d’accepter le changement, pour soi et ses équipes, c’est-à-dire accepter de sortir de sa zone de confort et d’adopter une approche constructive et active là où on est parfois plus passif et exécutant.

Il s’agit de faire accepter au client que :

  • oui, le produit final sera probablement différent de ce qu’on avait imaginé au départ, mais que c’est pour le mieux
  • non, cela ne signifie pas investir 4 fois le budget initial

Nous sommes dans une société où il y a eu entre 2000 et 2014 plus de progrès scientifiques que sur tout le XXème siècle (KURZWEIL Ray, 2007). Tout change très vite et même à l’échelle d’un projet, les facteurs internes et externes qui peuvent l’influencer sont nombreux. Les ignorer c’est ignorer la réalité. Or, quelle meilleure façon de faire échouer un projet que de le déconnecter de son environnement ? Puisque les utilisateurs sont seuls juges de la pertinence du produit, le fait de les y confronter au plus tôt permet d’obtenir des feedbacks importants pour adapter son évolution.

Nouvelle cure d’agilité

Forts de cette piqûre de rappel théorique administrée par Alfred, nous avons pu réintroduire Scrum et Kanban, de façon intelligente, pleinement conscients de pourquoi nous le faisions. Nous faisons attention à ce que les collaborateurs retrouvent un rôle de décisionnaire et à ce qu’ils soient suivis individuellement.

À ce jour, nous avons plusieurs projets conséquents gérés avec cette méthode et nous obtenons d’excellents résultats, en termes de délai, de qualité, et de satisfaction client. Cependant, il nous reste encore une marge de progression pour que le périmètre, même mouvant, reste en phase avec le budget estimé au départ. Et oui, cela aurait été trop beau 😉

Cela ne veut pas dire que nous soyons passés au « tout-SCRUM », il y a des prérequis :

  • Le périmètre doit être important : pas la peine de gérer un WordPress simple en méthode agile
  • Le client doit être réceptif aux valeurs énoncées plus haut et prêt à travailler en confiance, en s’impliquant à 100% de façon collaborative. La dimension intrinsèquement ROIste de la méthode doit guider sa réflexion.
  • Les équipes doivent être dédiées au projet. Les sprints sont élaborés de façon à s’assurer que tous pourront être à 100% sur le projet durant le sprint.
  • Les méthodes type SCRUM ou Kanban sont plus des « frameworks » que des méthodes strictes. Elles donnent un cadre de base qu’il est nécessaire d’adapter au contexte du projet pour en tirer tout le bénéfice. Là aussi, le produit fonctionnel est plus important que la méthode.

Et le contrat dans tout ça ?

Nous essayons d’avoir une approche contractuelle au sprint : l’équipe s’engage, non plus au forfait global, mais sur ce qu’elle va produire pendant ce sprint. Ainsi, il est toujours possible au préalable de chaque sprint de bouger les lignes pour adapter le livrable et obtenir le maximum de valeur. La logique est gagnante/gagnante pour le client et l’agence car tout le monde s’y retrouve à la fin.

Au-delà des méthodes, c’est la culture agile qui a infusé dans l’ensemble des projets, quelle que soit leur taille ou leur mode contractuel. Les valeurs agiles sont devenues des réflexes, adoptés par tous, et chacun, indépendamment de  sa position, se pose la question « pourquoi » avant « comment ». La rentabilité des investissements de nos clients est assurée, non pas en tirant sur les heures de travail ou sur la qualité des livrables, mais en misant sur l’équipe et sa capacité à s’améliorer dans le temps. Chaque semaine de travail, chaque projet, est un challenge que l’ensemble des collaborateurs prend à bras le corps pour atteindre les objectifs de nos clients et ceux de JETPULP.

Et de votre côté alors, les méthodes agiles sont-elles restées au stade de belles théories ou les mettez-vous en application au quotidien ?

J.S

KURZWEIL Ray. Humanité 2.0, la bible du changement. M21, 2007. ISBN 978-2-916260-04-4, p. 33

1 Commentaires
Répondre
Se joindre à la discussion ?
Vous êtes libre de contribuer !
Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *