C'est intéressant de rappeler d'ou viennent les mots, le contrôle, viens des doubles rouleaux sur lesquels on inscrivait les comptes pour éviter qu'ils soient falsifiés, bref quelque chose de plutôt utile.

Dans l'agilité, j'entend souvent le discours théorique "le contrôle c'est pas bien", dans les faits, le contrôle est omniprésent.

Dans l'ingénierie, grâce aux tests et à leurs automatisation, on contrôle en permanence si le code produit bien les modifications de données prévues.

Mais dans les rapports humain on ne pas peut pas vraiment contrôler quelqu'un, on peut lui donner des ordres, vérifier la bonne exécution de son travail (ça reviens à contrôler les résultats, ce qu'industrialise l'agilité), on peut contrôler la manière d'obtenir les résultats demandés (les critères de qualité de code dans la définition de terminée) à la rigueur on peut contrôler l'identité de quelqu'un...

Par contre si on introduit la notion de rôle (c'est amusant, le monde est petit, "rôle" vient de "feuilles roulées portant un écrit"), pour récemment avoir le sens de "système d'obligation et de droits déterminant l'ensemble des comportements d'une personne légitimement attendus par les autres".

Et là on peut contrôler la personne au travers de ses comportements, on lui dit quels comportements il doit adopter et on vérifie si le rôle est bien joué...

Alors que l'on pourrait plus simplement parler de positionnement et contrôler les résultats obtenus (ce que fait naturellement l'agilité avec les tests). Et je trouve que c'est beaucoup plus simple d'expliquer à un chef de projet qu'avec l'agilité (via Scrum), son positionnement c'est d'être au service de la relation entre le client et les développeurs, de fixer les attentes et les engagements de chaque parties (ce que fait naturellement un contrat de coaching), plutôt que de parler de "rôle de Scrum Master".

Ca serait se focaliser sur l'état d'esprit, et de proposer une forme qui ne sera pas tout le temps la même, ça serait comme faire de l'accompagnement "à façon", un peu comme faire un logiciel "à façon" au lieu de "passer l'entreprise à un ERP", un concept révolutionnaire dans l'agilité :)

Ce qui me surprend toujours c'est l'ambivalence du discours institutionnel Agile vis à vis du contrôle, l'Agiliste ajoute généralement une couche de contrôle trop importante, dit que c'est pas bien, mais se refuse à passer une certification....

Ca fait quelque temps que je suis convaincu qu'il faut se professionnaliser, à minima se former faire certifier ce que l'on à appris en formation, analyser ses pratiques professionnelles, faire contrôler la qualité de son travail par une supervision régulière, faire comme n'importe quel professionnel de l'accompagnement, bref être en congruence avec ce que l'on prône.

C'étais à titre personnel, je me suis formé et j'ai un peu évangélisé (j'ai fait la première session sur l'accompagnement professionnel il y a 3 ans à Agile France) maintenant il est peut être temps de parler collectif, de l'avenir du marché Agile...

Et je pense il est vraiment temps qu'il y ai une visibilité professionnelle (voir associative) sur une démarche de professionnalisation autour de l'Agile (pour ne pas parler de congruence...)

Vous avez en pensez quoi ?