Entre approche traditionnelle et agile, il faut choisir !
Vous connaissez l’histoire. Certaines entreprises, lassées de voir leurs forts Boyard devenir des prisons, ont décidé de passer à l’agilité. Et pour certaines, le résultat s’est révélé spectaculaire. Mike Cohn raconte ainsi, dans son ouvrage Succeeding with Agile : « Pendant la première année de transition, Salesforce.com a délivré 94% de fonctionnalités supplémentaires, 38% de fonctionnalités de plus par développeur, et 500% de valeur en plus à ses clients par rapport à l’année précédente… Après quinze mois d’adoption de Scrum, Salesforce a interrogé ses collaborateurs et a trouvé que 86% passaient du bon temps, voire le meilleur temps de travail jamais vécu dans l’entreprise. Avant d’adopter Scrum, ils étaient seulement 40% à dire la même chose. De plus, 92% des collaborateurs ont déclaré qu’ils recommanderaient une approche agile aux autres. »
L’agilité… Il y a une promesse d’eldorado dans ce mot, un sésame vers la feelgood company, des projets livrés dans les délais, car contraints par les délais… Les projets de développement applicatifs ont été pionniers en la matière, et on voit aujourd’hui des projets non-IT désireux d’abandonner des pratiques jugées ringardes pour goûter aux charmes de cette danseuse.
Se pose alors la douloureuse question de la cohabitation des approches traditionnelles et agiles au sein de l’entreprise. Faut-il favoriser…
- L’une ou l’autre ?
- L’une à côté de l’autre ?
- L’une dans l’autre ?
- L’une avant l’autre ?
L’une ou l’autre
Premier cas de figure : certaines entreprises décident de passer du tout traditionnel au tout agile (l’inverse est moins répandu, mais peut aussi se produire).
Ce choix peut se révéler judicieux dans le cas où le portefeuille de projets s’y prête (par exemple, si nous ne faisons que du développement applicatif, sans contrainte d’interactions lourdes avec d’autres applications).
Mais le problème, c’est qu’on n’a pas encore réussi à fabriquer un avion de ligne avec une approche agile. Certains développements supposent en effet de disposer d’une vision d’ensemble et systémique de la solution, ou de la manière dont cette dernière va être intégrée dans un ensemble plus vaste et contraint (si je fabrique une maison, il peut s’avérer difficile de construire la cuisine, puis la chambre, sans avoir un plan d’ensemble de l’édifice).
L’une à côté de l’autre : la bi ou la tri-modalité
Deuxième cas de figure : faire cohabiter les 2 approches en fonction des profils de projets.
Selon Michael Smith, le vice-président de Gartner Research : « Nos études révèlent que les DSI doivent adopter une approche bimodale pour soutenir la transformation de l’entreprise vers l’économie numérique : un mode cherche à développer une capacité, une culture et une approche plus agiles et innovantes. Le second mode met l’accent sur une plus grande industrialisation de l’informatique ».
L’approche est séduisante, mais comme souvent, le diable est dans les interfaces, quand il s’agit d’intégrer une solution développée en agile dans un environnement plus processé et urbanisé. C’est la raison pour laquelle certains, comme Dion Hinchcliffe, préconisent une approche tri-modale, en divisant les équipes projets en trois groupes :
- Les « pionniers » (pioneers) sont des adeptes de l’agilité : ils repoussent les frontières, explorent de nouveaux horizons, développent des solutions jusqu’alors inconnues.
- Les « colons » (settlers) sont des pragmatiques. Ils exploitent au quotidien les solutions développées par les pionniers et les urbanistes, et entretiennent de bonnes relations avec les deux populations.
- Les « urbanistes » (town planners) sont chargés d’apporter l’efficacité, la fiabilité, l’évolutivité et les économies d’échelle dans une transformation industrielle et planifiée de manière centralisée. Ils remettent donc en cohérence les innovations des pionniers dans un système plus large.
Il conviendra de se concentrer sur l’une ou l’autre des populations en fonction des projets et des objectifs de l’entreprise, tout en favorisant au maximum le décloisonnement des acteurs.
L’une dans l’autre : la Wagilité
L’expression peut faire sourire, mais si ça se trouve, vous êtes vous-même Wagile sans le savoir !
La wagilité consiste à intégrer certaines pratiques agiles dans un modèle en cascade, sans altérer de façon significative ce dernier. Imaginez par exemple que votre projet intègre :
- Des itérations courtes,
- Un stand-up quotidien permettant aux équipiers de faire le point sur leur avancement,
- Un processus d’intégration continue de la solution, depuis un « Minimum Viable Product » jusqu’à la complétion du périmètre attendu.
… sans forcément qu’il y ait d’équipe dédiée à 100% au projet, d’intégration du product owner ou de Scrummaster.
Cette approche est également appelée « Waterfall-Agile » et même « Wet Agile » (agile mouillé… et je vous conseille d’éviter de googliser cette expression !). Autant vous le dire tout de suite, le « Wagile » est fortement décrié par certains orthodoxes de l’agilité, qui y voient la solution idéale pour garantir un échec beaucoup plus rapide que si vous étiez restés en simple waterfall.
Mais on peut aussi considérer Wagile comme une première étape dans le déploiement Agile au sein d’une organisation, et un levier puissant d’adoption de la démarche. En fait, la principale différence entre le «bon Wagile» et «mauvais Wagile» tient à la capacité à tirer des enseignements de ses projets, et à mettre en œuvre un processus d’amélioration continue.
Une première expérimentation sur un projet peut donner envie d’introduire un nouveau concept agile : intégration continue, user storys, poker planning, équipe dédiée avec responsabilité partagée, invitation du product owner dans le cadre de la planification et de la revue de sprint…
L’agilité pourrait donc se déployer… de manière itérative et incrémentale !
L’une avant l’autre : WaterScrumFall ou ScrumWaterfall
Et si, au sein d’un même projet, certains lots étaient gérés avec l’orthodoxie de l’approche agile, et d’autres avec l’orthodoxie d’une approche traditionnelle ?
Certaines phases du projet peuvent supposer un processus très itératif, et il ne s’agit pas seulement des phases de développement de la solution. Dans les phases d’émergence du projet par exemple, pour cheminer vers une première maquette, un Proof Of Concept, ou un prototype opérationnel, il peut être intéressant d’adopter un processus qui va mettre le client/l’utilisateur au cœur de la machine, avec des validations régulières, des changements au fur et à mesure que les sprints s’enchainent… jusqu’à la stabilisation de la solution qui délivre le maximum de valeur.
C’est d’ailleurs un des principes fondateurs du Design Thinking, qui recommande d’itérer pour cheminer progressivement vers la solution correspondant le mieux aux besoins des utilisateurs (avant de la développer de façon industrielle).
Et si… vous choisissiez ?
La palette s’est élargie. Plus que jamais, l’équipe projet doit faire preuve de pragmatisme et d’ingéniosité pour choisir l’approche la mieux adaptée. En somme, faire preuve d’agilité de pensée pour adopter le bon degré d’agilité dans ses projets.
Je tiens à remercier Emmanuel Chenevier, Thierry Defendi, Jean-Louis Foucard et Frédéric Jeannin pour nos échanges passionnants sur le sujet de la cohabitation des approches traditionnelles et agiles.