Abonnez-vous au blog

Afin de vous abonner et pour des raisons de sécurité, votre navigateur doit accepter les cookies et le JavaScript.

Approche traditionnelle ou agilité : sommes-nous condamnés à choisir ?

Par le 27 juin 2016

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

ou

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.

Et

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 !

dans

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 ?

avant après

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.

Autre dossier sur le même thème

Laisser un commentaire

Avatar

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Avatar

Adil Mostakim Il y a 3 années

Bonjour M. Debois,
Votre article est fort intéressant. Les 4 approches expliquent clairement les différents modèles existants sur le marché. Bien plus, elles permettent aux entreprises de se mesurer en matière de maturité quant à l’application de l’agilité.
Passer complétement à l’agilité peut être des fois très difficile à relever comme défi, d’où l’intérêt d’avoir d’autres alternatives adaptées au contexte et aux besoins de chaque entreprise.
Adil Mostakim
Conférencier, formateur et consultant en gestion de projet

Répondre
    François Debois

    François Debois Il y a 3 années

    Bonjour Adil,
    Merci pour votre retour. Je suis complètement en phase avec la mesure de maturité de l’entreprise vs l’adoption de l’agilité. Car effectivement, certaines entreprises ont voulu franchir une marche bien trop haute pour se lancer dans l’agilité, et leurs échecs abîment la confiance qu’elles peuvent avoir vis-à-vis des méthodes agiles au sens large.

Avatar

Dirk Doppelfeld Il y a 3 années

Bonjour Monsieur Debois,
Merci beaucoup pour votre article fort intéressant.

Aujourd’hui je pense de plus en plus que l’Agile n’est pas seulement une méthode de management de projet. Elle va au-délà et devrait atteindre tous les niveaux de management d’une entreprise.
Je vous propose de lire l’article « embrace agile » dans la Harvard Business Review, may 2016. J’ai l’impression que nous sommes au début d’un mouvement qui pourrait pourrait presque révolutionner notre façon de manager une entreprise et non pas seulement des projets.

Bonne lecture,
Dirk

Répondre
    François Debois

    François Debois Il y a 3 années

    @Dirk : Oui, je suis entièrement d’accord. En fait, l’agilité se décline en méthodes de management de projet, et également en pratiques managériales qui « déverticalisent » l’entreprise. Mes collègues du blog du management s’intéresse d’ailleurs de très près à l’agilité : http://www.blog-management.fr/2016/06/20/autodiagnostic-equipe-agile/
    Et merci pour la proposition d’article d’HBR, qui est brillant (disponible ici pour nos lecteurs assidus : https://hbr.org/2016/05/embracing-agile )
    A bientôt,
    François

Avatar

Fabien RAYNAUD Il y a 3 années

Je partage tout à fait l’approche « Wagilité » : on garde l’approche Waterfall pour la structuration mais on met de l’agilité à tous les niveaux pour être réactif par rapport aux changements intervenant en « input », et être réactif aux retours faits par rapport aux délivrables produits à chaque étape.

Cordialement,
Fabien RAYNAUD
http://www.FabienRaynaud.com

Répondre

Abonnez-vous au blog

Afin de vous abonner et pour des raisons de sécurité, votre navigateur doit accepter les cookies et le JavaScript.