L’agilité, c’est à la mode. On en parle partout, dans tous les séminaires de management on nous dit « soyons agile ». Ca nous parle alors que nous travaillons tous dans un environnement qui change, fluctue. .Et pourtant, il est très difficile de trouver une définition de la méthode agile sur internet.
J’ai pensé qu’une explication sur ces différentes méthodes « Agile », qui répondent au doux nom de « scrum » et « kaban » – pouvait vous intéresser, même si vous ne travaillez pas dans l’industrie du développement de logiciels. La méthode Agile découle d’un manifeste de 2001. Le principe général d’une méthode Agile est de procéder de façon itérative et incrémentale pour augmenter les chances de succès des projets.
Planifier de façon itérative
Dans la méthode Agile, on planifie par étape. Au lieu de créer des spécifications hyper détaillées au début d’un projet, on adapte le planning en continu. Personnellement, cela me parle car je n’ai jamais aimé tout planifier au début d’un projet.
Cette approche pragmatique permet de changer la direction du projet, de le faire évoluer au fur et à mesure que d’autres besoins émergent. Travailler par étape permet aussi de prendre en compte, au fur et à mesure, la réalité du marché, les retours des parties prenantes et des utilisateurs.
Cette méthode permet de mieux évaluer le temps nécessaire pour compléter chaque unité de travail.
Finaliser de façon itérative
La logique est la même pour la finalisation du produit qui est également faite de façon itérative. Le produit est livré par fonctionnalités ou tâches individuelles. Chacun de ces mini projet sera livré en tant que produit minimum viable (Minimum Viable Product), c’est-à-dire un produit avec juste assez de fonctionnalités pour valider une hypothèse. Cela permet des retours clients réguliers et donc de minimiser les investissements inutiles et de mieux contrôler les budgets
Dans l’approche dite « Scrum », le travail est découpé en étapes courtes appelées «sprints», d’une durée de deux semaines. Les fonctionnalités sont livrées à la fin de chaque sprint.
Dans l’approche « Kanban », on liste toutes les tâches prioritaires (ou «backlog») pour livrer les éléments les plus importants en premier et identifier des goulets d’étranglement. Vous disposerez ainsi d’un arriéré de tâches à faire chaque jour, ce qui vous permettra de vous assurer que les fonctionnalités les plus utiles sont toujours en cours de traitement. Vous devrez examiner régulièrement vos priorités au fur et à mesure que votre projet progresse.
Définir des histoires d’utilisateurs (users stories)
On définit des histoires d’utilisateurs : « Comme [utilisateur], je veux [tâche], de sorte que [motivation] ».
Cette référence directe à des besoins de l’utilisateur permet de communiquer les exigences à tous dans un format clair et facile à comprendre pour toute l’équipe de développeurs.
Travailler de façon rapprochée avec ses clients, faire des présentations et points rapides (stands up)
Avec le cadre Scrum, les membres de l’équipe, et plus largement le groupe des parties prenantes du projet, évaluent régulièrement les progrès du projet.
Tout au long du « sprint », les points rapides (stand-ups) sont quotidiens. Les membres de l’équipe partagent ce qu’ils ont accompli la journée précédente, ce sur quoi ils vont travailler et les obstacles qu’ils rencontrent.
A la fin de chaque sprint, une présentation est faite devant les parties prenantes qui ne sont pas directement impliquées dans la gestion quotidienne du projet. Elle permet de recueillir des retours et de modifier la priorisation du projet. La présentation est aussi l’occasion pour l’équipe projet de réfléchir sur sa performance – identifier ce qui fonctionne bien et les domaines à améliorer.
Communiquer de visu et collaborer
Une collaboration efficace de l’équipe est nécessaire pour garder en permanence en tête les objectifs stratégiques et s’assurer que le produit répondra aux exigences du monde réel. L’enjeu est que l’équipe communique et travaille bien ensemble.
Enfin, vous pouvez introduire des tests dans vos processus pour donner des retours d’utilisateur final à un stade précoce.
Optimiser la structure de l’équipe et les rôles
Il est souvent recommandé de limiter la taille de l’équipe de base à trois à six personnes, pour maintenir concentration et vitesse.
Vous pouvez également définir des fonctions au sein de l’équipe :
- Le représentant du commanditaire du produit représente la voix de l’utilisateur, et doit s’assurer que le travail effectué offre la plus grande valeur possible aux utilisateurs finaux. Il maintient cette orientation utilisateur tout au long du projet
- Le facilitateur ( Scrum Master). Il aide à optimiser les performances de l’équipe en supprimant les points de blocages identifiés dans le stand-up quotidien.
Enfin, on ne fait pas de micro-management (ça c’est recommandé partout dans le monde du travail). Les équipes doivent être autonomes, capables de s’auto-organiser. Elles doivent avoir le droit de prendre des décisions, tout en maintenant une communication continue pour que le projet reste en phase avec les objectifs.
Attention, néanmoins, comme le dit l’auteur de kissmyfrog ne peut pas faire une religion de la méthode agile (comme je le disais en intro, le terme est à la mode). Le culte du feedback peut tuer d’excellentes idées, et la passion de ceux qui les portent, notamment quand le marché n’est pas prêt pour accueillir l’innovation.
Pour aller plus loin, je vous conseille la lecture de ce guide du scrum ainsi que ce site d’un enseignant qui applique ces méthodes à ses cours.
Et pour poursuivre votre acculturation au monde numérique, vous pouvez allez voir mon article sur une API, kesako ainsi que cet autre article sur les sites français pour améliorer votre culture numérique.