L’agilité chez QoQa : interview avec Joann Dobler

En décembre 2014, on recevait un appel de Joann Dobler qui est en charge des pôles multimédia et digital chez QoQa. Dans les grandes lignes, ça disait quelque chose comme “Salut Liip, on est en train de refaire tous nos sites et apps mobiles, et on cherche un partenaire pour nous aider à lancer le projet dans la bonne direction niveau méthodologie et techno. Ca vous tente ?”
En voyant l'opportunité de pouvoir pratiquer Scrum sur un chantier immense comme QoQa.ch, nous avons accepté sans hésitation.

Trois ans après cette discussion, leur nouvelle plateforme au nom de code “QoQa4” est désormais en ligne après de nombreux sprints, coups de gueule, montées en stress, sans oublier les fondues et choucroutes au Café Romand.
En voyant le chemin parcouru niveau méthodologie agile après plus de 70 sprints, je me suis dis que ça serait intéressant d’interviewer Joann pour avoir son retour d’expérience concret sur l’Agilité et Scrum, quelques années après avoir écrit sa première User Story.

Bienvenue à Joann Dobler, celui qui a introduit Scrum et ses outils assez carrés dans un environnement QoQasien où on pense que les règles sont plutôt faites pour être enfreintes !

Pourquoi toi, Joann, tu as pensé à l'agilité pour QoQa fin 2014 ? Quelles conditions t'ont amené à considérer cette méthodologie ?
En fait, je connaissais déjà l'agilité, et je savais qu’au vu de l'ampleur du projet et donc au temps de sa mise en place, nos priorités business et technologiques allaient évoluer. On devait donc choisir une méthode qui nous permette de nous adapter. De plus, pour une question d’état d’esprit, de partage, et de dynamisme au sein de l'équipe, on devait s’adapter, et donc dynamiser notre façon de travailler.

En résumé : il nous fallait un truc pour mieux nous adapter au business, faire face aux changements de priorités, offrir de la transparence, et amener un réel échange au sein de l’équipe.

Quelle méthodologie de gestion de projet utilisiez-vous avant chez QoQa ?
On utilisait une méthode traditionnelle, genre un agenda par étapes et jalons. Une fois les maquettes graphiques terminées, on débutait avec l’HTML… Pour les petits projets, ça pouvait jouer, mais dès que c’était plus conséquent, on finissait avec des délais jamais tenus, aucune flexibilité, et surtout un gros manque de dynamisme avec les équipes.
Si quelqu’un peut m’assurer un délai d’un gros projet un an à l’avance, je l’invite pour une bouffe afin qu’il m’explique sa technique — no joke !

Pourquoi avoir choisi Liip pour vous accompagner plutôt qu’un coach agile ? Autrement dit, quelle stratégie de montée en compétence recommanderais-tu à quelqu’un qui veut se lancer pour de bon dans Scrum et l’agilité ?
J'avais besoin d'experts dans le domaine pour nous accompagner à l'implémenter.
Je voulais une agence qui a de la bouteille, qui vit agile et qui connaît les avantages et les inconvénients de cette méthode. Je cherchais à ce qu’on se trouve en totale immersion.
Par dessus tout, je voulais bosser avec une agence “no-bullshit”. Du coup j’ai appelé Liip.

_Création du backlog QoQa4 de 300+ stories_

Comment se sont passées les premières semaines avec Scrum ?
Au début c’était assez excitant, on avait nos post-its, notre board Jira, on faisait nos rétros/reviews et on pouvait se la raconter en interne : “Regardez on arrive avec une méthode révolutionnaire !” Mais c’est seulement après trois mois qu’on a rencontré nos premiers véritables soucis ; c’est une fois que le projet est 100% agile que tu comprends ce que veut dire agile.

Combien de sprints a-t-il fallu pour que tu te rendes compte de l’impact et de la réelle valeur ajoutée de Scrum ?
C’est difficile à dire...je dirais aux alentours de 4 sprints (i.e. 8 semaines) pour la communication et l’échange entre les équipes. Par contre bien plus en terme projet, je dirais environ une dizaine de sprints de deux semaines chacun.
Les premiers mois furent très difficiles car on n’avait pas compris ce que Scrum et l’agilité demandaient, à savoir faire preuve d’une énorme rigueur, et adopter un vrai changement philosophique (vs. “simplement” faire des sprints).
Concrètement, on a du beaucoup plus échanger, se dire les choses de manière transparente. La hiérarchie aussi en prend un coup.

Comment aurais-tu géré ces premières semaines si tu étais resté avec ton ancien modèle de gestion de projet ?
C’est simple, je n’aurais tout simplement plus de job ;)
J’aurais fait un magnifique planning, j’aurais découpé mes tâches, et j’aurais attribué mes tickets. Du coup, peu d’échanges, pas de mise à profit des compétences de tous les membres de l’équipe. Je pense sincèrement que cette méthode nous a permis d’écouter nos utilisateurs, d’analyser leurs vrais besoins, et de s’adapter au fur et à mesure.

_Premier meeting d'estimation Scrum_

Comment s’est passé l’adoption de l’Agilité/Scrum en interne ?
Au début, c’était super facile car ça paraissait tendance. Mais c’est quand les premiers problèmes surviennent qu’on se rend compte de la difficulté d’intégrer cette méthodologie. Pourquoi ? Car par exemple, lors de nos premières retros/reviews, on a dû se parler en toute transparence ; cela paraît ridicule mais ça change tout.
On n’avait plus de titres mais des rôles à jouer, alors la hiérarchie est rapidement mise de côté au profit de l’échange. On est passés par des périodes difficiles car le projet sur lequel on a démarré est simplement le plus gros de projet de QoQa de ces dix dernières années. Pression, choix à faire, décisions à prendre, implication de plusieurs départements, merci à la méthode qui nous a obligés à rester calme, à partager nos problèmes, et à trouver des solutions ensemble.
Et je dois dire qu’on a eu la GRANDE chance d’être soutenu par la Direction, enfin par la Loutre in Chief qui nous a fait confiance.

Je dois avouer que les débuts furent plus que difficiles, j’avais la sensation de griller du cash en meeting. Le rôle du PO n’est pas simple car on a le budget en tête et un planning que le business attend avec impatience. Alors moi qui suis un impulsif, j’ai vraiment eu la sensation de bosser avec une méthode à la mode. Mais là encore, grâce au soutien, j’y ai cru, j’ai changé ma façon de penser, et aujourd’hui j’en suis heureux. Il faut laisser le temps que tout se mette en place, faire confiance, garder la rigueur, et se faire épauler.

Si tu ne devais citer qu’une valeur ajoutée que Scrum a apporté à QoQa dans son ensemble, qu’est-ce que ça serait ?
La COMMUNICATION !
Sans déc, c’est incroyable les silos que ça a fait péter. Même les gars de la logistique ont adopté des outils de Scrum avec des meetings courts de synchronisation chaque matin

_L'équipe cross-fonctionnelle QoQa-Liip — incluant développeurs, POs, et designers_

Si tu ne devais citer qu’une valeur ajoutée que Scrum a apporté à toi le PO, qu’est-ce que ça serait ?
Apprendre à couper dans le gras ! Autrement dit savoir mettre des priorités et ne pas partir la tête dans le guidon en se disant que tout est indispensable.

Qu’est-ce que tu penses de la qualité délivrée par un projet en mode agile (i.e. la correspondance entre besoins utilisateurs et le produit développé) comparé à un projet en mode “waterfall” ?
Alors c’est tout simplement différent. Avant c’était moi le pro du web et je savais mieux ce dont l’utilisateur avait besoin. Maintenant, c’est l’utilisateur qui dicte mon métier. On y va étape par étape, on commence par le minimum, on analyse, on implique tous les acteurs. Toutes ces discussions font que tu économies du temps de production car tu testes, tu récoltes des infos du terrain, et seulement après tu construis par dessus. C’est fini la belle époque où on se disait “Je sais une année avant ce qu’il te faudra”.

Est-ce que Scrum a solutionné tous tes problèmes ? Si non, qu’est-ce que ça ne couvre pas ?
J’ai envie de dire OUI — ce que je ne disais pas il y a deux ans — même si on a encore beaucoup à expérimenter. Ce qui est vraiment cool c’est qu’on a un scénario agréable avec un gros projet en interne sur lequel on peut réellement prendre le temps d’itérer, et non juste se contenter de lancer des fonctionnalités l’une à la suite de l’autre.

Combien de sprints avez-vous fait jusqu’à maintenant ?
69 ;)

Rétrospectivement (on est agile après tout), quelles sont les raisons qui font qu’après une soixantaine de sprints vous n’étiez toujours pas en production au printemps dernier ? Et qu’est-ce que tu ferais différemment aujourd’hui avec les connaissances que tu as acquises ?
On aurait dû couper dans le gras. On a fait la pire des erreurs de vouloir tout, tout de suite, et en mieux qu’avant.

Quid de la visibilité ? Mieux ? Moins bonne ? Niveau planning ?
Ce fut mon principal problème quand on a commencé l’intégration de l’agilité, avec tout le monde qui venait me dire “Alors on lance quand ces nouvelles plateformes ?”
J’ai dû geler le business pendant plus de deux ans, donc la question était tout à fait prévisible et je devais pouvoir y répondre. Mais au début, je n’en avais aucune idée avec notre backlog long comme le bras.
Grâce à Liip et leur méthodologie, j’ai pu finalement avoir ma réponse après ce qu’ils appellent une “speed estim”. En gros, on a pris les 300+ User Stories du backlog, et on les a estimé en moins de 3h30. C’était incroyable, j’avais enfin de la visibilité pour moi et les parties prenantes au projet.
Par contre, je me suis pris une grosse claque une fois qu’on a eu la somme totale de Story Points. Si je me fiais au estimation, on en avait pour deux fois plus de temps que notre roadmap initiale sur une année… Mais j’ai fini par comprendre qu’encore une fois je voyais trop gros, et que même si ça faisait mal, il fallait encore plus couper dans le gras.

_Le meeting de review Scrum amène de la visibilité sur le travail réalisé, et ce chaque deux semaines_

Quid de la communication au management/reporting en interne ? Toujours Gantt ?
C’est quoi un Gantt !!? Ca répond à ta question ?

Sinon, vous avez eu des changements au niveau scope/business en cours de projet ? Comment les as-tu gérés ?
Yes complètement ! Je dirais que quelques mois avant la mise en production, on a dû faire des choix car il fallait bien se lancer un jour. La méthode permet une telle transparence que ces choix furent pris de manière vraiment cool. Je pense qu’on pourrait encore être en train de développer à l’heure qu’il est, et encore pour quelques années au vu de tout ce qu’on veut faire. Mais non, on s’est lancés à l’eau. Comment ? En gérant nos priorités et qui de mieux placé que nos QoQasiens pour nous dire ce qui leur manquent ? Du coup, pas mal de fonctionnalités abandonnées dans une première version, et on a tellement bien fait !

Niveau priorités des parties prenantes dans le projet, comment as-tu géré ça ? Intégration des besoins du chef, des départements ?
Après avoir défini les grandes lignes du scope de la V1 du projet, on a impliqué tous les utilisateurs par département dans les choix, les priorités, le design, et surtout les testing. Les grands axes eux furent validés lors de nos COPIL. La méthode permet une vision très détaillée de l’avancement du projet, ce qui facilite la prise de décision.
Mais c’est important de souligner qu’après environ 6 mois de projet, on était totalement perdus... On sera prêts dans un an, deux an, trois ans… Aucune idée et je peux vous avouer que je faisais pas le malin, et c’est là qu’il faut faire confiance à la méthode, et rassurer les équipes avec un peu de bullshit…
De nouveau : speed estim, couper dans le gras, se faire accompagner, et elle est belle :)

Quid de la rigueur de l’agilité (oui oui l’agilité c’est beaucoup de rigueur malgré le nom !) chez QoQa qui est plutôt freestyle d’habitude ?
C’est ce qu’on n’avait pas compris au départ : il faut de la rigueur sinon c’est mort. Pour moi qui suis un créatif, la rigueur fut difficile à accepter. Mais maintenant je peux le dire, cette rigueur nous rend plus créatif !!! Mais il faut le vivre pour comprendre.

_Pause ping-pong, ou comment allier rigueur et freestyle !_

Un mot sur les cérémonies Scrum de début de sprint, estim et planning ?
C’est le début d’un projet ou d’une nouvelle itération, alors c’est cool et motivant.
Côté estim, on ne parle plus d’heures de travail, mais de complexité. Ca parait fou mais c’est juste top — ce qui me paraissait irréaliste il y a encore deux ans.

Un mot sur les cérémonies Scrum de fin de sprint, review et rétrospective ?
C’est la fin du projet donc ça dépend du résultat, mais normalement c’est top car il n’y a jamais de surprises. Si surprises, c’est qu’il y a eu une mauvaise communication durant le sprint. C’est un vrai moment d’échanges et de partage. On se dit les choses et on essaie de les améliorer ; c’est dingue mais ça marche ! Au début quand je recevais des post-its rouge, j’avais de la peine à l'accepter... mais aujourd’hui j’adore, on s’améliore sans cesse.

_Le meeting de rétrospective Scrum, un élément crucial pour l'amélioration continue_

Et le grooming en cours de sprint ? Vous l’utilisez ? Pourquoi ?
Le grooming est essentiel, il peut faire gagner tellement de temps comme on implique l’équipe très tôt dans le processus de création des User Stories. On détaille et on réfléchit ensemble, c’est très créatif. S’il y a un doute, alors la story n’est pas claire et ça nous pousse à être plus précis, et donc éviter les surprises. La boucle est bouclée.

Question finale: Si aujourd’hui tu devais recommencer un projet (pro ou perso d’ailleurs), tu t’y prendrais comment ?
Je débuterai par un Gantt évidemment ;)

---

Encore un grand merci à Joann d'avoir pris le temps de partager son retour d'expérience.
Chez Liip, ce qu'on retient le plus de cette aventure, c'est que "couper dans le gras" est l'une des clés de la réussite d'un projet.
On se réjouit de continuer à collaborer avec l'équipe des loutres pour échanger sur leurs expérimentations de Scrum.