C’est quoi le manifeste agile ?

Le « manifeste agile » est un document qui est né en février 2001 (à Snowbird dans l’Utah) lors d’un séminaire qui a rassemblé 17 experts [1] en logiciels et approches de gestion de projet. Ce document est considéré comme le point de départ du mouvement Agile, il comporte 4 valeurs et 12 principes.  

Manifeste Agile : Introduction 

Il existe des documents qui ont indéniablement marqué l’histoire humaine : il y a eu la déclaration universelle des droits de l’homme, la magna carta, la déclaration d’indépendance des États-Unis, le code d’Hammourabi, etc. Eh bien de la même façon, on pourrait dire que le « manifeste agile » s’inscrit dans cette lignée de ces documents historiques qui ont marqué l’histoire de la gestion de projet. Il s’agit d’un document révolutionnaire de gestion de projet initié originellement dans le domaine informatique par 17 spécialistes [1] des logiciels et des frameworks.

Ils y ont présenté 4 valeurs principales et 12 principes qui met davantage l’accent sur les individus et interactions humaines plutôt que sur les processus et les outils. En effet, on reprochait souvent aux chefs de projet traditionnels, une certaine rigidité et une certaine lourdeur dans l’application des processus qui venaient ralentir les projets. Le manifeste agile a donné naissance à un courant de pensée qui s’est démultiplié ensuite sur plusieurs approches dites « agiles » (Scrum, Crystal, Extrem programming ou XP, FDD, DSDM, AUP, Scrumban, etc.). Alors, je vous rassure tout de suite, si vous préparez la certification PMP® prochainement, n’aurez pas à les connaître par coeur. Toutefois vous devez avoir une bonne culture agile car l’agilité a désormais pris une place incontournable dans l’économie du projet. Et cela commence par le « manifeste agile ».

Etymologie du manifeste agile

D’abord d’où vient le terme « manifeste » ?

« Manifeste », signifie étymologiquement « visible ». À l’origine les manifestes servaient à exprimer des « revendications » politiques ou encore sociales pour les rendre « visibles ». Par exemple, il y a eu le manifeste allemand des 12 articles de 1525, le manifeste américain du mouvement des droits civiques (1960) ou encore le manifeste du parti communiste.

Si je devais faire un pari, je dirais que l’inspiration de l’expression « manifeste agile » provient du manifeste futuriste de Filippo Tommaso Marinetti (1909) car il a beaucoup contribué à influencer l’art et la culture du XXe siècle en prônant la modernité, la technologie et la vitesse. Je fais cette remarque car le premier des 12 principes du « manifeste agile » est centré sur une livraison « rapide » de fonctionnalités à grande valeur ajoutée, mettant en avant la vitesse dans le développement logiciel moderne. Je le rappelle pour mémoire : « Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée. » (extrait du principe n°1 du manifeste Agile). 

Schéma n° 1 : les 4 valeurs du manifeste agile

Les 4 valeurs du manifeste Agile : avantages et inconvénients

💡Interprétation : On comprend de cette première valeur que ce ne sont pas les processus dans les entreprises qui font la différence mais bien les femmes et les hommes qui la compose. Les outils et les processus ne sont que des « moyens » au service de finalités plus grandes. Par exemple : Un marteau est un outil mais il n’aura pas la même finalité dans les mains d’un plombier, d’un ouvrier ou d’un meurtrier. C’est l’intention initiale qui fait la différence.

Ceci étant dit (et ceci est valable pour les 4 valeurs du manifeste agile), les processus et les outils ne sont pas à jeter à la poubelle. On voit bien dans cet exemple du marteau que l’outil a une « réelle » valeur.  Il s’agit juste de dire que c’est une priorisation dans l’application des directives. Cf. la dernière phrase du manifeste agile : « Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers ».

✔️Avantage : La diversité humaine dépasse largement les processus et les outils utilisés. Par exemple : si l’entreprise de covoiturage BlaBlaCar (bla-bla : un exemple topique ! :)) avait suivi aveuglément les processus et les outils de leur Chief Compliance Officer de l’époque, l’entreprise n’aurait jamais pu exister ! Pour rappel, on leur reprochait d’exercer une activité de transport illégale. Ce conflit avec les autorités françaises a finalement abouti à la légalisation du covoiturage en France.

❌Inconvénients : On comprend également de cette valeur, que les individus et leurs interactions doivent être « saines ». Lorsqu’elles sont de piètre qualité, elles peuvent être catastrophiques pour une entreprise. Exemple : Lorsqu’Elon Musk a pris la décision de racheter l’entreprise Twitter, il a limogé bon nombre d’hommes et de femmes « clés ». Résultat, la valeur de Twitter a baissé de plus 50% au début du rachat (20 milliards de dollars contre 44 milliards). Les processus et les outils étaient là, mais ils n’ont pas su/pu convaincre les individus et leurs interactions de leur frénésie.

💡Interprétation : Il vaut mieux un logiciel qui fonctionne plutôt qu’un logiciel qui suit l’encyclopédie technique du cahier des charges mais qui plante à chaque clic ! Je pense qu’ici nous touchons du doigt une des plus grandes problématiques de gestion de projet, à savoir : « le recueil des exigences ». Parce qu’on touche ici aux limites du langage. Les mots sont ambigus car ils peuvent avoir plusieurs significations et ils sont incomplets car on ne peut pas toujours décrire toutes les nuances d’une idée ou d’une émotion. Selon Ludwig Wittgenstein (cf. « Le Tractatus logico-Philosophicus »), il est impossible d’expliquer par écrit une « couleur » à une personne aveugle. Cela nécessiterait des démonstrations complexes et peu efficaces. Parfois, les choses se comprennent mieux en se « montrant » qu’en « s’expliquant ». Bien sûr, cela ne signifie pas que les approches agiles doivent s’affranchir d’une quelconque documentation, mais disons qu’elles doivent rester « simples » et « courtes ». 

✔️Avantage : Cette valeur a le mérite d’être très pragmatique. Si la documentation technique se contredit : eh bien ce n’est pas grave ! Si la documentation n’est pas suffisamment précise sur un point, eh bien ce n’est pas grave ! Privilégions d’abord les hypothèses qui fonctionnent ! Regardez le schéma de la méthode TRIZ, une méthode de résolution de problèmes inventée par l’ingénieur russe Genrich Altshuller dans les années 1940. On voit bien sur ce schéma qu’il faut une bonne dose de motivation pour pouvoir utiliser cette méthode ! (humour : cliquez-ici pour la découvrir) Mais est-ce fondamentalement utile ? Parfois, en utilisant son bon sens et son intuition, on peut trouver des solutions opérationnelles à des problèmes complexes, sans nécessairement passer par des documents ultra sophistiqués ou théoriques.

❌Inconvénients 1 : Certains clients pensent du coup (à tort) que cette valeur doit les exonérer d’un cahier des charges (cf. le jugement du 7 octobre 2020 du tribunal de commerce de Paris décrit dans le paragraphe suivant). Le client avait demandé à son fournisseur de vérifier la conformité des applications en lui déléguant les phases de « tests » logiciel. Mais ce n’est pas parce qu’on cherche à avoir des logiciels opérationnels plutôt qu’une documentation exhaustive qu’il ne doit plus y avoir « d’exigences client ».

☝️ à noter : vous entendrez quelquefois des débats inutiles autour du terme « opérationnel ». Certains rigoristes tombent dans les travers du langage décrits précédemment. Ils reprochent à ce mot clé « opérationnel » de ne pas suffisamment mettre en relief le terme « valeur ». Car on peut avoir des logiciels qui fonctionnent bien mais qui ne correspondent pas aux besoins des clients. Je pense que c’est un débat stérile car il est indiqué dès le 1er principe du manifeste agile (cf. les 12 principes décrits plus bas) : notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.

💡Interprétation : Comme nous l’avons vu avec la précédente valeur du manifeste agile, le langage a ses propres limites et on ne peut pas « tout dire » au travers de l’écrit. Il est donc totalement utopiste de penser qu’un contrat parfait puisse exister. Mais en définitive, à quoi ça sert un contrat ? Un contrat ça sert à clarifier des attentes, à protéger des droits, à spécifier des responsabilités et à faciliter les recouvrements en cas de litige. Mais si on part du principe que nos droits seront bafoués, que nos garanties seront annulées ou encore qu’on rencontrera des problèmes de paiement à chaque interaction avec notre interlocuteur, alors pourquoi diable conclure un contrat ??

N’est-il pas au contraire préférable de ne pas conclure d’accord ? Laissez-moi vous donner un exemple : si vous êtes persuadé que votre livreur de pizza veut vous empoisonner, alors pourquoi continuer à choisir cette pizzeria ? Ne vaut-il pas mieux choisir une pizzéria en qui vous avez confiance ? Ce que je veux vous dire c’est qu’un contrat repose d’abord et avant tout sur de la confiance. Comme disait Maurice Dufresse (ancien sous-directeur de la DGSE) : la confiance c’est comme le permis à point, on donne tous les points dès le départ puis on les retire au fur et à mesure 🙂 Bien sûr cela ne veut pas dire qu’il faille être totalement naïf, on doit quand même mettre en place quelques garde-fous contractuels mais c’est surtout la confiance plutôt que la méfiance qui fera qu’on travaillera plus efficacement.      

✔️Avantage : Cette valeur offre l’avantage d’avoir plus de proximité avec ses clients et donc d’avoir davantage des relations de long terme. Ce qui est de nature à encourager la confiance. Quand on a confiance, on peut prendre quelques libertés avec les contrats qui peuvent être ajustés en fonction des besoins mouvants du moment. In fine, cette manière de faire coûte moins cher pour tout le monde (aux clients et aux fournisseurs) puisque les coûts juridiques et administratifs liés aux rédactions de contrat sont moins présents.

❌Inconvénient : D’aucuns pensent que cette valeur les dispense de formalisation. Si on fait l’impasse sur trop d’aspects contractuels, on s’expose à des risques importants. Le 7 octobre 2020, le tribunal de commerce de Paris a analysé la question de savoir si un fournisseur informatique était responsable d’un retard de livraison d’un projet effectué en mode « agile ». Le fournisseur n’a pas été jugé responsable et ce pour plusieurs raisons. Le prestataire n’avait pas de cahier des charges, le client avait signé les procès-verbaux de recettes sans émettre de réserves et surtout le client avait payé son fournisseur (le paiement est une preuve d’accord).

Autre inconvénient : Il peut également y avoir des problématiques de transfert de propriété intellectuelle entre le client et le fournisseur. Par exemple : si un client donne des directives régulières sur un produit qui ensuite est utilisé par des milliards d’utilisateurs, il voudra certainement s’en attribuer la paternité. Il convient donc de clarifier les responsabilités du client et du fournisseur.

💡Interprétation : Cette valeur va nous engager à créer un contrat suffisamment large pour qu’il offre certaines marges de manœuvres au fournisseur. Il devra prévoir des modalités d’adaptation au changement et des limites pour sécuriser le projet sans toutefois tomber dans les travers de la valeur n°3 (qui prévoirait une contractualisation extrême). D’aucuns parlent de « smart contrat » cela peut-être une idée intéressante. On peut également proposer une facturation au temps passé et au périmètre d’avancement (cf. les contrats à frais remboursable ou en régie, exposés dans le PMBOK®). D’autres nous invitent également à raisonner en « outcomes » (résultat) plutôt qu’en « outputs » (livrable ou donnée de sortie).

Par exemple : un bijoutier veut créer une application mobile avec un service de paiement Premium : ceci est « l’outcome ». Eh bien le fournisseur pourra proposer d’installer un bouton comme PayPal : ceci est le livrable (l’output). Mais d’autres solutions de paiement seront également possibles (Payoneer, Stripe, Google Pay, etc.). Le changement sera tout à fait possible tant que le résultat (l’outcome) reste le même. Dans le cas contraire, il faudra penser à créer de nouveaux annexes au contrat ou à changer de typologie de contrat. Tous les chemins mènent à Rome, ce qu’il faut comprendre ici c’est l’état d’esprit agile.     

✔️Avantage : l’approche agile permet de modifier facilement les termes et les conditions du contrat en cas de changement d’exigence client. La livraison régulière de petit bout de valeur permet de détecter et résoudre les problèmes rapidement. Ce qui réduit les risques pour les parties prenantes impliquées. L’ouverture au changement renforcera également la confiance entre les parties.

❌Inconvénients : sur le plan théorique tout le monde est d’accord il vaut mieux s’adapter aux changements plutôt qu’avoir une approche rigoriste de suivi de plan. Sur le plan pratique cette dernière valeur du manifeste agile peut être plus difficile à appliquer. Car les changements peuvent entraîner des coûts supplémentaires et des délais imprévus. Tout va dépendre de la nature du changement. S’agit-il d’un changement ? D’une transformation ? Ou d’une métamorphose ? En effet, ce n’est pas parce que le changement est bienvenu en approche agile qu’on va transformer projet de tuyau d’arrosage en vaisseau spatial ! 🙂

👉Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.

Le manifeste agile précise bien que les « seconds éléments » des 4 valeurs du manifeste agile (les processus, les outils, la documentation, le contrat et le plan) ont de la valeur. Ce qui prouve bien qu’ils n’ont pas disparu. Ils devront être également minutieusement traités pour pouvoir offrir toute leur « valeur ». Toutefois les premiers éléments seront à intégrer prioritairement. C’est comme une tarte au citron meringuée, le lait concentré ou la crème fraîche qui servent à adoucir la garniture au citron sont importants mais sans la pâte sablée, le gâteau ne sera jamais réussi ! 🙂                   

Les 12 principes du manifeste agile : illustrations et exemples

Principe n°1. Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.

Le principe est un des plus vieux principes du commerce avoir des clients satisfaits. Parce qu’un client satisfait c’est un client fidèle et un client qui recommandera de service. Les clients sont impatients donc il faut leur fournir des livrables rapidement. Mais la rapidité permet aussi aux clients de tester et donner du feed-back sur les fonctionnalités développées. Ce qui permettra de détecter rapidement les éventuels problèmes erreurs. Ne pas se perdre dans les détails. Pour ce faire, vous devez toujours raisonner « valeur ». Le « raisonnement valeur » orienté agile se traduit de la façon suivante : comment puis-je apporter une fonctionnalité qui soit la plus utile possible sans qu’elle me coûte une fortune ?

Principe n°2. 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.

Imaginez la situation suivante. Imaginez que les stakhanovistes de l’agilité et que les extrémistes des approches prédictives (Cycle en « V », Waterfall, etc.) se retrouvent un jour sur un terrain de football. Que va-t-il se passer ? Eh bien c’est très simple,  les adeptes des méthodes agiles vont reprocher aux traditionnalistes d’être paralysés par tous leurs plans qu’ils ont planifié rigoureusement à l’avance (le joueur n°1 qui fait une passe au joueur n° 4, le joueur n° 4 fait une passe au joueur n°8, etc.). Et d’un autre côté, les obsédés des approches prédictives, vont quant à eux reprocher aux agilistes de ne pas suivre les règles du jeu à la lettre.

En réalité, ces deux équipes ont toutes les deux raisons ! C’est juste qu’elles ne tiennent pas suffisamment compte de leur « environnement ». Un projet, c’est un projet – certes – contraint par des forces intérieures (le budget, les délais, le périmètre, etc.) mais il est aussi contraint par des forces « extérieures » : la vitesse des concurrents (le Time to Market), l’imprécision des besoins du client, la rareté des compétences techniques sur les projets innovants, etc.

• Dans un contexte certain (exemple : un projet de déménagement entre Paris et Marseille). Il sera préférable d’utiliser des méthodes prédictives de gestion de projet [3]. Mais si le changement arrive tard dans ce type de projet, il pourra être « catastrophique » pour ses coûts (le client informe son fournisseur la veille du déménagement qu’il veut déménager à Bordeaux).

• A l’inverse, lorsqu’un projet évolue dans un contexte incertain (à l’inverse de l’exemple précédent, il y a plus d’informations inconnues que d’informations connues. Exemple : les projets innovants de l’intelligence artificielle), il sera préférable d’utiliser des approches « agiles » de gestion de projet. Et les changements seront les bienvenus puisqu’ils seront « obligatoires » (cf. le modèle de STACEY, schéma n°1).

Schéma n° 2 : le modèle de Stacey [3]

Principe n°3 : Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.

Un des travers qu’on a pu voir apparaître dans les approches de développement prédictives (cycle en V, Waterfall, etc.), c’est « l’effet tunnel » c’est-à-dire l’absence de visibilité sur les projets. Quand les chefs de projet récupéraient leurs mandats de projet, ils disparaissaient, tels des David Copperfield :), ils ne ressortaient de leur cachette que pour présenter le résultat final. C’est justement pour cette raison que les méthodes agiles ont mis en place le concept du « sprint ». Un sprint c’est quoi ? C’est une durée fixe qui va permettre aux équipes de se mettre en ordre de bataille pour livrer fréquemment des « fonctionnalités » valeur.

Veuillez noter qu’à partir du moment où on va définir une durée fixe, on va s’efforcer de la garder pour pouvoir maximiser la cadence de travail et l’adaptabilité. Par exemple : l’équipe de développement travaille sur une application mobile pour des coiffeurs. Eh bien plutôt que de compiler toutes les tâches possibles de l’application mobile et de revoir son client que 8 ou 12 mois plus tard avec son application mobile. Elle va définir une durée, disons 2 semaines et à partir de là, elle va se demander ce qu’elle peut offrir comme fonctionnalités qui offriraient le maximum de valeur à son client d’ici 2 semaines. Est-ce que c’est le lien bouton de paiement « Paypal » ? « est-ce que c’est l’espace de chat » ? Etc. C’est important de garder une durée fixe et courte pour pouvoir voir si 2 semaines, les fonctionnalités apportent toujours autant de valeur au client ou s’il faut les changer.    

NB : parfois certains frameworks agiles (comme l’Extreme programming ou XP, Discipline Agile, SAFe, etc.) utilisent le terme « itération » en place et lieu du terme « sprint » (utilisé pour Scrum, Spotify, etc.) mais dites-vous qu’ils ont essentiellement la même signification.    

Principe n°4 : Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.

Dans la première partie de cet article (voir la 2ème valeur du manifeste agile : « des logiciels opérationnels plus qu’une documentation exhaustive »), j’explique qu’il y a eu un jugement datant du 7 octobre 2020 émanant du tribunal de commerce de Paris dans lequel on voit bien les travers possibles d’une relation client-fournisseur inefficace. Le client avait demandé à son fournisseur de faire lui-même les « tests » du logiciel (certains pensent que c’est un fonctionnement agile mais c’est une erreur !). Le mot-clé le plus important de ce 4ème principe est « quotidien ». Il ne s’agit pas de faire des points d’avancement une fois par semaine comme cela peut être le cas dans les approches prédictives. 

Il s’agit ici au contraire de faire des points quotidiens entre le(s) client(s) et le(s) fournisseur(s) en utilisant des communications en face-à-face (nous reviendrons sur ce point un peu plus loin dans cet article). L’idée étant de travailler dans un esprit de « confiance » et de « coopération » pour co-construire des solutions aux problèmes rencontrés. On est loin des réunions de type : « reporting » dans lesquelles on doit justifier ses problèmes face à des clients négligents. 

Principe n°5 : Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés

Richard Branson disait : « si vous prenez soin de vos employés, ils prendront soin de votre entreprise ». J’aime beaucoup cette idée. De la même façon qu’il s’agit de travailler en confiance avec ses clients externes, il s’agit de travailler en toute confiance avec ses clients internes : c’est-à-dire avec ses collaborateurs. Un collaborateur considéré est un collaborateur motivé !

Faire plaisir à ses collaborateurs n’est pas un crime, au contraire, c’est une preuve d’intelligence. Personne ne peut croire que les collaborateurs qui vivent dans la terreur et la méfiance sont plus efficaces que les collaborateurs qui prennent du plaisir au travail en toute autonomie pour atteindre les objectifs fixés. C’est ainsi qu’ils seront plus performants !

Principe n°6 : 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.

La communication écrite est utile lorsqu’on communique de façon « asynchrone » ou lorsqu’il y a un grand nombre de parties prenantes. Elle est souvent utilisée dans les projets prédictifs pour tracer les informations significatives. Mais elle peut également être très utile pour les projets agiles (cf. la première partie du présent article sur les 4 valeurs du manifeste agile). Toutefois la communication écrite nécessite souvent l’emploi de ressources dédiées et peut perdre en immédiateté. C’est la raison pour laquelle la communication orale en face-à-face (synchrone) est à privilégier pour les projets en approche « agile ». La communication orale est plus rapide et plus persuasive que la communication écrite. Par exemple, on résout beaucoup plus facilement les conflits en face-à-face que par écrit (non, non les conflits ne se résolvent pas par mail ou notes audio ! :))  

Principe n°7 : Un logiciel opérationnel est la principale mesure d’avancement.

Imaginez l’application « WhatsApp », il y a 10 ans elle n’était pas du tout la même que celle d’aujourd’hui. Elle s’est enrichie au fur et à mesure du temps à la manière d’un « millefeuille ». Elle s’est étoffée avec la technique des MVP (Minimum Viable Product).  

☝️ Dans une approche prédictive, on va lister toutes les tâches à réaliser, et on va ensuite communiquer sur le pourcentage d’avancement par rapport à ces tâches et par rapport au produit final. Ainsi 2 tâches achevées sur 10 par rapport un produit quelconque nous renseigneront sur son pourcentage d’avancement. Dans cet exemple on dirait que le projet a progressé de 20 %. Dans une approche agile, on va raisonner en MVP. C’est-à-dire à ce qu’on va pouvoir mettre tout de suite sur le marché.  Il s’agit de comptabiliser les livrables déjà « acceptés » par nos clients et mis sur le marché (et non pas comptabiliser les tâches terminées à l’intérieur de ces livrables). Et ce sont ces MVP qui serviront de mesure d’avancement.  

Principe n°8 : 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.

Si je devais parier, je dirais que ce principe succède aux excès des premières approches agiles qui imposaient un rythme important aux équipes de travail sur des délais très courts (certaines approches étaient basées sur la « rapidité » de développement). Ce qui a conduit à plusieurs démissions, tensions et burnout, etc.  

Parfois vous entendrez aussi parler « d’interlude » agile. Cet interlude consiste à proposer aux équipes, une semaine de repos entre 2 releases [5]. Si on lit le manifeste agile au pied de la lettre (« by-the-book » comme disent certains), cet interlude ne devrait pas exister. En tout cas, il ne devrait pas exister pour ce motif de « repos » puisque les personnes désignées ici doivent être capables de maintenir indéfiniment ce rythme. Ce qui va sans dire va encore mieux en le disant : « Il est inutile d’épuiser les collaborateurs en leur imposant un rythme frénétique !».

Principe n°9 : Une attention continue à l’excellence technique et à une bonne conception renforce l’Agilité.

A la fin des années 1980, la méthode RAD (Rapid Application Development) s’est fait connaître car elle était axée sur le développement rapide. Mais la précipitation a parfois pris le pas sur la vitesse et entraîné des problématiques de qualité. Les délais resserrés ont conduit comme nous l’avons vu précédemment à des périodes de stress mais également à des erreurs et à des bugs qui pouvaient se propager lors des versions ultérieures des logiciels. Or dans les projets IT, il n’est jamais bon de laisser traîner les bugs. Il faut donc veiller à travailler dans des délais raisonnables pour garder un temps de « toilettage » du code informatique. On appelle cet usage, le « refactoring » (réusinage de code).

Principe n°10 : La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.

Simple : Albert Einstein disait qu’il avait mis 30 ans à comprendre ce que voulait dire ce terme ! En effet, trouver une réponse « simple » ne signifie pas « simpliste » !

Pour vous aider à comprendre ce principe, la loi 20/80 (loi de Pareto) vous sera probablement très utile. Face à un problème, elle vous invitera à vous concentrer sur leurs causes essentielles. Exemple : 20 % de vos e-mails de la journée d’hier, recouvrent environ 80 % des sujets à traiter. 20 % des causes d’insatisfactions clients, recouvrent environ 80 % des sujets les plus irritants pour les clients, etc.

Autre exemple : Savez-vous que les utilisateurs d’Excel n’utilisent que 5 % des fonctionnalités qu’offre ce logiciel ? Eh bien, en appliquant ce principe on aurait probablement éliminé 95 % des fonctionnalités inutiles ou plutôt inutilisées d’Excel. On en revient au fameux MVP dont on parlait précédemment.

Principe n°11 : Les meilleures architectures, spécifications et conceptions émergent d’équipes auto-organisées.

Vous l’aurez deviné, le mot-clé le plus important ici est le mot-clé auto-organisée. Vous savez dans le domaine du sport ce ne sont pas les équipes qui ont les meilleurs joueurs individuels au monde qui gagnent (le PSG en est un illustre exemple !), mais ce sont les équipes qui ont la meilleure « auto-organisation ». Lorsque les joueurs ont l’habitude de travailler ensemble, ils sont tout simplement meilleurs ! Cela ne sert à rien de mettre les meilleurs joueurs individuels sur le terrain, s’ils ne savent pas jouer ensemble, ils ne gagneront pas. C’est aussi simple que ça !

Principe n°12 : À intervalles réguliers, l’équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.

Ce douzième principe est probablement inspiré du « lean management », il consiste à se dire qu’on peut toujours mieux faire. Je trouve que ce dernier principe est l’un des plus beaux puisse exister. S’efforcer d’être les meilleurs en se remettant régulièrement question : voilà un principe qui a de la gueule ! 🙂 Dans la pratique ce principe s’applique lors des réunions appelées « rétrospectives ». La réussite « rétrospectives » dépend essentiellement des personnalités des collaborateurs car il nécessite du discernement et de l’humilité pour identifier les meilleures actions à mettre en place. 

Conclusion

Pour parler de gestion de projet « agile », on prend souvent en exemple, l’anecdote du système d’information de l’agence suédoise des brevets : « Bolide » (Bolid ?) initié en 2002 qui a perdu des millions de dollars en raison de son approche traditionnelle de gestion de projet. Cette approche traditionnelle, appelée « prédictive » [3] aurait coûté la bagatelle de 35 millions de dollars pour ce système informatique de gestion des propriétés intellectuelles. De la même façon, les adeptes de la gestion de projet traditionnelle rétorquent aux adeptes des méthodes agiles qu’il existe de nombreux projets qui ont échoué avec les approches agiles : le projet healthcare.gov (2013), le projet canadien d’édition des bulletins de paie « Phoenix » (2016), le projet d’application mobile de la ville de New York (2019), etc. En réalité, et comme vous l’avez compris je l’espère avec le modèle de STACEY, il y a des typologies de projets qui sont faits pour être gérés de façon « prédictive » et d’autres qui sont faits pour être gérés de façon « agile ». De la même façon qu’il y a des personnes faites pour l’état d’esprit « prédictif » et des personnes faites pour l’état d’esprit « agile ». Après tout, l’agilité n’est-elle pas d’abord et avant tout une affaire d’individus et d’interactions ?  

__________________________________

Sources et références :

[1] Les 17 spécialistes qui ont créé le manifeste agile sont : 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.

[2] Traité de la réforme de l’entendement. Paragraphe n°30 et n°31. Baruch Spinoza.  

[3] Pour rappel, l’approche prédictive vient du verbe « prédire » car dans l’approche prédictive on « prédit » tout ce que l’on doit faire à l’avance avant de l’exécuter. Exemple : la construction d’une maison. Certains traduisent l’approche prédictive par « cycle en V » ou « Waterfall » (en cascade) mais ce sont des abus de langage car ces méthodes sont spécifiques au monde informatique. Par exemple, on ne les emploie pas dans les secteurs de la construction ou pharmaceutiques.   

[4] Exercice librement inspiré du livre de Jeff Patton : user story mapping.

[5] Qu’est-ce qu’une release ? Une release c’est une version d’un produit (ou d’un logiciel). Par exemple, lorsque vous utilisez votre smartphone, il y a des mises à jour à faire qui portent sur des versions. Eh bien lorsqu’on réfléchit aux produits que l’on va sortir, on va non seulement réfléchir à ses MVP (et comment ceux-ci vont être étoffés dans le temps), mais on va également réfléchir à ses releases. C’est d’ailleurs ce qu’on appelle un « plan de release ». Bien qu’il n’y ait pas de normes officielles sur les durées des releases, on va prévoir une release toutes les 10 semaines environ. 

________________________________