L’Agile à grande échelle [Benchmark TNP 2017]

L’objectif du benchmark est d’aider les DSI à obtenir une meilleure perspective de leur positionnement compétitif  sur la maturité la performance Agile de leur organisation. En conséquence, l’anayse vise à apporter des réponses au top management sur les questions suivantes : Quel est mon degré de maturité par rapport aux autres DSI ? Comment améliorer la maitriser des coûts de mes projets Agile ? Quels leviers en termes d’outils, d’organisation et de pratiques pour optimiser la performance de mes projets ?

Panel étudié et principales tendances

L’étude réalisée s’appuie sur 15 projets Agile menés par 4 grandes entreprises, issues des secteurs de l’assurance, de la gestion d’actif,du transport ou du commerce international. En cumulé, les chiffres de l’étude s’appuient sur plus de 200 sprints.

Le coefficient d’« environnement du développement » permet de mesurer la part consacrée aux développement par rapport à celle de toutes les autres activités du cycle de conception (conception générale, spécifications, intégration et tests,…). Avec un coefficient moyen deux fois inférieur à celui du cycle en V, les projets du panel étudié placent le développement au cœur de leur activité.

1-ceof

De plus en plus projets sensibles (50%) et cœur métier (86%) sont menés en Agile. Ces indicateurs montrent une progression du niveau de confiance de maitrise de la méthode par les DSI. En gérant des projets de plus en plus sensibles, une part non négligeable de ceux-ci est menée par des équipes dépassant les 20 ETP (29%). Le recours à des équipes de taille importante n’est pas recommandé en Agile, la taille étant un facteur de risque et ralentit le rythme de production. Pour continuer sa mise à l’échelle Agile et gérer des projets de taille importante, il est préconisé de mettre en place une organisation en « feature team » de taille limitée à 12 ETP.

2-ronds

Une première tentative d’intégration de progiciels en Agile a été lancé par la DSI la plus mature du panel. Les retours d’expérience de TNP ont montré que la mise en place de l’Agile est plus simple dans un contexte de développements spécifiques. Ceci a été confirmé par les DSI consultées, qui souhaitent avoir suffisamment de maturité pour généraliser cette méthode aux projets d’intégration de progiciels. D’après nos observations, les freins principaux du déploiement de l’Agile aux projet d’intégration de progiciel demeurent les problématiques contractuelles avec l’éditeur ainsi que les contraintes techniques intrinsèques du progiciel, qui peuvent être mal adaptées à l‘Agile. Pour les DSI qui souhaite augmenter leur maturité, il est préconisé d’adapter la méthodologie en tenant compte des contraintes de l’intégration progiciel, à définir avec l’éditeur avant le projet et mener une première expérimentation.3-ronds

 

Analyse de la performance budgétaire
Le point fort de la méthode Agile est sa capacité d’arbitrage des User Story. Les projets qui arbitrent le moins, connaissent les dérives budgétaire les plus importantes. Ces projets répliquent les modes de fonctionnement du Cycle en V où les imprévus se traduisent par des dérives budgétaires. La médiane des arbitrage est à 8%. Par conséquent, la méthode n’induit pas forcément des renoncements importants : les renoncements sont des renoncements tactiques mais pas stratégiques : ils permettent d’absorber les imprévus en limitant les dérives budgétaires. TNP recommande de suivre le taux de renoncement dans le cadre des indicateurs de la performance des projets Agile, ceci afin d’éviter qu’un projet masque son inefficience par un taux de renoncement trop élevé. Il est à noter qu’un modèle de contractualisation par Sprint facilite l’arbitrage des User Story tout en restant dans un cadre forfaitaire. Un modèle de contractualisation par un forfait global n’est pas adapté à un projet Agile.

4-us-arbitr

Leviers de performance des projets Agile

La régression fonctionnelle est un problème récurent auquel sont confrontés les projets Agile. Pour s’en prémunir, il est nécessaire de tester, à chaque sprint, une partie importante de l’application. Cette approche est difficilement applicable lorsque les tests sont réalisés de manière manuelle. Le fait d’automatiser les tests, tout au long du projet (et pas à la fin), permet de garantir la qualité et la performance du projet. L’automatisation des tests requiert deux points principaux : un choix d’outil de test conforme au contexte technologique de l’entreprise ainsi qu’une revue des processus projets de la DSI pour y introduire l’activité de production des cas de tests automatisés.

5-nb-anos

Localisation de l’équipe et outils collaboratifs

Pour les projets Agile, il est généralement recommandé que l’équipe soit co-localisée (PO, SM et Dév.) et que des outils collaboratifs (ex. Wiki, Lync…) soient mis en place. Ceci afin de simplifier la collaboration, qui est un des piliers de l’Agile. Dans notre panel, la majorité des projets respecte ces recommandations. Dans les situations pour lesquelles la co-localisation est impossible à mettre en place (ex. projets internationaux, contraintes de locaux…), il est impératif que le Scrum Master et les développeurs soient sur le même site, que certains rituels de l’Agile soient réalisés en présentiel avec l’ensemble de l’équipe : ces rituels sont les rétrospectives (permettant d’identifier les douleurs et les actions d’amélioration) et les réunions de début et de fin de Sprint (une demie journée en cumulé pour ces deux rituels), et qu’au moins un outil collaboratif soit mis en place.

6-loc

Expérience des équipes

Au lancement d’un projet Agile, une hypothèse de « vélocité théorique » est généralement prise pour estimer la fin du projet. Cependant, la vélocité réelle de l’équipe s’avère généralement plus faible que la « vélocité théorique ». Notre étude montre que l’intervention d’un Scrum Master expérimenté au sein du projet permet de limiter cet écart. Il est à noter qu’un écart de vélocité induit soit un écart budgétaire (à périmètre fonctionnel constant) ou un taux d’arbitrage fonctionnel élevé (à budget constant). Un écart de vélocité est plus impactant à mesure que la taille du projet est importante. Par conséquent, pour mieux gérer les risques, il est impératif de faire accompagner les projets de taille importante par des Scrum Master expérimentés.

7-xp-scrum

Auteur: Guillaume VIARD

Partager cet article :