Ça veut dire quoi être agile ? Non, mais vraiment. Avec des mots simples.
Si vous lisez un peu les articles sur les sites Tech ou rien qu’un détour par LinkedIn, vous tomberez très sûrement sur le magique « Agile ».
Derrière un concept pas si permissif que cela se cache une méthodologie intéressante de la relation entre l’individu et son travail.
Inutile de préciser que je n’ai pas l’ambition d’expliquer avec mes mots la théorie, je vais plutôt me concentrer sur la pratique.
Pour bien saisir les possibilités de l’agilité, il faut se concentrer sur les savoir-être et non les savoir-faire.
Quelques grandes règles sont donc immuables :
- Laissez vos équipes décider de la façon dont elles souhaitent travailler (et non pas la tendance du « on a toujours fait comme ça »)
- Délivrez de la valeur, pas juste un produit / service
- Communiquez, toujours et à n’importe quel stade (en positif comme en négatif)
- Gardez sous le coude ceux qui décident, les choix doivent être faits rapidement et efficacement avec la bonne information
- Laissez vos équipes décider des prochaines tâches, de choisir ce qui fait le plus sens (et non pas votre feuille de suivi de projet idéalisé)
Ce qui est souvent un peu frustrant avec cette appellation « Agile », c’est surtout le fait d’empêcher les collaborateurs de travailler comme ils le veulent. Ce qui marche pour équipe n’est pas forcément vrai pour une autre.
Il existe bien évidemment de grands préceptes qui fonctionneront à chaque fois. Cependant ils restent bien rares et sont plutôt génériques malheureusement. Votre produit est unique, votre service est unique. Enfin non, ça, c’est générique. Ce qui est unique est la force ainsi que votre vision de ces deux composantes.
Ce qui sera réaliste d’un côté deviendra utopiste de l’autre si la vision ne coïncide pas avec les moyens nécessaires. Vous aurez beau mettre plein d’Agile, de Scrum et de Kanban dedans, ça ne marchera pas forcément. L’apprentissage de l’autre est long et doit passer par des phases d’échecs avant d’atteindre les petits succès.
Toutefois, si on reprend les gros incontournables de la méthode, on peut parler assez facilement des stands ups, du planning et de la rétrospective.
Stand ups
C’est un principe de communication rapide entre personnes d’une équipe. Pas une réunion. Il s’agit de faire le point sur ce qui est fait, à faire et ce qui reste à arbitrer. Ces moments peuvent être faits par jour, par semaine, par sprint, par version d’application … Le tout est qu’ils soient réguliers et utiles.
Il y a trois choses à faire pour chaque stand up :
- Un rapide débrief de la situation globale, ce qui est en cours et le temps nécessaire pour aller à la tâche suivante. La vue globale !
- Ce qui est entrain d’être fait par le collaborateur et qui est important d’être fait juste ensuite. Les priorités !
- Ce qui est bloquant et ce qui pourrait être une aide pour résoudre ce point de frustration. Les solutions !
Il y a plusieurs façons de voir les moments d’échanges, mais ce qui marche le mieux est de suivre la roadmap visuelle et de pointer du doigt les avancées et les implications de celles-ci.
Planning
Il s’agit d’une étape indispensable pour bien prévoir la prochaine itération. Et de prévoir ce qui sera fait à la prochaine itération. Il est fortement recommandé d’arriver à avoir une vue sur les prochaines nécessités de l’équipe et de mettre ceci en liaison avec les livraisons attendues. En gros, les stories dont tout le monde parle sont alors vraiment utiles.
Le planning permet de savoir si l’on peut se permettre de déployer ou non une itération.
Retrospective
Pour cette étape, on parle souvent de revue de la dernière itération réalisée. Ce qui se concrétise par :
- La valeur de ce que l’on a délivré. Le truc cool !
- La revue de ce que l’on n’a pas réussi à délivrer. Le pas cool !
- L’explication de ce qui a bloqué notre chemin parfait. Le grand méchant !