A l’origine des méthodes agiles il y a les 12 principes. Que vous travailliez en méthode Scrum, Kanban ou autre, il est important de ne pas les perdre de vue. Trop souvent on croit travailler en mode agile parce que l’on utilise quelques éléments de la méthode Scrum alors qu’il n’en est rien. C’est pourquoi il est parfois bon de revenir aux 12 principes, eux seuls garantissent l’agilité de votre méthode. Nous vous proposons dans cet article de les passer en revue et de les détailler.

1. Prioriser la satisfaction du client

Ceci est le principe le plus important des méthodes agiles. Cela peut paraître évident mais ça ne l’est pas forcément. En effet, pour savoir si le client est satisfait il faut savoir l’impliquer dans le processus de développement, parce qu’après tout, dans un cycle en V de deux ans on cherche aussi à satisfaire un client, mais il n’est pas ou peu impliqué.

Travailler en cycles courts ne suffit pas, même si vous avez désigné un Product Owner en interne pour valider les livraisons. Si ce n’est pas le client ou l’utilisateur final, cela ne fonctionnera pas.

2. Accepter les changements

Ce principe est la définition même de l’agilité. Allégez les phases amont de conception et de définition du besoin, ceux-ci évolueront de toute façon au cours du projet, et organisez-vous pour accepter les changements sans que ce ne soit la panique à bord. Cela ne veut pas dire que l’on doive tout bouleverser à la moindre demande. Chaque imprévu doit être traité comme n’importe quelle autre fonctionnalité : on l’analyse, la chiffre, la priorise.

3. Livrer en permanence des versions opérationnelles de l’application

Découper le cycle de développement en sprints ne suffit pas, il faut que chaque sprint soit couronné d’une ou plusieurs livraisons de features fonctionnelles. S’il vous faut plusieurs sprints pour faire une livraison valide, allongez la durée de vos sprints. Si au contraire pendant un sprint vous avez fait 15 mises en production et couvert 3 sujets, raccourcissez-les. Dans le premier cas le client croira que vous avez du retard, dans le deuxième il sera débordé par la quantité de fonctionnalités à valider.

4. Assurer le plus souvent possible une coopération entre l’équipe du projet et les gens du métier

Parlez-vous ! Oubliez les mails froids du type « Voici les specs pour le prochain sprint, on se revoit dans deux semaines ». Ou le développeur qui dit à la fin du sprint « On a pas corrigé ce bug parce qu’on n’a pas réussi à la reproduire ». Echangez, clarifiez, demandez…

L’agencement des espaces de travail peut aider grandement quand métier et développement sont dans la même entreprise. Au lieu de regrouper tous les développeurs au même endroit (alors qu’ils ne travaillent pas forcément sur la même chose) et les gens du métier ailleurs, rassemblez les personnes en fonction des projets. Il faut toutefois éviter l’effet inverse : l’utilisateur qui va interpeller à tout bout de champ le premier développeur qu’il trouve pour lui remonter un bug ou faire une suggestion. Canalisez-les vers le Product Owner, il est là pour ça.

5. Construire les projets autour de personnes motivées

Une équipe agile doit être motivée pour réussir. Si c’est une erreur de considérer les gens comme des ressources interchangeables, c’est d’autant plus vrai en méthode agile. En effet, une équipe agile a besoin de temps pour se « rôder ». En Scrum par exemple, les tâches sont chiffrées en points qui ne correspondent à aucune valeur. Il faut quelques sprints pour que l’équipe arrive à déterminer combien de points elle est capable de produire, parce que les membres apprennent à se connaître, apprennent des erreurs et des succès des sprints précédents. Transférer les membres d’une équipe à l’autre brutalement peut casser cet équilibre.

Lire aussi | La méthodologie Scrum : comment s’y prendre ?

6. Favoriser le dialogue direct

Parlez-vous ! Privilégiez l’oral, et limitez autant que possible l’écrit aux équipes éclatées géographiquement. Il n’y a rien de plus frustrant que de voir deux personnes dans la même pièce qui communiquent par Skype/Slack (sauf si c’est pour demander « Je peux venir te parler ?»).

7. Mesurer l’avancement du projet en fonction de l’opérationnalité du produit

Avec des méthodes telles que Scrum il est très facile de tout mesurer, de tout KPIser : points, burn-up/burn-down charts… C’est bien de produire de nombreux points mais cela ne suffit pas si ceux-ci reviennent sous la forme de bugs dans un ou deux sprints. Le but de chaque itération est de produire du logiciel qui fonctionne, idéalement dans les temps estimés, c’est la meilleure façon d’évaluer la performance d’une équipe.

8. Adopter un rythme constant et soutenable par tous les intervenants du projet

Si les méthodes agiles doivent vous faire tendre vers une plus grande adaptabilité, elles ne sont pas synonymes de chaos pour autant. Etre agile, ce n’est pas tout interrompre suite à une demande du client, faire travailler l’équipe toute la nuit et se féliciter ensuite d’avoir été réactif, c’est même tout le contraire ! Si une demande de changement doit provoquer de la friction et amener l’équipe à l’épuisement, c’est justement le signe que vous n’êtes pas agile. N’oubliez pas également que le client/Product Owner fait partie de l’équipe : produire des quantités de fonctionnalités que le PO n’a pas le temps de valider n’est pas un rythme soutenable.

9. Contrôler continuellement l’excellence de la conception et la bonne qualité technique

Agile ne doit pas vous faire abandonner la conception, sinon vous allez essayer d’assembler des bouts de code produits par différentes personnes et espérer que tout fonctionne. Ce qui est à bannir, c’est la phase de conception sur toutes les fonctionnalités du projet en amont. En tant que Scrum Master, demandez à vos équipes de faire de la conception avant de coder. En tant que Product Owner, demandez leurs d’écrire des specs détaillées pour s’assurer que l’histoire a été comprise. Le but n’est pas de produire de la documentation, cela peut être une liste dans un mail, un bout de pseudo-code ou même une discussion. Si vous travaillez en Scrum ou en Kanban, vous pouvez rajouter une colonne Conception sur le tableau, entre To Do et On Going. Toutes les cartes ne seront pas concernées. Un bug qui se corrige en une heure n’en aura pas forcément besoin tandis qu’une carte qui prendra une journée et plus devrait passer systématiquement par de la conception.

10. Privilégier la simplicité en évitant le travail inutile

Simplifiez au maximum. Si le projet ressemble à une montagne insurmontable, ne visez pas la fin mais seulement la première étape. Au besoin, divisez chaque étape autant qu’il le faudra pour que chaque tâche, chaque histoire paraisse simple.

11. Auto-organiser et responsabiliser les équipes

Vous aurez beau avoir les meilleurs talents, une équipe travaillant sous la contrainte sera toujours moins performante, laissez-les s’auto-organiser. Les personnes qui travaillent vers un but commun parce qu’elles le veulent seront toujours plus efficaces et plus fiables que des équipes travaillant ensemble parce qu’on leur a dit de le faire.

12. Améliorer régulièrement l’efficacité de l’équipe en ajustant son comportement

L’amélioration continue est un principe que l’on doit garder en tête quand on travaille en méthode agile. Pourtant, la rétrospective est généralement la réunion qui passe à la trappe : c’est à la fin du sprint, souvent le vendredi, les gens sont fatigués, n’en voient pas l’utilité… C’est une erreur car il n’est pas possible de s’améliorer en arrière. Ne négligez pas ce moment-là, c’est peut-être le plus enrichissant pour vos équipes.

Nous venons de voir pourquoi il est important d’avoir ces principes toujours à l’esprit, ils vous permettent de garantir l’agilité de vos équipes quelle que soit la méthode que vous employez. De plus, grâce à ces fondamentaux, vous pouvez même implémenter votre propre méthode agile !

Besoin d’un conseil en développement avec les Méthodologies Agiles ?

Conscients des changements à appliquer, SoftFluent vous accompagne dans la mise en oeuvre des méthodologie agiles et notamment de la méthodologie SCRUM.

Avec l’appui des logiciels du marché tels que VSTS ou TFS, nous vous proposons une méthodologie adaptée et vous accompagnons dans la mise en œuvre et dans la phase de transition, à la fois à l’aide d’experts méthodologiques, notamment des Scrum Master mais aussi des développeurs qui ont fait de l’Agilité une expertise.