Après le départ de développeurs, les demandes se retrouvent souvent dispersées entre tableurs, messages, tickets et souvenirs des personnes restantes. Ajouter des cérémonies Scrum ne résout pas ce problème. L’objectif est d’abord de créer une organisation minimale qui rende les priorités et les blocages visibles.
Commencer par un backlog unique
Tous les travaux doivent être réunis au même endroit : incidents, engagements clients, dette technique, refonte et nouvelles fonctions. Chaque sujet comporte au minimum un objectif, un responsable métier, un niveau de priorité et un critère permettant de dire qu’il est terminé.
Le backlog ne doit pas devenir un inventaire infini. Les doublons, idées sans sponsor et tâches devenues inutiles peuvent être archivés. La confiance revient lorsque la liste reflète le travail réel.
Séparer les types d’urgence
Tout ne peut pas être prioritaire. Une grille simple aide à arbitrer :
- production ou sécurité : traitement immédiat ;
- engagement client daté : décision explicite ;
- blocage d’équipe : résolution rapide ;
- amélioration produit : arbitrage selon la valeur ;
- dette technique : priorité selon le risque futur.
Cette classification évite qu’une demande portée par la personne la plus insistante remplace silencieusement le travail en cours.
Clarifier trois responsabilités
Même dans une petite équipe, trois décisions doivent avoir un propriétaire :
- Produit : pourquoi et pour qui construit-on cette fonction ?
- Technique : comment la livrer sans créer un risque excessif ?
- Exécution : qui fait quoi, avec quelles dépendances et pour quelle démonstration ?
Une personne peut cumuler plusieurs rôles, mais les décisions ne doivent pas rester implicites. Un CTO externalisé peut assurer temporairement la responsabilité technique pendant la reconstruction de l’équipe.
Travailler en cycles courts
Un cycle d’une ou deux semaines limite la quantité de travail invisible. Au début, l’équipe choisit peu de sujets et vérifie qu’ils peuvent réellement être terminés. À la fin, elle montre un résultat utilisable : correction en production, parcours en préproduction, déploiement automatisé ou décision technique documentée.
La vélocité n’est pas l’objectif principal d’une équipe en transition. La prévisibilité l’est : terminer régulièrement vaut mieux que commencer beaucoup.
Installer seulement les rituels utiles
Une organisation légère peut fonctionner avec :
- un point quotidien de quinze minutes centré sur les obstacles ;
- une planification courte au début du cycle ;
- une démonstration avec les décideurs ;
- une rétrospective avec une ou deux améliorations concrètes ;
- un point de priorisation produit séparé lorsque nécessaire.
Chaque réunion doit produire une décision, une information partagée ou une amélioration. Sinon, elle peut être supprimée.
Rendre le travail visible à la direction
Le reporting doit répondre à quelques questions stables : qu’avons-nous livré, que livrerons-nous ensuite, quels risques menacent la production et quelles décisions sont attendues ? Évitez les pourcentages d’avancement sans preuve observable.
Les indicateurs utiles peuvent inclure le délai entre début et livraison, le nombre d’incidents, la fréquence de déploiement et la part de travail imprévu. Ils servent à détecter un problème, pas à comparer les développeurs.
Intégrer la dette et le DevOps au produit
Une équipe en transition ne peut pas consacrer toute sa capacité aux nouvelles fonctions. Les tests, déploiements, sauvegardes et dépendances conditionnent les futures livraisons. Ils doivent apparaître dans le même backlog et être expliqués par leur impact métier.
L’exemple MyTwiga
Lors de la reprise de MyTwiga, les sujets étaient répartis entre plusieurs outils et treize dépôts. Farrago a centralisé le backlog, explicité les responsabilités et organisé des cycles courts couvrant mobile, API, DevOps et maintenance. Cette visibilité commune a permis de terminer les refontes et de remettre les applications en production. Découvrez la réalisation complète.
L’organisation agile ne remplace pas l’expertise technique. Elle lui donne un cadre pour produire des décisions et des livraisons régulières. Si le départ est encore récent, commencez par notre plan d’urgence après le départ du CTO ou des développeurs.