Qu’est ce que l’Agilité ?

Cette question apparemment simple mérite d’être posée car nous entendons parler de l’Agilité partout, sans forcément prendre le temps de l’expliciter.

En consultant l’article de la méthode Agile sur Wikipedia, nous lisons ceci :

« En ingénierie logicielle, les pratiques agiles mettent en avant la collaboration entre des équipes auto-organisées et pluridisciplinaires et leurs clients. »

➜ L’Agilité est un mode d’organisation et de gestion de projet qui vise la collaboration des équipes et de leurs clients.

En parcourant wikipedia, nous y trouvons une définition plus précise de l’Agilité :

« Les pratiques Agiles s’appuient sur l’utilisation d’un cadre méthodologique léger mais suffisant centré sur l’humain et la communication. Elles préconisent une planification adaptative, un développement évolutif, une livraison précoce et une amélioration continue, et elles encouragent des réponses flexibles au changement. »

Dès lors, nous observons la mise en place de concepts forts : « cadre méthodologique léger« , « centré sur l’humain et la communication« . En continuant, il est abordé la planification adaptative, le développement évolutif et encore la livraison précoce. De tout cela découle ce que nous appelons désormais, depuis 2001 : les Valeurs et les Principes Agiles, issus du Manifeste Agile.

Il y a  4 valeurs Agiles :

1. 1. Les individus et leurs interactions plus que les processus et les outils
   2. Des logiciels opérationnels plus qu’une documentation exhaustive
   3. La collaboration avec les clients plus que la négociation contractuelle
   4. L’adaptation au changement plus que le suivi d’un plan

Et, il y a 12 Principes Agiles pouvant se résumer ainsi :

1. 1. Satisfaire le client
   2. Accueillir les changements
   3. Livrer fréquemment
   4. Travailler ensemble (Utilisateurs & Développeurs)
   5. Motiver les personnes
   6. Dialoguer régulièrement
   7. Mesurer l’avancement avec les fonctionnalités du logiciel
   8. Maintenir un rythme constant – Pas de pression inutile
   9. Excellence Technique
   10. Simplicité
   11. Auto-organisation des équipes
   12. Amélioration Continue

💡 Pour découvrir les principes dans leur totalité, c’est ici 👉 Les principes du Manifeste Agile.

Le Manifeste Agile est finalement une synthèse des pratiques de gestion de projet et d’équipes qui existaient avant.

Revenons aux sources de l’agilité.
Voyons en détails dans cet article les principales inspirations et pratiques qui ont inspirées et qui éclairent les agilistes encore aujourd’hui.

LA GESTION DE LA QUALITE

Dans les années 1920, les entreprises se sont intéressé à la gestion de la qualité :

1. La qualité pour l’utilisateur : c’est à dire le respect et la satisfaction des besoins utilisateurs.
   Cette catégorie est considérée comme créatrice de valeur pour l’entreprise et a pour but d’augmenter les recettes.
2. La qualité de la réalisation : c’est à dire le fait d’être sans défauts, ni erreurs, pouvant causer une charge supplémentaire de travail.
   Cette catégorie vise davantage la productivité des équipes et tend à diminuer les gaspillages et les coûts liés à un trop grand nombre d’anomalies.

La gestion de la qualité s’effectue donc sur 2 niveaux :

1. Pour assurer la qualité pour les utilisateurs, les équipes suivent les spécifications, correspondantes aux besoins, et communiquent avec les utilisateurs sur de potentiels ajustements .
2. Pour la qualité de réalisation, il est nécessaire de mettre en place un processus d’amélioration continue de type PDCA (Plan, Do, Check, Act), par exemple.

 

LE PDCA OU ROUE DE DEMING

Dans les années 1950, W. Edwards Deming est au Japon pour enseigner et former à ses techniques de management. Il a donné son nom à la « Roue de Deming ».

Ce cycle PDCA ou Roue de Deming se définit de la manière suivante :

• Plan : Déterminer les besoins des utilisateurs et les processus pour produire les fonctionnalités attendues.
• Do : Développer les fonctionnalités et mettre en place des outils de mesure de performance.
• Check : Evaluer la performance des équipes et identifier les améliorations possibles.
• Act : Mettre en place les actions qui permettent ces améliorations.

Les premiers agilistes ont retenus de la roue de Deming plusieurs notions :

• Le principe de fonctionnement en itération ➜ Ce qui a donné : les Sprints.
• La mise en place de l’amélioration continue ➜ Ce qui a donné une cérémonie récurrente pour l’amélioration continue que l’on appelle : la Retrospective.
• La définition de mesures de performance ➜ Ce qui a donné : la Vélocité pour mesurer la prédictibilité et le rendement moyen des équipes.

 

L’APPROCHE ITERACTIVE ET INCREMENTALE

Intéressons-nous maintenant aux évolutions liées à la gestion des projets informatiques. De manière générale un projet informatique repose sur un cycle de 3 étapes majeures :

1. La spécification et la conception des besoins utilisateurs
2. L’implémentation des fonctionnalités et les tests de validation
3. La livraison des fonctionnalités implémentées et la maintenance

Une approche intuitive peut être mise en place en considérant que ces étapes se suivent sans revenir en arrière :

• Les opérations sont séquentielles : on ne passe pas à l’étape suivante avant d’avoir terminé l’étape d’avant.
• Le processus est  linéaire : on ne revient pas sur une étape passée.

 

_ Le Cycle en V & le Cycle en cascade

Ce mode opératoire séquentiel et linéaire est à la base des modèles de gestion de projets informatiques qui prévalaient jusqu’aux années 2000. On appelle ces modèles cycle en V ou cycle en Cascade dont voici des représentations :

 

Ces modèles de gestion de projets ont pour conséquence de nombreux problèmes :

• Comme il est très difficile d’être exhaustif lors de l’expression des besoins avant de voir les fonctionnalités implémentées, il manque des éléments, des fonctionnalités lors de la livraison.
• Si les besoins utilisateurs évoluent, il est impossible de s’adapter aux changements.
• La conception ne tient pas compte de la complexité technique inhérente aux développements informatiques.
• Les spécifications deviennent rapidement très lourdes et difficiles à appréhender. Cela complexifie la compréhension des besoins utilisateurs, la prise de décision et la réalisation.

Ces problèmes occasionnent un taux d’échec des projets élevé. En 2015, une étude du Standish Group révèle ces chiffres édifiants :

« 29% des projets basés sur un cycle en Cascade sont des échecs. » – Chaos Report Standish Group 2015

 

_ Le modèle en Spirale

Bien avant le Rapport Chaos du Standish Group, des ingénieurs s’intéressent à la gestion des risques sur les projets informatiques. En 1988, Barry Boehm tente de répondre aux problèmes identifiés sur le cycle en Cascade en proposant une approche évolutive : le modèle en Spirale.

Cette approche est réalisée de manière itérative et incrémentale en 4 étapes :

1. Définition des objectifs : On part de l’expression des besoins et on identifie les risques potentiels liés à la conception.
2. Identification et résolution des risques : La conception est lancée sous forme de prototypes et on explore les différentes zone d’incertitude.
3. Développement et tests : L’implémentation démarre sur un périmètre étendu et une validation est réalisée de manière continue.
4. Planification de l’itération suivante : Une inspection des résultats est réalisée pour déterminer le plan d’action de la prochaine itération.

 

L’Agilité s’est inspirée de ce modèle en reprenant les pratiques suivantes :

• Planification itérative des développements ➜ En Agilité, les développements sont réalisés au sein d’itérations qui démarrent par la cérémonie de Sprint Planning.
• Identification des risques et exploration des zones d’incertitude ➜ En Agilité, il y a une réunion pour affiner les besoins fonctionnels, c’est la cérémonie de Refinement.
• Inspection des fonctionnalités implémentées ➜ En Agilité, à chaque fin d’itération les fonctionnalités sont présentées pour avoir des retours lors de la cérémonie de Démo.
• Analyse des résultats pour adapter l’itération suivante ➜ En Agilité, lors de la cérémonie de Review, l’équipe Agile inspecte le résultat de l’itération qui vient de s’écouler. C’est le moment de relever les écarts avec le plan d’action du début de l’itération. L’analyse de ces écarts va permettre d’adapter la planification de l’itération suivante.
• Enfin, le fonctionnement incrémental où la réalisation du cycle suivant vient s’accumuler aux réalisations précédentes ➜ L’effet boule de neige !

Toutes ces pratiques correspondent à un cadre de travail dont le but est une meilleure gestion des projets informatiques. Citons à nouveau le Rapport Chaos pour montrer le taux de réussite des projets Agiles, en regard avec  les projets en Cascade (Waterfall en Anglais) :

➜ Le modèle en Spirale représente donc une avancée marquante dans la gestion des risques liés aux développements de projets informatiques.
Dans ce sillon, le mouvement Agile s’est inspiré de ce modèle ce qui en a augmenté le taux de succès associé.

 

LEAN THINKING & KANBAN

Dans les années 1950, W. Edwards Deming développe de nouveaux concepts qui reposent sur ses découvertes issues de la gestion de la qualité.
Son objectif est de transformer le management des équipes par l’introduction d’une philosophie moderne :

• Vision à long terme
• Motivation intrinsèque des équipes
• Coopération
• Droit à l’erreur
• Leadership
• Suppression de la direction par objectifs
• Développement de l’innovation
• Formation de tous les membres de l’entreprise
• Satisfaction au travail

La liste des 14 points de Deming offre une compréhension des principes que souhaitait développer W. Edwards Deming.

De nombreux dirigeants d’industries japonaises se sont inspirés des préceptes mis en avant par Deming. Cette influence est visible dans la création au Japon en 1950 du prix Deming pour récompenser l’innovation managériale des entreprises.

Une des premières entreprises à gagner ce prix est le constructeur automobile japonais Toyota avec son système de production intégré : le Toyota Production System (TPS).

En 1990, James Womack et Daniel Jones invente le terme « Lean«  (que l’on pourrait traduire en français par « maigre », « épuré »), en étudiant les caractéristiques du modèle TPS. Le but recherché est la simplicité et la réduction du gaspillage dont la mise en œuvre nécessite la mise en place de plusieurs pratiques :

• Value Stream Mapping (VSM) : Analyse de la chaîne de valeur livrée au client.
• Minimun Viable Product (MVP) : Proposer au client ce qu’il est prêt à payer « sans plus ».
• Autonomiser, responsabiliser les équipes.
• Stand-up meeting : Réunion quotidienne pour favoriser la coopération.
• Système Kanban : Système visuel de suivi de production qui repose sur les concepts suivants :
  • Just in time & Pull strategy
  • Visualiser le flux de travail : Kanban Board
  • Small Batches & Limit work-in-progress (WIP)
  • Suivi de métriques : Lead Time & Cycle Time

L’Agilité reprend toutes ces pratiques de l’industrie pour les mettre en application au sein des projets informatiques, comme la méthode Kanban, très utilisée par les équipes supports / RUN.

L’Agilité va ainsi puiser dans le Lean une nouvelle approche du management des équipes. En Agilité, nous allons insister sur la coopération, l’auto-organisation et l’amélioration continue des équipes. Les membres de l’entreprise vont être considérés comme le moteur de l’innovation et de la performance.
Et, les managers dans tout cela ? Ils vont évoluer en leaders bienveillants sachant guider les personnes et libérer leurs motivations intrinsèques.

➜ De manière générale, nous pouvons dire que l’Agilité s’inspire du changement de paradigme que représente le « Lean ».

 

L’ARTISANAT LOGICIEL / CRAFTMANSHIP

Maintenant que nous avons évoqué la philosophie de l’Agilité, passons à son côté plus technique. Évoquons, par exemple, son inspiration dans le domaine de l’excellence technique et des bonnes pratiques de développement :

1 – Software Craftmanship & eXtreme Programming

Dans les années 90, une approche de développement logiciel fait son apparition en mettant l’accent sur la qualité et les bonnes pratiques de développement: le Software Craftmanship.

Avec ce mouvement, les développeurs sont considérés comme des artisans qui implémentent le code avec passion et recherchent le travail bien fait.

En 2008, les principes du mouvement Craftmanship sont explicités dans le manifeste pour l’artisanat logiciel qui évoque et répond au manifeste Agile :

• • Pas seulement des logiciels opérationnels, mais aussi des logiciels bien conçus.
  • Pas seulement l’adaptation aux changements, mais aussi l’ajout constant de la valeur.
  • Pas seulement les individus et leurs interactions, mais aussi une communauté de professionnels.
  • Pas seulement la collaboration avec les clients, mais aussi des partenariats productifs.

On recherche avec ce manifeste à soutenir l’excellence technique au sein des projets informatiques

➜ Un logiciel fonctionnel n’est pas suffisant, il faut qu’il soit bien réalisé.

 

2- La méthode eXtreme Programming

En parallèle, toujours dans les années 90, apparaît la méthode eXtreme Programming (XP) que l’on nommera Agile par la suite (il faut rappeler que le manifeste Agile a étécréé en 2001).

Cette méthode vise à définir les bonnes pratiques de réalisation d’une application informatique.

Le but est de mettre en place une discipline de développement pour produire des applications de qualité.

Les techniques qui sous-tendent l’eXtreme Programming sont les suivantes :

• • Emergent Design : Définir l’architecture pendant sa création.
  • Code Review : Pratique de revue du code par d’autres développeurs.
  • Test Driven Development / Test First Development : Développer les applications en commençant par les tests.
  • Tests unitaires : Réaliser des tests sur chaque partie du code.
  • Tests d’intégration : Pratiquer des tests suite à l’intégration d’une nouvelle partie de code avec le code général de l’application.
  • Pair Programming : Pratique d’implémentation par 2 pour partager des connaissances et s’améliorer.
  • Refactoring : Améliorer le code d’une application sans en modifier son comportement fonctionnel.
  • Spike : Phase d’exploration technique sur un besoin complexe à implémenter.
  • User Stories : Format de spécification des besoins en partant du point de vue de l’utilisateur final.
  • Story Point : Unité de mesure de la complexité et de l’effort d’une implémentation.
  • Acceptance Tests : Tests de validation fonctionnelle d’une implémentation.
  • Gestion de la dette technique : Adaptation et mise à jour du code pour pallier à la complexité générée par des implémentations successives.
  • Déploiement quotidien : Permet de tester les fonctionnalités et l’utilisation de l’application.
  • Increment réalisé en 1 semaine : Implémentation des fonctionnalités sur des périodes courtes pour livrer de la valeur aux utilisateurs régulièrement.

Toutes ces pratiques correspondent aux bonnes pratiques qui sont encouragées pour le développement d’application. L’Agilité n’a donc pas inventé ces bonne pratiques mais elle s’en alimente pour atteindre l’excellence technique.

 

CONCLUSION : Mon Oeil de Coach 🧐

En conclusion, l’Agilité n’est PAS une nouveauté puisqu’elle ne marque pas une rupture avec son passé. Mais, elle s’inspire de toutes les avancées organisationnelles, managériales et techniques qui sont apparues avant elle.

En effet, l’Agilité a puisé, dans la roue de Deming, la pratique de l’amélioration continue. Elle a puisé dans le modèle en Spirale, les cycles itératifs et incrémentals. Dans le Lean, l’autonomie des équipes et la valeur pour le client. Dans le Software Craftmanship, l’excellence technique et les meilleures pratiques de développement.

Ce que l’Agilité a apporté est une agrégation de ces pratiques sous un dénominateur commun. Cette simple opération  semble anodine alors qu’elle est en fait capitale. Elle a conduit à la définition de Valeurs et de Principes qui guident la culture des entreprises vers plus de performance, de qualité et d’innovation.

Les difficultés rencontrées dans la mise en œuvre de l’Agilité ne viennent donc pas de la nouveauté des pratiques. D’après moi, Charles LOVISI, elles sont plutôt le résultat de l’ambition de l’Agilité qui est de transformer les projets informatiques et les entreprises. Les besoins en Coachs Agiles qualifiés et pédagogues sont, par conséquent, indispensables dans le monde Agile qui s’ouvre devant nous.

Avez-vous aimé cet article ? Soutenez-nous en le partageant ! 😉
Une question ? Un mot doux ? Un retour ? Laissez-nous un commentaire ci-dessous 👇 !

…………………… ✂……………………………… ✂………………………………… ✂……………………

Envie d’aller plus loin ?

• Agile et première fois en remote ? Voici la trousse de survie !
• [LIVRE] L’art de devenir une équipe agile de Claude AUBRY
• « Ce qui est important c’est l’humain. » – Pascale POTHIN, coach agile
• 4 modèles inspirants pour construire votre équipe agile
• Mythe Agile : Scrum génère de la réunionite aigüe

…………………… ✂……………………………… ✂………………………………… ✂……………………

En quoi puis-je vous aider ?

Je suis Charles LOVISI, Coach agile

« J’accompagne les entreprises dans leur transformation agile : formation, coaching d’équipes, facilitation de l’amélioration continue, déploiement méthodologie Scrum, suivi des métriques Agiles. »

Coach Agile ayant une riche expérience depuis le développement (Frontend + Back-end) jusqu’à la gestion de projet (Chef de projet, Product Owner, Scrum Master, Agile Coach).

Contactez-moi pour en parler :

🚀 Linkedin : https://www.linkedin.com/in/charles-lovisi-02489713/
🌐 Site web : https://myagileexpert.com/