Démarche pragmatique

L’agilité est venue en réaction aux processus standardisés issus de la division du travail, en proposant une façon de travailler basée sur l’auto-organisation, selon une démarche pragmatique.

Les problèmes liés aux processus standardisés

L’intention d’Adam Smith et de ses successeurs (Taylor, Ford) qui ont poursuivi la division du travail, c’est d’augmenter la productivité, en identifiant des tâches élémentaires pouvant être répétées.

La façon de travailler est codifiée dans un processus afin que le travailleur exécute ses tâches sans se poser de question. La standardisation des processus a fonctionné dans l’industrie, mais ce n’est plus adapté à notre monde incertain et, de plus, pas du tout adapté au domaine de la connaissance.

Les travailleurs subissent ces processus imposés de l’extérieur ; cela provoque des problèmes. Voici quatre exemples avec les substitutions apportées par l’agilité.

La bureaucratie

La division du travail s’affirme par les processus et s’accompagne d’une augmentation de la bureaucratie, avec des règles, des documents pour les décrire et des rapports pour vérifier leur application.

Contre la bureaucratie, l’agilité propose des conversations directes. L’équipe discute et choisit la meilleure façon de répondre à une demande. La production de documentation inutile est évitée. Ces conversations sont facilitées par :

• La co-localisation. Plutôt que de s’adresser à une machine (un écran), on va parler de son problème à quelqu’un en face à face.
• Les rites réguliers. Ils permettent de discuter directement avec les bonnes personnes.

Lire un exemple de conversation pour affiner une story.

Le morcellement des tâches

Quand il effectue une petite tâche, le travailleur n’est plus en mesure d’appréhender l’ensemble du travail, il perd la notion de sa finalité.

Contre cette perte d’initiative, l’agilité encourage à travailler sur un élément qui apporte de la valeur.

• Une user story est typiquement l’élément sur lequel une personne travaille. Cet élément possède une finalité pour les utilisateurs qui est perçue par le travailleur.
• De plus, on travaille à plusieurs sur cet élément. Sur une story, le développeur et le testeur coopèrent jusqu’à la finir.

Lire l’article sur les catégories de story.

L’outillage lourd

La transition numérique — à la différence de la transition écologique ou de la transition agile — a abouti. La crise du COVID a amplifié la numérisation.

La numérisation, du point de vue technique, passe par des outils. Ces outils ont été mis en place, sans que leurs usages soient toujours bien justifiés, à part aider à la standardisation des processus (critiquée plus haut).

L’agilité promeut les outils low tech :

• Le post-it a été longtemps l’emblème d’une équipe agile.
• Au-delà du simple usage du post-it, le management visuel a fait ses preuves de pratique qui apporte des bénéfices. Plutôt que de remplir un formulaire, la personne qui finit un travail fait glisser le post-it dans la colonne de droite.

De plus, l’équipe elle-même choisit les outils dont elle a besoin en les expérimentant.

Lire l’article L’agilité, un outil convivial.

Le carcan du processus

Quand le processus standardisé est codifié dans un outil, celui-ci décline ce processus et n’autorise rien d’autre. L’outil ne discute pas des situations non standards qui surviennent pourtant dans la réalité.

En suivant le processus qu’on lui impose, le travailleur va perdre l’initiative que lui permettait son savoir-faire.

L’agilité favorise les expérimentations et donne le droit à l’erreur.

Suivre une démarche pragmatique

Dans le travail de la connaissance et des services, la standardisation est contre-productive, car, contrairement à la production de masse, les façons de faire ne sont pas les mêmes d’un contexte à un autre.

Au début des années 2000, l’agilité est arrivée en réponse aux processus lourds (hérités du taylorisme et ses avatars). Cela se concrétise en une façon de travailler différente, moins linéaire, moins répétitive, tenant compte de la situation et surtout toujours en mouvement.

C’est le pragmatisme, plus que l’empirisme, qui définit le mieux cette approche.

Le pragmatisme s’intéresse en premier au résultat, aux conséquences de ses actions pour les utilisateurs, et pas au suivi d’un processus pensé par un expert.

Cependant, le pragmatisme mal compris présente des écueils quand on le décline pour l’agilité.

Bonnes pratiques

Voulant expérimenter rapidement, on prend de l’agilité ce qu’on croit en être les bonnes pratiques sans maîtriser les fondamentaux.

Ça fait des années (voir cet article Non aux bonnes pratiques) qu’on proclame que cette idée de ne garder que les bonnes pratiques est dangereuse.

Solution expéditive

Sous prétexte de pragmatisme on privilégie l’efficacité à court terme sans prendre le temps de la réflexion qui permet de définir l’objectif d’une expérimentation.

À rebours de cette solution expéditive, une itération possède un objectif pour évaluer le résultat obtenu et intégrer le feedback.

Oubli des conséquences

Le travail de l’équipe porte parfois (comme quand elle développe un service pour la transition numérique) sur l’automatisation d’un processus pour des utilisateurs. Il est probable que de nombreux projets de transition numérique soient développés par une équipe qui se réclame de l’agilité. Dans ce cas, les coéquipiers peuvent influencer le résultat donné aux utilisateurs. Ce serait paradoxal qu’une équipe qui suit une démarche pragmatique pour elle impose un processus standardisé à d’autres.

Pour une équipe agile, la congruence s’opère dans les principes fondamentaux des boucles de feedback (orientées utilisateurs) et de sobriété (intégrant de la réflexion sur la valeur du résultat).