Acceptez que des équipes ne fassent pas partie d’un train Agile !

Entendez-vous parfois des équipes se plaindre du manque d’utilité des réunions de coordination dans vos trains ? « Le Scrum of Scrum » est ennuyeux, personne ne s’écoute », Peut-on faire notre PI Planning avant les autres équipes, nous n’avons pas de dépendances avec elles ? », Je ne viens plus aux démos de train Agile, ça ne m’intéresse pas ! »

Train Agile, oui ou non ?

Il arrive effectivement que des équipes ne voient pas l’utilité de faire partie d’un train, ou ne ressentent le besoin de travailler avec les autres équipes de ce train. Voici quelques symptômes, illustrés par les remarques précédentes :

• Des équipes n’ont pas besoin d’un PI Planning pour planifier ce qu’elles vont développer lors du prochain PI. Parfois même, cette planification est quasiment terminée lors de la préparation du PI Planning.
• Il n’y a peu d’échange lors des Scrum of Scrum, PO Sync ou autres réunions de synchronisation de train. Chacun parle à son tour. Parfois on n’a rien à dire.
• Idem lors des démos de train : on assiste poliment aux démos des autres équipes sans poser de questions, parfois même sans trop comprendre.

Ne pas confondre train Agile, guilde ou communauté de pratiques

Peut-être a-t-on alors oublié qu’un train Agile, c’est avant tout un ensemble d’équipes construisant un système, un produit, et non pas un ensemble d’équipes que l’on a regroupées car historiquement elles faisaient partie d’un même département, ou qu’elles font peu ou prou le même type de développement.

• Si une équipe est seule responsable d’un produit complet, garder là indépendante ! suivant le manifeste Agile « La simplicité (…) est essentielle » Ne regroupez des équipes en train que si c’est absolument nécessaire. C’était à dire dans le cas ou l’architecture cible du produit à construire ou à faire évoluer nécessite de faire collaborer plus d’une cinquantaine de personnes organisées en petites équipes agiles. Le train formant alors une équipe d’équipes.
• L’Agilité est aussi au niveau de l’organisation des trains : S’il fait sens qu’une équipe change de train parce que son périmètre fonctionnel ou technique évolue, ou parce que plus simplement on s’est trompé en s’associant à un train Agile, proposez-lui de changer ! 

Enfin ne pas confondre train et guilde ou communauté de pratique.

• Un train est un ensemble d’équipe développant un même produit, un même système et ayant besoin de se synchroniser pour gérer des dépendances et délivrer un produit/application/système en partie ou complètement.
• Une guilde ou une communauté de pratique est un ensemble d’équipes utilisant une même technologie, un même progiciel, etc… et ayant besoin d’échanger des bonnes pratiques, de résoudre des difficultés similaires, sans pour autant devoir gérer des dépendances.

Dans le cas de guilde, la seule chose dont vous aurez besoin est de réunions d’échanges pour résoudre les difficultés communes ou échanger des bonnes pratiques, voire de démos pour partager des réalisations. Appelez un chat un chat : une guilde, une communauté de pratique n’est pas un train, n’utilisez pas la structure de train pour résoudre des problèmes communs à plusieurs équipes !

Ainsi, en ayant des trains uniquement composés d’équipes ayant réellement besoin de se synchroniser, de travailler ensemble, de collaborer pour livrer un produit, un système, vous redonnerez du sens à cette notion de train et aux évènements qui vont avec (PI Planning, Scrum of Scrum, PO Sync, Démos de train), et vous perdrez moins de temps en réunions peu utiles.

Quel bilan de votre organisation en trains  ?

• Quelles équipes ne se sentent pas à leur place ? Pourquoi ? 
• Est-ce que toutes les réunions sont utiles ? A qui ? pourquoi ?
• En fonction des résultats, réorganiser vos trains en prévision du prochain PI Planning : Quelles équipes peuvent être indépendantes ? Quelles équipes seraient mieux dans un autre train ? Quelles équipes seraient mieux dans une guilde ou une communauté de pratiques que dans un train ?
• Et recommencer à chaque PI : l’Agilité est aussi dans votre organisation !

Dans de nombreuses organisations nous voyons des silos se recréer sous la forme des trains SAFe et l’idéal d’organisation autour de la valeur et de réactivité semble s’être volatilisé. Or pour gagner en adaptabilité et réactivité il faut avoir la capacité de requestionner l’organisation des trains SAFe de façon régulière en cherchant à créer les conditions d’une plus grande autonomie des équipes. Cela passe par la composition des équipes et des trains mais aussi par l’évolution de l’architecture du produit qui doit être composable et agile.

Chez inspearit nous avons une expérience avancée de ces sujets que nous abordons dans les missions de conseil auprès d’organisations avancées dans leur transformation agile à grande échelle.

Si ce sujet vous intéresse n’hésitez pas à nous contacter

Thierry Ventadour, Coach Agile