J’ai besoin qu’on réfléchisse ensemble sur un problème que plusieurs d’entre vous vivent ou ont vécu surement.
Celui, des organisations qui ont séparé les domaines d’interventions informatiques en '« Silos verticaux ».
Exemple de découpages en silos.
Les équipes de développement et entretiens de systèmes
Les équipes technologies (Serveurs, Configuration matérielle, etc.)
Les administrateurs de base de données (DBA)
Les services de télécommunication et réseaux
Et dans ce genre d’organisation, tous les besoins passent par un billet ou par une demande de services. Avec la priorisation dans chacun des services et leur sous-organisation hiérarchisée.
Je ne cherche pas un marteau piqueur pour briser les murs. Mais, des stratégies pour améliorer la communication, voir la dynamique inter équipe.
Impossible non plus, d’avoir administrateur de serveurs dans notre équipe Scrum.
P.S. J’ai quelques idées bien sûr. Mais, j’aime la réflexion collective.
MERCI à l’avance de vos partages d’idées ou d’expériences.
Bruno Larouche
« Empêcheur de tourner en rond’ » et pas sur le toit de silo
Dans un premier temps, je suggère d’aller regarder du côté des X-as-a-service de Team topologies.
Si on ne fait pas tomber les murs, on peut au moins contractualiser les interventions des uns et des autres. En formalisant les choses on améliore la prédictibilité avec des SLA, et donc on peut s’attendre à ce que le tiers ait terminé son intervention avant telle date/heure. Cela a l’énorme avantage de produire des indicateurs de volumétrie ou de taux de réussite, qui peuvent ensuite servir de point de départ à une discussion quantitative sur l’intérêt du cloisonnement ou du décloisonnement.
Je plussoie le recours à Team Topologies. L’idée est de faire les choses progressivement.
J’ajouterais qu’il ne faut pas oublier qu’on ne peut pas casser tous les silos. Ca fait des millénaires qu’on essaie et qu’on n’y arrive pas. L’humain finalement a besoin de silos pour travailler efficacement (cf. nombres de Dunbar entre autres). Quand on casse des silos verticaux, généralement on obtient des silos horizontaux et vice versa. Ca ne veut pas dire que les silos ne peuvent pas être poreux. La méthode à la mode aujourd’hui est de construire alors des communautés de pratiques, mais ça ne fonctionne pas non plus. Il vaut mieux densifier les liens informels (cf. travaux de Dave Snowden là-dessus : https://thecynefin.co/mycorrhiza-scaffolding-1-of-2/ et https://thecynefin.co/mycorrhiza-scaffolding-2-of-2/) pour ensuite éventuellement formaliser certaines communautés informelles.
Bonjour Messieurs, j’ai bien dit que d’un premier temps. je ne parlerais pas de mes solutions.
Oui, je suis d’accord avec vous, la Team as service, en faisant partie. Car, le livre « Team Topologies » est sur mon bureau justement pour bien me rappeler de tous les détails.
Je suis dans une organisation gouvernemental, avec les bons et les mauvais cotés et pensent à contractualiser les services ou les demandes, n’est pas à mon niveau d’influence ou encore moins de décision.
La seule forme de contrat à laquelle, est d’ajouter un item de travail, associé à membre virtuel(à service). Une peut-être simpliste, qui peut-être fonctionné.
…
Il est sur, que mon objectif, n’est pas de casser des silos d’un coté pour en construire, de l’autre, travail inutile !
L’historique de l’organisation, n’a pas eu grand succès avec le communauté de pratique. Elles sont souvent porter à bout de bras qui se sont épuisé en bout de course.
Je pense que, au contraire, il est tout à fait possible de formaliser les demandes, peu importe ton niveau dans l’organisation. Nous sommes nos propres empêcheurs de tourner en rond. A moins bien sûr que cette organisation soit dans un véritable culte de l’aversion contre l’initiative, ou qu’elle ait défini un méta-process strict.
Sinon, rien ne t’interdit d’établir un document qui liste les services que ton équipe fournit aux autres, et le SLA que tu t’engages à respecter. Idéalement, tu peux aussi décrire la manière dont tu préfères que les sollicitations soient transmises. Il suffit ensuite de renvoyer tous les demandeurs sur ce document. Après, il n’y a pas d’engagement juridique, ni de pénalités, c’est juste un moyen de bien communiquer avec les tiers qui dépendent de ton équipe. Le simple fait d’avoir formalisé tes propres services devrait plutôt avoir une influence positive sur les autres, voire leur donner des idées.
Une fois l’exemplarité en place, tu peux ensuite te retourner vers les autres services que toi tu consommes. Si c’est trop intrusif de leur demander de faire le même exercice, tu peux leur demander dans un mode plus collaboratif : « pour ma planification, j’ai besoin d’avoir une idée du délai que je dois espérer pour tel service, et la manière dont vous préférez qu’on vous sollicite ». Tu notes le tout dans un document que tu leur envoies, et ensuite ils en font ce qu’ils veulent.
Mon propos était de dire qu’on ne peut pas faire autrement. Les humains ont besoin des silos. Si quelqu’un les casse, les humains les reconstruisent, éventuellement avec des frontières différentes.
Je suis d’accord, les humains ont besoin de structure et de cadre (limite). Mais, des silos trop étanches. Ça n’aide pas non plus.
Donc, je pense que le problème, n’est pas d’avoir des silos (verticaux ou horizontaux). Mais, de trouver un moyen de communication. Une certaine « osmose communicationnelle », un meilleur du point.
Pas juste l’échange d’un ticket, « J’ai besoin de cette partante »… sans comprendre, le pourquoi, l’impacte organisationnel de la prise en action ou pas.
Un des points mécompris de Conway, c’est que ce n’est pas seulement la structure d’une organisation mais également les moyens et outils de la communication entre les différentes actrices qui induisent la forme du produit. Parler de silo est une première chose, mais d’observer et accommoder les processus et outils qui vont servir à la communication entre ces silos est tout aussi important. C’est notamment ça qui qualifie la porosité entre les dits silos.
