Cet article ne parle pas d’Agile.

Il parle d’avancer.

Et il parle d’un processus qui sert les objectifs business.

Ce ne sont que quelques mots, mais ils impliquent tellement de choses.

• Définir des objectifs S.M.A.R.T.
• Mettre en place et exécuter un plan pour atteindre ces objectifs
• Suivre les progrès
• Faire communiquer une équipe (avec des mots que tout le monde peut comprendre)

Il est tendance de parler d’Agile. Mais ce n’est pas si tendance de l’utiliser correctement, à bon escient.

Et il est aussi tendance, en réaction, de dire que l’Agile ne sert à rien.

Choisir la bonne méthodologie

Qu’on l’appelle un guide, un processus ou une méthodologie, ça revient toujours à la même chose :

• Planifier des étapes
• Exécuter les étapes
• Évaluer les résultats
• Recommencer

Toute méthodologie au monde, qu’il s’agisse du Waterfall, de l’Agile, d’une de ses nombreuses déclinaisons, ou de quoi que ce soit d’autre, en viendra à un moment ou à un autre à cela.

Je ne crois en aucune méthodologie écrite et acclamée par la foule, ou pas, qui soit parfaite. Toutes ont des défauts.

C’est à vous de trouver celle qui correspond le mieux à vos objectifs et de travailler sur les défauts pour qu’ils ne bloquent rien.

Comprendre votre contexte

L’essentiel, c’est votre contexte. Qu’est-ce que vous construisez ? Pour qui ? Comment est votre équipe ?

Peut-être avez-vous besoin du Waterfall, parce qu’il est excellent pour certains secteurs.

Peut-être avez-vous besoin de Scrum parce qu’il est excellent pour certains développements logiciels.

Peut-être avez-vous besoin de l’Extreme Programming.

Peut-être avez-vous besoin d’autre chose.

Start-up SaaS : ma recommandation

Mon opinion, basée sur mes expériences (succès et échecs inclus), est que Scrum apporte la meilleure solution, jusqu’à présent, dans un contexte de start-up SaaS :

• Produits en ligne (vendus comme service), impliquant :
  • Des objectifs de revenus et une certaine urgence
  • Des jalons fixés par vos objectifs de revenus, le marché et vos concurrents
• Équipe composée de personnes techniques et non techniques, impliquant le besoin d’une communication appropriée
  • Description des fonctionnalités de façon abstraite par rapport à l’implémentation technique
  • Métriques permettant de déclencher des alertes dès que possible, pour trouver des solutions dès que possible

Ce qui est formidable avec cette méthodologie, c’est qu’elle encourage l’approche top-down et une gestion lean de la roadmap.

On commence par décrire l’utilisateur et les problèmes qu’on cherche à résoudre, puis on descend vers les solutions possibles, on conçoit la solution préférée et on s’appuie enfin sur les atouts technologiques. À chaque étape, on a l’occasion de se demander :

• Est-ce que ça va vraiment résoudre le problème ?
• Cette fonctionnalité résout-elle directement le problème, ou apporte-t-elle juste plus de confort ?
• Est-ce que je ne suis pas en train de sur-concevoir la chose ?

Et ensuite décider de garder/supprimer.

La méthodologie que vous avez choisie est de toute façon la mauvaise

Si vous croyez que vous pouvez simplement suivre le manuel dès que vous avez choisi une méthodologie qui semble adaptée à votre contexte, vous avez tort.

Les méthodologies ne peuvent jamais s’adapter à tous les humains. Du moins pas à tous. Nous avons tous des cultures, des formations, des caractères différents, et il est pratiquement impossible de faire accepter à tout le monde une réponse universelle.

Sauf sur 42, bien sûr.

Sémantique

C’est le premier problème avec les méthodologies, quelles qu’elles soient. Elles utilisent des mots.

Un mot peut signifier quelque chose pour quelqu’un, et autre chose pour quelqu’un d’autre.

La première chose à faire, c’est de leur donner votre sens. Celui que toute votre équipe comprendra et utilisera. Et vous pouvez décider que Scrum s’appellera Pomme, les Sprints seront des bananes, etc.

N’hésitez pas à rédiger un dictionnaire interne que vous partagerez avec votre équipe.

Engagement

Waouh. Mot effrayant. Personne ne veut “s’engager”. Qu’est-ce que ça signifie ? Que je brûlerai en enfer si je ne livre pas ?

Je suppose que non. Pour moi, ça signifie “travail d’équipe pour avancer”. Il faut du travail d’équipe pour qu’une méthodologie fonctionne. Il faut du travail d’équipe pour sortir une fonctionnalité. Et potentiellement pour trouver des solutions alternatives ou des compromis.

Et si vous échouez, la seule chose qui vous restera sera le travail d’équipe pour comprendre pourquoi. Et le travail d’équipe pour ne pas échouer à nouveau pour les mêmes raisons.

Outils

J’adore Jira. Vraiment. Je devrais acheter des actions Atlassian. Du moins tant que je travaille dans un contexte où Scrum est la méthodologie la plus adaptée. Et je les revendrais dès la minute où je quitterais ce contexte.

Les outils sont là pour soutenir une méthodologie. Ils ne sont pas une méthodologie en soi. Quand vous allez faire vos courses, vous pouvez utiliser vos chaussures pour marcher jusqu’au supermarché le plus proche, ou votre ordinateur pour commander en ligne. Mais vous devrez quand même 1) vous demander ce dont vous avez besoin/ce qui vous manque 2) sélectionner les produits 3) passer en caisse.

Jira a des fonctionnalités intégrées qui facilitent la pratique de Scrum : gestion du backlog, versioning, tableaux, métriques, workflows. Bien sûr, il génère de la sérendipité. Vous n’êtes pas un pro Scrum ? Prenez une minute pour parcourir l’outil et mieux comprendre comment vous utilisez Scrum. Mais n’essayez pas d’apprendre les bases depuis lui, vous êtes sûr d’échouer.

Métriques

Ah, le burndown chart. La vélocité. Les points de complexité ! Quel ramassis de camelote ! C’est vrai : si vous n’avez pas accepté et compris la méthodologie et les outils.

Oui, ils arrivent en fin de chaîne alimentaire et sont les plus difficiles à digérer. Mais les utiliser correctement vous permet d’évaluer ce que vous avez fait et de comprendre où vous devez concentrer vos efforts. Que ce soit sur le développement de fonctionnalités ou sur l’adaptation du processus lui-même.

Il n’existe pas de mauvaises métriques. Il n’y a que des métriques que vous ne comprenez pas, ou des métriques qui ne servent pas vos objectifs. Celles définies dans une méthodologie sont là pour aider, donc votre meilleure option est d’essayer de comprendre comment les utiliser.

Réunions !

Attendez, non. Dans l’Agile, on les appelle rituels ou cérémonies. Les réunions, ça craint. Tout le monde les déteste. Les Français sont réputés dans le monde entier pour organiser des réunions inutiles avec une foule de participants qui n’ont même pas de partie prenante dans ce qui devrait être discuté.

Et oui, l’Agile recommande des réunions régulières. Mais elles ont un objectif commun, et chacune a un objectif spécifique.

L’objectif commun : avoir la bonne discussion au bon moment. Cela signifie que vous devriez pouvoir rationaliser votre approche top-down :

• Pas de discussions sur le développement quand on parle de specs
• Pas de discussions sur les specs quand on développe
• Garder toutes les plaintes pour la rétrospective
• S’assurer chaque jour que si vous avez un problème que vous ne pouvez pas résoudre seul, les personnes qui peuvent vous aider sont informées

Backlog refinement : C’est le moment où on ne parle que des spécifications fonctionnelles, des maquettes, et plus généralement des solutions au problème de l’utilisateur. C’est là où on challenge toutes les idées notées avant la réunion. C’est là où tous les membres de l’équipe comprennent les objectifs fixés pour une fonctionnalité spécifique et à quoi elle devrait ressembler.

Sprint Planning : L’heure de parler implémentation. Maintenant vous pouvez analyser les stories et discuter du fonctionnement technique.

Daily stand-up : Des problèmes ? Besoin d’aide ? C’est maintenant qu’on pose la question. Et la personne qui peut vous aider vous contactera juste après. C’est pourquoi ça doit se passer en début de journée, pour que la personne puisse réellement vous aider plutôt que de courir déjeuner.

Demo & Rétrospective : L’heure du bilan ! Comment avons-nous performé ? Qu’est-ce qui a mal marché ? C’est toujours agréable d’entendre qu’on est satisfait, mais c’est aussi le moment de dire qu’on ne l’est pas, et d’être constructif. L’objectif est de trouver des solutions.

Vous me direz : “Quel gaspillage de temps ! Quand est-ce qu’on développe vraiment ?”. Calculons. Le temps standard pour des sprints de 2 semaines sera de 2h + 2h + 10x5min + 2h = 6,8 heures. Moins d’une journée toutes les deux semaines pour que tout le monde soit au courant, s’accorde sur tout, partage les connaissances, résolve les problèmes quotidiens, évalue le travail accompli et donne un feedback sur le sprint précédent. Au moins maintenant vous pouvez mesurer ce temps, et même le réduire. Alors que sans discipline/méthodologie, il est facile de perdre plusieurs heures par jour dans des discussions interminables.

À propos du Manifeste Agile

Je ne l’avais pas lu. Et je ne pensais pas le lire. J’avais entendu qu’il était obsolète car écrit en 2001. Je suppose que c’est vrai. Mais ce que je sais, c’est que l’Agile, c’est ce que vous en faites. Tant que vous respectez quelques principes de base.

Ce que je sais, c’est que si vous échouez avec l’Agile, à condition que ce soit adapté à votre contexte, l’échec vient de vous, pas de la méthodologie. Vous avez réellement échoué à comprendre et à vous approprier un paradigme.

Si vous avez entendu parler d’un nouveau paradigme qui fonctionne mieux pour mon contexte, je serais ravi de l’entendre 😉

Image de une par Lynne Cazaly