REX de notre consultant Stéphane Déprès qui intervient dans le cadre d’un vaste programme de déploiement de l’Agilité à l’échelle en tant que coach agile@scale et coach lead.

retour expérience d'un train SAFe

Contexte

L’organisation pour laquelle j’interviens possède un data warehouse (entrepôt de données) dont le développement, la maintenance et le support occupe environ 150 personnes.

L’objectif de ce data warehouse est de fournir un ensemble de données servant de référence unique pour le reporting et la prise de décisions dans l’entreprise. Il est alimenté par de très nombreux fournisseurs de données et utilisé par de très nombreux consommateurs de données.

La structure organisationnelle et les mécanismes de synchronisation mis en œuvre autour du data warehouse

Comme beaucoup de data warehouse, ce data warehouse est traversé par plusieurs chaines de valeur métier. Se pose donc la question de la structure organisationnelle et des mécanismes de synchronisation agile permettant à la fois :

  • D’optimiser le time-to-market par chaîne de valeur en synchronisant de manière efficace le développement des applications consommatrices des données, le développement du data warehouse et le développement des applications fournissant les données. En sachant qu’historiquement, les équipes concernées avaient du mal à se coordonner.
  • De garder une stratégie de développement du data warehouse non segmentée par chaîne de valeur et d’adresser la cohérence cross chaînes de valeur.

L’organisation pour laquelle j’interviens prône une approche Spotify pour la structure organisationnelle à laquelle viennent s’ajouter des mécanismes de synchronisation dimensionnés en fonction du contexte allant d’un « light sync » dérivée de LeSS à des trains SAFe. Nous avons donc exploité cette approche.

Nous avons décidé de garder une tribu centrée sur le data warehouse, ce qui permet d’adresser la cohérence cross chaînes de valeur et donc l’optimisation des coûts. Nous avons également déployé des trains SAFe pour synchroniser de manière efficace data warehouse, consommateurs et fournisseurs de données. Ceci permet de tirer parti du meilleur des deux mondes.
Avec cette approche nous avons donc des trains SAFe avec peu de dépendances externes, ce qui n’aurait pas été le cas d’un train SAFe dédié uniquement au développement du data warehouse.

Mais revenons à la structure organisationnelle de la tribu data warehouse et en particulier à l’axe de découpage de la tribu en Feature Teams. Nous avons en fait envisagé de nombreux scénarios pour lesquels nous avons étudié les avantages et les inconvénients dans le cadre d’un workshop impliquant une trentaine de membres de la tribu.

Deux scénarios principaux se sont dégagés :

  • Un axe de découpage par ligne métier qui avait l’avantage d’optimiser le time to market par ligne métier mais qui n’adressait pas la rationalisation du développement (un même type de données étant utilisé par plusieurs lignes métier)
  • Un axe de découpage par type de données qui avait l’avantage d’optimiser la cohérence et les coûts mais qui impliquait que le Product Owner d’une Feature Team doive prioriser pour plusieurs lignes métiers.

Nous avons finalement opté pour la deuxième solution et donc pour des Features Team par type de données.

Un train SAFe atypique

Un premier challenge a été d’identifier le périmètre du train. Nous nous sommes appuyés sur les chaînes de valeur qui correspondaient en fait relativement bien aux projets/programmes traversant le data warehouse (le concept de projet/programme existe encore pour l’instant. Il devrait -à terme- être remplacé par le concept d’Epic au sens SAFe).

Ceci nous a conduit à un périmètre centré sur le Data warehouse traversant 8 tribus et 13 équipes. Il a donc fallu convaincre les responsables des autres tribus et les différents sponsors de lancer le train. Période de plus d’un mois ou nous avons pris notre bâton de pèlerin pour « vendre » le concept du train.

Une contrainte forte était que nous avions le mandat pour réorganiser les équipes au sein de la tribu du data warehouse mais que nous ne l’avions par pour les autres tribus. De cette contrainte a émergé une différence fondamentale avec un train SAFe classique : toutes les équipes ne sont pas dédiées à 100% au train !

répartition equipe train SAFe

Ceci a bien sûr eu des conséquences sur le déroulement des PI Plannings.
En particulier pour les équipes non dédiées à 100% au train :

  • Uniquement une fraction convenue à l’avance de la vélocité de l’équipe est dédiée au train
  • Uniquement la partie de l’équipe concernée par le train participe au PI Planning (la participation du Scrum Master étant quant à elle obligatoire)

D’autre part, autant les équipes au sein du la tribu du data warehouse sont engagées sur le train de manière pérenne, autant nous envisageons que des équipes puissent être ajoutées/retirées du périmètre du train d’un PI Planning à l’autre (avec toutefois des variations faibles).

Ce setup même s’il peut apparaitre bancal de prime abord fonctionne en fait très bien !

Un deuxième challenge a été d’identifier la Product Management Team étant donné que le data warehouse lui-même n’est pas de visibilité métier direct. En l’occurrence nous avons décidé que les membres du Product Management seraient le Chief Data Officer ainsi que l’ensemble des Program Managers ou Sponsors des programmes constituant le périmètre du train.

Un train SAFe multi-régions

Un autre élément de complexité est venu du fait que le train était multi-régions (5 régions dont principalement Paris et Bangalore) et qu’il n’était bien sûr pas envisageable de faire déplacer les équipes pour le PI Planning.

Un program board physique n’était donc pas envisageable. D’autre part, aucun outil dans l’organisation ne permettait de le gérer. Après une courte étude, nous avons décidé d’utiliser l’outil iObeya. L’outil est simple et très souple d’utilisation et nous a donné entière satisfaction.

Lors du premier PI Planning, nous avons également géré les boards des équipes avec iObeya. Cela permettait certes au RTE d’avoir une visibilité multi-régions lors du PI Planning mais cela diminuait la collaboration au sein de chaque équipe. Lors des PI Plannings suivants, nous avons donc utilisé iObeya uniquement pour la gestion du Program Board et nous avons gardé un board physique par équipe.

Malgré ce PI Planning multi-régions nous sommes restés sur un agenda de deux jours avec un team breakout séparé en 3 parties. La première partie où n’intervenaient que les équipes de Paris ; une deuxième partie où n’intervenaient que les équipes de Bangalore et une troisième partie où intervenaient Paris, Bangalore et les petits contributeurs. Cette dernière partie du team breakout étant centrée sur la gestion des dépendances entre les équipes de Paris, de Bangalore et les petits contributeurs.

Conclusion

Malgré un faible budget de coaching, le train est un grand succès. L’ensemble des équipes ainsi que la PMT ont attribué un ROTI de 4,4/5 relativement à la mise en place du train.

En particulier le train permet de :

  • Partager la vision stratégique avec l’ensemble des parties prenantes,
  • Synchroniser de manière efficace le développement des applications consommatrices des données, le développement du data warehouse et le développement des applications fournissant les données,
  • Planifier à moyen terme et donner de la visibilité.

Le RTE est désormais totalement autonome et l’amélioration continue est en place.

Stéphane Déprès

 

Comments are closed.