Durant les formations, je me retrouve souvent en situation de devoir expliquer pourquoi (et en quoi) l’agilité est différente des processus classiques, mais pas seulement. Bien sûr on pense au bon vieux « cycle en V », la tarte à la crème des processus non-agiles, mais nous pouvons aussi évoquer les processus itératifs tels qu’Unified Process !

Unified Process est un cas intéressant, voir embarrassant. Certains le classent dans la limite basse des méthodes agiles [4] (après tout, on est loin du cycle en V), d’autres considèrent qu’il ne s’agit définitivement pas d’une approche agile. C’est mon cas. Je trouve par ailleurs intéressant de voir que Ken Schwaber lors de sa première présentation de Scrum en 1995 classait déjà ces approches (pourtant plutôt novatrices à l’époque) en dehors de ce que l’on appelait pas encore les « approches agiles » [1] !

Pour débuter notre reflexion, je vous propose de nous intéresser au modèle Cynefin.

Le modèle Cynefin

Le modèle Cynefin permet de classifier la complexité des contextes en fonction de la nature des relations de causalité entre problème et solution. Je simplifie un peu, pourtant cela doit sembler obscure. Ne vous en faites pas, cela deviendra plus clair lorsque nous expliquerons le modèle. Le voici.

Le modèle Cynefin [2] est une illustration de la théorie de la complexité. Ce n’est pas le seul modèle développé à cet égard. L’usage premier de ce modèle est de montrer le dynamiques de transition entre les différentes zones. Pourtant, ce n’est pas ce à quoi il va nous servir aujourd’hui. Nous allons l’utiliser pour catégoriser nos contextes projet !

Le domaine simple (évident)

La relation de causalité est directe, évidente. Dès lors la solution s’impose d’elle-même. C’est pourquoi nous sommes dans le domaine des « best practices » : on peut déterminer la meilleure solution à un problème donné. La déclinaison la plus connue de cette approche de « bonnes pratiques » est le management scientifique du travail, qui se traduit par la décomposition d’un travail en tâches élémentaires optimisées. Nous reviendrons bientôt sur ce sujet.

Le domaine compliqué

Toujours sur la base de la relation de causalité, on estime ici que cette relation de causalité nécessite une analyse ou une expertise pour pouvoir être établie à priori. C’est le domaine des « bonnes pratiques ». La solution au problème n’est donc pas nécessairement unique ! On s’offre un éventail d’options restreintes pour traiter notre problème. Cette déclinaison correspond assez bien à Unified Process qui supporte une forme de customisation [5] par rapport au contexte, permettant cette notion d’options.

Le domaine complexe

Il est en rupture avec les deux précédents, car ici, le lien de causalité ne peut être établi à priori, mais seulement observé à postériori. Nous sommes donc dans le domaine de l’approche empirique et des phénomènes emergents utilisant une boucle de feedback.

Nous sommes dans le « sweet spot » de l’agilité : les territoires inconnus se prêtant à une approche exploratoire.

Le domaine chaotique

Ici, il n’y a aucune corrélation entre cause et effets. Ce domaine induit de purs comportement de réponse aux situations. Nous sommes dans des environnements type « guérilla urbaine » qui ne sont plus le domaine de prédilection de l’agilité.

Le cadre du management scientifique du travail

Le « management scientifique du travail », vous en avez tous entendu parler. Mais peut-être pas sous ce nom. Peut-être êtes-vous plus familier avec le terme « Taylorisme » ?

Dans les grands traits, le management scientifique du travail [3] divise les responsabilités entre deux groupes :

• Les managers dont le rôle est d’analyser et de dicter la façon de faire le travail
• Les ouvriers qui doivent suivre à la lettre les instructions (selon le propos de Taylor « ils sont trop stupides pour savoir comment bien travailler » !)

Replacé dans le contexte de la fin du XIXème siècle, à une époque où le travail des ouvriers avait une nature hautement mécanique, cela a du sens. Je vous choque ? Pourtant le Taylorisme fut une avancée majeure pour permettre la production de masse (qui n’existait pas avant) et a permis la révolution industrielle. Aujourd’hui même, les biens de consommation que nous ne saurions nous passer sont presque là grâce au Taylorisme !

Quelle place le Taylorisme occupe-t-il dans le modèle Cynefin ? De mon point de vue, il s’agit indubitablement du quadrant « simple » (évident). On est réellement dans le domaine des « best practices, d’ailleurs Taylor parle bien de selection du « best movement » (p. 57) !

Toutefois, et cela a été ignoré par les successeurs de Frederick Taylor, il y a bel et bien des postulats au Management Scientifique du travail

Les postulats du Taylorisme

Ma lecture du texte de Taylor m’amène à penser que les postulats de base sont au nombre de 3. Allons-y !

Le travailleur est trop stupide pour savoir organiser son travail lui-même !

Vous êtes surpris (ou de nouveau choqués) ? En fait, je ne fais que répéter les propos même de Frédérick Taylor ! En fait il répète même cela à plusieurs reprises dans son livre. Il faut dire que l’humain n’était pas forcément le soucis principal de cet ingénieur.

Si le respect des personnes ne semble pas tellement présent, le texte ne laisse pas non plus penser que les travailleurs en question sont des genies…

Le besoin du travailleur se situe au niveau de la sécurité

Certes, on n’avait pas encore la pyramide de Maslow à l’époque, mais un point méconnu est pourtant tout à fait explicite dans le texte de Frederick Taylor : le partage des gains opérés entre le détenteur du capital, le travailleur et le consommateur !

Il faut se replacer dans le contexte de l’époque. Les travailleurs manuels luttent pour nourir leur famille, se loger et s’habiller. L’accomplissement de soi n’est pas leur problème du moment. Ils e situent bien au second niveau de la pyramide de Maslow

Ce que propose Taylor est une augmentation très importante de leur revenu [3], p. 46 allant de 80% à 100% avec une réduction significative de leur temps de travail (de 10,5 heures à 8,5 heures). Ce qui, chemin faisant, fait du travailleur un consommateur !

Curieusement, cette contrepartie a progressivement disparue chez les successeur de Taylor !

Le domaine adressé est celui du travail répétitif

Ce postulat n’est pas explicite. Mais il est implicitement présent tout au long du livre. Car l’auteur parle bien de « mechanical shops ». Il n’est fait mention nul part d’expérimentation portant sur du travail non répétitif ou du fait qu’un travail de reflexion puisse être assimilé à un travail répétitif. On trouve cependant une référence au travail de chirurgien, dont il est dit à juste titre que les opérations simples peuvent tomber dans le cadre du « management scientifique du travail ». Un raisonnement que l’on peut accorder à l’auteur … en gardant à l’esprit que l’on parle de chirurgiens du 19ème siècle !

La nature intrinsèque des méthodes classiques

Que l’on parle de cycle en « V » ou d’Unified Process, ces processus sont toujours abordés de la même façon : sous l’angle de ce qui est produit, par qui, comment … En fait tous ces processus peuvent être décrits par le biais d’un métamodèle ! C’est déjà ce que Ken Schwaber mettait en lumière en 1995 [1] !

Voici justement, à peine simplifié, celui d’Unified Process.

Même avec un processus accordant certains degrés de liberté, la logique reste bien là : on définit qui produit quoi, comment est-ce produit et dans quel contexte. Intrinsèquement, nous faisons la même chose que Taylor, il y a 130 ans, mais sans respecter aucun de ses postulats. Aucun !

Les approches agiles : une nature disruptive

Ce qui distingue les approches agiles (j’évite le terme « processus » à dessein) des autres, c’est justement de ne pas être construites sur un métamodèle, mais sur ce que nous appelons souvent la pyramide agile. Vous la connaissez très certainement, pardonnez-moi de la refaire figurer ici (et de l’expliquer).

Les valeurs : Ils figurent dans le manifeste agile et nous montrent la direction. C’est ce que j’appelle la « boussole agile ».

Les principes : Mise en musique du manifeste, les principes donnent des axes concrets sur les règles à suivre.

Les pratique : Boite à outil infinie (ou presque) à utiliser tel quel pour réaliser les logiciels, les pratiques nous donnent des aides, des façons de faire.

Point de métamodèle ici : on ne peut être émergent et prescriptif. On peut seulement fournir un cadre pour nous aider à aller dans la bonne direction !

Et alors ?

Retour au modèle Cynefin. Le Taylorisme n’est pas mauvais en soi. Il ne l’était surtout pas à l’époque. Mais justement le contexte doit être pris en compte : aucun des 3 postulats, ni le domaine d’application ne sont adaptés au développement du logiciel. Cela devrait nous laisser froid s’il n’existait pas une incarnation directe de celui-ci dans le monde informatique : c’est le micromanagement !

Las, les méthodes classiques s’éloignent quand même au moins un peu du micromanagement. Néanmoins, l’observation sous l’angle du métamodèle nous montre que le paradigme est le même !

Une approche moderne du développement logiciel doit satisfaire :

• Les besoins des personnes, qui se situent aux niveaux 3 à 5 de la pyramide aujourd’hui.
• La nature émergente, non prédictive du travailleur du savoir qui a d’avantage besoin d’une boussole que d’un marionnettiste !

Et vous, vous ai-je convaincu ?

Ressources

[1] : The Scrum Development Process – Ken Schwaber – OOPSLA 1995

[2] : The Cynefin model : http://en.wikipedia.org/wiki/Cynefin

[3] : The Principles of Scientific Management – Frederick Winslow Taylor

[4] : Agile and iterative development, a manager’s guide – Craig Larman

[5] : The Rational Unified Process, an introduction, third edition – Philippe Kruchten