Des OPTIONS pour changer la composition de l’équipe

Agile
Des OPTIONS pour changer la composition de l’équipe

Chaque changement de composition d’une équipe a des répercussions plus ou moins positives mais généralement significatives sur l’ambiance de l’équipe, sur ses résultats, et donc sa performance.

Si la pratique commune des entreprises est de confier la responsabilité de ces changements à un ou plusieurs managers, pour garantir une certaine optimisation globale de l’occupation des ressources, il en reste pas moins le besoin d’anticiper et de penser les conséquences de changements de composition d’équipes avec elles, afin de préserver au mieux ou renforcer les dynamiques collectives existantes.

Plutôt que de mettre tout le monde devant le fait accompli d’un départ impromptu ou d’une réorganisation plus ou moins large, il existe différentes options dans la façon de penser, préparer et conduire ces changements.

Si ce changement est motivé dans le sens des intérêts de l’équipe pour l’accomplissement de sa mission, il y a bien sûr plus de chances d’en tirer bénéfices rapidement.

Si ce changement est subi, pas suffisamment pensé, partagé et accompagné, il peut occasionner évidemment davantage de problèmes.

Mais il s’agit là que 2 idées trop simplificatrices de l’ensemble des nuances possibles de la façon dont les changements interviennent dans les équipes.

Une intention positive et partagée ne garantit pas le succès. Les groupes humains sont complexes, déjà par les relations qu’ils entretiennent.

Tout changement dans ce tissu relationnel n’est pas sans incidence sur l’ensemble du groupe.

Un point d’accroche pour diminuer cette complexité organique est de bâtir des équipes en considérant les critères de bon fonctionnement d’une équipe agile retenus par Claude Aubry et résumés avec l’acronyme T.A.P.I.S. : Taille réduite, Auto-organisée, Pluri-disciplinaire, Identité, Stable.

La stabilité d’une équipe sur une certaine durée est un facteur déterminant de l’engagement sur un objectif collectif, d’autant plus que cet objectif n’est atteignable que par la coopération quotidienne entre membres de l’équipe.

Il en reste pas moins que l’équipe est nécessairement amenée à changer, et qu’il convient d’anticiper et penser ses changements pour conserver les capacités d’équipe à répondre à sa mission.

La bonne taille et composition initiale d’une équipe est discutable. Elle dépend bien sûr du contexte et de la mission qui lui est confiée.

Malgré tout, les schémas de départ peuvent être identifiés :

  • Une équipe centrée sur le DISCOVERY comprendra a minima un product trio avec 3 représentants : du business (product manager), des utilisateurs (designer UX/UI), de la technique (développeur)

Une équipe peu mature sur le DISCOVERY, pourra bénéficier de l’assistance d’un « coach produit » pour conduire une démarche d’identification et priorisation d’opportunités (cf. Opportunity Solution Tree Mappping par exemple)

Les opportunités ainsi priorisées peuvent demander une capacité de développement plus importante que seul un développeur ne peut combler.

Lorsque l’activité demande une organisation des éléments de travaux en 2 niveaux stratégie et tactique Opportunités/Fonctionnalités Stories User ou techniques, le modèle d’une équipe Scrum trouve son sens en complément des rôles sur le discovery.

  • L’équipe Scrum est composée du Product Owner (une personne pour prioriser l’activité de l’équipe), de Développeurs, d’un Scrum master (ou coach agile) pour formaliser le cadre de travail de l’équipe, l’aider à définir des règles communes, à les respecter et à revoir ses pratiques, afin de maximiser sa performance et la maintenir durablement.

Une équipe peut avoir besoin de définir d’autres rôles, reflétant surtout le besoin d’auto-organisation et de pluridisciplinarité pour accomplir sa mission de façon plus autonome, d’obtenir des résultats de façon plus prédictible.

Maintenant que ces principes de construction d’organisation d’équipe agiles sont posés, nous pouvons passer au « DYNAMIC RETEAMING ».

Pour changer une équipe il y a plusieurs options :

  1. One by one : ajouter une personne à une équipe

Cela peut demander de retirer cette personne d’une autre, ou simplement de la recruter.

  1. Grow and split : lorsque la taille de l’équipe devient trop importante, que la complexité relationnelle et de communication pèse à l’ensemble de l’équipe, il est temps de se séparer.

  2. Isolation : des membres d’équipes diverses sont regroupés pour faire une nouvelle équipe. Cela traduit en particulier la volonté d’avoir une équipe Pluri-disciplinaire pour se focaliser sur un nouveau sujet.

Monter une Task Force. Cela demande d’anticiper les changements de chacune des équipes précédentes, en ayant quelques options sur des disponibilités plus ou moins partagées entre 2 équipes. Il convient pour chacun d’avoir une équipe prinicipale et de réguler les sollicitations hors de cette équipe.

  1. Merging : Rassembler 2 équipes en une seule.

Lorsqu’une ou les 2 équipes gagnent à être rassemblées pour se focaliser ensemble sur un objectif principal commun. Le gain est d’optimiser la communication via la synchronisation et la coopération (travailler ensemble au jour le jour sur la même chose) et donc limiter les écarts/délais d’intégration.

  1. Switching : 2 équipes s’échangent 1 de leur membre

Cela permet d’éviter les tours d’ivoire de connaissance en facilitant le partage de connaissances.

Maintenant ces principes et options de changement posées, nous voilà un peu plus armés pour mieux comprendre où nous en sommes, où voulons-nous aller et quels chemins de transitions d’équipes opérer.

Reteaming sportif

Le rapprochement d’équipes de développement logiciel avec des équipes sportives a certainement ses limites mais n’est pas dénué d’intérêt.

Le rôle d’entraineur/sélectionneur vient bien sûr à l’esprit quant il s’agit de déterminer la meilleure composition de l’équipe pour un match et pour opérer les changements en cours de match. Gérer les affects de chacun pour construire un collectif performant est une gageure.

Je laisse au lecteur le soin de décrypter ces 3 sources :

La suite …

La suite de cet article sera de considérer l’ Onboarding de nouveaux équipiers avec des rôles spécifiques, à partir de retour d’expériences de situations (exotiques ?) rencontrées récemment :

  • Onboarding d’un Scrum master dans 3 jeux de quilles

  • Onboarding d’un nouveau Product Owner (un de plus pour la même équipe !)

Référence

  • Le livre Reteaming

  • Team Topologies