Blog

L’agilité en tant que prestataire

Je me rappelle lorsque Pierre m’a parlé de l’agilité il y a 4 ans. Je faisais les gros yeux, je lisais les explications des agilistes avec perplexité et me demandais bien comment cela pouvait être possible…Pierre a mis tout cela en place dès notre association, d’abord les outils, puis les méthodes, et enfin m’a poussé pour la facturation. Sans lui OCCITECH ne serait pas ce qu’elle est devenue et l’agilité me ferait toujours sourire. Nous avons voulu faire part de nos difficultés et nos succès sur cette transition. Et au départ ce n’était pas gagné, un agiliste nous ayant même dit qu’on ne pouvait être agile en tant que prestataire…

Nous sommes progressivement passés en agilité en 2012. Il a fallu en amont mettre en place des outils le permettant : un gestionnaire des tâches (Redmine), un tracker de temps (Toggl), un service de déploiement continu (Jenkins) et implémenter un outil de déploiement automatisé (Capistrano). Nous avons formé notre équipe au TDD (développement guidé par les tests) et à plusieurs bonnes pratiques d’écriture du code (clean code et d’autres). Nous étions « fin prêts » pour basculer en agilité, il ne restait plus qu’à le mettre en application.

Nous ne prétendons pas avoir fini notre conversion agile, loin de là (puisse-t-elle être finie un jour…) ! Prenez cet article comme un simple témoignage, nous n’avons pas de leçon à donner.

Vendre l’agile

Bien sur, la première difficulté consiste à expliquer et vendre les méthodes agiles aux clients. Bien qu’elles soient de plus en plus connues, il ne faut pas se leurrer, le client en a rarement entendu parlé, et quand c’est le cas il est assez méfiant.

Ce que retiendra le client à la première explication c’est qu’il paie au temps passé, et il y voit surtout un énorme avantage pour nous sans contre-partie pour lui, le laissant de plus dans une incertitude financière et/ou fonctionnelle.

Nous expliquons alors l’impossibilité de prétendre tout prévoir, ni pour lui ni pour nous, avant d’avoir commencé le projet, de notre impossibilité d’assumer financièrement les mauvaises surprises en cours de développement et à contrario de ne pas surfacturer les développements qui se sont mieux passés que prévu (si si ça arrive). La solution dont il a vraiment besoin va se construire au fur et à mesure qu’on va la développer, par petits bouts. Il pourra interagir avec et il aura au final la solution correspondant en tout points aux besoins exprimés qu’il n’aurait pas pu décrire au moment du devis. On vise donc un aboutissement et pas un prix. Et cet objectif suppose que les besoins puissent être remis en question. Heureusement, le client peut changer d’avis en cours de développement.

On va aussi le rassurer sur notre capacité à travailler dans un budget défini, la variable étant le nombre de fonctionnalités réalisées selon ses priorités et donc par intérêt métier décroissant. Le développement contiendra donc les fonctionnalités vitales attendues à minima, mais aura la souplesse de s’adapter si besoin à de nouvelles priorités.

Les clients ayant déjà eu une expérience au forfait se rappellent facilement les frustrations issues du mode forfait en phase de livraison et vont plus facilement comprendre l’intérêt de travailler ainsi.

Nous avons mis au point une brève démonstration de nos outils et méthodes de 15 minutes pour nos prospects. Elle est décisive et nous permet clairement de valoriser notre approche. Commercialement, beaucoup de choses se jouent à cet instant précis : on ne parle plus de concepts, on montre comment se déroule un projet du point de vue du client dans notre approche qualité. Le prospect n’a généralement rien vu de tel ailleurs et nous marquons de très gros points.

Donc la vente d’une prestation agile n’est clairement pas simple, elle demande de montrer et démontrer les avantages qui nous différencient de la concurrence, ce qui est toutefois plus facile que d’être un bon baratineur commercial. Cela permet également de « filtrer » les clients qui cherchent un prix plutôt qu’un résultat ce qui génère rarement une collaboration fructueuse.

Être agile quand on est prestataire

L’agilité est souvent expliquée pour des équipes en mode « produit » et pas pour des prestataires. Certaines choses sont plus compliquées ou ne fonctionnent carrément pas en tant que prestataire.

Le Product Owner est forcément le client…. le mythe !

Être un bon Product Owner demande clairement une bonne formation. Quand on travaille avec un client pour seulement 200 heures de développement, on est déjà content lorsqu’il réussi à se rendre disponible pour faire un point tous les 2 jours. Il ne faut pas espérer qu’il trouve le temps, et l’argent, pour se former à l’agilité et à son rôle de PO. Nous arrivons maintenant à le faire venir quelques jours sur site pour faire une formation accélérée après lui avoir offert le livre « Spécifiez agile » de Thierry Cros.

Le client, qui gère déjà une entreprise par ailleurs rappelons-le, qui a déjà du mal à se rendre disponible autant que nécessaire car il ne l’avait pas prévu, n’a pas forcément les moyens financiers et le temps de suivre une telle formation. Or si les besoins sont mal spécifiés, agile ou pas, le résultat ne sera pas bon. Nous avons donc créé un poste de « facilitateur agile » (proxy PO) qui va faire la liaison entre client et développeurs et accompagner le client pour rédiger les demandes. Avec le temps, le client va s’améliorer et prendre de l’autonomie, mais notre facilitateur conservera le pouvoir de passer un ticket en « accepté », soit « prêt à partir en développement dans la prochaine itération ».

Nous nous sommes rendu compte qu’en étant plus disponible pour spécifier les besoins du client avec ce facilitateur, nous jouons un nouveau rôle dans le projet puisque nous allons pouvoir apporter plus de conseils en amont et ce même au-delà du périmètre technique. Nous allons pouvoir parler « Lean Kanban », « MVP » ou « Impact Mapping » et aider le client à choisir les fonctionnalités utiles au bon moment et ainsi prioriser ses besoins. Cela s’avère plus économique que de faire une énorme solution pleine de fonctionnalités complexes dont on ignore pour l’instant l’utilité faute de retours utilisateurs.

Il faut donc accompagner le client et « partager » le rôle de Product Owner avec lui.

Travailler avec des points plutôt que des heures

En agilité, on estime la difficulté des développements par des points d’effort et ils ne doivent avoir aucun rapport avec des heures. Seulement, en tant que prestataire, lorsqu’un client demande un lot de développement les points ne lui parlent pas du tout. Il a besoin d’avoir une estimation de ce que ça va lui coûter et quand ce peut être prêt, et c’est compréhensible. Nous avons donc fait le choix d’estimer les fonctionnalités en heures et ne voyons pas comment faire autrement. Certains clients ont 6 améliorations à faire pour quelques centaines d’euros, pourquoi les embrouiller avec une nouvelle unité ? Puisque nous ne travaillons pas à temps plein, comment vendre une itération complète ? Nous sommes preneurs de retour d’expérience à ce niveau.

Régularité des sprints

Chaque intervention pour chaque client sera différente des autres. Pour le client X il y a 20 heures estimées pour faire quelques modifications, pour le client Z on s’est engagé à travailler 100 heures pour faire avancer son projet en cours. Il est donc impossible de faire des sprints réguliers. C’est d’ailleurs assez éprouvant pour les développeurs qui ne vont pas toujours travailler ensemble sur le même projet et parfois changer de projet plusieurs fois par jour au gré des urgences ou pour aider leurs camarades. Nous essayons toutefois au maximum de minimiser ces situations.

Facturer en agile

Nous facturons le temps passé par toute personne de l’équipe sur le projet client, quel que soit son rôle, au même taux horaire. Le client paie pour tout ce que nous faisons pour son projet, sauf la correction des éventuelles anomalies pendant la période de garantie.

Pour les petites missions (< 1000 €) nous facturons à la livraison. Pour les missions moyennes (< 5000 €) nous demandons un acompte de 50% et pour les gros projets en cours nous facturons un sprint d’avance.

Les règlements sont malheureusement rarement immédiats et il faut pouvoir payer les salaires du mois en cours. Plus on décale la facturation d’une mission, plus on risque de n’être payé qu’un mois après l’avoir réalisé. Or les salaires sont à payer de suite. Comme on travaille généralement en confiance avec le client, il n’y aura pas de problème à s’entendre sur une facturation en avance ou précoce. Si ça coince, ça peut éventuellement permettre de détecter que le client est un peu juste en trésorerie ou en budget et d’en tirer les conclusions nécessaires.

Mais il faut aussi prendre en compte le temps que nous passons à nous améliorer en général, qui n’est pas imputable directement à un projet en particulier. Les rétrospectives d’équipe, le stand-up meeting quotidien, la transmission interne des compétences, la R&D, les formations, les conférences et les frais annexes générés… cela prend du temps et parfois de l’argent ! Ce ne sont pas des loisirs, ce sont des activités qui nous rendent meilleurs, au bénéfice de notre travail donc des clients.

Grâce à notre tracker de temps, nous avons vu qu’un développeur ne « produit » un travail facturable qu’environ 5 heures par jour. Cela corrobore les explications ci-dessus, mais s’explique également par le fait que le développement est un travail intellectuel qui ne peut être fait à la chaîne. Les développeurs doivent échanger entre eux mais aussi se concentrer et donc en contre-partie faire des pauses. Plutôt que de facturer les pauses (rappel, nous trackons notre temps donc les pauses seraient imputées à un client en particulier), nous avons décidé d’intégrer cette réalité dans notre taux horaire.

En définitive, vouloir se donner les moyens de faire du code plus propre avec des technologies sans cesse mises à jour implique de s’accorder du temps en plus des missions client. Nous avons donc augmenté notre taux horaire de 33% pour financer ce temps. (Si l’envie de crier au scandale vous prend je vous rassure : nous sommes toujours sous les 100 €).

Ce que nous apporte l’agilité

En gros, cet article explique que beaucoup de choses ne sont pas facilement applicables aux prestataires en agilité. Les formations agiles sont toujours dans un contexte produit, nous avons donc du nous adapter. Mais on aimerait tellement avoir l’occasion d’approfondir en ce sens avec des confrères ou des coachs qui savent gérer cette situation.

Voici la liste des choses géniales apportées par l’agilité :

  • avoir amélioré très nettement les rapports avec les clients, travailler en confiance et dans le respect mutuel
  • travailler avec des clients qui nous laissent aller jusqu’à « la qualité »
  • pouvoir travailler en TDD et en pair, avoir une cohésion d’équipe géniale
  • pouvoir embaucher des profils passionnés qui sont attirés par nos méthodes dans l’intérêt de tous (clients et nous)
  • avoir une plus grande implication sur les projets car notre rôle a évolué
  • prendre le temps de nous analyser pour progresser (rétrospectives toutes les 2 semaines) et agir
  • pérenniser la société par une facturation enfin en accord avec l’énergie donnée aux clients

Merci Pierre !