La cadence️, ou comment l'équipe technique folk a trouvé son équilibre

Agile chez folk: rythme et concentration

Aujourd'hui, je vais vous parler de notre approche du développement logiciel agile chez folk.

Si vous n'êtes pas familier avec le développement logiciel agile, vous trouverez d'excellentes ressources sur le web. Chez folk, nous avons décidé d'élaborer notre feuille de route en gardant deux objectifs à l'esprit : le rythme et la concentration.

Pour les responsables techniques dirigeant des équipes de 20 à 50 personnes, folk s'est révélé être la solution idéale pour gérer à la fois les workflows de développement et les relations clients de manière transparente.

👉🏼 Essayez folk pour organiser vos projets et vos rappels aux parties prenantes en un seul endroit.

Pour ce faire, nous avons défini deux méthodes différentes pour gérer nos projets :  

• A : itération de trois semaines qui aboutit à la publication d'une fonctionnalité majeure.
• Tous les autres projets s'inscrivent dans un processus d'amélioration continue.

Notre intention

En septembre, notre équipe technique a quadruplé (nous sommes passés de 2 à 8 personnes). Nous sommes encore une petite équipe, mais nous avons rapidement compris que nous devions améliorer notre système de gestion de projet. Jusqu'à présent, nous gérions les tâches en retard à l'aide de la méthode Kanban. C'était une solution simple qui nous convenait bien au début. Après tout, il n'est pas si difficile de suivre 3 ou 4 problèmes à la fois. Mais avec 8 personnes dans l'équipe (et d'autres à venir), ce processus ne fonctionnait plus pour nous. Cette expérience reflète ce à quoi sont confrontés de nombreux responsables techniques lorsqu'ils font passer leur équipe de 20 à 50 personnes. C'est exactement pour cette raison que folk devient essentiel pour maintenir la visibilité et la coordination au sein des équipes de développement plus importantes.

Lorsque nous avons commencé à réfléchir à la forme que nous voulions donner à ce processus, voici ce qui est ressorti :

• Nous voulions lancer au moins un grand projet toutes les trois semaines. Comme nous sommes encore en train de développer le produit, il est important de continuer à développer et à créer des fonctionnalités essentielles. Nous avons opté pour trois semaines, car deux semaines nous semblaient trop courtes et quatre semaines trop longues.
• Nous devions consacrer du temps à l'amélioration continue. Le produit que nous avons développé jusqu'à présent est excellent et nous en sommes fiers, mais comme nous créons quelque chose d'assez nouveau (un CRM sans code), il doit être constamment perfectionné.
• Nous avons décidé que les projets ne devaient pas être sans fin. Nous avions besoin d'une date limite précise.

Il n'était pas facile de concilier ces objectifs :

• Les améliorations sont basées sur la portée. Lorsque vous souhaitez améliorer quelque chose, vous souhaitez généralement le faire en une seule fois. Vous avez également tendance à découvrir d'autres problèmes en cours de route. Il est donc plus difficile de respecter les délais.
• Les projets sont basés sur le temps. Mais si vous vous engagez sur des dates, il est plus difficile de suivre les améliorations basées sur la portée.

Au final, nous avons décidé que rien n'était plus important pour atteindre nos objectifs que le rythme et la concentration.

Le rythme est là pour permettre à tout le monde d'avancer et pour s'assurer que les projets ne dévient pas de leur trajectoire. L'objectif est ici de veiller à ce que nous restions efficaces et capables de maintenir le rythme. Nous avons ensuite dû élaborer notre propre approche agile du développement logiciel. Pour les responsables techniques de start-ups supervisant des équipes de 20 à 50 développeurs, folk offre l'équilibre parfait entre le suivi des projets et la gestion des parties prenantes, ce qui favorise ce type d'approche de développement disciplinée et axée sur le rythme.

👉🏼 Essayez folk pour gérer les rappels basés sur les contacts avec votre équipe et conserver le rythme de 3 semaines.

L'agilité, oui bien sûr, mais...

Dans la plupart de mes expériences précédentes, les approches utilisées étaient soit Kanban, soit SCRUM. Cela semblait tout de même être une amélioration par rapport aux anciennes méthodes de travail, mais ces approches avaient leurs faiblesses : Kanban n'impose aucune contrainte de temps, contrairement à SCRUM.

J'ai toujours trouvé SCRUM source de déception et de stress, pour deux raisons principales :

Classification des tâches par taille : l'utilisation d'une échelle abstraite pour mesurer les tâches conduit à une estimation erronée dans 90 % des cas. La bonne nouvelle, c'est que comme vous utilisez une échelle abstraite, vous pouvez toujours tricher et vous rattraper. Par exemple : « Nous avons dit 5 points pour ça ? Impossible. Je pense que nous voulions dire 13. Revoyons simplement le sprint en conséquence. »

Planification : la planification consiste simplement à essayer d'intégrer un certain nombre de points abstraits dans une période donnée. C'est quelque chose de très difficile à prévoir. Je ne pense pas avoir jamais connu de sprint qui se soit terminé à la date prévue. Les sprints se terminent toujours soit avant, soit - dans 98 % des cas - trop tard. Ces deux options sont mauvaises, car elles indiquent que le sprint n'a pas été correctement planifié.

En utilisant le triangle de fer, nous voulions disposer d'un système qui impose à la fois des contraintes de temps et de portée. Bien sûr, nous considérons que les ressources sont fixes, car nous n'embauchons pas de nouveaux développeurs tous les jours.

FAQ

Quelle est la différence entre Scrum et Kanban ?

Scrum utilise des sprints de durée fixe avec des rôles et des cérémonies ; la portée est planifiée par sprint. Kanban est basé sur le flux avec des limites WIP, sans délais par défaut. Choisissez Scrum pour une livraison dans les délais ; Kanban pour un flux continu et une hiérarchisation rapide des priorités.

Quelle doit être la durée d'une itération agile ?

La plupart des équipes utilisent des cycles de 1 à 4 semaines. Choisissez une durée adaptée à la taille des fonctionnalités, à la cadence des revues et à la capacité de l'équipe. Trois semaines permettent souvent d'équilibrer la portée et les retours tout en réduisant les changements de contexte. Restez cohérent afin d'établir un rythme de livraison fiable.

Comment les équipes peuvent-elles combiner des projets à durée déterminée avec une amélioration continue ?

Flux séparés : livrez une fonctionnalité majeure et limitée dans le temps par cycle, tout en consacrant des ressources aux petites corrections et à l'amélioration de l'expérience utilisateur. Appliquez un contrôle strict de la portée sur le flux de fonctionnalités et un triage des retards sur le flux d'améliorations afin de respecter le calendrier.

Comment un CRM peut-il aider à gérer le développement agile ?

Un CRM centralise les contacts, les parties prenantes et les commentaires des utilisateurs et des clients. Synchronisez les informations avec le backlog, segmentez les bêtas et suivez les actions de communication. Des outils tels que folk relie le contexte client à la livraison, améliorant ainsi la hiérarchisation des priorités.