L’histoire de l’agilité chez DoYouBuzz
Après des années de fidélité, nous avons décidé de rompre avec Scrum.
Récit de notre changement de méthodologie.
Avant l’agile
Aux débuts de DoYouBuzz (circa 2008), nous n’avions pas de processus bien cadrés de développement : nous sortions les fonctionnalités quand cela nous semblait utile, mais sur des délais assez longs, la raison était qu’une mise en production était un véritable cérémonial qui demandait de nombreuses manipulations manuelles.
Les symptômes de cette organisation étaient assez dramatiques :
- des temps d’attente de livraison de plusieurs mois
- des mises en productions qui ressemblaient souvent à une intervention sur Fukushima (“C’est DOWN !”)
- et des fonctionnalités tuées avant même de voir le jour
Bref, nous faisions exactement ce qu’il ne faut pas faire, et nous étions tous malheureux…
Scrum à la rescousse
Après moultes lectures et discussions, nous avons commencé à mettre en oeuvre Scrum en 2011, et bien entendu, cela nous a fait un bien fou.
Nous avions désormais un cadre bien déterminé pour agir, basé sur la réalité du monde du développement. Nous suivions la plupart du modèle Scrum religieusement : des dates de livraison fixes (tous les 15 jours), des réunions quotidiennes pour suivre l’avancée du projet, des estimations collectives, des rétrospectives qui nous permettaient de nous améliorer.
De la structure, enfin !
Scrum fatigue
Trois ans plus tard, nous avons commencé à sentir les limites de Scrum pour notre organisation.
Un manque de réactivité
Une livraison tous les 15 jours, on peut penser que c’est plutôt satisfaisant. Et pourtant, ce n’est pas l’idéal. Cela signifie en effet qu’une nouvelle fonctionnalité ou une amélioration peut prendre jusqu’à un mois avant d’être mise en ligne — même s’il ne faut que quelques heures pour la développer !
Le dogme de Scrum (“on ne change pas le périmètre”) nous obligeait parfois à planifier des développements trop loin dans le temps alors qu’ils auraient nécessité un traitement rapide, ou bien on les acceptait mais le sprint était alors mis en péril et la personne à l’origine de la demande en était responsable.
Le cas des fins de sprint
En fin de sprint, trois cas différents peuvent en général se présenter :
- On est en avance
- On est en retard
- On est pile-poil dans les temps
Le dernier étant assez rare, il nous arrivait soit de nous dépêcher de terminer les fonctionnalités à livrer, soit de trouver des tâches pour occuper le temps. Dans ce derniers cas, nous avions décidé de passer le temps “en trop” sur la qualité. L’effet pervers n’a pas tardé à se faire sentir : nous travaillions la qualité en mode “si on a le temps en fin de sprint”… pas très bon non plus.
Parmi les pistes d’amélioration que nous aurions pu envisager, nous aurions pu lister les suivantes :
- Avoir des durées de sprint fluctuantes (une hérésie Scrum, mais des gens très bien le pratiquent)
- Nous améliorer sur l’estimation (mais nous étions dans une période de refactoring assez intense, et bien souvent le code legacy nous réservait quelques surprises de taille)
- Être plus sérieux sur l’aspect qualité ☺
Les p*** de bugs
Le cas des bugs est intéressant. Comment les intégrer dans le planning ? Devons-nous réserver du temps pour les traiter ? Combien de temps exactement ? 10% ? 20% ?
Sachant qu’un bug n’est pas planifié, il nous arrivait d’avoir des sprints sans aucun bug (donc du temps en trop à la fin du sprint), et parfois des sprints où il fallait intervenir rapidement sur des bugs complexes (donc du temps grignoté sur les autres tickets, parfois sur plusieurs journées).
Bref, les bugs cassaient complètement notre planning. Nous devions faire sauter des fonctionnalités, et des clients en attente d’une livraison devaient patienter 15 jours de plus (l’équipe technique a bien essayé d’entraîner les commerciaux à ne plus annoncer de date, mais bon… vous imaginez la suite ☺).
Les tickets qui traînent
Nous avions aussi un truc, “les tickets qui traînent”, aussi appelés “tickets glissants”. Vous savez, ces choses qui sont à faire mais dont la durée s’allonge proportionnellement au temps passé dessus. Chaque jour, l’estimation du temps restant à passer sur le ticket va à la hausse, et tout le monde finit par devenir fou.
Ces tickets étaient de véritables tueurs de sprint. On a donc décidé de leur offrir un traitement spécial : s’ils commençaient à trop dépasser, on le dépriorisait pour le prochain sprint. Bam, au placard !
Résultats : ces tickets traînaient en longueur, bien souvent sur plus d’un mois, et avec cela l’impression de ne pas avancer, des utilisateurs / clients / développeurs furieux. De plus, il s’agissait souvent de problèmes assez velus, et les développeurs devaient régulièrement se replonger dans la complexité du problème avant de s’y remettre vraiment. Pas idéal pour la productivité.
Trop de réunions
L’un de préceptes de l’agilité est de beaucoup communiquer. Scrum propose pour cela plusieurs points de communication :
- Le scrum meeting : 15 minutes, tous les jours
- Le planning de sprint : 1 ou 2 heures tous les 15 jours
- La rétrospective : 2 ou 3 heures tous les 15 jours
- Les estimations : 3 ou 4 heures tous les 15 jours
Bref, sur un sprint de 2 semaines, nous passions au moins une journée complète en réunion (je ne parle pas du travail nécessaire pour les préparer et en noter les enseignements). De plus, ces réunions sont longues et ont la fâcheuse tendance à s’empiler autour de l’échéance du sprint.
Le scrum meeting, que tout le monde jugeait très utile, pouvait quant à lui casser certains développeurs dans leur élan : si on commence à bosser à 9h12 et qu’il faut faire le Scrum quand tout le monde est arrivé vers 10h, il est facile de perdre son mojo ! A ce sujet, vous connaissez sûrement le principe du “maker’s schedule”.
Une solution : que tout le monde arrive à l’heure. Possible dans certaines organisation, mais vraiment pas dans notre culture.
Freedom & Scrum ?
Dernier point qui nous chagrinait avec Scrum : son incompatibilité avec le modèle d’entreprise que nous essayions de mettre en place. Nous étions en plein Reboot, et la liberté était au coeur de nos préoccupations : nous ne voulions plus être dépendant d’un lieu ou même d’un fuseau horaire pour travailler efficacement.
Or, Scrum est difficilement compatible avec ces principes. Scrum demande de la communication, du présentiel et de la synchronisation (le manifeste agile lui même parle de “face-to-face conversation”). Difficile de déménager à l’étranger ou de travailler de manière asynchrone de cette manière. Ou en tout cas il fallait une sérieuse adaptation du modèle.
Back to basics
Pour toutes ces raisons, nous avons décidé d’expérimenter un modèle plus simple, plus efficace (selon nous), et résolument asynchrone. Nous aurions aussi pu essayer de résoudre nos propres limites face à Scrum (il y aurait eu des solutions), mais nous avons décidé d’explorer une autre voie.
Le modèle Kanban semblait coller de manière plus précise à ce dont nous avions besoin : un flux de travail simple, des priorisations susceptibles de changer au dernier moment, mais en gardant l’idée centrale qu’un travail commencé doit être terminé.
Pour cela, nous avons fait plusieurs changements (certains ont été fait avant ce passage, mais semble aujourd’hui primordiaux dans notre nouvelle façon de travailler) :
- Au lieu de faire un point de synchronisation le matin, nous avons pris pour habitude de publier un point quotidien sur notre chat interne, HipChat (chacun le publie quand il le souhaite, de préférence quand il commence à bosser, et les autres commentent s’ils ont quelque chose à dire). Et hop, cette modification dans notre manière de travailler nous permet de ne plus être en synchrone : si l’un d’entre nous veut faire une grasse matinée, il peut le faire sans déranger les autres !
- Un flux d’information plus étoffé : les commits sur le dépôt git, les notifications du serveur d’intégration continu et les notifications de notre outil de geston de projet (Jira) sont maintenant envoyés sur HipChat, ce qui permet une meilleure transparence de l’information ;
- Nous fonctionnons par Pull Request pour terminer les nouvelles fonctionnalités, ce qui offre une meilleure lisibilité sur les nouveautés ;
- Nous partageons beaucoup plus notre documentation sur un wiki (nous utilisons Confluence), afin qu’une seule personne ne détienne plus à elle seule une information essentielle. Nous avions précédemment un wiki, mais sa présence devient désormais indispensable ;
- Nous ne faisons plus d’estimation, sauf pour faire des devis, et si nous le faisons, c’est de manière asynchrone, par commentaires interposés ;
- Evidemment, nous avons parfois besoin d’échanger des idées en direct, sur les problèmes un peu complexes ou bien là où on a besoin de réfléchir ensemble. Pour cela, Google Hangouts et Sqwiggle sont nos meilleurs amis
- La roadmap “macro” est désormais discutée, argumentée et priorisée tous les 3 mois avec l’ensemble de l’équipe (technique et non-technique). Cela permet de se donner des objectifs commun et de se poser régulièrement des questions de fond sur le produit. La priorisation au jour le jour des micro-évolutions, correctifs et des tâches technique reste généralement la prérogative de l’équipe technique ;
- A date régulière, nous faisons une rétrospective pour faire le point et améliorer notre manière de fonctionner. Nous n’avons repris cette bonne habitude que très récemment, et c’est une bonne chose !
A noter que le modèle Kanban propose deux choses que nous ne pensons pas mettre en oeuvre pour l’instant car cela ne semble pas nécessaire pour notre fonctionnement : l’estimation, et la mesure du cycle de vie d’une tâche.
Bilan à 6 mois
Nous travaillons de cette manière depuis maintenant plus de 6 mois et nous ne pensons pas avoir trouvé la recette absolue du succès, mais nous avons observé des améliorations notables dans notre manière de travailler.
Les choses avancent
Les tickets qui traînent en longueur ne sont plus remis au lendemain. C’est un changement majeur car ces problèmes étaient assez centraux et avaient tendance à plomber le moral, comme la productivité, de toute l’équipe.
Nous sommes beaucoup plus réactifs
Si l’envie nous prend de développer une fonctionnalité, on sait qu’elle peut être mise en ligne en quelques heures ou quelques jours. Désormais, nous disposons d’une souplesse magique : nos utilisateurs peuvent suggérer une idée et la voir en ligne la semaine suivante ☺.
Nous passons plus de temps à développer, moins à discuter
Il y a moins d’interruptions dans le travail et moins de réunions. Nous communiquons toujours, mais de manière beaucoup plus asynchrone, sans interrompre les autres dans leur travail.
Ne plus estimer la totalité des tâches est une vraie libération. Nous partons plus désormais du principe que si quelque chose doit être développé, alors il doit être développé ☺. En réalité il y a bien toujours une notion d’estimation, mais il s’agit plus d’évaluer la complexité d’une tâche de manière intuitive pour savoir si elle va durer quelques heures, quelques jours ou quelques semaines, que de valider définitivement une estimation (une journée qui se transforme en deux journées, cela ne pose pas de problème particulier).
Les points négatifs
Le principal point négatif porte sur le scrum quotidien (qui a été transformé en point asynchrone sur notre IRC) : l’équipe a moins d’échanges qu’auparavant sur le travail en cours. Cela ne nous a pas encore posé de problème particulier, mais c’est une transparence de l’information que nous regrettons tous un peu. Cependant, nous ne sommes pas prêt pour autant à abandonner la souplesse que nous offre la communication asynchrone.
J’espère que ce petit retour d’expérience sur notre méthodologie de gestion de projet vous aura plu ! Nous sommes plutôt contents d’avoir remis en cause la méthode Scrum afin d’offrir plus de souplesse à tout le monde et d’améliorer notre productivité. Et bien sûr si vous avez des questions ou même des objections, la discussion est ouverte ! ☺
Crédit Photo : Diana Robinson.
