Release Train Engineer (RTE) : Postures, défis et réalités du terrainPar Pierre Medina – Coach agile Senior, SPC/RTE Senior, formateur (Nombre de mots : 2 230 / Temps de lecture estimé : 11 minutes)
Depuis plus de vingt ans, j’ai arpenté les couloirs de l'IT, d’abord comme développeur, puis chef de projet, directeur de programme (avec des programmes avec jusqu'à 50 personnes), architecture d'entreprise, auditeur, manager de transition, coach agile, jusqu’à piloter des transformations à l’échelle SAFe.
Au fil des missions, j’ai accompagné plus d’une trentaine de DSI, en direct ou en mission de transformation, dans des contextes riches, parfois critiques, toujours différents.
Banque, assurance, santé, industrie, luxe, retail, énergie, transport, services publics, tech...
J’ai eu la chance d’intervenir auprès d’acteurs comme Axa, Natixis Financement, Murex, MGEN, La Poste (BGPN), France Travail (ex Pôle Emploi), Société Générale, EDF, Renault, RATP, Institut Français du Petrole, Alstom/General Electric, Tissot, Eaton, Christian Dior, L’Oréal, Lacoste, Orange Business Services, et bien d’autres encore.
Chaque organisation porte son ADN, ses arbitrages, ses contraintes. Mais une constante m’a toujours frappé: souvent plus stable que les équipes elles-mêmes - Jira.
Je l’ai découvert en 2007. Depuis, je l’ai vu partout. Parfois redoutablement efficace, parfois totalement hors de contrôle.
Et c’est précisément cette ambivalence que je voudrais explorer ici : Jira n’est jamais neutre. Il reflète la manière dont une organisation pense, s’organise, collabore ou dysfonctionne.
Dans l’un de mes derniers accompagnements, je suis tombé sur un backlog Jira de 2 000 tickets. Des user stories, des bugs, des tâches techniques, des items qui traînaient depuis 3 ans.
Quand j’ai demandé au Product Owner s’il pouvait m’expliquer ce qui était encore valide, il a hésité, puis m’a dit : « Franchement, je ne sais plus. Je n’ose même plus ouvrir le backlog. »
Jira n’était pas le problème. Jira reflétait exactement ce qu’ils faisaient. C’est ça qu’il faut comprendre : Jira est un outil. Il montre ce que vous mettez dedans. Ni plus, ni moins.
Ce qu’on attend (ou espère) de Jira dans une équipe agile
- Un backlog structuré, clair, priorisé
- Une coordination fluide entre PO, SM, devs
- Des rituels outillés, basés sur des données fiables
- Un pilotage visuel des flux
- Des indicateurs utiles pour décider, pas pour contrôler
Ce que je vois trop souvent
Jira devient un outil de documentation
« Pas besoin de doc, tout est dans Jira. » C’est l’erreur la plus répandue. Jira est un outil d'exécution. Pas un référentiel produit. Pas un espace de conception.
Les décisions clés doivent vivre ailleurs. Sinon, cinq ans plus tard, impossible de reconstruire l’intention produit à partir de milliers de tickets épars.
Lecture recommandée: Gérer la dette technique agile : bonnes pratiques pour maintenir la qualité du code
Le statut "bloqué" : la voie de garage
Créer un statut "bloqué", c’est souvent créer une zone de non-action. Les tickets s’y accumulent et n’en ressortent jamais.
Préférez un flag, un label ou un champ dédié, mais surtout : un traitement immédiat, dans le flux, sans détour.
Des boards illisibles
J’ai vu des boards à 15 colonnes, avec des workflows imbriqués, des sous-tâches techniques empilées et des tickets qui ne bougent jamais.
Un board utile est lisible en 3 secondes. Ce qui est à faire, en cours, fait. Pas plus.
Recommandations terrain
Backlogs : entretien, nettoyage, cadrage
- Backlog d’équipe : entretenu toutes les deux semaines ou en continu
- Backlog de train (features, MMF) : revue continue, nettoyage complet au moins une fois par trimestre
- Volume cible : 2 à 3 fois la capacité du train sur un PI. Au-delà, c’est un cimetière.
Lecture recommandée: PI Planning : un investissement stratégique pour l’efficacité et l’alignement
Exploiter les bons rapports
Control Chart : pour suivre le cycle time, l’âge des tickets, les dérives de flux
Cumulative Flow Diagram : pour repérer les goulets, les interruptions, les effets de lot, etc...
... Et quelques autre Reports
Dashboards utiles à l’équipe
Pas de reporting pour le contrôle. Un outil de vigilance collectif.
- US non reliées à une MMF
- Tickets vieux de plus de 3 jours
- Bugs non traités depuis X jours
Lecture recommandée: Les 5 KPI incontournables pour suivre efficacement un sprint agile
Utiliser JQL et l’automatisation pour renforcer la qualité
Quelques exemples :
Des règles d’automatisation simples peuvent faire gagner un temps précieux, en évitant les oublis, en alertant, en nettoyant.
Et le management ?
Mal accompagné, il devient un frein
Jira peut vite devenir un outil de micro-management. Vélocité individuelle, suivi à la tâche, dashboards détournés.
Résultat : perte de confiance, contournement de l’outil, rejet de l’agilité.
Bien accompagné, il devient un levier
Un manager formé comprend ce que montre un dashboard et ce qu’il ne montre pas.
Il devient sponsor des pratiques saines, relai d’exigence et facilitateur d’amélioration continue. Selon qu'on soit dans un train ou une equipe agile, cette tache incombe au RTE ou aux SM.
Lecture recommandée: Release Train Engineer (RTE) : Postures, défis et réalités du terrain
Conclusion
Jira ne vous rend pas agile. Il vous montre si vous l’êtes. Brutalement. Mais honnêtement.
Un backlog tenu, un flux maîtrisé, des décisions prises au bon niveau : Jira le reflète.
Mais si votre fonctionnement est confus, Jira l’expose. Et ce n’est pas la faute de l’outil.
Formation recommandée
📘 Formation : Mettez Jira au service de votre organisation agile
Conçue pour les Scrum Masters, Product Owners, Coachs Agiles et RTE, cette formation vous donne les clés pour exploiter Jira en mode agile, sans le subir.
- Structurer et entretenir vos backlogs (équipe et train)
- Créer des dashboards utiles à l’équipe
- Maîtriser JQL et l’automatisation
- Éviter les dérives (reporting, micro-management, complexité)
📝 Demander un devis ou s’inscrire
📩 Contact : contact@knowledgeladder.academy
📞 Tél : 07 49 23 91 00
Aucun commentaire:
Enregistrer un commentaire