La system team est une composante essentielle de l’agile à l’échelle.
Parfois, la relation entre équipe de dev dans le train et elle n’est pas au beau fixe. En effet, sa redevabilité dans l’organisation n’est pas toujours claire.
Un manque d’amélioration continue (via retrospective, stop the line…), une communication bancale sont autant de causes de cet état de fait qui perdure.
Les équipes considèrent la system team – https://lnkd.in/eYXh8hzw – comme une « hotline » multi-services que l’on peut contacter pour tout et n’importe quoi.
Et la system team bien souvent néglige le nécessaire apprentissage, pour ne pas dire formation, qui permettrait une utilisation plus efficace de la tool chain.
Que faire ?
Évidemment, ne pas laisser s’installer un climat qui peut finir par être délétère. Le problème est que cela va très vite. Les neurosciences (intelligence émotionnelle) nous apprennent qu’un ressenti s’engramme fortement après trois semaines et qu’à partir de là, il devient beaucoup plus difficile de rectifier le tir.
La communication, valeur de l’Extreme Programming, reste une solution incontournable. Je me souviens d’une organisation dans laquelle j’avais organisé une session dédiée à ce problème. C’est là que nous avions constaté un décalage entre ce que la system team pensait être d’une part et ce que les équipes de dev croyaient de leur côté. Nous avions alors défini ensemble la raison d’être de la system team dans l’ensemble.
Une vision de produit, type Lean Canvas, vision XP ou impact mapping, permet aussi de fédérer les parties prenantes.
Ce décalage consubstanciel aux natures des équipes est à l’origine du mouvement DevOps, aujourd’hui partie intégrante de SAFe. Profitons donc de ce que nous pouvons apprendre ici pour améliorer le quotidien de chacun dans le développement du produit.
https://lnkd.in/eY3M7egJ
* Je t’aime… Moi non plus : chanson et film de Serge Gainsbourg (https://lnkd.in/eJaR-P3c)