Il existe de nos jours de nombreux framework Agile@scale disponibles sur le marché : SAFe, LeSS, DaD, Nexus pour ne citer que ceux-ci.

Plutôt que les mettre en opposition, je considère que chacun d’entre eux est le fruit d’une capitalisation d’expérience, a été éprouvé sur le terrain et apporte de la valeur. J’ai d’ailleurs signé depuis longtemps la charte Agnostic Agile

Certains frameworks sont sans doute plus adaptés que d’autre à certains contextes mais l’on peut également considérer qu’ils sont de formidables boites à outils dans lesquelles on peut venir puiser afin de proposer une solution optimisée pour un contexte donné.

Ce qui est important à mes yeux est de ne pas suivre aveuglement un framework mais que les équipes comprennent pourquoi l’on fait les choses. Comprendre quels sont les bénéfices et les inconvénients de tel ou tel mécanisme afin de sélectionner ceux qui sont le plus adaptés, voire d’adapter ces mécanismes pour en tirer le maximum de valeur.

Concernant l’adaptation des mécanismes, garder bien sûr en tête les principes Lean et Agile mais n’ayez pas peur d’être créatif pour répondre au contexte. Expérimentez et prenez en compte le retour d’expérience.

 

 

A propos de la portée temporelle de la planification

Dans cet article, je vais prendre pour exemple les mécanismes de planification cross-équipes qui sont assez différents d’un framework à l’autre, en particulier en ce qui concerne la portée temporelle de la planification. Par exemple, pour LeSS, la portée temporelle de la planification est d’un sprint alors que dans SAFe un Program Increment (PI) adresse en général 4 sprints.

Quelle approche embrasser ? L’argumentaire suivant ne se veut en aucun cas exhaustif mais donne un exemple de réflexion pour choisir la solution la plus adaptée au contexte.

S’il existe des contraintes métier de délai fortes et justifiées (dates réglementaires par exemple), alors une planification plus long terme sur un PI peut être intéressante car elle permet d’avoir de la visibilité et une stratégie sur le moyen terme.

Dans des cas de système complexe avec des dépendances fortes entre équipes, une planification sur un PI peut également être intéressante car elle permet de gérer les dépendances de manière proactive plutôt que de les subir sprint par sprint.

Dans les autres cas de figure et en particulier pour de la maintenance évolutive, une planification cross équipes avec une portée temporelle d’un sprint comme le prône LeSS est sans doute suffisante, plus flexible, plus simple, et permet au passage de réduire le WIP.

 

A propos des participants de la planification cross-équipes 

Autre axe de choix et d’adaptation : une participation de l’ensemble des membres de l’équipe à la planification cross équipes est-elle requise ? Pour SAFe, l’ensemble des membres des équipes participent au PI Planning. Pour LeSS, la participation de l’ensemble des membres des équipes au Sprint Planning One n’est pas imposée. Il est même recommandé de n’avoir que des représentants afin de faire en sorte que le Sprint Planning One soit le plus léger possible. Quant au Sprint Planning Two de LeSS, il englobe tous les membres d’une équipe mais est réalisé équipe par équipe sauf exception.

Là encore les approches LeSS et SAFe sont différentes. SAFe considère qu’avoir l’ensemble des équipes présentes, PO, PMT, architecte et Business Owner inclus est plus efficace car les délais de communication et de prises de décision sont optimisés. C’est effectivement ce que j’ai constaté sur tous les trains que j’ai accompagnés. Mais cette efficacité vaut elle le temps passé et la complexité de mise en œuvre ? LeSS au contraire joue la simplicité et considère une participation à priori nécessaire et suffisante. Mais est-ce vraiment suffisant pour adresser une solution complexe ?

Je ne rentrerai pas dans ce débat. Mais je rajouterai que d’autres variantes sont possibles. J’ai par exemple récemment accompagné une planification multi-équipes et multi-sprints dans un contexte de faible degré de dépendance entre équipes. Mettre en place un vrai PI Planning me paraissait donc surdimensionné et j’ai proposé l’approche suivante qui a été acceptée :

  • Présentation de la vision métier à l’ensemble des équipes
  • Présentation de la vision architecturale à l’ensemble des équipes
  • Planification (team breakout) : chaque équipe planifiant séparément avec l’agenda souhaité. Seules contraintes : un délai max d’une semaine et un Scrum of Scrum journalier pendant cette période
  • Une revue du plan et un arbitrage pour aligner la roadmap souhaitée avec la vélocité des équipes et les contraintes

 

A propos du découplage de la structure organisationnelle avec les mécanismes de synchronisation Agile

Les framework considèrent en général que si des besoins de synchronisation entre équipes existent, ils doivent forcément impliquer chaque équipe dans son entier. Vous allez bien sûr me dire que si ce n’est pas le cas, la structure organisationnelle est incorrecte. Mais il existe des cas de figure où cela n’est pas si simple :

Avant d’aller plus loin, analysons les différents types d’équipes. Les équipes projet sont structurées autour d’un projet ou d’un programme mais elles souffrent d’inconvénients majeurs : en particulier une perte de la connaissance dès le démontage d’une équipe ainsi que la constitution de silos projet / maintenance.

Des équipes par application suppriment ces inconvénients mais le time-to-market n’est pas optimal. En effet, pour un changement impactant l’ensemble de la chaine de valeur métier, toutes les équipes applicatives doivent se coordonner pour délivrer la solution.

Les équipes de type Feature Team alignées sur les chaines de valeur permettent d’éliminer cet inconvénient. Des mécanismes de synchronisation Agile sont alors déployés entre les Feature Teams ayant des dépendances structurelles.

Mais il arrive parfois qu’une initiative éminemment transverse (par exemple réglementaire) induise des besoins de synchronisation temporaire entre des sous-ensembles d’équipe. Il n’est d’ailleurs pas toujours souhaitable de construire des équipes dédiées (grand nombre d’applications impactées et augmentation des dépendances).

Parfois, il s’agit également d’une stratégie pour gérer les backbones transverses comme les data warehouse 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 ;
  • 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.

Pour plus de détail sur le sujet, je vous invite à consulter l’article « REX d’un lancement de train SAFe atypique » http://www.inspearit.fr/2018/11/19/rex-safe/

Dans ce contexte, j’ai été amené à lancer un train pour lequel les équipes n’étaient pas dédiés à 100%. Le PI Planning a été adapté comme suit :

– Ne viennent au PI Planning que l’Agile Master et les personnes impliquées
– Un % prédéfini de la vélocité de chaque équipe dans ce contexte est dédié au train

 

Ainsi, ce qui compte avant tout est de mettre en place des solutions qui conviennent au contexte. Les frameworks Agile@scale peuvent être utilisés tels que ou comme une boite à outil dans laquelle on vient puiser pour construire la solution.

 

Comments are closed.