Bonjour à tous,
Petit papier d’été sur un sujet qui me tiens à cœur (mais vous l’avez déjà compris) : l’Agilité.
Ce qui est formidable avec l’Agilité et avec le fait de la présenter et la proposer à des équipes, des projets : c’est qu’on apprend chaque jour.
Dans ma mission actuelle, je suis amené à travailler sur différents frameworks Agile. Ceci est dû à la connaissance de l’Agilité et la sensibilité à l’Agilité de chaque équipe / projet.
Cela pose la question suivante : Quel framework Agile pour répondre à une problématique donnée ?
La réflexion du framework : lequel pour quoi faire ?
Souvent, les développeurs associe Agilité avec le Framework Scrum.
Cette association est faite grâce à la popularité du Framework par les développeurs et dans les entreprises françaises qui demandent, maintenant à tous les développeurs d’être certifié Scrum.
Bien que c’est une excellente chose d’être certifié Scrum, je ne pense pas qu’il est obligatoire de connaitre uniquement Scrum pour comprendre l’Agilité au sens large du terme.
Il existe énormément de coach en agilité qui ne dispense qu’un seul et unique Framework Agile pour répondre à toutes les problématiques.
Or, après avoir expérimenter plusieurs frameworks Agile, je m’aperçois qu’en fonction du besoins et des gens qui le composent, de leurs parcours et de leur sensibilité à l’Agilité, certains frameworks Agile vont « mieux marché » que d’autre.
Ainsi, je fais ce constat aujourd’hui : L’Agilité doit se dispenser en fonction des gens et de leur rôle sur le sujet qu’ils doivent traiter : une équipe, un projet, un programme, un portfolio de programme, une entreprise.
Et pour cela, il faut connaitre et comprendre différents Frameworks Agile pour savoir quel Framework va correspondre à votre contexte.
Chaque Framework a ses forces et également ses faiblesses : Aucun ne répondront à toutes les situations possibles.
Les frameworks Agile ne doivent pas être utilisés comme des règles absolues et comme une vérité inébranlable.
Ainsi, chaque groupe de personnes ayant un but commun et cherchant à mettre en place l’agilité, doit avoir une réflexion sur le Framework Agile qu’il va utiliser !
Par contre, une fois qu’un Framework est accepté par tous, il faut que les règles « imposées » par ce Framework soient suivies scrupuleusement.
Et il faut surtout, ne pas perdre l’objectif du Framework Agile :
- Donner un vocabulaire commun à tous
- Donner des rituels et artefacts pour travailler ensemble.
- Donner des rôles pour connaitre les responsabilités des acteurs.
- Donner des règles globales à respecter (Agile Manifesto)
Pour ma part, j’ai eu la possibilité d’expérimenter les Frameworks Agile suivant :
Chacun de ces framework a ses forces, son « public », ses faiblesses.
Il est important d’identifier les publics et les objectifs que vous désirez atteindre avec l’Agilité :
- La partie Initiate ?
- La partie Discover ?
- La partie Deliver ?
- La partie Release ?
- La partie Scaling ?
- La partie LeaderShip ?
Pour le moment, je n’ai trouvé que ce schéma qui résume, me semble-t-il, assez bien les sujets abordés dans les différents Framework Agile et surtout les liens entre ces framework.
C’est fait par Christopher Webb de l’entreprise Deloitte.
Bien que l’idée même de représenter l’ensemble des Frameworks Agile sur un plan de type métro me semble bien compliqué, c’est un début pour faire comprendre que chaque Framework Agile est destiné à suivre plus particulièrement un certain nombres aspects et pas tous les aspects.
Bien que ce schéma contient un bon nombre d’erreurs (voir l’article https://medium.com/tech-sojourna/7-things-wrong-with-deloittes-agile-tube-map-641192e20068), c’est un début !
J’espère vous avoir donner un peu matière à penser !
Et je vous souhaite un excellent été à vous !
0 Commentaire(s)