Cartographie d'un groupe d'équipes avec OrgTopologies

Contexte du cas d'usage

J'ai eu la chance de participer début mars 2024 à la toute première formation OrgTopologies en France avec les deux co-créateurs Alexey Krivitsky et Roland Flemm

Comme souvent, les idées s'évaporent après les formations. Or j'ai eu l'opportunité d'utiliser ce bel outil seulement trois semaines plus tard, à l'occasion d'un atelier avec un groupe de personnes travaillant sur le système d'information d'un domaine bancaire. Le périmètre de ce domaine étant celui de la tenue de compte et de la gestion des différents moyens de paiement (SEPA ; IP ; Virement Gros Montants...).

Les personnes du domaine regroupent différentes expertises assez classiques telles que Business Analyse ; programmation dans différents langages ; Ops. Les expertises sont parfois dans la même équipe, parfois dans des équipes distinctes.

Mise en scène

Avant l'atelier, la demande des commanditaires portait sur l'identification de piste pour "être plus agile". J'ai partagé avec eux que de gagner en fluidité et gagner en capacité à changer de priorité était une manière de qualifier et quantifier le fait "d'être plus agile".

J'ai débuté l'atelier en racontant l'histoire d'une startup que je connais dans l'archétype C3, qui a été lancé en 2013 par ses deux fondateurs, lesquels faisaient absolument tout pour leurs premiers clients. En grossissant, la startup a changé de structure et s'est retrouvée avec plusieurs équipes spécialisées, perdant la vision globale du produit et la fluidité initiale. Pour illustrer l'archétype Y0, j'ai évoqué la caricature de l'expert en sécurité qui interdit tout à tout le monde.

Ensuite, j'ai proposé aux participants de cartographier leurs équipes actuelles dans un premier temps, en travaillant par groupe afin de partager leur point de vue sur la place des différentes équipes.

Pour ce faire, j'ai expliquer assez brièvement un premier niveau de lecture avec une carte 2x2 (no-team / team et livrables / bénéfices) et ensuite je suis allé dans un niveau de détail plus fin avec la carte des 16 archétypes dans une matrice 4x4.

Les personnes présentes étant les managers seuls. Les Développeurs n'étaient pas présents. Aussi, nous avons clarifier l'objectif qui était de faire émerger des idées d'amélioration. Beaucoup de personnes étant absentes, je ne souhaitais pas que les participants s'engagent sur des plans d'action impliquant les absents.

Les sous-groupes ont apporté des questions subtiles sur la finesse du grain des "Produits". D'un côté, parler de "Produits" trop petits (Transfert SEPA ; Transfert IP ; Transfert Gros Montants...) conduit à de l'optimisation très locale ; fait perdre de vue la vision globale ; amène à l'accumulation de listes de travaux, de files d'attente, de besoin de couche de coordination et d'arbitrage de priorités... Et de l'autre, parler de "Produits" trop gros (la Banque) devient trop abstrait et fait perdre pied avec la réalité des collaborateurs.

J'ai choisi de les laisser régler eux-mêmes leur curseur de lecture de la cartographie afin de favoriser leur engagement dans l'atelier, plutôt que de rentrer dans une posture de "formateur", ce qui n'était pas à l'ordre du jour.

De ce fait, plusieurs tickets ont été placé au niveau B (équipe d'équipes ou méta-équipe, multi-fonctionnelles et multi-technologies) alors qu'il aurait probablement été plus judicieux de les placé au niveau A (groupe d'équipes plus ou moins focalisées sur des fonctionnalités et des domaines fonctionnels distincts).

D'autres débats ont émergé autour des frontières entre les colonnes 1 et 2 voire 3. Je les ai orienté vers les archétypes "bas" afin de garder les options d'amélioration plus visibles.

Les groupes ont placé leurs tickets sur le tableau partagé, et discuté pour s'aligner sur leurs points de vue.

J'ai lancé quelques débats autour de certaines équipes identifiées A1 ou A2 ; B2 ou C2, mais j'ai décidé de ne pas gaspiller notre temps sur des détails peu importants pour ce tout premier atelier.

Les participants ont apprécié cette représentation graphique même s'ils n'ont pas fait de grandes découvertes car la carte était déjà partiellement dans leurs têtes.

Ensuite, nous avons dessiné des lignes afin de clarifier les interactions entre les différentes équipes, ce qui sera précieux pour l'émergence d'idée qui suivra.

A partir de ces tickets et des liens, les participants ont ensuite échangé sur leurs options d'amélioration et de restructuration des équipes afin de progresser vers les archétypes de plus hauts niveaux, vers la droite et le haut de la cartographie.

On peut observer ici le regroupement de trois équipes ensembles (Business Analysts + Programmeurs + Ops), trois fois, ainsi que l'éclatement d'une équipe Ops pour partager rapidement son expertise. A terme, cela devrait donner lieu à la création d'équipe d'équipes pluri-fonctionnelles et pluri-technologies ayant des périmètres de responsabilités et d'autonomie plus vastes qu'initialement.

Je n'ai révélé mon tour de magicien qu'à la fin de l'atelier, en ne mentionnant qu'à ce moment là que j'avais utilisé la cartographie OrgTopologies.

Pour terminer l'atelier, j'ai proposé quelques questions de réflexion, avec un tour de table pour que chacun puisse confortablement s'exprimer :

• qu'est-ce que l'atelier m'a révélé ?
• qu'ai-je appris ?
• Sachant que de nombreuses personnes sont absentes, quel peut être MA prochaine action (leur parler de la carte ; refaire un atelier similaire dans quelques mois) ?
• Comment je me sens maintenant (plutôt confiant ; curieux...) ?

Conclusion

Avec ce matériel produit, Roland Flemm m'a aidé par la suite à clarifier plusieurs points en lien avec la carte qui a émergé de l'atelier, ce qui m'a permis de mieux comprendre la carte pour des ateliers futurs.

Nous avons amorcé un mouvement avec un atelier assez simple grâce à la cartographie. Il nous reste à entretenir cet élan et à accompagner les équipes à monter vers ces archétypes de plus hauts niveaux.

Et vous, dans quel contexte pourriez vous utiliser cette cartographie ?