Cet article est la cinquième partie d’une série sur : La fin du monde Agile n’est pas arrivée. Lisez la partie 4 ici.

S’adapter au changement plutôt que suivre un plan. Probablement l’une des valeurs agiles les plus difficiles à appliquer.

La première réaction quand la panique frappe à la porte, parce que vos délais approchent, parce que le travail d’équipe a été chaotique ces dernières semaines, ou parce que les managers ne comprennent pas pourquoi leur équipe est si lente et coûteuse par rapport aux résultats attendus, c’est de construire un plan. Et un plan de contingence. Et un plan de contingence B. Et de les construire dans un beau style de rétro-planning.

Les plans nous rassurent.

Je sais de quoi je parle : je suis un homme Produit. J’ai une expérience en gestion de projet. Je suis celui qui écrit les roadmaps. Vous savez, ces beaux trucs qui ressemblent à des diagrammes de Gantt et font croire que la voie est tracée pour les 5 prochaines années. Je peux même les rendre jolis, avec de belles couleurs, des icônes et des polices. Et j’aime les règles qui mettent un peu d’ordre là où règne le chaos.

Mais vous savez quoi ? Je suis de la génération du film Matrix. Et il y a une chose que j’ai apprise de Morpheus :

Ce que vous devez apprendre, c’est que ces règles ne sont pas différentes de celles d’un système informatique. Certaines peuvent être contournées. D’autres peuvent être brisées.

Remettre en question votre roadmap

Je crois fermement que les plans devraient être rédigés, car leur bénéfice direct est la communication au sein de l’équipe. Et mieux vaut une courte histoire qu’une longue, sur papier, rappelons-le ?

Mais je suis aussi bien conscient qu’il est impossible d’écrire un plan qui sera exécuté dans son intégralité, tel qu’il a été écrit le premier jour. Surtout dans le contexte actuel du développement logiciel. Les forces internes comme externes feront tout ce qu’elles peuvent pour torpiller votre roadmap. Quelques exemples :

• Nouvelles demandes de fonctionnalités clients avec une ultra haute priorité
• Un développeur qui quitte l’entreprise (maladie, vacances, ou même démission), emportant avec lui des connaissances cruciales et uniques
• Un bug plante votre produit / un service tiers ne livre pas, tuant votre service / un serveur tombe
• La réalité qui rattrape votre rétro-planning
• Nouvel investisseur à bord

Beaucoup d’événements imprévus qui impacteront directement votre capacité à livrer.

Ce que cette valeur agile nous dit, ici encore, n’est pas que les plans ne devraient pas être écrits. Elle nous dit qu’ils devraient être flexibles.

Ils devraient être un guide, à revoir régulièrement. En d’autres termes : une roadmap est un organisme vivant.

Remettre en question votre organisation

Et il en va de même pour toute l’organisation.

Des concepts comme l’intégration continue, l’automatisation des tests logiciels et les releases quotidiennes commencent à devenir tendance dans les entreprises tech, car ils favorisent la capacité à livrer du logiciel régulièrement et rapidement. Mais ce n’est que du logiciel. Les humains le gouvernent. Et les humains doivent être prêts à accepter qu’un planning change d’une semaine à l’autre. Qu’une fonctionnalité qui était autrefois vue comme révolutionnaire doit maintenant être abandonnée parce qu’elle est inexacte ou dépassée. Tant que cela répond à un changement dans la façon de livrer de la valeur au client.

J’ai déjà écrit que je suis pour avoir des rôles et responsabilités clairement définis.

Ce pour quoi je suis encore plus favorable, c’est d’évaluer régulièrement l’efficacité de l’organisation. Est-ce que les rôles et responsabilités actuels, les outils et les processus, aident à atteindre nos objectifs ? En faisons-nous bon usage ? Devraient-ils être modifiés ? Ou simplement améliorés ?

Oui, certains changements de processus et d’outils, voire de personnel, peuvent s’avérer coûteux. Il est même possible de calculer ce coût, la plupart du temps. Mais là où il est pratiquement impossible de calculer le coût de ne pas changer, il sera souvent bien plus élevé, car vous échouerez à atteindre vos objectifs.

Déléguer les responsabilités à l’échelon le plus bas possible

Plus avant dans les organisations, nous avons longtemps souffert d’un défaut. Commandement et contrôle. Hiérarchies. Chaînes de commandement interminables.

Je suis un homme heureux, vous savez. Étant dans une petite entreprise, ça n’existe pratiquement pas. Mais j’ai eu quelques expériences où moi, ou mes collègues, attendions l’approbation d’un “N+3”/“N+4” pour un projet qui aurait dû démarrer il y a 2 jours. Vous savez, ces personnes dont l’agenda est rempli 3 mois à l’avance et qui ne s’en sortiront jamais, entre deux avions ?

S’adapter au changement requiert d’être flexible. Et il est impossible d’être flexible quand quelques personnes sont des goulots d’étranglement par lesquels vous devez passer à chaque fois que vous voulez faire quelque chose.

Il y a un sérieux besoin de délégation, à l’échelon le plus bas possible.

Peur de responsabiliser un jeune ? Vous êtes-vous déjà demandé si certains de ces jeunes étaient en réalité meilleurs que vous dans ce que vous faites ? Oh, c’est peut-être pour ça que vous ne voulez pas les responsabiliser. Et peut-être que c’est votre plus grande erreur : 1) ça ne sert pas votre organisation 2) déléguer des responsabilités vous libérera pour vous concentrer sur des sujets plus stratégiques, ou pour recruter davantage de personnes et les soutenir dans des responsabilités que vous leur déléguerez. Qu’est-ce que ça fait de vous ? Vous n’êtes plus le gars avec le fouet. Vous êtes le gars avec la carotte. Oui, vous êtes toujours le manager, mais d’une façon bien plus positive. Vous êtes un coach, et les gens vous apprécieront pour ça.

Peur que le jeune soit mauvais dans le boulot ? Eh bien, soit vous n’avez pas trouvé la bonne tâche pour lui, soit il ne correspond peut-être tout simplement pas à votre organisation. Et le pousser un peu vous permettra de le découvrir. Dans tous les cas : 1) il pourrait être bien plus motivé et efficace une fois que vous trouvez la bonne place pour lui 2) il ne se laissera pas moisir quelque part.

Cet article sur la dernière valeur agile étant écrit, je suis plus que jamais convaincu que l’agile est loin d’être mort. Un ami à moi, qui n’est pas impliqué dans le développement logiciel ou l’ingénierie, a lu la série et m’a dit : “Eh bien, je ne vois que du bon sens ici. Rien de bien compliqué, pourquoi est-ce si difficile à comprendre dans votre secteur !?” Je ne pourrais pas être plus d’accord. Oui, c’est extrêmement difficile de sortir de notre ancien paradigme de commandement et contrôle et des méthodes en cascade. Mais sortir de notre zone de confort nous place à la pointe. Et la plupart des organisations qui disent que l’agile est mauvais/mort/ne répond pas à leur situation spécifique sont probablement passées complètement à côté de ce dont il est fait.

Réveille-toi, Néo.

Image de une par Sergiu Bacioiu