Note : 7 ; Un « back to basics » très bien écrit et malheureusement aujourd’hui nécessaire… mais par moments trop empreint de dogmatisme XP !
Quand on ouvre un livre de Robert Martin, on est presque toujours sûr de passer un bon moment. C’est bien le cas ici, et c’est sans doute pourquoi j’ai avalé ce court opuscule en à peine 2 jours. Le sous-titre « back to basic » traduit bien la volonté de l’auteur, revenir aux sources de ce qu’est l’agilité, de pourquoi et comment la met-on en œuvre. Le retour aux sources, c’est le retour à la véritable agilité, et pour l’auteur ce ne peut être rien d’autre que Extreme Programming. Nous verrons que cela induit quand même quelques biais qui peuvent aller de légèrement irritant à franchement embarrassant.
Place au texte ! Comme énoncé, c’est une lecture fort digeste : 185 pages réparties sur 8 chapitres. C’est d’histoire dont nous parle Robert Martin dans ce premier chapitre. L’histoire telle qu’il la connait et qu’il l’a vécue. Cela couvre des éléments bien antérieurs aux années 89/90, que les non-férus d’histoire découvriront, et bien sûr l’écriture du manifeste à Snowbird. Un régal. Le chapitre se termine sur le « circle of life » d’extreme programming, car pour l’auteur agile est synonyme d’extreme programming, et en fait rien d’autre.
Le chapitre 2 couvre les raisons de faire de l’agile (oui, j’ai dit « faire »). Le chapitre incarne assez bien l’aspect « retour aux bases » avec un éclairage résolument XP et ingénierie du développement. Ce n’est pas vraiment une découverte bien sûr, ni une redécouverte pour moi, mais il pourra éclairer des nouveaux venus qui n’ont que le prisme facilitation en tête. Le plus curieux dans le chapitre 3 est le titre « business practices » qui pour moi correspond peu au contenu (pour ne pas dire pas du tout). Peut-être que selon le prisme XP, le business est tout ce qui n’est pas strictement l’ingénierie de développement ? On y aborde de manière conséquente les estimations et la vélocité ce qui, même si c’est bien et clairement abordé est tout à fait ennuyeux. La fin du chapitre sur les tests et la QA parvient tout de même à me sortir de ma torpeur.
Le chapitre 4 est consacré aux pratiques d’équipe. Elles font références aux « cercles de la vie d’XP » et couvrent évidemment les pratiques d’XP et rien d’autre. On y retrouve ce qui est déjà largement couvert dans les ouvrages de la « XP series », à peine remis au goût du jour (j’avais quelques espoirs sur l’intégration continue…). Je note toutefois deux points. D’abord la pratique de la métaphore que l’auteur redirige vers l’univers du DDD, ce qui me semble opportun mais n’est ni la même chose ni une évolution naturelle de la pratique comme cela est suggéré. Ensuite le propos autour du Daily standup, très dogmatique auquel je n’accroche pas.
Les pratiques techniques évoquées au chapitre 5 sont cantonnées au TDD/refactoring et au pair programming. Ces sujets sont largement couverts par ailleurs, peut-être est-ce pour cela que le chapitre est curieusement court ?
Le chapitre 6 « becoming agile » est celui qui m’a le plus fait tiquer, pour le moins. Nous verrons toutefois qu’il y a aussi une bonne surprise. Le dogmatisme XP est ici à son maximum. Pour l’auteur certaines choses sont possibles et d’autres pas possibles car possibles ou non-possibles avec XP. D’ailleurs il appelle le non-XP la « ménagerie ». Ainsi la transformation d’organisations n’est pas possible car les middle-managers ne sont pas compétents à comprendre XP. De même l’application de l’agilité à l’échelle est sans objet car c’est un problème résolu depuis des millénaires (et incidemment non couvert par XP). L’auteur a raté ici de très très grosses choses, comme par exemple un pan entier de littérature et d’expériences. La bonne nouvelle est que Robert Martin a passé la plume à d’autres au sein de ce chapitre, notamment à Damon Poole qui évoque le coaching à contre-pied de l’auteur (respect à Robert Martin pour avoir accueilli cela) est qui est particulièrement intéressant. Un chapitre sauvé en quelque sorte.
C’est aussi à un tiers, en l’occurrence Sandro Mancuso, que le chapitre 7 est confié. Il nous parle de craftsmanship bien entendu, pour l’évoquer sous l’angle du mouvement et du courant de pensée plus que sous l’angle des pratiques. Un chapitre agréable à lire, même s’il n’est pas indispensable.
La plume de Robert Martin n’a rien perdu de sa qualité. Sa culture et sa capacité à raconter des histoires font mouche également. Oui, le « back to basic » est hélas bienvenu. Et certes les vertus de l’Extreme Programming sont nombreuses. Mais j’ai toujours eu du mal avec le dogmatisme et il est ici à son paroxysme. Il conduit l’auteur à ignorer ou mépriser des choses qui sont désormais partie intégrante du mouvement agile mais pas de ses œillères. Sans cela le texte aurait grignoté un ou deux points, le 7 étant bien noté.

Référence complète : Clean Agile – Robert C. Martin – Pearson Education 2020 – ISBN: 978 0 13 578186 9
Bonjour Christophe,
« Ainsi la transformation d’organisations n’est pas possible car les middle-managers ne sont pas compétents à comprendre XP. » : cette phrase (certes sortie du contexte) m’interpelle. Rien que pour ça ça me donne envie de lire le livre, mais ça m’intéresse si tu as des références liées de prêt ou de loin à cette position et ce que je vais appeler les freins liés à une vision de l’agilité restreinte aux « implémentations » de l’agilité mettant en avant un nombre restreint de composantes d’ingénierie logicielle (on va vaguement retrouver selon la maturité de la code review, intégration continue, Infra as code, voire du déploiement continu) et qui recourent à des experts / coach alignés avec ces implémentations (tout ceci sans aller sur le terrain de l’échelle qui va probablement risquer d’atténuer encore certaines composantes technique au profit d’autres plus organisationnelles).
Éric
J’aimeJ’aime
Bonjour Eric,
Quand tu parles de références, à quoi penses-tu ? Des références dans le texte de Robert Martin ou ailleurs pour étayer ce qui m’a fait bondir ?
Je ressens aussi le problème de la « prise en étau » entre l’agilité restreinte aux pratiques d’ingénierie et la partie « à l’échelle » qui vient avec sont lot de positions embarrassantes…
Maintenant le texte vient aussi en réaction avec le délaissement des pratiques d’ingénierie dans des déploiements agiles. Je peux comprendre.
J’aimeJ’aime
Bonjour Christophe,
Oui quand je parlais de références, je pensais surtout à des lectures que tu aurais à me recommander sur cette thématique de freins à la transformation vers une agilité inclusive de ses dimensions d’ingénierie (voire plus spécifiquement de ce qui dans XP ou dérivés – référence au craftsmanship par exemple – touche au travail en équipe)
Eric
J’aimeJ’aime
Bonjour Christophe,
« Ainsi la transformation d’organisations n’est pas possible car les middle-managers ne sont pas compétents à comprendre XP. » : cette phrase (certes sortie du contexte) m’interpelle. Rien que pour ça ça me donne envie de lire le livre, mais ça m’intéresse si tu as des références liées de prêt ou de loin à cette position et ce que je vais appeler les freins liés à une vision de l’agilité restreinte aux « implémentations » de l’agilité mettant en avant un nombre restreint de composantes d’ingénierie logicielle (on va vaguement retrouver selon la maturité de la code review, intégration continue, Infra as code, voire du déploiement continu) et qui recourent à des experts / coach alignés avec ces implémentations (tout ceci sans aller sur le terrain de l’échelle qui va probablement risquer d’atténuer encore certaines composantes technique au profit d’autres plus organisationnelles).
Éric
J’aimeJ’aime