Dans un monde de changement permanent, les méthodes traditionnelles de Project Management sont de plus en plus diagnostiquées comme obsolètes et, au sein même d’entreprises où elles sont appliquées dans un cadre méthodologique défini et mature, on constate la poussée de tendances à rapprocher du concept d’agilité. Cette agilité, intervenant à la croisée des nouvelles tendances susmentionnées, s’est imposée de fait comme un thème récurrent de la littérature de recherche et de la transformation des entreprises.

L’entité dans laquelle cette étude a été réalisée utilise un cadre méthodologique traditionnel, dit « en V », descendant des méthodologies « waterfall » et est sujette à des pratiques agiles temporaires, poussées par un contexte de plus en plus incitatif au changement. Elle possède néanmoins un contexte particulier qui pose la question de sa compatibilité structurelle, culturelle et stratégique avec les Méthodes Agiles. 

Depuis la publication du Manifeste Agile (Beedle, et al., 2001), les experts de la gestion de projet et du développement de software ont porté une attention particulière aux Méthodes Agiles de Project Management. En effet, l’impact de la méthodologie suivie sur les éléments de coût, de qualité ou de planning, les trois piliers du Project Management, est considérable et décisif dans le succès d’un projet (Atkinson, 1999). En outre, la bonne gestion de ces facteurs tout au long du cycle de vie du projet peut être influencée par les facteurs de succès dont la méthodologie représente une partie intégrante (Müller & Turner, 2007).

On oppose usuellement les méthodes traditionnelles, auxquelles on assimile la méthodologie « waterfall » (ou cycle en « V »), et les Méthodes Agiles. Ces dernières ont été largement reconnues comme plus efficaces ces dernières années. À titre d’exemple, le ratio de succès passe de 11% à 39% de traditionnel à agile et, dans les projets larges et complexes, le ratio de succès d’agile est six fois supérieur à celui des méthodes traditionnelles (Chaos Report 2015, 2015).

Les Méthodes Agiles se définissent en réaction aux méthodes traditionnelles (Boehm, 2002) et développent de nouvelles valeurs qui ne sont pas prises en compte par ces dernières. Elles se concentrent notamment sur l’individu, l’interaction, l’implication du client et sont synonymes de bouleversements du paradigme des méthodes traditionnelles (Beedle, et al., 2001). Elles visent aussi à fournir rapidement une solution utilisable, plus qualitative (Huo, Verner, Zhu, & Babar, 2004) et apte à maximiser la satisfaction du client. Un simple regard porté à ces bénéfices motive les managers du monde entier à adopter les Méthodes Agiles. De nombreuses firmes et organisations parmi les plus modernes en termes de management les utilisent, si ce n’est globalement, au moins ponctuellement sur leurs projets. On peut par exemple citer Microsoft, Google, IBM ou Nokia (Cohan & Glazer, 2009). Pourtant, de très nombreuses firmes continuent à utiliser les méthodes traditionnelles de Project Management. Certaines d’entre elles ont une bonne expérience en termes de méthodes traditionnelles (synonyme de barrière à la sortie) quand d’autres craignent tout simplement de franchir le pas (Gandomani, Zulzalil, Ghani, & Sultan, 2013).

La méthode traditionnelle « Waterfall Model » (Royce, 1970) ou mode de développement linéaire et séquentiel, se base sur un principe simple : chaque phase du processus ne peut commencer qu’une fois la phase précédente totalement terminée. À chaque étape, le projet est revu et une documentation créée pour s’assurer de la conformité du travail développé avec les demandes initiales du client (chez les professionnels, en français, la formule « expression des besoins » est largement répandue pour décrire ceux-ci, en anglais, on retiendra « business requirements », l’environnement « business » étant l’environnement client).

A ses origines théorisée en huit phases, la méthodologie « waterfall » est aujourd’hui usuellement simplifiée en cinq (Sasankar & Chavan, 2011).

Besoins du business : Il s’agit de la phase de collecte des besoins du client. On va ici prendre en considération tous les aspects du business dans le but de déterminer les aspects pouvant être incorporés dans la solution (Sasankar & Chavan, 2011). Lors de cette phase, la communication entre le client (business) et l’équipe d’analyse ou de développement est essentielle.

Design de la solution : Il s’agit de transformer les besoins du business identifiés en une intégration réelle à travers une solution. Lors de cette phase, il est important de comprendre comment le système va être construit et à partir de quelles données il va être susceptible de fonctionner (design d’un processus pour ceci). À la fin de cette phase, une vision du produit fini doit être fournie.

Construction : Synonyme de programmation ou code pour ce qui est du domaine de l’IT, cette étape inclut la construction du produit choisi. Les éléments identifiés dans les phases précédentes doivent être retranscrits dans un langage compréhensible par un système.

Tests : Il s’agit tout d’abord de tester la solution dans les environnements dans lesquels elle a été construite. L’équipe de programmation testera dans son environnement, l’équipe d’analyse dans le sien pour ensuite aller gérer les tests effectués dans l’environnement final du client. Sont ici testées toutes les fonctionnalités et spécifications de chacune des parties ainsi que les exigences diverses qui ont pu être soulevées au cours du processus.

Déploiement : Il s’agit d’aller implanter la version finale de la solution chez le client. Cette phase comprend non seulement une date de lancement officielle, mais aussi toutes les exigences qui ont pu être émises auparavant en termes de formation, documentation du processus ou de gestion du changement par exemple.

Les méthodologies traditionnelles ont longtemps eu la faveur des managers pour leur facilité d’usage, de coordination, leur traçabilité (grâce au rôle de la documentation) et plus généralement pour la visibilité qu’elles permettent. On peut alors se poser la question de la raison d’une relative décroissance de l’usage d’une telle méthodologie alors même qu’elle s’était imposée comme une « one best way » en particulier dans le secteur du développement software. Dans un environnement de plus en plus changeant, les inconvénients intrinsèques à ces méthodologies tendent à prendre le pas sur leurs avantages.

Tout d’abord, ces méthodologies supportent mal l’incertitude. Dans un secteur complexe, aux besoins volatiles, l’inertie engendrée par un fonctionnement par phases cloisonnées est synonyme d’inefficacité (Chavhan, 2015). On comprend dès lors que dans un monde structurellement de plus en plus complexe, des méthodes plus agiles leur soient préférées. De même, les phases de test et de déploiement sont perçues comme trop tardives et liées à des périodes d’activité intenses et critiques pour les équipes. L’un des inconvénient d’un fonctionnement par phases aux validations planifiées est une nécessaire croissance de l’activité, de l’aspect critique et du stress en fin de chaque phase. Celui-ci est à mettre en relation avec un relâchement des équipes en début de phase. Dans une perspective de personnalisation de la solution à l’activité du client, le sortir du projet après la phase d’expression des besoins jusqu’à la phase de test client ne parait pas adapté et peut être potentiellement associé à une fausse impression de progrès (Sasankar & Chavan, 2011). La faible flexibilité entre les phases du projet induit enfin un risque non négligeable d’explosion du coût et des délais en cas d’inadéquation entre le produit et les besoins du client ou simplement en cas d’erreur (Stoica, Mircea, & Ghilic-Micu, 2013). 

Le cœur des méthodes Agile a été développé par 17 personnes en 2001 sous forme écrite (Beedle, et al., 2001). Leur Manifeste Agile de développement de logiciels développe une mentalité révolutionnaire se voulant plus « humaine », basée sur la valorisation des individus et la collaboration avec le client. Les quatre valeurs cardinales d'Agile sont exprimées comme suit :

• Les individus et leurs interactions plus que les processus et les outils.
• Un logiciel qui fonctionne plus qu’une documentation exhaustive.
• La collaboration avec les clients plus que la négociation contractuelle.
• L’adaptation au changement plus que le suivi d’un plan.

Les fondements d'Agile sont simples. Pour entamer un projet, l'organisation forme et habilite une équipe réduite, pleinement dédiée à la tâche, interfonctionnelle et autonome. Le « Product owner » de l'équipe, qui provient généralement d'une fonction business et divise son temps entre l'équipe Agile et les principaux intervenants, utilise des techniques telles que le design thinking, la création d'un catalogue d'idées ou de fonctionnalités potentielles prometteuses (product backlog). Il classe cette liste (de manière continue) en fonction des dernières estimations de valeur apportée au client, des résultats financiers et d'autres initiatives d'innovation. Un facilitateur protège l'équipe des distractions et met son intelligence collective au travail (scrum master dans le cas de la méthodologie Scrum).

L'équipe divise ensuite les tâches prioritaires en petits modules, décide du travail à accomplir et de la façon de le mener et commence à créer des versions fonctionnelles à travers des cycles courts (itérations) appelés sprints. Le processus est transparent pour tous. Les membres de l'équipe tiennent de courtes réunions quotidiennes pour examiner les progrès et identifier les obstacles. Ils résolvent les désaccords avec des boucles de rétroaction expérimentales plutôt que par des débats sans fin ou des appels à l'autorité. Ils testent les modules avec le client de manière incrémentale. Si les clients sont satisfaits, le module peut être déployé immédiatement. L'équipe doit ensuite réfléchir aux façons d'améliorer les cycles futurs et se prépare à entamer le nouveau module (en fonction de la priorisation du « product backlog » par le « product owner » vue plus haut).

En somme, une méthode Agile de Project Management se base sur un processus itératif adaptable aux variations potentielles des besoins du client. La circulation de l’information se fait davantage du bas vers le haut que dans l’approche « top-down » traditionnelle et l’on retrouve un rapport à la planification davantage mu par le court terme. La distinction séquentielle entre planification et action est renvoyée à la dimension « mythique » que lui accordait Mintzberg (Mintzberg, 1997). On passe à un processus dans lequel la frontière est trouble entre planification et action et dans laquelle intuition et interaction ont une place prépondérante (interpénétration de ces valeurs étant caractéristiques du manager selon le même Mintzberg) davantage qu’une planification de long terme pourtant au cœur du rôle du manager selon les premiers penseurs classiques des théories de l’organisation, d’après Henri Fayol notamment (Fayol, 1917).

Ces méthodologies sont au cœur des tendances actuelles du Project Management de par leur potentiel d’amélioration continue de la qualité et de l’adéquation aux besoins du client ainsi que leur compatibilité avec les récentes appétences aux modèles plus flexibles, davantage axés sur la communication, la co-construction, favorisant l’innovation et répondant aux problématiques posées aux organisations par le digital. Un des principaux points fort des méthodologies agiles est de proposer un cadre méthodologique clair et stable tout en facilitant le changement en proposant une grande flexibilité et adaptabilité aux acteurs (Stoica, Mircea, & Ghilic-Micu, 2013) (Darell K. Rigby ; Steeve Berez ; Greg Caimi ; Andrew Noble, 2016). La rapidité d’identification des problèmes et de livraison est tout autant soulignée par la recherche. Cette dernière est permise par une hiérarchisation des besoins et un développement incrémental de la solution ponctué de déploiements réguliers des dernières améliorations développées (Darell K. Rigby ; Steeve Berez ; Greg Caimi ; Andrew Noble, 2016). Enfin, certains chercheurs soulignent le potentiel managérial de telles méthodologies au sens où elles encouragent la communication, impliquent le client et les membres de l’équipe dans une perspective de co-construction et favorisent la construction de compétences managériales complètes (Darell K. Rigby ; Steeve Berez ; Greg Caimi ; Andrew Noble, 2016). Certains vont jusqu’à théoriser une amélioration rapide du « bonheur au travail » (aussi subjective et discutable que puisse être l’introduction d’une telle notion vis-à-vis des théories de l’organisation) (Darell K. Rigby ; Steeve Berez ; Greg Caimi ; Andrew Noble, 2016).

Si les travaux récents incitent à l’optimisme, il s’agira de garder une certaine distance de rigueur vis-à-vis de l’emballement général pour les méthodes agiles, trop souvent présentées comme meilleure forme de Project Management aujourd’hui. Celles-ci recèlent en effet des barrières à l’implantation non négligeable pour certaines organisations. Elles requièrent une expérience importante du facteur humain : non seulement une expertise pointue des développeurs vis-à-vis du produit développé mais aussi des compétences sociales pour exploiter au mieux les synergies permises par la co-construction. Le management se doit d’être en capacité d’articuler plusieurs équipes « agiles » dans une structure matricielle pour coordonner un niveau supérieur de production. Ces méthodologies requièrent en outre une implication forte des parties prenantes pour éviter les écueils classiques provoqués par l’aspect fastidieux des nombreuses (et très régulières) réunions. On pourra aussi noter la difficulté de substitution du facteur humain en cours de projet (due à une documentation projet légère).

L’appréhension des méthodologies agiles comme « one best way » et son étude isolée et sans confrontation à son environnement constitue l’une des principales faiblesses de la recherche à ce sujet. « Quel manager pourrait être assez accroché à ses méthodes traditionnelles pour résister au changement ? » A cet emballement généralisé nous ne répondrons qu’un seul mot « contexte ». Si plusieurs études se sont intéressé à la dimension de gestion du changement vis-à-vis de des méthodes agiles (Babuscio, 2009), (Fraser, Boehm, Jarkvik, Lundth, & Vilkki, 2006 ) (McCarthy & Tsinopoulos, 2003), elles ne font que répondre au “comment”. La question du “pourquoi” se doit d’être posée pour une remise en cause complète des Méthodes Agiles comme “one best way”.

Nous présenterons à travers cette série d’article dédiée aux Méthodes Agiles de Project Management une grille d’évaluation contextuelle du déploiement de telles méthodes sur quatre plans : structurel, culturel (au niveau organisationnel et national) et stratégique. Celle-ci a été construite à la suite d’un travail de recherche scientifique. Puis, pour conclure cette série, nous appliquerons cette grille d’évaluation à travers un cas pratique réalisé en tant qu’étude d’opportunité pour BNP Paribas Group Finance Services. Nous étudierons ainsi la dimension propice ou non de l’organisation au déploiement des Méthodes Agiles de Project Management.

Bibliographie

Atkinson, R. (1999). Project management: cost, time and quality, two best guesses and a phenomenon, it's time to accept other success criteria. International Journal of Project Management.
Babuscio, J. (2009). How the FBI learned to catch bad guys one iteration at a time. Proceedings of the Agile Conference. Chicago: AGILE 2009.
Beedle, Bennekum, Cockburn, Cunningham, Fowler, Highsmith, . . . Thomas. (2001). The Agile Manifesto.
Boehm, B. (2002). Get ready for agile methods, with care. Computer.
(2015). Chaos Report 2015. The Standish Group.
Chavhan, A. (2015). Waterfall model advantages and disadvantages. Software testing and ISTQB.
Cohan, S., & Glazer, H. (2009). An agile development team's quest for CMMI® maturity level 5. Agile Conference. Chicago: AGILE 2009.
Darell K. Rigby ; Steeve Berez ; Greg Caimi ; Andrew Noble. (2016). Agile innovation . Bain & Company.
Fayol, H. (1917). Administration industrielle et générale. Paris: Dunod & Pinat.
Fraser, S., Boehm, B., Jarkvik, J., Lundth, E., & Vilkki, K. (2006 ). How do Agile/XP development methods affect companies? Proceeding of the 7th International Conference on Extreme Programming and Agile Processes in Software Engineering. Oulu.
Gandomani, Zulzalil, Ghani, A., & Sultan. (2013). Towards Comprehensive and Disciplined Change Management Strategy in Agile Transformation Process. Research Journal Of Applied Sciences, Engineering and Technology.
Huo, M., Verner, J., Zhu, L., & Babar, M. (2004). Software quality and agile methods. Proceeding of the 28th Annual International Computer Software and Applications Conference. Hong Kong: COMPSAC.
McCarthy, I., & Tsinopoulos, C. (2003). Strategies for agility: An evolutionary and configurational approach. Integr. Manufact. Syst.
Mintzberg. (1997). Structure et dynamique des organisations. Editions d'organisation.
Müller, R., & Turner, J. (2007). The influence of project managers on project success criteria and project success by type of project. European Management journal.
Royce, W. W. (1970). Managing the development of large software systems.
Sasankar, A., & Chavan, V. (2011). SWOT Analysis of Software Development Process Model. IJCSI.
Stoica, M., Mircea, M., & Ghilic-Micu, B. (2013). Software Development: Agile vs. Traditional. Informatica Economică.