L'agilité
Depuis plusieurs années, on entend parler de l’agilité et de méthodologie comme SCRUM, de Kanban (ou encore le Google Design Sprint), etc. Ces changements dans nos façons de travailler ne datent pas d’hier, exemple avec le LEAN Management de Toyota qui date de 1988. Mais les bases de l’agilité ont été formalisées en 2001 avec le manifeste agile ou agile manifesto.
Aujourd’hui je vous partage mon expérience et ce que j’ai pu en apprendre.
Qu’est-ce que c’est ?
Popularisées en 2001 via le manifeste agile, les méthodes agiles sont des pratiques qui mettent en avant la collaboration entre des équipes auto-organisées et pluridisciplinaires, et les clients.
On entend avec ce terme avoir de la flexibilité, de la souplesse face aux changements, et suivre une vision claire de l’avancement du produit (contrairement aux cycles en V ou cascade où le produit était réalisé en plusieurs mois via un cahier des charges dont les spécifications sont difficilement modifiables et où les clients découvrent leur nouveau produit quand il est livré).
Nous allons voir dans cet article les 4 valeurs et les 12 principes de l’agilité, et aussi une petite analyse sur les risques et les bonnes pratiques à adopter pour chaque élément.
Les 4 valeurs
Le manifeste nous dit “Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.” mais cette phrase est assez ambigüe, de même que la formulation des valeurs.
Elles sont formulées comme ceci “1ere partie PLUS QUE 2eme partie”. Dans beaucoup de société, la seconde partie de la formulation n’est pas comprise ou mal exploitée. La 2eme partie n’est pas un objectif en soi, mais un moyen au service de la 1ere qui elle est bien l’objectif visé.
Maintenant, découvrons-les avec leur finalité et leur bonne pratique.
L’interaction entre les individus PLUS QUE les processus et les outils
Finalité : Définir la meilleure solution possible.
Bonne pratique : Challenger la valeur de chaque élément du produit à réaliser.
Un logiciel opérationnel PLUS QUE une documentation exhaustive
Finalité : Prioriser chaque élément du backlog en fonction de sa valeur et des risques projet.
Bonne pratique : Réaliser un Produit Minimum Viable (MVP) enrichit par incréments si la valeur des ajouts est démontrée.
Une collaboration avec les clients PLUS QUE une négociation contractuelle
Finalité : La réussite qui s’obtient en négociant puis en préservant les intérêts divergents de chacun.
Bonne pratique : Rechercher un accord WIN-WIN entre toutes les parties prenantes.
Une adaptation au changement PLUS QUE le suivi d’un plan
Finalité : Maîtriser les aléas sur la cible produit et sa trajectoire en anticipant les risques.
Bonne pratique : Décider le plus tard possible puis délivrer le plus vite possible.
Les 12 principes
Après les valeurs, voici les principes de l’agilité. Vous allez le voir, les risques de dérive sont fréquents.
Satisfaire le client en délivrant rapidement
Risque : Croire que le délai prime sur le contenu livré.
Bonne pratique : Utiliser un diagramme de Kano pour mesurer la satisfaction client.
Accueillir positivement les changements de besoins
Risque : Démonétiser la prise de décision.
Bonne pratique : Challenger l’acceptabilité et la valeur de chaque item du backlog.
Livrer fréquemment un logiciel opérationnel
Risque : Noyer les utilisateurs par des recettes et des modification incessantes.
Bonne pratique : Cible un MVP en V1 puis des incréments selon un rythme soutenable.
Les utilisateurs et les développeurs doivent travailler ensemble quotidiennement
Risque : Croire que l’efficacité maximum est obtenue en réunissant tout le monde dans une salle rarement adaptée.
Bonne pratique : Disposer d’outils de collaboration, d’espaces de travail variés (en groupes isolés) et garantir la disponibilité des sachants selon une planification du sprint révisée quotidiennement.
Réaliser les projets avec des personnes motivées, leur fournir l’environnement et le soutien dont ils ont besoin
Risque : Confier la responsabilité antérieurement au Chef de Projet vers un Product Owner sans revoir le cadre de management.
Bonne pratique : Il faut manager chaque collaborateur en fonction de 2 axes : compétences et motivation. Ce management est confié à un tuteur qui peut être un membre de l’équipe ou un tiers.
Le dialogue en face à face
Risque : Négliger l’importance des compétences en communication, être en face à face ne suffit pas.
Bonne pratique : En présentiel ou en visio, décrypter le non verbal de son interlocuteur et maîtriser le sien.
Un logiciel opérationnel comme principale mesure d’avancement
Risque : Négliger le suivi du consommé et du Reste À Faire (RAF) qui doit être fait quotidiennement.
Bonne pratique : Définir clairement les conditions d’acceptabilité pour chaque item du backlog (US, tâches...).
Un rythme de développement soutenable et constant
Risque : Epuiser les équipes pour tenir chaque échéance.
Bonne pratique : Respecter comme pour tout autre métier le code du travail et les dispositions légales de l’organisation.
L’attention continue à l’excellence technique et à une bonne conception renforce l’agilité
Risque : Conduire le projet en mode agile en oubliant de concevoir un SI agile apte à supporter aisément des changements.
Bonne pratique : Concevoir la solution en respectant de bonnes pratiques d’architecture.
La simplicité est essentielle
Risque : Se focaliser sur la seule simplicité technique or elle doit d’abord être simple sur le plan fonctionnel.
Bonne pratique : Eviter les fonctions superflues et complexes à réaliser mais livrer une solution aux standards industriels de production et pas l’équivalent d’un Proof Of Concept (POC).
Les meilleures architectures, spécifications et conceptions émergent d’équipes autoorganisées
Risque : Le projet fonctionne en vase clos et n’a pas de vision de la réalité.
Bonne pratique : Faire un dossier d’architecture sur chaque projet validé par des architectes ou des responsables SI.
L’équipe réfléchit aux moyens de devenir plus efficace, puis modifie son comportement
Risque : Induire l’idée que tout problème doit être solvable par l’équipe livrée à elle-même.
Bonne pratique : L’équipe identifie tous les problèmes du projet et les actions / décisions à prendre, les traite à son niveau et à l’échelle de toutes les parties prenantes du projet (CODIR, gouvernance...).
Le mot de la fin
Comme nous avons pu le voir, l’agilité est une pratique puissante pour concevoir des produits mais il faut faire attention aux mécompréhensions et aux risques de certains éléments. Si vous voulez vous initier facilement à une méthodologie, je vous conseille le SCRUM qui est déjà très fortement utilisé aujourd’hui. Si vous voulez quelque chose de plus avancé, je vous conseille alors le LEAN Management qui possède plusieurs niveaux de certification (de débutant à expert).
Vous pouvez aussi allez voir notre article sur le Google Design Sprint !
Si vous avez apprécié cette présentation sur l’agilité, n’hésitez pas à la partager et à nous faire des retours. Vous pouvez aussi consulter nos autres articles ou entamer la discussion pour une future collaboration.
