Kisio Digital est une société qui a connu une croissance rapide de ses effectifs ces dernières années. En un peu plus de 3 ans ils ont été multipliés par 2. Une telle croissance, notamment des équipes de réalisation, n’a pas pu se faire sans modification d’organisation et de méthodes. Ces changements ont été faits dans une optique « Kaizen » : l’amélioration continue sans trop de rupture. Chaque obstacle rencontré a été analysé et a trouvé une solution, bonne ou… pas au fur et à mesure que l’entreprise changeait.
Par Majo statt Senf – Created with Affinity Designer — Travail personnel, CC BY-SA 4.0
Une organisation d’équipes par composants
Historiquement, les équipes de réalisation étaient orientées composants : chaque équipe avait la responsabilité d’une ou plusieurs briques techniques ou de produits complets qui utilisaient ces briques. Par exemple une équipe développait et maintenait Navitia et tous ses composants (recherche d’itinéraires, d’horaires, auto complétion, l’outil de génération des données Navitia, …), une autre développait les applications mobiles qui utilisent les web services Navitia, une autre encore développait le portail back-office et les applications qui le composent (génération de fiches horaires, suivi des statistiques d’utilisation des données clients, …).
Du projet vers le produit et vers l’agilité
Cette structure des équipes a très peu bougé au fil du temps. Des équipes se sont créées sur des briques ou des produits qui n’existaient pas jusqu’alors, toujours avec la philosophie : une brique technique est sous la responsabilité d’une et une seule équipe. Ce qui a évolué en revanche c’est le positionnement de l’entreprise : d’une orientation projet ou service (je fais ce que mon client demande), Kisio Digital est passé à une orientation éditeur ou produit (je développe des solutions que j’ai construites en analysant les différents besoins de mes clients et je leur vends). Ce changement s’est accompagné d’une mutation méthodologique forte : du cycle en V, les équipes sont passées à l’agilité.
Nous avons décidé collégialement de travailler en Scrum. Sont alors apparus de nouveaux postes (Scrum Masters , Product Owners) et un nouveau langage (backlog, itérations, démo, rétro, valeur, …). L’agilisation de l’entreprise est un processus sans fin par nature puisque l’objectif est de s’améliorer continuellement. Nous avons commencé par une équipe sur un produit en 2013, équipe qui a fait de son mieux sans beaucoup de moyens avec une réussite mitigée. Disons que le résultat a été « encourageant », ce qui n’est pas un synonyme de « bon » soyons bien d’accord…
En juin 2014 Kisio Digital a décidé de passer la seconde : toute l’entreprise a été formée à Scrum, chacun avec une formation adaptée à son poste. Toutes les équipes se sont mises à s’agiliser, l’équipe de Scrum Masters s’est fortement staffée, celle des Product Owners également. Nous avons été accompagnés par des coaches de manière régulière, le recrutement des développeurs a continué à un rythme à peu près constant, les équipes ont grossi, se sont multipliées. Nous avons commencé par « faire » agile : coller l’équivalent de forêts entières sous forme de post-it® sur les murs, rythmer la vie des équipes de réalisation de stand up, démos, rétros, … Puis nous nous sommes attelés au « être » agile. Honnêtement nous en sommes encore loin mais on y travaille. L’amélioration continue quoi !
Vers plus d’autonomie
Le résultat de cette mutation à multiples facettes c’est une entreprise où la majorité des collaborateurs se sentent plus responsables, comprennent mieux le sens de ce qu’ils font, apprécient le changement et la critique et demandent plus d’autonomie dans la réalisation de leur travail.
De l’autonomie ? Oui c’est bien l’autonomie. Tous ceux qui ont lu « Drive« , l’ouvrage de Daniel Pink, savent qu’un des piliers de la motivation c’est justement l’autonomie, la capacité à réaliser de A à Z ce qu’on engage (et ceux qui n’ont pas lu « Drive » devraient le faire dès que possible ^^ ). La notion de Time To Market est aussi de plus en plus évoquée : rendre minimale la durée entre l’expression d’un besoin et la mise à disposition des fonctionnalités associées. Bref, en responsabilisant les collaborateurs on augmente leur niveau d’exigence. C’est normal, c’est la voie à suivre, celle de l’excellence : pour devenir meilleur j’ai besoin que les autres deviennent meilleurs et que l’environnement s’adapte. Et là, le besoin, l’envie d’amélioration continue se confrontent aux limites de l’organisation par composants.
Un exemple concret
Plutôt qu’une longue démonstration prenons l’exemple d’un cas imaginaire : la représentation du numéro d’une ligne de bus. Pour représenter le numéro d’une ligne de bus nous avons besoin d’une couleur : celle de la ligne.
Cette couleur est intégrée aux données de Navitia, les sites et applications mobiles utilisent cette couleur pour « dessiner » une représentation sous forme de texte avec une couleur de fond. Les équipes mobile et web ont codé une fonction qui permet de déterminer si le texte doit être écrit en noir ou en blanc pour maximiser le contraste. Et hop voila le travail !
Un jour l’équipe web a un nouveau ticket de bug : la charte graphique d’une ligne n’est pas respectée parce la couleur du texte qui n’est qui n’est pas celle qui maximise le contraste avec celle du fond (pour ceux qui sont perdus : on « calcule » qu’il faut du noir mais sur le terrain c’est du blanc, bim le bug).
Conclusion : la charte d’une ligne est finalement composée d’une couleur de fond ET d’une d’une couleur de texte donnée qui peut n’être ni le blanc ni le noir. C’est dommage parce qu’intégrer directement la couleur du texte n’aurait presque pas pris de temps supplémentaire lors de l’implémentation initiale. Tant pis… Alors, comment fait-on pour ajouter sur le site web une couleur de texte à la représentation d’un numéro de ligne ?
C’est parti :
- L’équipe data doit ajouter la couleur du texte dans ses formats de données
- Une partie de l’équipe Navitia développe la gestion de cette donnée dans l’outil d’alimentation de Navitia
- Une autre partie de l’équipe Navitia intègre l’attribut de couleur de texte dans les web services concernés (lignes, itinéraires, horaires, …)
- L’équipe web utilise la donnée de couleur de texte pour modifier le rendu du numéro de ligne
Tadaaaa !
Les étapes sont ordonnées séquentiellement et chacune nécessite une priorisation de la demande spécifique à l’équipe, autrement dit la personne qui a besoin de ce développement doit s’assurer de 4 prises en compte différentes de son besoin à des moments différents pour avoir une chance de le voir réalisé. Toutes les équipes ont des sprints synchronisés et livrent à la fin de chaque sprint. Comme les étapes sont séquentielles, chaque équipe a besoin de la livraison de l’étape précédente pour faire son job. Donc si tout se passe bien en 2 mois tout est en prod. Wouhou ! Et on n’a pas perdu de temps si on le fait en 2 mois ! 2 mois pour… quelques jours de travail effectif.
Attention : s’il y a un bug dans une seule des réalisations ou même un imprévu qui engendre du retard, le délai augmente de 2 semaines minimum (*).
Enfin, en tant que lecteur attentif, vous aurez remarqué que l’affichage est maintenant correct sur le site web… mais pas sur l’application mobile puisque c’est une autre équipe à qui il faudra faire la même demande (l’équivalent de l’étape 4 mais sur l’application mobile).
Vous aurez compris, il y a trop de dépendances dans ce modèle. L’idéal serait de demander à une équipe (et une seule) de modifier le rendu des numéros de ligne et que cette équipe se charge de tout : de la donnée aux médias qui les mettent en forme en passant par les web services. Ce serait plus simple à suivre pour le porteur du besoin (ce serait « faisable » en fait), l’équipe serait autonome et le résultat formerait un tout cohérent.
Un jour un coach agile a lâché : « Peut-être qu’une organisation en feature teams serait plus adaptée… »
* Au fait, ce n’est pas un cas imaginaire. Et il y a vraiment eu un bug dans une livraison ce qui nous a plutôt fait toucher les 3 mois de délais au final.
Guillaume & Faten
Les agilitateurs 