Durant une de mes premières missions Lean dans une société de service, le responsable des équipes techniques avait eu cette formule provocante : « chez nous, on fait du SCRUM en V ». Derrière ce paradoxe (SCRUM et les méthodes agiles se positionnent en opposition à la méthode de Cycle en V) se cache une réelle difficulté. Comment introduire de l’agilité dans un écosystème qui a été construit selon des préceptes plus traditionnels ?

Dans cet article, j’aimerais pointer les obstacles structurels qui rendent impossible la mise en œuvre des principes de lean et de l’agile et proposer des pistes pour les dépasser.

SCRUM en V, ou que faire quand on est trop gros pour l’agilité

Des contraintes incompatibles avec l’agile

Les principes lean et agile semblent devoir rester inaccessibles à certains domaines d’activité. C’est le cas, par exemple, pour la maintenance des applications « legacy » au sein des DSI. Ces outils sont critiques pour l’entreprise (ex : outils cœur de métier) mais, nés il y a plusieurs décennies, ils n’ont cessé d’évoluer jusqu’à atteindre un niveau de complexité tel que parler d’« agilité » prête à sourire. Il est en effet impossible pour les entités qui entretiennent ces mastodontes – et qui doivent veiller à les adapter sans cesse aux nouvelles règles et réglementations – de livrer une évolution toutes les 3 semaines.

Obstacle à l’agile

Les contraintes inhérentes à ces systèmes expliquent bien cette incapacité :

• Par choix initial ou par transformation successives, le système est souvent cimenté en un seul bloc. Tout dépend de tout et chaque changement menace de déstabiliser le reste du système. Les durées de tests de non régression se comptent typiquement en mois, ce qui pousse à la mutualisation en constituant des lots d’évolutions plus importants.
• De par leur longue histoire, il n’est pas rare que ces systèmes couvrent un vaste champ de fonctionnalités. Le moindre arbitrage nécessite la consultation d’experts fonctionnels spécialisés et même eux ne parviennent pas toujours à appréhender complètement le fonctionnement du système et à décrire finement l’attendu après évolution.
• À prendre en compte également, le fait que la connaissance du fonctionnement de systèmes très riches est très longue à acquérir. Les ressources techniques sont également plus rares sur le marché et il est plus long d’adapter la taille des équipes pour encaisser une hausse de charge (et en réduire la taille signifie la perte de ressources clefs).
• En outre, la criticité de l’application, le manque de modularité et la perte de maitrise augmentent le niveau de risques associé à chaque évolution de l’outil. Les décisions doivent donc être prises à un niveau hiérarchique plus élevé. Ceci induit une charge non négligeable de gouvernance et une augmentation des délais d’arbitrage.

Comment contourner ces contraintes pour se perfectionner

Que faire, alors, dans des contextes contraints où les méthodes agiles ne sont pas applicables en l’état ? Une approche consiste à diviser l’activité pour créer des sous-domaines autonomes et pour y réintroduire les principes qui font le succès du Lean et de l’Agilité : l’orientation client, la proximité et la subsidiarité. Évidemment, il devient nécessaire d’ajouter un dispositif transverse de suivi des sujets qui ne rentrent pas naturellement dans ce découpage. Il est important d’apprécier néanmoins les avantages de ce procédé.

Les fondamentaux du lean et de l’agile

Les principes qui suivent sont issus des expériences du cabinet.

• 1^ère principe : Découper la production en lots de tailles plus petites pour réduire l’enjeu
  • Travailler sur de plus petits lots permet de rendre appréhendable la complexité du système. Cela facilite l’évaluation du risque et permet d’ajuster les mesures de sécurisation au cas par cas. De fait, cela permet de réduire les délais et d’améliorer la qualité générale de la production.
  • Ce nouveau découpage fixe également un cadre d’apprentissage utile aux équipes projet. Elles sont amenées se confronter à plusieurs lots. C’est l’occasion pour elles de mieux saisir les aléas qui sont intrinsèques au système. On peut alors structurer cette amélioration continue en instaurant des rétrospective à la fin de chaque lot pour démultiplier l’amélioration de la qualité.
  • La diminution de la taille des lots permet également de réduire le niveau d’enjeux. Les équipes s’autorisent à expérimenter davantage ce qui rend l’organisation plus agile.
• 2^ème principe : Découper le domaine applicatif en sous-domaines clairs (tout en prenant garde à bien documenter les interfaces) permet de renforcer l’autonomie de chaque domaine :
  • Constituer des équipes autonomes et resserrées autour d’un objectif (plutôt qu’une longue chaine d’interlocuteurs) permet de limiter l’effet « téléphone arabe ». La mise en place de management visuel est alors possible pour fluidifier encore la communication.
  • Le découpage d’un périmètre en plusieurs domaines relativement autonomes permet aussi de déléguer la plupart des prises de décision à un échelon inférieur. Le responsable du sous-domaine n’a plus besoin de l’aval de son N+2 et les arbitrages se font plus rapidement.
  • On peut même aller plus loin : s’il est possible de rendre un sous-domaine complètement indépendant du reste de l’application, on peut alors déployer localement un processus agile complet tout en continuant à gérer les autres domaines de façon plus traditionnelle.
• 3^ème principe : Organiser la production en logique flux là où c’est possible. Pour les raisons développées précédemment, de nombreuses contraintes empêchent de livrer les développements au fil de l’eau. Cependant, d’autres processus amont peuvent être transformés (c’est par exemple souvent le cas de l’instruction des évolutions à inclure dans un lot).
  • N’embarquer dans un lot que les besoin mûrs et suffisamment bien décrits permet d’améliorer la qualité en aval
  • Alimenter un lot au fil de l’eau permet également de lisser la charge des équipes d’instruction.
  • Couplé à un découpage efficace en sous-domaines, une instruction au fil de l’eau créé de l’agilité au sein d’un lot : un pic ponctuel d’évolutions venant d’un sous-domaine A peut être absorbé en s’appuyant sur les moindres besoins du domaine B.
  • NB : ce procédé n’est acceptable par le prescripteur métier que lorsque les lots sont peu espacés dans le temps (c-à-d. de petite taille) de sorte qu’il ne perd pas grand-chose en prenant le train d’évolutions suivant.

Ces pistes sont présentées dans le contexte d’une DSI mais elles sont déclinables dans tous les processus projet industriels pour augmenter à la fois la réactivité, la qualité et réduire les coûts.