Les méthodes Agiles sont-elles efficaces?

Alexis ENG 111 Fattarsi session 2012 Les méthodes Agiles sont-elles efficaces? Illustration de couverture réalisée avec le site wordle.net

Table des matières Introduction...3 I. De l'entreprise à l'entreprise 2.0...4 A.Une gestion de projet traditionnelle...4 La gestion de projet, un long parcours...4 La gestion de projet, une recherche de performance...5 Différents cycles de gestion de projet...6 B.La gestion de projet Agile...7 Évolution des méthodes Agiles...7 Se réunir pour promouvoir ces méthodes...7 Le manifeste...8 Les principes...9 L Agilité pratique...10 Une approche itérative et incrémentale...10 Un esprit collaboratif...11 Un formalisme léger...11 Un produit de haute qualité...12 Différentes méthodes pour différents contextes...12 II. Les méthodes Agiles : des effets nuancés...15 A.L'apport des méthodes Agiles...16 Agile en offshore pour Visual chez Microsoft...16 Retour d'expérience Valtech sur le projet Lafarge...17 La vision d'un consultant pour la SSII Sopra group...18 L'analyse du «Chaos report»...18 B.Les limites des méthodes Agiles...19 Un mauvais état d'esprit...19 Le casting du «product owner»...20 Le contrat Agile «nearshore»...20 Développeurs, mauvais élèves...21 De multiples responsables...21 Le projet impossible...22 Le projet pilote...22 Conclusion...23 Index des illustrations...24 Index des acronymes et anglicismes...25 Bibliographie...26 2 / 26

Introduction L informatique, discipline jeune, est souvent controversée dans sa perception et sa réalisation. Autrefois seulement réservée à l entreprise, elle est aujourd'hui accessible et disponible à tous avec des supports physiques et des logiciels de plus en plus performants. La vision et les attentes du client envers l'informatique deviennent en conséquence de plus en plus pointues. L excellence des techniciens n'est plus suffisante pour gérer le développement informatique, la gestion de projet se démocratise dans le secteur informatique auprès d'un panel d'acteurs variés, ayant une vision allant bien au-delà de la réalisation technique et prenant également en compte le coût, la qualité et les délais de livraison. C'est le rôle du chef de projet. Les méthodes de réalisation de projet normalisées, séquentielles ou itératives, ont pour vocation l'amélioration et l optimisation des différents processus. Ces concepts, bien plus vieux que l'informatique, ont su être adoptés avec brio dans les différents domaines d'activités, tels que les télécommunications, le bâtiment ou l'industrie automobile. Le secteur informatique les utilise également, ce qui a permis d'introduire cette discipline au cœur l'entreprise. Bien que très utiles et indispensables, l'histoire a néanmoins démontré certaines faiblesses dans ces processus quant à la réalisation de projets de haute technologie où l'impact client était très important. Dans sa quête de performance, l'homme cherche donc de nouveaux modes d'action. Les méthodes dites Agiles apparaissent alors comme une des réponses en vogue. Dénigrées ou considérées comme révolutionnaires, il s'agira dans ce mémoire d'évaluer l'efficacité de ces méthodologies de réalisation de projet et de comprendre leur fonctionnement. Pour cela, j'aborderai plus en détail la gestion de projet classique dans l'entreprise puis j'expliquerai le fonctionnement des méthodes Agiles. Je m'intéresserai ensuite à leur efficacité concrète, à l'aide d'exemples en France et à l'étranger, illustrant des réussites et des échecs selon un contexte donné. Je conclurai sur ces retours d'expériences et ma vision des méthodes Agiles. 3 / 26

I. De l'entreprise à l'entreprise 2.0 A. Une gestion de projet traditionnelle Selon PMI 1 «project management institut» : Un projet est une entreprise temporaire visant à créer un produit et/ou un service unique La gestion de projet, un long parcours Fin XIX e Début XX e Milieu XX e Ces dernières années Le monde des affaires est en pleine expansion, la nécessité d'organiser les tâches et la communication avec les employés devient primordiale. Un des premiers grands projets requérant une telle organisation est la construction du chemin de fer transcontinental en 1860. Frederick Taylor instaure le concept d'un travail plus efficace. Henry Gantt, associé de Taylor, approfondit ses recherches sur l'ordre des opérations dans le travail et publie ses premiers diagrammes (dits «de Gantt» 2 ) affichant l ordonnancement des tâches dans les travaux. L'urgence des projets gouvernementaux et militaires liés à des ressources minimes, imposent une réorganisation des tâches. On voit alors apparaître les diagrammes de PERT 3 qui furent ensuite adoptés dans les années 60 par les dirigeants d'entreprises souhaitant de nouvelles méthodes pour la gestion de leurs projets. Depuis les années 60, ces modèles se sont développés dans le cœur même de l'entreprise, en incluant désormais des acteurs gérant des projets, formant des équipes et garantissant la communication interacteurs. Deux nouvelles tendances émergent dans la gestion de projet : la planification avec analyse descendante (cycle en cascade, cycle en v) et la planification ascendante, autrement dit les méthodes dites Agiles. Fig 1 : Historique de la gestion de projet : office.microsoft.com 1 PMI : association professionnelle qui propose des méthodes de gestion de projet. 2 Diagrammes de Gantt : affiche en fonction du temps l'ordonnancement des tâches d'un projet. 3 Diagrammes de Pert : affiche de manière ordonnée les relations entre les tâches d'un projet dans le but de calculer le chemin de réalisation critique. 4 / 26

La gestion de projet, une recherche de performance Comme le définit PMI, un projet est un ensemble d'activités et d'actions ayant pour but de répondre à un besoin défini. Un projet comprend un objectif déterminé devant être livré dans un coût et un délai imparti et dans la limite des ressources disponibles. Ces trois points sont représentés par les angles d'un triangle isocèle. Cette représentation dite du «triangle OCD», démontre que le moindre changement sur un des points déséquilibre le triangle et donc la réalisation du projet. Ressources Délai Coût Un projet est décomposé en une suite d'étapes liées les unes aux autres. Dans le référentiel PMI, ainsi que dans la normalisation AFNOR 4, on retrouve différentes étapes quasi-identiques : la conception, la planification, la réalisation et la terminaison. La conception a pour objectif de déterminer le but du projet, d'estimer les ressources, les coûts et les délais, d'évaluer les risques et surtout de choisir la personne qui mènera le projet : le chef de projet. La planification, elle, met en place la structure du projet. Les coûts et les délais vont être détaillés, les différents acteurs vont être recrutés et les rôles attribués. Évidement comme son nom l'indique, c'est dans cette phase que la planification globale sera fixée en fonction des tâches et que les outils de type Gantt et Pert seront, entre autres, utilisés. Dans la réalisation, le projet doit arriver à terme. Avec une démarche de suivi, les différentes tâches découpées précédemment vont aboutir. Le pilotage dans cette phase est important, c'est grâce à lui qu'on pourra vérifier si les branches du triangle ne sont pas trop mouvantes, afin de résoudre les éventuels problèmes. La terminaison joue également un très grand rôle. L'expérience passée sur le projet engrange du savoir-faire. Cette étape, trop peu considérée, a pour vocation d'améliorer le déroulement des futurs projets. C'est en commettant des erreurs et en prenant du recul, que nous améliorerons nos processus. La gestion de projet consiste alors à relever les défis de l entreprise, que ça soit pour la mise en place d'une nouvelle solution informatique, pour la création d'une chaîne d'assemblage ou pour envoyer des astronautes dans l'espace, elle met en place une organisation, une planification de l'ensemble des activités, un pilotage et un suivi du projet. Elle est aujourd hui indispensable pour le fonctionnement de l'informatique en entreprise. 4 AFNOR : Association française de normalisation 5 / 26

Différents cycles de gestion de projet Type Nom Description Remarques Normes Z67-101 ISO 12207 Découpage d'un projet en phases et étapes Processus de base d'un cycle de vie Répond aux questions» qui fait quoi» et «quand»? Ne traite pas le «comment» destiné aux projets de type gestion Evolution de la norme z67, difficilement applicable sans adaptation orientée vers les gros systèmes séquentiels Cascade Intégration Découpage du projet en phases, sans retour à la phase précédente Découpage d'un projet en phases commerciales Réduction des risques. Intervention des utilisateurs en fin de cycle seulement, souvent trop tard Contrôle qualité à la fin de chaque phase. Destiné à un projet < 1 an et connotation réglementaire Pas d'évolution des besoins Projet de type intégration d'un progiciel dans un SI existant V Contrôle qualité continu tout au long du processus Projet de taille moyenne et peu complexe RAD Construction de la solution avec l'utilisateur Implication forte des utilisateurs Nécessite une maîtrise des technologies Expertise de tous les participants Itératifs Incrémental Découpage du projet en domaines ayant chacun un cycle autonome en cascade Grands projets Spirale Méthodes évolutive basée sur la réalisation de prototype Destinée aux grand projets complexes internes difficilement contractualisables Maîtrise et réduction des risques Fig 2 : Cycle de vie des projets : Manager un projet informatique, Eyrolles 2010 6 / 26

B. La gestion de projet Agile Malgré des cycles de gestion de projet et des référentiels bien définis, la gestion de projet informatique connaît des hauts et des bas. D'après les chiffres du «Chaos report» du Standish group 5 en 1994, les projets informatiques, notamment aux Etats-Unis, ne sont seulement réussis qu'à 14 %. A ce faible taux de succès s'ajoutent les coûts exorbitants des divers projets qui ont été abandonnés et ceux qui ont dû être repensés, étant devenus obsolètes pendant leur réalisation. C'est durant cette difficile période informatique que 17 experts, ayant chacun des domaines de compétences bien précis, se sont mis à travailler sur des nouvelles méthodes de gestion de projet informatique : les méthodes Agiles. Évolution des méthodes Agiles Fig 3 : Les méthodes Agiles en date, blog valtech informatique. Se réunir pour promouvoir ces méthodes Pour ne pas rester dans l'ombre, ces experts se sont réunis en février 2001 afin de promouvoir une approche différente de la réalisation de projet informatique, s'attachant à délivrer de la meilleure façon possible ce qui est important pour le client. Le document issu de cette réunion débute ainsi : «Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire.» Le manifeste Agile est né. 5 Standish group : regroupement de professionnel informatique spécialisé dans l'évaluation des risques, des coûts et dans la valeur ajoutés de l'informatique. 7 / 26

Le manifeste Le manifeste met au premier plan quatre nouvelles valeurs encore peu exploitées dans la conduite d'un projet : Les individus et leurs interactions plus que les processus et les outils. Des logiciels opérationnels 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. Fig 4 : Le manifeste Agile : http://agilemanifesto.org Ces quatre valeurs démontrent bien la volonté de pallier aux insuffisances de la gestion traditionnelle. L'aspect humain dans le projet est ici bien plus présent. Cette conception mise sur l individu et son interaction avec les autres, permettant, à ce stade, de parler d'équipe. De son côté, le client intègre le projet et y participe au fur à mesure du développement pour en affiner sa vision et communiquer son ressenti. Il n'est en effet pas évident pour un client de définir au départ l'intégralité, et en détail, un projet qui n'aboutira qu'un ou deux ans après. Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas Fig 5 : Les 17 experts donnant naissance aux méthodes Agiles : http://agilemanifesto.org 8 / 26

Les principes Pour définir ces valeurs les experts posent 12 principes : Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée. Accueillez positivement les changements de besoins, même tard dans le projet. Les processus Agiles exploitent le changement pour donner un avantage compétitif au client. Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts. Les utilisateurs, ou leurs représentants, et les développeurs doivent travailler ensemble quotidiennement tout au long du projet. Réalisez les projets avec des personnes motivées. Fournissez-leur l environnement et le soutien dont elles ont besoin et faites-leur confiance pour atteindre les objectifs fixés. La méthode la plus simple et la plus efficace pour transmettre de l information à l'équipe de développement et à l intérieur de celle-ci, est le dialogue en face à face. Un logiciel opérationnel est la principale mesure d avancement. Les processus Agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant. Une attention continue à l'excellence technique et à une bonne conception renforce l Agilité. La simplicité c est-à-dire l art de minimiser la quantité de travail inutile est essentielle. Les meilleures architectures, spécifications et conceptions, émergent d'équipes autoorganisées. À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence. Fig 6 : Le manifeste Agiles, principes : http://agilemanifesto.org 9 / 26

L Agilité pratique Selon Jean-pierre Vickoff dans «Puma essential» : L'Agilité est la dynamique de l'organisation réactive et apprenante. Selon Véronique Messager-Rota dans «Gestion de projet Agile» : Une méthode Agile est une approche itérative et incrémentale, qui est menée dans un esprit collaboratif, avec juste ce qu'il faut de formalisme. Elle génère un produit de haute qualité tout en prenant en compte l'évolution des besoins clients. Une approche itérative et incrémentale L'approche itérative consiste à créer une esquisse totale du produit qui pourra être retouchée afin d'atteindre le résultat escompté. L'avantage consiste dans la possibilité de retouches. Le désavantage est que le travail s'effectue sur l'intégralité du projet. Donc si la vision initiale sur le rendu est erronée, on améliorera, mais l'objectif final ne sera pas atteint. L'approche incrémentale consiste à créer des briques, des modules, qui viendront se greffer les uns aux autres, afin d'atteindre l'objectif. L'avantage est que les tâches peuvent être effectuées simultanément. L'inconvénient réside dans le fait que toutes les briques sont déjà définies, si l'une évolue le résultat final peut être discordant. Le but des méthodes Agiles est de combiner ces deux éléments, pour créer le cycle itératif incrémental : Chaque brique est faite par esquisse jusqu'à obtention du résultat attendu, chaque incrément contient donc un résultat «définitif» et validé. Fig 7 : Illustration des cycles incrémentaux, et itératifs : www.entreprise-agile.com/histoagile.pdf 10 / 26

Un esprit collaboratif De part l'obtention du résultat attendu, cette approche établit une communication perpétuelle entre les différents acteurs, puisque chaque brique fait l'objet d'une mise en production et d'une validation de tous. La communication se traduit par le partage d'informations, l'entraide et non la concurrence. Mais tout ceci ne peut être possible que si le rôle traditionnel de chef de projet évolue. Au lieu de diriger et contrôler, il doit manager son équipe : trouver les conditions optimales de travail afin que chacun des acteurs contribue au résultat de l'équipe, donc au résultat le plus optimal du projet. Un formalisme léger A l'inverse des méthodologies classiques, où la rédaction d'importants documents (spécifications et documentations) occupe beaucoup de temps sur le projet, les méthodes Agiles sont qualifiées de méthodes légères. Il ne faut pas considérer ce terme comme péjoratif, bien au contraire cette réalisation met en avant les éléments clefs du projet et non pas l'ensemble. Ceci facilite le pilotage : comme moins d'éléments sont à suivre, ils bénéficient d'un suivi plus rigoureux. Un terme, qui n'est pas abordé dans la définition précédente, mais qui définit bien cette partie est «adaptatif». C'est-à-dire que l'équipe adapte son comportement, ses habitudes en fonction de la tâche à effectuer. Dans un cycle classique, les méthodes de réalisation, les outils, les environnements, sont définis dans la conception. Les équipes sont formées sur les outils et malheureusement si un outil choisi n'est pas adapté, l'équipe devra s'y former au détriment du délai imparti dans le projet. Alors qu'avec cette approche adaptative, au fur et à mesure des itérations, l'équipe prend connaissance des points qui bloquent, tout comme des éléments qui se sont révélés particulièrement performants. Cette expérience pourra ensuite être réutilisée afin d'optimiser les prochaines itérations. 11 / 26

Un produit de haute qualité La qualité d'un produit issu d'un projet se caractérise par la satisfaction du client. Bien que le produit puisse être d'une grande performance d'un point de vue technique, il se peut qu'il ne corresponde pas du tout aux attentes du client ou de l'utilisateur. Je peux citer en exemple, la réalisation d'un site vitrine pour mon entreprise. Des spécifications détaillées on été rédigées et validées par les deux parties mais la réalisation du projet s'est étendue sur plusieurs mois. Comme le prestataire du site n'a pas pu prendre en compte l'évolution de l'entreprise durant ce laps de temps, pour faire évoluer les spécifications initiales, le résultat final s'est révélé en inadéquation avec les besoins. Des spécificités indirectes étaient logiques pour le client mais totalement inutiles pour le maître d œuvre. C'est un site techniquement et visuellement parfait qui a été conçu mais loin d'offrir les fonctionnalités espérées. Le projet a donc été une seconde fois redéfini, ce qui a soulevé de nombreux problèmes techniques d'intégration et une mise en production bien au delà du planning initial et critique. Dans un processus Agile, les fonctionnalités importantes auraient pu être rediscutées après les premières itérations. Le «feedback 6» aurait permis un réalignement direct. Cet exemple soulève également les problèmes techniques d'intégration que le deuxième projet a impliqué. Ajouter du code en urgence dans une architecture qui ne le permet pas dégrade de façon considérable la qualité de celui-ci. On voit donc apparaître des duplications anarchiques dans le code puisque l'équipe en charge du projet initial n'était plus disponible et l'expérience du précédent développement n'a pas été utilisée (convention de codage par exemple). Avec cet exemple on comprend que dans une approche classique la valeur «satisfaction du client» est complexe et difficilement atteignable. On remarquera que les principes des méthodes Agiles semblent être plus disciplinés et offrent un pilotage de meilleur qualité. Différentes méthodes pour différents contextes Une fois exposées les généralités des méthodes Agiles, il existe une douzaine de méthodes pour faire de l'agilité. Chacune est née à partir des échecs de réalisation de projets. En 2011, un des signataires du manifeste publie un livre blanc sur ces différentes méthodes : http://www.agilebok.org. Dans la même lignée que le célèbre PMBOK 7 édité par PMI, ce recueil définit les bonnes pratiques de ces différentes approches. En me basant sur ce référentiel et mes différentes sources et bibliographies sur les méthodes Agiles, j'ai dressé dans le tableau suivant leurs types et champs d'action : 6 «Feedback» : traduit communément par «retour», désigne le commentaire du client vis-à-vis d'une application après son utilisation. 7 PMBOK : édité par PMI, c'est un référentiel des bonnes pratiques de gestion de projet. 12 / 26

Nom Type Caractéristiques Adaptive Software Development Dynamic System Development Method Feature Driven Development Crystal / crystal clear SCRUM EXtrem Programing La méthode ASD se compose d'une série de trois phases : spéculation, collaboration et apprentissage Méthode évolutive qui complète les manques de la méthode RAD 9 Méthodologie itérative et incrémentale se basant sur l'hypothèse que 80 % du projet se réalise en 20 % du temps Méthode basée sur des itérations courtes pour livrer rapidement de nouvelles fonctionnalités Méthode basée sur la diffusion incrémentale de fonctionnalités Méthode itérative basée sur des réunions quotidiennes Chaque fonctionnalité fait objet d'un «sprint» Méthode Agiles la plus radicale, la communication avec le client est continue Livraison à chaque itération d'un livrable Méthodologie adaptée au projet e-business 8 Avantages : Souplesse au changement Rapidité, délais, coûts Inconvénient : Nécessite une forte implication de l'utilisateur Méthode plutôt orientée vers des projets de moyenne et grande envergure Avantage : Gestion de projet rapide Inconvénients : Nécessite des experts. Contractualisation difficile Orientée sur des projets à hauts risques Avantages : Risques mesurés Équipe d'une vingtaines de personnes Inconvénient : Développeurs seniors exclusivement Plutôt orientée pour les petite structures Avantages : Petite équipe et forte communication. Mise en œuvre simplifiée Inconvénients : Petit projet Qualité de code moins rigoureuse Méthode rigoureuse Avantages : Contrôle continu Cycle d'un mois. Inconvénients : Petit projet Nécessite des managers qualifiés Méthode souple ouverte au changement Avantages : Qualité du code Satisfaction du client Inconvénients : Petit projet Implique la présence du client dans les locaux 8 «E-business» : se traduit par «commerce électronique». C'est l'action d effectuer des actions commerciales en utilisant un support numérique, le web par exemple. 9 RAD : «Rapid Software Development», apparu dans les années 80, c'est une autre méthode de gestion de projets, qui pourrait s'apparenter aux méthodes Agiles dans son cycle semi-itératif : cadrage, design, construction mais la planification est très rigide. Pour certains, RAD a donné naissance aux méthodes Agiles... 13 / 26

Chaque méthode dispose d'un champ d'action particulier. Les avantages et inconvénients démontrent l'importance de choisir la méthodologie de gestion en fonction du type de projet. Fig 8 : Comparaison des méthodes Agiles : www.businessinteractif.fr Dans cette première partie, j'ai dressé la vision globale de la gestion de projet et j'ai ensuite approfondie sur les des méthodes Agiles, en définissant leur concept ainsi que les aspects pouvant les différencier des cycles traditionnels. D'un point de vue purement théorique nous avons vu ici l'apport qu'elles ont en informatique. Nous allons à présent nous intéresser à leurs applications réelles dans le monde de l'entreprise. 14 / 26

II. Les méthodes Agiles : des effets nuancés D'après les statistiques annuelles fournies par Version one 10 en 2011, 59 des sondés seraient favorables à l'adoption des méthodes Agiles dans leurs futurs projets ; 33% ne se prononcent pas et seulement 8 % y seraient défavorables. Notons que ce panel est composé à 60 % d'entreprises utilisant et ayant utilisé des méthodes Agiles. Fig 9 : Utiliser les méthodes Agiles dans le futur : http://www.versionone.com/ Ces chiffres tendent à montrer que les professionnels qui ont employé de ces méthodes en sont globalement satisfaits. Plus qu'un terme à la mode, ces données font le constat d'une réelle adoption des méthodes Agiles. Pourtant, après avoir moi-même consulté quelques chefs de projets et directeurs informatiques du département, aucun ne veut basculer vers de la gestion de projet Agile. En approfondissant les recherches et en consultant le «Chaos report» du Standish group, on constate alors de nombreux échecs dans les projets informatiques et beaucoup d'avis, de commentaires très négatifs au sujet de ces méthodes. Pour comprendre ce paradoxe, nous allons évoquer l'utilisation des méthodes Agiles à travers des exemples concrets. Fig 10 : Statistiques du chaos report : standish group 10 Version one : éditeur de logiciel de gestion de projet Agiles qui réalise depuis 2008 des enquêtes annuelles, aux travers de sondages, sur l'utilisation des méthodes Agiles, dans plus de 88 pays. 15 / 26

A. L'apport des méthodes Agiles Agile en offshore pour Visual chez Microsoft Microsoft, leader mondial de l'informatique grand public, développe des systèmes d'exploitation et de nombreux logiciels. Mais en terme de réalisation de projet, il n'est pas l'acteur le plus efficace. Certains logiciels sont et restent inadaptés malgré des millions de dollars d'investissement. Pour le développement de l'outil Visual studio (logiciel de programmation facilité), la filiale Microsoft France a alors choisi d'utiliser les méthodes Agiles et plus particulièrement SCRUM. C'est au cours du Microsoft Days 2011 que le résultat a été communiqué. Ce projet présente un haut risque d'échec. En effet c'est un projet qui s'étale sur 2-3 ans, les équipes sont délocalisées (France, États-Unis) et le produit est destiné à un client peu consultable (utilisateurs très différents). Le développement itératif incrémental a été choisi pour pallier aux problèmes dits de «tunnelling». Mieux vaut des itérations validées, plutôt que de continuer les yeux fermés vers un résultat incertain. En effet, dans le cas de ce projet un peu particulier c'est un comité de direction qui se place dans la position du client de l'application. Le développement valide, environ toutes les deux semaines, avec ce comité directionnel, une itération du futur logiciel. Si le projet paraît peu adapté dans les premières occurrences, le client peut ensuite redéfinir ses exigences, reformuler les points qui ont été mal interprétés ou définis, et d'itération en itération, on s'approche du résultat que le client a souhaité. Microsoft, lors de cette conférence, a appuyé longuement sur l'importance de la communication pour l'avancement et la qualité du projet. Que ce soit avec des logiciels adaptés ou par des «meeting», c'est l'interconnexion et l'intercommunication qu'implique la stratégie Agile qui donne la possibilité à cette équipe de réaliser un produit de qualité. Microsoft insiste également sur l'importance d adapter la méthode en fonction du contexte. Bien que la méthode SCRUM soit utilisée, certaines particularités sont ainsi laissées de côté ou réadaptées au vu du contexte. C'est le cas du comité directionnel qui prend le rôle du client, afin de pouvoir être présent avec les équipes de développement. Le projet se déroule dans les meilleures conditions, chaque acteur semble satisfait du résultat approchant. 16 / 26

Retour d'expérience Valtech sur le projet Lafarge Étienne Charignon, consultant pour Valtech 11, livre son retour d'expérience concernant le projet de création d'un site internet dédié aux professionnels, pour l'achat en ligne de ciment. Le client Lafarge a souhaité faire réaliser ce projet avec deux méthodes. L'une utilisant le cycle en V, l'autre utilisant les méthodes Agiles. Pour la méthode traditionnelle, le projet a été estimé à deux mois avec une équipe de 10 personnes, contre 4 mois avec une équipe de 5 développeurs pour la méthodologie Agile. Après diverses spécifications et étapes de codage voici le résultat du projet : On constate que le projet utilisant le cycle en V n'est pas arrivé à terme dans le planning, au contraire du projet Agile qui lui est en production à la date spécifiée lors de la conception. Dans la première approche, tout le contenu du site, voire plus, est présent mais le site n'est pas fonctionnel. Dans la seconde approche, le contenu a été réduit pendant le projet mais le résultat final est satisfaisant pour le client. Pourquoi? La réalisation pour le cycle en V a fait appel à une équipe «offshore» 12 composée de 10 personnes qui, en raison de leur nombre, n'ont pu travailler correctement en équipe. Avoir choisi de tout spécifier en amont, n'a pas permis de prendre en compte les évolutions du projet, et le client n'a pu que constater le jour de la mise en production la non fonctionnalité de l'application. Le choix, pour la réalisation en Agile, a été une équipe chez le client. Un chef de projet a été défini et a piloté l'équipe en interne. De part ce choix de structure le client a été au cœur du processus de développement. La mauvaise réalisation issue de la méthode de cycle en V vient donc du fait que les communications client et maître d œuvre ont été inexistantes. C'est un des concepts Agiles définis dans le manifeste : «La collaboration avec les clients plus que la négociation contractuelle». Cet exemple, tout comme celui du projet Visual de Microsoft, met en évidence l'importance de la communication entre les différents acteurs d'un projet, qui est moins évidente dans une gestion de projet utilisant le cycle en V. 11 Valtech : groupe de conseil international spécialisé dans les technologies de l'e-business. 12 «Offshore» : développement d'un projet extra-territorial. 17 / 26

La vision d'un consultant pour la SSII Sopra group Philippe Paysan, consultant pour le groupe Sopra, explique son intérêt pour les méthodes Agiles, lors d'une interview réalisée pour le journaldunet.com. Philippe Paysan compare les anciens projets auxquels il a participé et leurs effets tunnels par rapport aux projets Agiles. En moyenne, 20 % seulement des fonctionnalités choisies sont utilisées dans les applications. Ce consultant a pu participer à de nombreux pilotes puis projets Agiles au sein de cette entreprise. Ses conclusions sont majoritairement positives. Pour lui, les méthodes Agiles représentent la solution idéale. Elles remettent les clients au cœur de l'application. Le passage en Agile dans les projets auxquels il a participé a conduit au succès. Les clients ont été satisfaits et l'entreprise a gagné en notoriété. L'analyse du «Chaos report» Le «Chaos report», outre des échecs de projets, indique aussi les facteurs qui, aujourd'hui, aident à la réalisation des projets. Parmi les nouveaux processus cités comme des facteurs de réussites, les méthodes Agiles figurent à la sixième position. Pour rappel, le «Chaos report» se base sur les statistiques de 60 % d'entreprises américaines, 20 % européennes et 20 % d'autres pays. Ces quelques exemples montrent l intérêt et le succès des méthodes Agiles pour les entreprises les utilisant. Chacune, à son niveau, a vu son taux de satisfaction client s'accroître. 18 / 26

B. Les limites des méthodes Agiles S'il est facile de trouver des critiques sur les méthodes Agiles sur les forum internet ou dans différentes bibliographies, il est beaucoup plus compliqué de les illustrer par des cas réels, les entreprises préférant taire les échecs de projets afin de sauvegarder leur image de marque. Dans mes recherches et mon réseau professionnel, j'ai également souvent obtenu la réponse suivante : «J'ai participé à un projet dit «Agile» mais au final c'était de la gestion de projet sans méthode réellement définie.» Le terme Agile aide en effet à la prospection du projet mais les conditions de réalisation en sont fréquemment toutes autres. C'est pourquoi je me suis essentiellement basé sur la conférence donnée par Alexandre Boutin lors du SCRUM Day 13 2011. Coach Agile indépendant, il a participé à la réalisation de projets dans de grands groupes tels Kelkoo, Yahoo, ou Orange. Il expose plusieurs projets auxquels il a participé et qui se sont tous soldés par un échec. Ceci à plusieurs niveaux : arrêt du projet, arrêt de la méthodologie Agile, désengagement de l'équipe... Par professionnalisme et par respect pour les entreprises, l'anonymat est conservé. Dans chacun des exemples suivants le choix de la méthodologie Agile a été approuvée par la direction, les budgets étudiés et les équipes choisies. Un mauvais état d'esprit Dans cette configuration, tout est réglé comme une horloge, l'équipe a un état d'esprit Agile, les différentes valeurs sont bien acceptées par l'ensemble des acteurs, les rôles bien définis : le contexte de réalisation idéale. Mais un acteur, le directeur technique, ne voulant pas adapter son mode de travail à l'approche Agile, a interféré avec les processus en se positionnant comme seul dirigeant et surtout en gardant la vision de rentabilité ponctuelle, sans prendre en considération les gains futurs. Lors des différents meeting, cette personne est immédiatement entrée en conflit avec la planification des différentes étapes. Lorsque l'équipe métier annonçait un délai de X jours pour une étape, sa réponse était immédiatement X % 2. Même après différentes négociations il fallait se conformer à ses exigences, totalement en désaccord avec l'esprit Agile. Ce qui a eu pour effet de créer des tensions. Ce directeur technique avait, en plus, tendance à court-circuiter les accords en ordonnant des tâches et des délais non prévus, sans passer par l'ensemble de l'équipe du projet, de façon répétitives et poussives. C'est une forme de harcèlement qui a eu des effets plus que négatifs sur la réalisation. Ce projet n'a pu aboutir car plus aucune des parties n'étaient coordonnées, il a été totalement stoppé et considéré comme un échec par la direction. 13 SCRUM Day : événement annuel visant à exposer la méthodologie SCRUM et les méthodes Agiles (retours et utilisations). 19 / 26

Le casting du «product owner» 14 Le «product owner» (PO) est la personne quasiment la plus importante dans une approche de type SCRUM. Elle a la responsabilité d'amener le projet à bien. Elle gère le budget, les équipes, intervient au moins deux fois par semaine pour suivre le bon déroulement et anime l'équipe. Dans ce projet, le PO avait été choisi, il était formé sur la méthodologie, il était disponible pour son équipe, même plus que nécessaire, et comme le souligne fortement Alexandre Boutin, il était sympathique et ouvert. Mais au fur et à mesure des itérations, il s'est révélé être plutôt gestionnaire que visionnaire, s'impliquant trop dans les tâches, voulant tout contrôler, en n'offrant pas la vision nécessaire à l'équipe. C'est un des principes fondamentaux de la gestion de projet Agile qui a été lésé ici. N'ayant plus de liberté tout en étant dans un contexte Agile, l'équipe n'a pu avancer correctement. La méthodologie ne correspondait plus. C'est à la cinquième itération (sur 13) que le projet a été abandonné. Cet exemple montre que manager un projet Agile c'est tout d'abord avoir l'esprit Agile et ne pas se positionner comme «monarque». Le contrat Agile «nearshore» 15 Délocaliser le développement informatique est une pratique qui se produit de plus en plus. Pour ce projet de création d'un «back-office», le choix s'est porté sur un contrat «offshore» en Chine puis «nearshore» dans les provinces chinoises. Ce choix, un peu particulier, n'est pas incompatible avec la gestion de projet. Précédemment, dans le cas de Microsoft, nous avons vu que cela était tout à fait possible et que si les risques sont déterminés et connus, il n'y a pas de difficulté. Ici, comme pour tout développement «offshore», la motivation était le coût. En effet le porteur du projet savait que pour un développeur de même qualification, le coût à l'étranger était 50 % moins important qu'en France. Des contrats on été signés mais des contrats de même type que pour une approche classique. Une centaine de pages prédéfinissant l'intégralité du projet et qui ôtent, par là-même, toute marge de manœuvre aux responsables du projet Agile. Néanmoins, par la suite il s'est avéré que pour encadrer deux développeurs il fallait une troisième personne à temps plein. En fin de compte, 100 % des bénéfices apportés par le «nearshore» ont été perdus dans l'encadrement. Dans ce cas, on constate également un non-engagement sur les valeurs portées par les méthodes Agiles. Le non respect de celles-ci ont tout simplement entraîné le projet dans un effet tunnel. Le budget n'a pas pu être renégocié, les équipes non complétées, le délai du projet a été multiplié par quatre. 14 Le «product owner», dans la méthodologie SCRUM est l'unique personne qui porte la vision du projet, ce poste se rapproche de celui de chef de projet. 15 «Nearshore» : identique à la délocalisation mais dans une région ou un pays proche. 20 / 26