Qu’est-ce que l’agilité ? #1

Avis aux non-sportifs 😱

Non, l’agilité n’est pas une nouvelle astuce des entreprises pour nous faire bouger plus 😉

L’agilité, c’est avant tout un cadre pour les équipes, un cadre avec des valeurs qui permettront aux membres de l’équipe de gagner en efficacité dans l’environnement complexe du développement qui contient trop d’inconnues, ce qui nécessite alors une intelligence collective.

Pas d’inquiétude, nous allons voir tout cela ensemble. Le but de cet article n’est pas de paraphraser tous les articles de blog sur le sujet, mais plutôt de centraliser les différentes informations que j’ai pu récupérer jusqu’à présent avec leurs liens respectifs.

Les valeurs de l’agilité

L’agilité repose sur quatre valeurs disponibles ici.

L’agilité tend à privilégier :

• les individus et leurs interactions plus que les processus et les outils
  • le recueil du besoin métier devrait pouvoir se faire directement avec l’interlocuteur métier à l’origine du besoin
• des logiciels opérationnel plus qu’une documentation exhaustive
  • un logiciel intuitif et simple qui fonctionne correctement parlera de lui-même, la documentation attachée sera juste un appui supplémentaire pour l’utilisateur
• la collaboration avec les clients plus que la négociation contractuelle
• l’adaptation au changement plus que le suivi d’un plan
  • il arrive parfois qu’un besoin évolue en cours de route, plutôt que de finir de développer le besoin initial pour ensuite perdre du temps à le faire évoluer de nouveau, il est important de faire valoir sa capacité d’adaptation au nouveau besoin (dans la mesure du possible, toujours)

Il est important de noter que les premiers éléments sont privilégiés par rapport aux seconds, ce qui ne veut cependant pas dire que les seconds sont à négliger. L’agilité, c’est l’équilibre que l’équipe devra trouver entre la mise en application des premiers éléments tout en tenant compte des seconds.

Maintenant que ces bases sont posées, intéressons-nous au deux méthodes dont on parle le plus en agilité : la méthode Kanban et la méthode SCRUM.

Méthodologies agiles

Les rôles communs aux deux méthodes

• Scrum master : c’est le garant de la méthodologie au sein du projet. Sa position de Servant Leader fait de lui un super-héros de l’ombre qui va rester à l’affût de tous les besoins de l’équipe afin de lui assurer des performances et un environnement de travail optimaux.
• Product owner : c’est le garant du produit, le product owner va suivre les différents besoins du métier, arbitrer, décider, les affiner avec les développeurs, les décrire etc. Le tout afin que les développeurs n’aient plus qu’à développer le besoin.
• Dev team : développeurs, app builders, administrateurs, toute personne qui va transformer un ticket Jira/une demande métier en une fonctionnalité est appelé « Dev » en agilité
• (coach agile pour les débuts : si vous vous initiez à l’agilité, et si votre client/entreprise en a les moyens, il vous est possible de vous faire accompagner d’un coach agile au début afin qu’il/elle vous aide à mettre en place les cérémonies, et les bonnes pratiques de l’agilité etc.)

Méthode SCRUM

La méthode SCRUM se base sur l’empirisme, c’est à dire la capacité à apprendre en faisant des expériences et en testant de nouvelles choses.

Elle se base sur trois piliers :

• La transparence : donner à chaque personne le degré d’information suffisant pour pouvoir comprendre et prendre des décisions
• L’inspection du travail et de ses résultats
• L’adaptation

En SCRUM, on travaille par incréments :

• Une tâche est un incrément, c’est à dire une petite partie, d’une User Story
• Une User Story est un incrément, c’est à dire, une petite brique de la fonctionnalité finale demandée par le métier
• Les US sont stockées dans un backlog (la foire aux US) et une fois qu’elles sont prêtes à être développées (suffisamment mûres du point de vue du besoin et de la solution à apporter), elle vont être embarquée dans un Sprint
  • Chaque sprint va comprendre les cérémonies agiles suivantes qui vont permettre à la scrum team de respecter les trois piliers de la méthodologie :
    • Le daily team meeting : réunion quotidienne
    • Le sprint planning : qui marque le début du sprint
    • Le backlog refinement : qui permet aux US d’arriver à maturité
    • La sprint review et la rétrospectives qui marquent toutes deux la fin du sprint

Pour plus d’informations sur le SCRUM, je vous propose cet article qui met aussi à disposition un guide de démarrage.

Méthode Kanban

La méthode Kanban, elle, s’adapte plus aux projets qui délivrent en continu en environnement de production. Elle se base sur quatre principes et six pratiques :

• Principe n°1 : commencer par ce que l’on est en train de faire
• Principe n°2 : respect des rôles, fonctionnalités et processus actuels
• Principe n°3 : accepter d’opérer des changements petit à petit
• Principe n°4 : accepter les actes de leadership à tous les niveaux

Les pratiques :

• visualiser (célèbre tableau « to do », « in progress », « done »)
• privilégier un flux continu, limiter le nombre de tâches en cours, garder à l’oeil les tâches bloquantes
• travailler en flux tiré plutôt qu’en flux poussé (c’est le rythme de développement qui impose sa cadence et non pas le rythme des demandes)
• expliciter les règles de passage d’une colonne à l’autre du tableau
• amélioration continue (à travers les rétrospectives)
• amélioration collective

Le travail en Kanban va se faire en continu et non pas à travers les sprints que l’on retrouve en scrum. Les cérémonies seront les suivantes :

• le daily team meeting
• le backlog refinement qui se fera à fréquences régulières
• la rétrospective

Pour plus d’infos sur la méthode :

• Kanban – mieux le comprendre
• Un petit bouquin très bien expliqué : Kanban – l’approche en flux pour l’entreprise agile

To keep in mind

• Ce n’est pas parce qu’on fait des daily team meeting qu’on est agile 😩
• Ce ne sont pas les cérémonies agiles qui font l’agilité 👎
• L’agilité ne permet pas d’aller plus vite, elle permet de mieux faire 👏
• L’agilité est avant tout un mindset 💪