Tragédie De La Définition D'une Méthode

Fleeting

• voir,
  • misconceptions about scrum,

like in most fields — there’s an upper-echelon discussion with identifiable thought leaders, and then there’s what everybody really does in practice, and there’s a big space between these two conversations

— https://wildetruth.substack.com/p/simpsons-paradox-and-existential

— https://www.smbc-comics.com/comic/ideology

définition d’une méthode vs usage ordinaire d’un mot

Les mots qu’on emploie évoluent en fonction de la propagation des usages par théorie causale de la référence.

how do we increase our knowledge in ordinary life?

Quand on définit une méthode, on lui donne un nom, par exemple « scrum ». Comme toute méthode, elle est perfectible et évolue dans le temps.

Cependant, cette méthode n’échappe pas à la loi de l’évolution des mot. Ainsi, après sa première publication, on voit converger dans les usages ordinaires une nouvelle définition, qui, sans être si éloignée, est tout de même différente.

Or, lorsqu’on cherche à définir une méthode, on cherche à lui donner un ensemble de propriétés. Ainsi, on va faire évoluer sa « définition officielle ». Certains vont alors propager la nouvelle définition, aboutissant par la même loi à un usage légèrement différent.

Pour chaque version publiée de la méthode, on risque d’observer une communauté langagière d’utilisateurs officiels et une version dont l’usage ordinaire aura convergé.

Cela cause autant de débat sémantique qu’il y a de communauté en cours d’existence.

Comme toutes ses définitions sont probablement assez proches, il est fort probable qu’il existe aussi des tas d’ententes verbales. Lorsque les débats sémantiques ont lieux, la dissonance cognitive de se rendre compte qu’on ne parle pas de la même chose amène probablement à encore plus de hooliganisme sémantique, chacun étant persuadé d’avoir raison dans sa définition.

Ainsi, plein de gens croient que scrum prescrit dans un daily scrum de poser trois questions qu’on ne retrouve pourtant pas du tout dans le scrum guide, du moins dans la version 2020.

La tragédie réside dans le fait que toutes ces communautés langagières ont raisons. Il est normal de voir évoluer un usage ordinaire et il est tout aussi normal de vouloir conserver une définition qui véhicule les principes et valeurs officielles.

Par exemple, on me dit que l’agilité, c’est avant tout de savoir réagir en cas de changement, je peux soit accepter cet usage, soit réagir en indiquant que cet aspect n’apparaît que dans le douzième et dernier principe du agile manifesto et rétorquer que quitte à mettre en avant un principe, autant considérer le premier (Our highest priority is to satisfy the customer through early and continuous delivery of valuable software)¹.

Les méthodes sont en général inspirées d’autres méthodes, elles même étant sujettes cette tragédie.

Ainsi, scrum est considéré comme une méthodes agiles, et sa définition officielle indique qu’elle s’inspire de l’empiricism et le lean. Cela ouvre donc la porte au autant de débats sémantiques sur ces sources.

Autant dire qu’il existe en fin de compte probablement autant de définitions possible d’une méthode X que de feuilles dans un arbres de possibilités d’interprétations.

Cela m’amène à beaucoup de modestie épistémique sur ma légitimité à prétendre connaître une méthode en invoquant seulement son nom (scrum, gtd, agile, etc). Cela active aussi fortement mon bullshitomètre quand quelqu’un semble avoir cette prétention.

En conclusion, l’expression que j’entends souvent « scrum, ça ne marche pas » est tout à fait vrai et aussi tout à fait fausse, suivant quelle définition de scrum on a. C’est donc une expression qui n’apporte pas vraiment d’information.

Notes pointant ici

• Agile & Scrum Don’t Work | Allen Holub In The Engineering Room
• comment assurer qu’on se comprends ?
• naming things tragedy
• tragedy of estimations in softwares

Permalink