Reprenons plus concrètement le rôle du RTE… Basé sur SAFe bien sûr.
Voici la première redevabilité du RTE.
Manage and optimize the flow of value through the ART using various tools, such as the Program Kanban and other information radiators.
Amélioration continue
Comme toujours, le mindset constitue notre boussole. Commençons par les valeurs. Où nous découvrons… Program Execution. Nous sommes au cœur du sujet. Cette gestion du flot de valeur, son optimisation, sont en dernière analyse la raison d’être de SAFe. C’est ce que l’on retrouve dans le mindset constitué par la maison Lean et le Manifeste agile :
- Le toit de la maison Lean (sa finalité) Shortest sustainable Lead Time,
- Le premier principe agile (qui est le principe Lean initial adapté au Lean Development) Our highest priority is to satisfy Customer through early and continuous delivery of valuable software .
Et une clé : l’Inspect and Adapt. Disons le autrement, via un principe SAFe : Build incremenistaly with fast integrated learning cycles. Pour être tout à fait clair, le travail du RTE est quasiment impossible sans ces boucles d’apprentissage. Encore une autre façon de dire la même chose : « Feedback concret et rapide », principe clé de l’Extreme Programming, qui est un corollaire de Just in Time ou bien de « petits stocks ».
- Cycle d’amélioration du produit : via les démonstrations. Ces sessions pendant lesquelles les Développeurs démontrent le produit, concrètement (pas de slideshow) et surtout les invités donnent du feedback à l’équipe, au train. Nous pourrions même dire que ces invités conseillent le train.
- Cycle d’amélioration des pratiques, via les rétrospectives et autres Problem Solving Workshop.
Ces deux sessions sont obligatoires en agile et dans SAFe en particulier.
En fonction de la situation, le RTE pourra provoquer des démonstrations et/ou rétrospectives supplémentaires, sans attendre la fin du Program Increment.
Flot de valeur
Dans « flot de valeur », il y a valeur. De nombreuses pratiquent permettent d’estimer cette « valeur », cette importance de chacune des features qui composent le produit, progressivement. Si SAFe s’appuie sur le Cost of Delay, un simple Business Value Poker permet déjà d’objectiver un peu cette valeur. Sinon, le risque est grand d’être encore le jeu de ses biais cognitifs et de confondre priorité et valeur. Une mesure importante ici est donc la valeur acquise après chaque Program Increment.
Voila pour la base.
Comment s’améliorer ?
- D’une part à partir de la vie du train, tout simplement. Un événement, un incident, devrait être une opportunité d’amélioration ;
- d’autre part en respectant – n’est-ce pas évident… – les principes lean-agile condensés dans les principes SAFe.
Apprendre en faisant
C’est la base de l’agile et de ces approches : l’empirisme. Souvenons-nous du préliminaire du Manifeste agile : Nous découvrons… en pratiquant….
Mais, un Program Increment est long… Une bonne dizaine de semaines, voire plus. Comment faire ? Une pratique complémentaire à la rétrospective, et très utile, est le bac rouge. Notez simplement dans un coin du Management visuel, ou sur une page de votre wiki wiki web préféré, chaque incident rencontré en Program Execution.
- Date
- Référence (par exemple du ticket dans le backlog)
- brève description.
Ensuite, il reste à dépiler ce log pendant la prochaine rétrospective. Cette pratique, issue du Lean Manufacturing, est vraiment très efficace. Pas de « bla bla » en rétrospective.
As usual… Les principes
Ces principes constituent votre boussole. Pour en revenir au propos initial, et vous laisser au passage un peu de travail perso :), posez-vous la question :
Quels sont les principes SAFe directement en lien avec cet aspect du boulot de RTE : optimiser le flot de valeur ?
Un indice : il y en a plusieurs !
Le RTE s’appuie alors sur l’un de ces principes pour optimiser la valeur dans le train. Par exemple Apply System Thinking.
Où l’on découvre le goulot d’étranglement. Alors… Que faire ? Supposons que la tool chain de la System Team soit le goulot.
- Améliorer le goulot, par exemple renforcer le serveur d’intégration ou bien modifier les protocoles de Build…
- Puis, subordonner l’ensemble au goulot, par exemple, aussi paradoxal que cela puisse paraître, diminuer les demandes de Build…
- Enfin, si tout cela reste insuffisant, envisager de changer le système.
Et bien d’autres principes sont très utiles ici.
Attention à un point, pour éviter toute frustration : dans les organisations classiques, structurées, hiérarchiques, très « process », seul le Management peut changer le système.
En résumé, le travail de RTE est absolument passionnant… Quand il est réalisable.