Vous avez des équipes agiles mais n’êtes toujours pas satisfait de votre Time To Market ? Peut être que ces équipes contribuent aux mêmes fonctionnalités mais ont des difficultés à se synchroniser. Je vous livre dans cet article, non pas la réponse “il vous faut des feature teams”, mais plutôt ce que vous pouvez faire avec vos équipes applicatives / composants pour les orienter “fonctionnalités” et les aider à mieux interagir. Le contenu proposé ici est basé sur un retour d’expérience d’un an dans un grand groupe. Le succès de cette expérimentation a donné lieu à plusieurs communications internes.

Des équipes agiles ne font pas une chaîne d’applications agile

Une chaîne d’applications est un ensemble d’applications qui contribuent aux mêmes fonctionnalités. La construction d’une fonctionnalité nécessite donc, dans ce cadre, l’assemblage de parties réalisées par les différentes applications. Ainsi, même si les équipes sont très performantes, ont développé une culture software craftsmanship et devops, le Time To Market global peut être mauvais dans le cas où une équipe a prévu de livrer sa partie dans quinze jours et une autre équipe dans huit mois.

Les feature teams, un idéal

Les feature teams sont devenues populaires après cette publication de Henrik Kniberg & Anders Ivarsson sur l’agilité à l’échelle chez Spotify. Une feature team est un groupe de personnes autonome pour travailler sur l’intégralité d’une fonctionnalité et la mettre en production. Cela implique d’avoir dans un même groupe les personnes qui définissent le besoin, celles qui font la réalisation et mettent en production. Les deux dernières activités sont difficiles à réaliser en autonomie si les fonctionnalités sont associées à plusieurs applications, et que ces dernières sont vieilles de plusieurs années.
Il est possible d’effectuer un travail d’architecture pour dédier une application à une fonctionnalité / service mais c’est quelque chose de compliqué à entreprendre (cependant possible), tout en sachant que pendant ce temps, les fonctionnalités doivent continuer d’évoluer.
Les feature teams sont un idéal qu’il faut garder en tête et vers lequel essayer de tendre dans sa stratégie de conception applicative au fil des années.

Des feature teams dans des component teams

Quand il n’est pas possible d’avoir de vrais feature teams, on peut essayer d’en construire des virtuelles. Il s’agit de groupes de travail composés de toutes les personnes qui contribuent à la chaîne de valeur, du besoin à la production :

• un product owner de la fonctionnalité / domaine fonctionnel.
• un facilitateur.
• un ou plusieurs business analysts et développeurs de chaque application.
• des personnes du support, test, infrastructure, déploiement, etc.

Ce groupe de travail se réunit entre une et deux fois par semaine en fonction des cérémonies. Chaque personne continue de passer la plupart de son temps avec son équipe applicative ou métier.

Le weekly meeting est la cérémonie la plus importante, elle ne doit pas durer plus d’une demi-heure (sauf au début, durant la période de rodage où il y a aussi du temps pour mieux se connaître et discuter de l’organisation). Le product owner donne l’actualité sur la fonctionnalité et son feedback sur les derniers items livrés / testés. Le facilitateur anime le management visuel et veille à ce que chacun ait la place de s’exprimer sur les sujets abordés. Cet espace est également un temps qui permet à deux ou plusieurs personnes, d’application différentes par exemple, d’identifier qu’elles ont besoin de travailler ensemble à la résolution d’un problème une fois le weekly meeting terminé.

La deuxième cérémonie à prévoir est la rétrospective. Elle est essentielle pour se donner du feedback et faire les ajustements pour que le peu de temps passé dans ce groupe soit le plus profitable.

Quand les applications sont traversées par plusieurs feature teams, il est nécessaire d’avoir un super product owner qui anime et opère la priorisation avec l’ensemble des product owners des feature teams. Une rétrospective sur l’ensemble des feature teams piloté par le super PO est également à prévoir pour partager les bonnes expériences / pratiques mais aussi faire des adaptations entre elles.

L’expérimentation d’un an

En juin 2016, j’ai été sollicité pour accompagner le responsable d’un programme de transformation agile. Cette personne avait le mandat pour développer l’agilité à l’échelle sur un périmètre de quatre équipes applicatives qui avait déjà été accompagnées sur l’agilité par le passé. Bien que performantes localement, elle ne permettait pas d’obtenir un bon Time To Market en raison d’une forte dépendance entre elles et d’une faible synchronisation sur les fonctionnalités à livrer.
La solution feature team avait déjà été imaginée avant mon arrivée mais sa définition était difficilement applicable en raison de la complexité des applications (vieilles de plusieurs années avec un nombre important de contributeurs). J’ai travaillé avec le responsable sur une solution hybride, qui ne remettait pas en question les équipes applicatives mais apportait des groupes de travail fonctionnels dont les membres sont issus de différentes équipes applicatives.
Jusqu’à la fin de l’année 2016, nous avons avancé avec des groupes de travail composés essentiellement de responsables de projet et produit. Ce groupe se voyait chaque semaine pour discuter de l’avancement et des prochaines étapes à partir d’un backlog produit. Les problèmes de synchronisation pouvaient désormais être identifiés rapidement par les responsables de projet qui pouvait adapter la priorisation de leur backlog applicatif respectif par rapport aux enjeux du produit / de la fonctionnalité.
A la fin de l’année, le commanditaire a souhaité poursuivre l’expérience et aller plus loin avec ces groupes de travail. Les feature teams ne seraient plus seulement composées de responsables de projet mais aussi de personnes participant à l’analyse et à la réalisation. Les product owners, initialement rattachés aux applications, ont été invité dans ces groupes. Les feature teams commençaient à prendre tout leur sens, avec un vrai product owner, qui rencontrait chaque semaine tous les acteurs de la fonctionnalités. Les product owners ont apporté beaucoup de sens et d’engagement dans les features teams. Les membres, issus d’applications différentes, n’avaient plus besoins de demander à leur manager de résoudre un problème qu’ils avaient avec une autre équipe. Ces personnes, qui commençaient à se connaître de plus en plus, se parlaient directement et travaillaient plus facilement ensemble sur des solutions. Les facilitateurs animaient les weekly en se préoccupant de la qualité des échanges et du management visuel (la liste des fonctionnalités en cours et à venir, avec les contributeurs, les dates prévues et le niveau de confiance).

Lors de la clôture de l’accompagnement à la fin du premier semestre 2017, les participants à cette expérience ont constaté une amélioration de la communication et du time to market par rapport aux années précédentes. Elle a été jugée suffisamment significative pour en faire un retour d’expérience positif à l’ensemble du département de l’entreprise qui se lançait justement sur l’agilité à l’échelle.

Le rôle du coach dans tout ça ?

Mon rôle a consisté à offrir régulièrement aux différents acteurs une prise de recul sur la direction que prenait l’organisation et sur leurs rôles. J’ai travaillé avec les responsables sur des exemples de mise à l’échelle et les options possibles au vu de l’organisation existante. J’ai animé les premiers ateliers (team building, cérémonies) pour rapidement laisser la place aux facilitateurs.

Apprentissages

1. Les weekly meetings : ils étaient le principal rendez vous des membres d’une même feature team. La priorisation du backlog de la feature team, l’avancement des sujets et la confiance à atteindre l’objectif par rapport à la date théorique y étaient discutés. La présence du product owner et du scrummaster était vitale.
2. Durée de vie des feature teams : dans le contexte de l’organisation, les groupes de travail cross-application avaient une durée de vie de 3 à 6 mois.
3. Rétrospectives de l’organisation : elles avaient lieu chaque mois avec les product owner, les facilitateurs, le responsable de la transformation et les responsables d’application et de projet.
4. L’importance du responsable de la transformation: ce rôle opérationnel est très important car il a le mandat pour mener la transformation et la légitimité pour embarquer tous les acteurs. Il porte des décisions (co-construites) comme le design des feature teams et les modifications de l’organisation.
5. Un outil pour relier les user stories applicatives aux fonctionnalités “macro” a été proposé à chaque feature team. Dans les fait, l’outil n’a apporté que peu de valeur et les équipes se sont facilement synchronisées sans.

Vers une évolution (ou pas) en vrai feature teams

Peut-on parler de cette expérience comme une transformation en feature team ? Pas au sens Spotify en tout cas car les feature teams n’étaient pas autonomes pour livrer. Elles dépendaient toujours du cycle de livraison des applications. Ce n’était pas vraiment gênant puisque le backlog applicatif était alimenté et priorisé à l’aide des backlogs des feature teams.

Les feature teams étaient créées lorsqu’il y avait une densité et proximité de sujets fonctionnels à venir suffisantes. Elles n’avaient dans ce cadre qu’une durée de vie limitée de trois à six mois en fonction de l’actualité du produit. Ce contexte n’a pas nourri un besoin d’identifier des parties d’application qui pouvaient être détachées pour former un composant fonctionnel livrable indépendamment.

Peut être que par la suite, ces équipes applicatives auront un contexte qui justifiera la formation de vrai features teams; c’est à dire, avoir sur du moyen / long terme, une densité et proximité de sujets fonctionnels suffisantes et un retour sur investissement du changement d’architecture pour former un lot fonctionnel autonome positif.

photo credit: crosathorian PC270069 via photopin (license)