Décentraliser la prise de décision

Description

La validation des décisions par la hiérarchie introduit des temps d'attente préjudiciables à la fluidité de la production, et l'utilisation de l'escalade diminue la qualité de la prise de décision en raison de la perte de contexte et des changements potentiels inhérents aux temps d'attente [SAFe 2021-9].

C'est pourquoi l'agilité propose une décentralisation de la prise de décision en fonction du contexte.

Le principe de base est celui de la subsidiarité, qui implique que chacun peut faire ce qu'il veut, sauf s'il est démontré que la décision de rang supérieur est plus efficace [Delavallée 2011].

Dans cette ligne, SAFe propose de tout décentraliser sauf quand [SAFe 2021-9].

• cela arrive rarement
• la décision n'est pas susceptible de changer à court terme
• des économies peuvent être réalisées avec un facteur d'échelle

L'organisation centrée sur le client va s'organiser pour créer de la valeur ajoutée et la hiérarchie, créée par le besoin de rationalisation de l'organisation, et les deux modes d'organisation entrent généralement en conflit mais la hiérarchie gagne toujours [SAFe 2021-17]. Ce principe de décentralisation permet une sorte de juste milieu entre ces deux organisations.

Ainsi, le Management 3.0 intègre la dimension hiérarchique nécessaire à l'entreprise, notamment sur les aspects liés aux autorisations [Appelo 2010]. Il prévoit un atelier appelé "Poker de la délégation" [Appelo 2014], qui permet de définir le niveau de délégation attendu entre "Tu fais exactement ce que je te dis" et "Je te délègue complètement" pour chaque type d'action.

Application à la maturité des tests

Lorsqu'une stratégie de test a été décidée par un Test Manager ou est définie trop longtemps à l'avance, seules les personnes confrontées au contexte réel du produit à tester sont les plus à même de décider de la meilleure approche à adopter sur le terrain, que ce soit en termes d'outils ou de manière d'aborder le test, sauf si les critères de délégation prédéfinis sont violés.

Par exemple, dans une équipe Scrum, le testeur doit se synchroniser avec le Product Owner (PO) pour que le PO décide de la valeur ajoutée d'un choix sur le temps alloué aux tests car les règles de Scrum indiquent que le PO est responsable du retour sur investissement [Schwaber 2020]. En d'autres termes, Scrum introduit une gouvernance sur ce qui est délégable et ce qui ne l'est pas, le PO estime la valeur ajoutée de l'activité de test sur la base de conseils avisés tandis que le testeur définit l'approche qui lui semble la plus pertinente en fonction du temps alloué ; cette politique est similaire sur la part allouée au refactoring dans le Sprint. A cet égard, l'approche SRE, vision de Google du DevOps, propose la gestion d'un budget d'erreur qui est géré par le PO [Beyer 2016].

La position d'Agilitest sur cette pratique

Agilitest propose un outil d'automatisation des scripts de test. Le choix d'adopter agilitest ou un autre framework peut être vu sous l'angle de la subsidiarité car, selon les profils et les besoins, agilitest peut être adapté (notamment dans le cas de testeurs ayant une formation non technique) ou inadapté (dans le cas d'équipes de développeurs qui préfèrent gérer l'automatisation des tests tout en restant dans leur IDE préféré).

Il n'est pas rare qu'une organisation veuille adopter le même outil pour toute l'entreprise afin de massifier les achats et de bénéficier de prix plus bas ; cependant, les coûts de licence associés à Agilitest ne représentent que quelques jours du temps d'un ingénieur et le gain de la réduction commerciale ne compense pas vraiment les pertes dues à la démotivation d'une équipe productive.

‍

Pour découvrir l'ensemble des pratiques, cliquez ici.

‍