Toutes les équipes agiles ne se valent pas

Référence :

• lien meetup;
• lien de rediffusion sur streamyard

Feature team ou Component Team ?

Ces notions viennent de LeSS.

• l’équipe reçoit les sujets depuis le backlog produit (par le PO).
• Multi fonctionnelle.
• Multi composant.
• Stable sur le long terme (élément central pour pouvoir considérer une équipe comme étant une équipe produit mature).
• Livre des incréments du produit (“potentiellement” livrable).

La Feature Team fonctionne en cascade (i.e. “Waterfall”) entre analyse, conception, implémentation, puis test : les étapes se suivent sans se chevaucher, sur un composant donné.

Les équipes composants (“Component Team”) interviennent au moment de l’implémentation. Elles n’interviennent qu’à ce moment là, avec un risque d’incohérence, s’il n’y a pas d’interraction. Chaque équipe composant va alors récupérer les éléments de son composant de la fonctionnalité donnée. Elle vise à optimiser la charge de travail sur un composant donné.

Avec des équipes fonctionnalités (“Feature Team”), les différentes équipes travaillent sur une même fonctionnalité, même si elle concerne plusieurs composants. Cela permet à chaque équipe de prendre directement une fonctionnalité issue du backlog produit.

Une feature team :

• ne peut pas compter trop de personnes (ou alors elle s’est redécoupées en équipes composants : backend, frontend, etc);
• est organisée de telle sorte que l’expertise est partagée entre les membres de l’équipe (plusieurs personnes ont plusieurs compétences).

Les limites pour constituer une authentiques équipe fonctionnalité

Une équipe agile classique sera en réalité un hybride entre “feature” et “component” team, de sorte que l’équipe fonctionne en apparence en mode composant, mais dans la pratique, les personnes se retrouvent par compétence, par besoin (collaboration), etc.

“Au sein d’une équipe fonctionnalité, quand la spécialisation devient une contrainte, l’apprentissage survient” (cf. less.works). Autrement dit, une bonne équipe fonctionnalité surmonte la contrainte par le partage de la connaissance.

La clé pour se différencier d’une équipe composant se trouve dans l’approche de l’apprentissage.

Feature team, agile ou pas ?

Pas tant que ça : l’équipe fonctionnalité en est encore aux balbutiements. Plus loin se trouvent :

• les squads,
• les impact teams, et
• (le saint graal), l’équipe produit.

On peut aller plus loin …

Si on reprend le découpage stratégie / discovery / delivery / run…

• Une équipe composant se positionne uniquement sur le delivery.
• L’équipe fonctionnalité reste très orienté sur le delivery, mais couvre également les problématiques de run (sans en être responsable).
• La squad (tel qu’introduit, pas le retour d’expérience de Spotify) élargit le périmètre du discovery jusqu’au run : pérenne sur un domaine fonctionnel donné. La squad a totalement la main sur le run.
• Impact Team (venu de Meilleurs Agents) : se base sur un impact business;
• Product Team (notamment issue de Marty Cagan, sous le nom de “impowered team”).
• l’Impact Team prend totalement en main son discovery, et commence déjà à prendre la main sur la mise en œuvre de sa stratégie (en plus du reste).
• L’équipe produit a totalement la main sur l’aspect stratégie (en plus du reste).

Quelle organisation ? Centrée sur quoi ?

• L’équipe composant est sur une organisation très traditionnelle, en waterfall et en silo. Elle est concentrée sur la productivité (“output”).
• L’équipe fonctionnalité se rapproche plutôt de ce que propose “Agile@Scale”. L’équipe vise déjà la production de valeur (même si elle n’a pas encore la main dessus).
• Les squads pratiquent du “vrai” DevOps, et le découpage d’organisation en micro-service (sans forcément le propager sur le plan technique, suivant les besoins du métier). Les squads sont déjà engagées dans la pérennité de leur produit (il doit être maintenable, etc.) et de la valeur produite.
• L’impact Team dispose déjà du product management, et sera typiquement pilotée par des OKR. L’équipe est également pilotée par ses impacts business, et la croissance de son produit (acquisition de nouveaux marchés, etc.).
• Une équipe produit ressemble déjà nettement plus à une mini-startup au sein de l’entreprise (elle est totalement autonome, dans la définition de ses objectifs, de la valeur qu’elle souhaite produire, la nature de cette valeur, etc.).

Du point de vue du passage à l’échelle ?

Le système de Product Team permet également beaucoup plus de souplesse, car chaque équipe produit est capable de s’organiser. D’autre part, on peut découper le problème, pour répartir son traitement entre plusieurs équipes. On se retrouve avec une équipe en auto gestion.

une équipe composant va croître de façon assez lourde et nécessiter une gestion assez verticale et rigide, de type pyramidale.

Les modes d’organisations entre les deux permettent d’obtenir de plus en plus d’autonomie et de souplesse de l’organisation. On retrouvera par exemple une organisation matricielle, pour les organisations en fonctonnalité ou en squad. À noter que cette organisation en matrice est encore lourde, pour les personnes à responsabilité (souvent d’une équipe et d’un chapitre/forum/etc.). C’est d’ailleur la raison pour laquelle Spotify est revenu en arrière. À partir du format de la squad, on va aussi commencer à éviter la centralisation, pour en arriver à se concentrer sur une vision commune.

Point de vue marketing ?

L’équipe composant va se retrouver “esclave” des personnes décidant de la direction du produit (patron, équipe market, etc.). L’équipe fonctionnalité redescend la responsabilité entre les mains du Product Manager, plus proche de l’équipe. La squad va encore plus loin, en créant un partenariat entre le produit l’équipe. Dès le format d’impact team, la responsabilité du produit est “dans” l’équipe.

Correspondance entre modèle et framework ?

• Équipe componsant : pas agile (ou pas vraiment …). Par contre, LeSS et SAFe permettent de partir d’une équipe composant, tout en favorisant l’évolution de l’équipe vers une vraie agilité.
• Équipe fonctionnalité ou squad : commence à faire du Scrum. LeSS et SAFe visent ce format.
• à partir des Squads, c’est beaucoup plus difficile de retrouver un modèle LeSS ou SAFe, qui vont avoir du mal à s’adapter (après, ils peuvent servir de base pour aller plus loin)
• Certaines squads, mais surtout les niveaux supérieurs disposeront d’un vrai focus produit, et donc vraiment faire du Scrum. Par contre, LeSS est SAFe ne sont plus du tout adaptés.

Plus on avance, plus on voit une grande maturité agile (cf. “Agile Fluency”) :

• une équipe fonctionnalité commence à appliquer un changement de culture au niveau de l’équipe;
• la qsuad apporte un changement de répartition des compétences au sein de l’équipe; l’impact team retravaille sa structure au niveau de son organisation;
• enfin, l’équipe produit en arrive à impliquer une évolution de la culture de l’entreprise.

Bien que Spotify ait popularisé son modèle sous le nom de “Squad”, son modèle ne s’y tiens plus tel qu’on se représente les squads aujourd’hui, et peut aussi correspondre à un modèle d’impact team ou d’équipe product.