RTE : l’autre compétence

Vous aurez noté que le cadre SAFe s’appuie sur un « pattern » reproduit à différentes échelles : besoin (Product Manager), Solution (System Architect and Engineering) et Support (Release Train Engineer) pour le niveau « Program ». Si l’importance des deux premiers rôles est généralement évidente, il n’en est pas de même du troisième.

C’est pourtant le postulat de Scrum puis de SAFe : un rôle de facilitation (mais pas que) est nécessaire dans ce monde « mangé par le logiciel ». En d’autres mots, il ne suffit pas d’être bon en termes d’architecture et de définition de besoin, encore faut-il piloter par feedback concret et rapide (merci XP), s’améliorer continuellement, etc.

D’ailleurs, SAFe est clair sur le sujet : le RTE (et incidemment le STE) est un Lean-Agile Leader. Autrement dit, leur but est (entr’autres) de mener leur équipe vers plus de Lean-Agile.

The roles of the STE and the RTE have many similarities. Both facilitate the PI lifecycle events, act as Lean-Agile leaders to their group, and work to cultivate a Lean-Agile mindset and practices in their areas of concern.

© Scaled Agile, Inc.

https://www.scaledagileframework.com/solution-train-engineer/

Reportage photo ?

Imaginez un photographe qui, aujourd’hui, voudrait aller sur un terrain d’opérations et publier son reportage. Toutefois, par ignorance, manque de compétence, inconséquence, il part avec son matériel argentique. Quelle en est la conséquence ? À l’heure de l’instantanéité, le succès de son reportage est peu probable. L’argentique était pertinent… Au XIXème siècle.

Ceci étant, nous avons à faire face à deux écueils.

Le RTE est-il à la hauteur ?

Ce rôle étant parfois sous-estimé, il est confié à des personnes qui, à l’évidence, n’ont pas les moyens de l’assurer. Ainsi, le RTE est vu comme un « facilitateur », un PMO… Et certainement pas un Lean-Agile Leader au sens SAFe. En conséquence, le rôle est confié à une personne considérée comme compétente au regard de cette définition.

Tout le monde a sa petite idée…

Le deuxième écueil est lié à la nature des compétences du RTE : le fonctionnement du train. Autrement dit, les différentes pratiques de planification, développement, intégration, validation, etc. Or, chacun, dès la sortie de l’école ou de la fac, a sa petite idée sur le sujet. Comme le disait mon Chef de Service, il y a bien loin : « l »informatique, c’est la science des ânes »… Idem pour l’organisation et le fonctionnement de l’équipe.

Imaginez un Architecte qui devrait faire face à des remarques, commentaires, propositions… de personnes qui n’ont strictement aucune compétence technique. Et passer son temps à convaincre…

Et donc… ?

À mon sens, la toute première étape consiste à reconnaître que le passage à l’agile est une véritable libération, une révolution. La vente continue pendant les travaux… Ce qui – généralement – prend beaucoup de temps. Encore faut-il garder l’objectif à l’esprit : répondre aux défis de l’époque actuelle en termes de gestion des incertitudes, des changements… En appliquant des pratiques lean-agiles. D’où l’importance du RTE, spécialiste de son domaine, tout comme le Product Manager ou l’Architecte peuvent l’être. RTE : l’autre compétence nécessaire aujourd’hui.

Le Management – dans les grandes organisations – a un rôle crucial : il est exemplaire en valorisant (quitte à caricaturer parfois) la parole du RTE.

Peut-être une autre piste est du côté du RTE lui-même : être convaincu de l’importance de son rôle et de la valeur de ses compétences dans l’organisation.

It’s a Long Way to Tipperary