Les méthodes agiles sont à la mode. Issue du monde digital et particulièrement prisée des start-up, cette nouvelle génération de pratiques de pilotage et de réalisation de projets est adoptée d’un bloc par de plus en plus d’entreprises dites traditionnelles. Mais, bon nombre d’entre elles s’y sont cassé les dents.

Ayant été personnellement souvent associé, impliqué, initiateur, témoin ou simplement spectateur de projets développés en mode agile, voici les enseignements que nous en avons tirés et que nous vous livrons, sous forme de 50 conseils, rien que pour vous, maintenant.

Loin des livres et des théories, ces conseils puisent leur source dans une quarantaine de projets, espacés dans le temps par plus d’une dizaine d’années, développés au sein d’entreprises culturellement très différentes, appartenant à des secteurs que tout oppose, touchant à des problématiques hétérogènes : e-commerce, internationalisation, fintech, BtoB, luxe, SEO, UX, shopbot, supply chain, logistique, transport, relation client, API, back office, WMS, migration technologique, CRM, paiement, chatbot, RTB, programmatique…

Nous les listons ici, pèle mêle, sans les classer selon une logique classique, préférant ainsi :

  • Rester fidèle à la philosophie du développement agile qui veut qu’un projet soit davantage une succession d’itérations plutôt qu’un séquençage méthodologique bien découpé.
  • Nous inscrire dans l’esprit proprement digital qui veut que le développement d’un projet, d’une application, d’un site web, ne s’interrompe jamais, évoluant au rythme du monde digital, lui-même en perpétuelle mutation.

En revanche, nous suivons plutôt l’approche du triple l’entonnoir, allant du plus général au plus spécifique, du plus simple au plus complexe, du moins technique au plus technique.

Les premières leçons pourront donc porter sur des aspects généraux comme le cadrage d’un projet, la gestion des ressources, la survie du projet en interne… Tandis que les derniers conseils vous feront regretter de ne pas les avoir lus :

  • le jeudi soir à 21 : 50, alors que vous étiez bloqués face à un problème, tandis que le programme manager trépignait en attendant de finaliser sa présentation d’avancement du projet à la direction, le lendemain à 11 : 00.
  • ou tout simplement avant de commencer le projet.
  • ou bien parce que votre projet a déjà démarré et qu’il est peut-être déjà un peu trop tard.

Cet article inaugure donc une série de cinq épisodes intitulée Méthodes Agiles : 50 conseils pratiques.

C’est parti !

1.      Révisez vos gammes

Parce qu’elles sont une réaction aux modes de gestion de projets classiques, les méthodes agiles sont souvent adoptées avec enthousiasme par les néophytes, séduits trop vite par leur apparente simplicité. A l’instar du jazz, qui semble facile et libérateur comparé à la musique classique trop bien orchestrée, le développement agile requiert rigueur, méthode et travail. Si le musicien de jazz détonne par son aisance, il n’en est pas moins un très bon instrumentiste, un grand connaisseur de la musique et l’improvisation qui le caractérise cache des heures de préparation. Ne vous y trompez pas, le développement agile ne s’improvise pas. Il est comme un saxophone que vous prendriez en main pour la première fois et duquel vous ne parviendriez pas à sortir un seul son. Il faut du temps pour devenir un digne interprète du développement agile et une formation classique (aux méthodes de projets à l’ancienne) constitue souvent un atout pour celui ou celle qui sait s’en libérer sans oublier complètement non-plus les bons réflexes acquis.

2.      Prenez garde à l’analyse

L’analyse en amont du projet est quasi contraire à la philosophie du développement agile qui invite au démarrage immédiat et aux itérations et corrections incessantes. Pourtant elle existe, même quand l’entreprise a adopté les méthodes agiles. Quel responsable de projet ne s’est pas entendu demander des informations de cadrage, si ce n’est orales, du projet : délais, coûts, nombre de ressources mobilisées, gains attendus… ?

Quoi qu’il en soit, ne vous fiez pas trop à l’analyse faite en amont du projet. Elle reste l’exercice le plus difficile. Les plus aguerris peinent encore à exceller dans cette phase. A leur décharge, n’oublions jamais que les professionnels de l’IT partagent ce défaut d’être toujours trop optimistes. Donc, ne considérez pas les estimations que leurs analyses procurent (délais de réalisation, coût du projet, degré de complexité, ressources nécessaires, interdépendances, chemin critique…) comme paroles d’évangile. Notre conseil : augmentez de 50% le planning et de 30% les coûts.

3.      N’écoutez pas ce qui se raconte

C’est un leurre de croire que vous aurez un site e-commerce en trois semaines et même en trois mois. Les étapes de validations qui s’éternisent, les RTT des uns, les vacances des autres, les imprévus, les instabilités techniques, les mésestimations, les dépendances, les interfaçages avec les bases de données existantes, les effets de bord, les contraintes non identifiées en amont, les plantages, les incompréhensions, les évolutions du périmètre fonctionnel, les bugs… auront vite raison de cet optimisme.

4.      Rappelez-vous que Paris ne s’est pas faite en un jour

Ne croyez pas que les méthodes agiles permettent de développer nécessairement plus vite. Une tâche qui demande trois jours-hommes consommera toujours trois jours-hommes, que les codeurs évoluent dans le cadre d’une gestion classique de projet, ou assis au sein de l’open space d’une start-up rompue aux méthodes agiles. Les grandes vertus de ces méthodes sont au nombre de trois.

  • Premièrement, de sortir le projet du fameux tunnel au bout duquel, après des mois de développement, le client se voit livrer quelque chose de plus ou moins conforme à ses attentes.
  • Deuxièmement, de réduire le risque en assurant une meilleure gestion tout au long du projet.
  • Troisièmement, de faire évoluer le produit ou le service que l’on développe, en cours précisément de développement, de manière à l’adapter aux évolutions du contexte dans lequel il verra le jour.

5.      Ne montez pas les marches quatre à quatre

Les méthodes agiles sont bien souvent assimilées au monde digital et par conséquence associées à la notion de vitesse. L’emballement, le désir d’avancer vite, conduisent trop souvent à bâcler certaines phases critiques, comme les validations intermédiaires par certains groupes d’utilisateurs, le débogage, le resettage, que quelques jours supplémentaires auraient simplement contribué à améliorer au point de s’éviter bien des problèmes ensuite. Sachez lever le pied de l’accélérateur pour ces phases en les présentant en interne, simplement comme des virages dans lesquels il convient de ralentir, pour s’éviter une sortie de route.

6.      Offrez une connexion Wi-Fi irréprochable.

L’environnement de travail des développeurs et de leurs pendants côté client ne saurait être moyen. Il doit être excellent. Le Wi-Fi doit pulser, la maintenance être parfaite. Les codeurs utilisent familièrement l’instant messaging entre eux ou avec les autres interlocuteurs du projet. Ils se connectent également à des logiciels propres au développement agile comme Jira. Ne laissez pas de basses considérations économiques, sécuritaires ou techniques les polluer. Ce sont de fausses économies, de nature à ralentir l’ensemble.

7.      Mettez de la techno à tous les étages

Le développement agile a besoin de méthode, de rigueur et d’excellence dans l’exécution des deux côtés du projet. Celui que l’on nomme PO ou Product Owner, autrement dit le donneur d’ordre, qui se situe généralement chez le client et à qui il revient de s’assurer que ce qui sera livré sera conforme à ce qui est attendu, peut difficilement être un néophyte. Ayant idéalement un background technique, il aura aussi une forte familiarité avec l’environnement dans lequel le produit développé évoluera (le web, les OS mobiles, les back offices e-commerce, les CMS, les comparateurs de prix, les plateformes d’affiliation, les bases de données, la programmatique, les bibliothèques d’API…), sans parler d’une préoccupation incessante de défendre véritablement l’utilisateur, couplée donc à une sensibilité à l’UX. Avoir lu Eric Ries ou Steve Blank, connaître les grands principes ou tout simplement admirer comment Indra Nooyi a utilisé le design thinking pour en faire, avec le concours de Mauro Porcini, une véritable stratégie pour PepsiCo ne suffisent pas. Constituez minutieusement vos équipes.

8.      Rappelez-vous toujours que trop de sprint tue les sprints

Si vous optez pour le scrum, évitez de tomber dans le piège qui consiste à clore un sprint, le considérant terminé, sous prétexte que 95% des tâches qu’il comprenait ont été réalisées. Attention, toutes les tâches de sont pas égales en termes de de délais nécessaires à leurs réalisations, de complexité ou de disponibilité des compétences requises pour les effectuer. Nous avons trop souvent vu des équipes projets avancer très vite et qui, au bout de trois mois, croyant avoir presque terminé le projet, réalisaient que les 5% manquants du premier sprint, additionnés aux 3% manquants du second sprint, additionnés aux 4% manquants du troisième sprint, etc. représentaient finalement une charge de travail nécessitant encore trois mois supplémentaires de développement. Surveillez scrupuleusement la clôture des sprints.

9.      Dotez-vous d’un scrum master solide

Prises au pied de la lettre et parfois encore mal comprises, les méthodes de développement agiles conduisent parfois à penser que le donneur d’ordre est le maître absolu et qu’il revient aux développeurs de s’exécuter sans réagir. Intégrer à l’équipe projet un scrum master, côté développement, peut être un formidable moyen de mettre en place un contre-pouvoir, non pas ennemi du premier, mais à son service pour le guider :

  • En le sensibilisant au fait que s’il attend trois semaines de plus par exemple, pour se voir livrer une nouvelle fonctionnalité, le développement de celle-ci ne nécessitera que deux jours, puisque d’autres aspects du projet auront été mis en place entre temps, tandis qu’elle demandera dix jours si on commence immédiatement. Exemple : l’intégration de la solution Paypal avant que le module de gestion des paiements ait été installé, ou après.
  • En lui expliquant pourquoi il est préférable de regrouper le développement de trois fonctionnalités, ou de réaliser conjointement cinq tâches, parce qu’elles requièrent une même ressource rare et disponible prochainement, et reposent sur la même technologie. Exemple : le déploiement d’un formulaire de commande de produits, une fonctionnalité de cross-selling ou l’envoi automatisé de la liste des prix actualisés quotidiennement, des produits en catalogue, à des comparateurs de prix.
  • En lui montrant que la validation d’une fonctionnalité en l’état aura pour conséquence de requérir des développements additionnels et impactant plus tard le projet. Exemple : proposer des moyens de paiement à des pays membres de la communauté européenne est une chose. En proposer pour d’autres régions du monde en est une autre.

10.  Optez pour la gouvernance flash

Tout projet nécessite des phases de validations intermédiaires qui bien souvent portent sur des sujets qui n’avaient pas été anticipés. Un comité de pilotage est en théorie là pour décider, arbitrer, trancher. Qu’il le fasse, vraiment ! Si vous demandez à vos développeurs de réaliser une course de fond au rythme d’un sprint, dites-vous bien que toute décision remise à demain les oblige à s’arrêter et rendra la reprise de leur course plus difficile encore ensuite. Soyez comme des supporters. Vos décisions doivent être flash, à l’instar des flashs des photographes qui se situent le long de la piste d’athlétisme.

Share