Quel gâchis !

Lorsqu’une organisation tente d’appliquer des concepts de leadership conçus pour des environnements simples et prévisibles à un environnement Agile, cela génère beaucoup de gaspillage, sans parler de la frustration, des opportunités manquées et de l’échec de l’adoption d’Agile.

Dans cet article, nous examinerons 3 concepts qui fonctionnent mieux pour résoudre des problèmes commerciaux simples, mais qui sont moins efficaces dans un environnement Agile.

Utilisation

L’idée de maintenir les personnes et les ressources occupées pour réduire le gaspillage semble logique, mais elle se retourne contre soi dans des environnements complexes. Insister excessivement sur l’utilisation peut engendrer des inefficacités.

Imaginez une équipe de 30 personnes divisée en trois groupes spécialisés : les chargeurs de données, les processeurs et les créateurs de factures. Pour garder chaque groupe occupé, le Product Owner veille à ce que leurs flux de travail spécialisés soient constamment remplis. Cependant, cette attention portée à maximiser l’activité détourne l’attention de la livraison des travaux les plus prioritaires. La flexibilité et la polyvalence – plutôt que la spécialisation rigide – sont essentielles pour répondre à ce qui compte le plus pour les clients.

Cette approche entre également en conflit avec la loi de Conway, qui stipule que la conception des systèmes reflète les structures organisationnelles. Par exemple, si quatre équipes construisent un compilateur, le résultat sera un compilateur à quatre passes — un résultat dicté par leurs flux de travail divisés plutôt que par les besoins des clients.

Vélocité

Lorsque nous parlons de vélocité et d’Agile, ce que nous évoquons réellement, c’est le nombre de « points » de travail livrés par Sprint. Ce qui signifie que la vélocité n’est pas un concept utilisé dans les approches de gestion traditionnelles. Alors, pourquoi en parler dans cet article ?

Je mentionne cela parce que, dès qu’un manager découvre le concept de vélocité, il essaie souvent de l’utiliser comme un outil pour rendre les membres de l’équipe responsables. Et je comprends tout à fait pourquoi. Lorsque nous expliquons la vélocité à quelqu’un qui découvre le concept, on a fréquemment tendance à dire quelque chose comme « c’est une mesure de ce qui peut être livré par Sprint », ce qui est en grande partie vrai, mais ce n’est pas toute la vérité. La vélocité est spécifique à une équipe. Elle est utilisée uniquement à des fins de planification, car la vélocité n’est pas nécessairement équivalente à la valeur.

Voici pourquoi. Les équipes Scrum qui utilisent la vélocité à des fins de planification choisissent généralement un système de points de quelque sorte. Par exemple, elles peuvent utiliser une échelle simple de 1 à 5, ou elles peuvent utiliser la série de Fibonacci. Elles prennent la décision que certains types d’éléments du Product Backlog valent un point, d’autres en valent deux, et ainsi de suite. Chaque élément qui est intégré dans un Sprint se voit attribuer une valeur en points en fonction de l’effort, de la complexité et de l’incertitude. Chaque élément terminé lors d’un Sprint est additionné pour déterminer la vélocité de ce Sprint. Au fil du temps, l’équipe Scrum apprend les valeurs totales en points qu’elle termine habituellement à chaque Sprint.

La vélocité ne peut pas être comparée entre deux équipes Scrum, car ce qui vaut un point pour une équipe peut se voir attribuer une valeur différente pour une autre équipe. Les équipes peuvent également avoir des niveaux de compétences différents et des objectifs différents.

Non seulement cela, mais même lorsqu’on observe la même équipe au fil du temps, une vélocité plus élevée ne correspond pas nécessairement à une valeur plus élevée livrée. Il se peut que l’équipe ait surestimé le travail, ou peut-être que le travail livré n’a pas réellement amélioré les résultats pour les clients.

Validation des exigences

Les validations sont souvent utilisées comme un mécanisme de contrôle pour limiter les changements. La logique semble raisonnable : figer les exigences pour éviter les perturbations plus tard. Mais les équipes Agile accueillent le changement, même tardivement dans le développement. En fait, c’est l’un des principes fondamentaux de l’Agile. C’est pourquoi Scrum utilise un Product Backlog plutôt qu’un document d’exigences statique.

Le Product Backlog est dynamique. Il évolue à mesure que nous en apprenons davantage sur ce que le produit doit livrer pour créer de la valeur. Le Product Owner met à jour et réorganise en continu le Product Backlog en fonction des retours clients, des commentaires des parties prenantes et des évolutions du marché. Contrairement à un document d’exigences, qui nécessite des signatures pour officialiser les modifications, le Product Backlog ne nécessite aucune validation formelle. Le Product Owner a le dernier mot sur son contenu et ses priorités.

Cette flexibilité est cruciale dans des environnements complexes. Imaginez une équipe travaillant avec un document d’exigences figé. Lorsque de nouvelles informations apparaissent — que ce soit une initiative concurrente, un changement réglementaire ou des retours clients inattendus — l’équipe se retrouve avec deux options : rester avec des exigences obsolètes ou passer par un processus de validation lourd pour apporter des modifications. Dans les deux cas, des opportunités sont perdues, et la capacité de l’équipe à livrer de la valeur est compromise.

Les validations peuvent également créer des tensions et des retards. Lorsqu’il faut l’accord de plusieurs parties prenantes avant de pouvoir avancer, des désaccords surviennent souvent, ralentissant ainsi le progrès. En revanche, l’Agile donne au Product Owner le pouvoir d’agir en tant qu’autorité unique pour le Product Backlog, permettant ainsi des ajustements rapides qui maintiennent l’équipe alignée sur la livraison de la valeur la plus importante.

Cette approche peut sembler risquée pour ceux qui sont habitués à des contrôles rigides, mais c’est en réalité le contraire. En éliminant les goulots d’étranglement bureaucratiques, les équipes Agile restent agiles, réduisent le gaspillage et se concentrent sur la livraison des résultats qui comptent pour les clients. Les validations peuvent fonctionner dans des environnements simples avec des résultats prévisibles, mais en Agile, elles sont davantage un obstacle qu’une aide.

Conclusion

Dans les environnements Agile, le succès dépend de l’adaptabilité, de la priorisation et de la focalisation sur les résultats plutôt que sur des métriques obsolètes ou des processus rigides. En repensant des concepts traditionnels tels que l’utilisation, la vélocité et les validations, les organisations peuvent éviter le gaspillage et réaliser pleinement la valeur de l’Agile.