Note : 7 ; Une déclinaison en pratiques pas si pratique que ça du « book of the year 2010 » mais qui reste très enrichissant.

Cet ouvrage va de pair avec « Scaling Lean & Agile Development » des mêmes auteurs. Il se veut le guide de mise en pratique de ce précédent ouvrage. Nous verrons que ce n’est pas tout à fait vrai, ce qui ne signifie nullement que le texte ne vaille pas le détour.

S’agissant du volet « pratiques », on ne devra guère s’étonner du volumes substantiel de l’ouvrage : 560 pages ! L’ensemble tient en 15 chapitres, beaucoup d’entre-eux sont tout à fait conséquents en taille ! Ce n’est pas le cas de l’introduction qui ne compte que 6 pages. Il s’agit plutôt de deux mises en gardes qui seront des thèmes récurrents des chapitres suivants : pas de fausses dichotomies (beaucoup de choix ne sont pas exclusifs) et il n’y a pas de « best practices » mais plutôt des pratiques bien adaptées à certains contextes. Le second chapitre est aussi une introduction en quelque sorte, celle du « large scale Scrum » ici appelé FW2, qui deviendra LeSS plus tard.

Les choses sérieuses, vraiment sérieuses commencent au chapitre 3 qui évoque les tests et compte 75 pages ! Le chapitre couvre beaucoup de sujets, depuis la cartographie des tests jusqu’aux pratiques elles-mêmes. Les quelques messages essentiels sont : l’activité de test est indissociable du développement et doit se passer au sein de l’itération elle-même. C’est dense et c’est que du bon !

Le chapitre 4 est consacré au product management. Du moins, c’est ce que l’on pourrait croire. En réalité, il s’agit plutôt des dynamiques de fonctionnement entre le PO (ou PM) et l’équipe de développement. Et les auteurs de revenir sur le principe que le PO doit réellement être le « owner » du produit et non un analyste. Un anti-pattern hélas souvent rencontré. Au chapitre 5, on passe au planning et l’on en a pour 35 pages. Il s’agit de mettre en avant ce qui est différent par rapport à un Scrum classique : Vision workshop, big room planning. Mon take-away, c’est la vue en expansion de la Definition of Done !

Le chapitre 6 aborde la coordination. On souffle un peu avec 25 pages seulement ! C’est une occasion de plus pour se dresser contre les « coordinateurs externes », ce qui est un différentiant par rapport à SAFe. Ce sont surtout 3 concepts qui sont développés ici : les « scouts », les ambassadeurs et bien sûr les meetings de synchronisation type Scrum of Scrum. Un chapitre simple et efficace dans son propos. Le chapitre 7 consacré aux exigences est nettement plus conséquent avec ses 65 pages. Comme moi, les auteurs accordent une très grande importance au découpage en tranches des stories. Le sujet occupe la plus grande partie du chapitre, abordé de plusieurs manières au travers d’exemples différents. Au final cela rend ce chapitre plutôt désagréable à lire, et c’est bien dommage !
Design et architecture sont au programme du chapitre 8. Ici les victimes expiatoires sont les architectes-PowerPoint qui ne salissent pas les mains avec du code. Car pour les auteurs, la vérité est dans le code. Ce qui n’empêche pas d’évoquer la modélisation « juste à temps » comme une pratique à valeur ajoutée qu’il faut développer. Je ne saurais dire mieux. Il y a un chapitre consacré au code Legacy, c’est le chapitre 9. Il est court avec une quinzaine de pages, mais tout n’est-il pas dit dans le texte de Michael Feathers ? Ici on parle surtout d’éviter de créer du code legacy (et comment). Le chapitre ne dit pas grand-chose, mais la présence même de celui-ci souligne l’importance du sujet.

L’intégration continue est un sujet qui a bien progressé depuis la publication du livre. Le chapitre 10 lui consacre une vingtaine de pages. On retrouve derrière la notion de « multi-stage CI » les principes développés sous le nom de « pipeline d’intégration » par Jez Humble. On y évoque aussi le développement en petits lots et une stratégie de développement sur la branche principale. Bref, de l’ingénierie moderne. Près de 40 pages sont dédiées à « inspect & adapt » au chapitre 11. Il s’agit d’un melting pot de petits sujets reliés entre-eux par un même thème : joint-retrospective, culture de l’expérimentation, centre de coaching, etc. C’est assez décousu et malgré l’intérêt de la plupart des sujets abordés, pas folichon à lire.

Le développement multi-site est une composante hélas presqu’inévitable du développement à grande échelle. Les auteurs n’éludent pas le sujet et en abordent les points cruciaux au long des 30 pages de ce chapitre 12. Les équipes dites dispersées n’ont pas leur faveur et c’est facile à comprendre. J’ai bien aimé les nombreuses pratiques présentées pour faire face à la facilitation à distance et au partage d’information. Fort logiquement, c’est l’offshore qui est ensuite abordé au chapitre 13, sur 50 pages. Le texte s’appuie essentiellement sur l’expérience Valtech en Inde. Les auteurs semblent avoir régulièrement besoin de victimes expiatoires, ce sera CMMi ici. Deux volets s’y dégagent : connaitre les personnes (et leur culture) en allant rencontrer les autres, et aménager les moyens techniques et humains pour rendre la communication plus fluide. Nous sommes loin du « outsource it ! », mais on pourra glaner quelques idées au passage.

Le chapitre 14 traite des contrats et noircit près de 50. Il est aussi co-écrit avec un juriste qui transparait dans l’originalité du propos. En fait, ce sont surtout ces points que j’ai appréciés, tels que les 3 focus majeurs des juristes sur les contrats ou les « top contractuals concerns ». Du côté des auteurs, l’accent mis sur le modèle de contrat de Robert Martin fait un peu réchauffé… L’ouvrage se clôt sur un court « feature team primer » issu de l’ouvrage précédent et qui ne nous apprends rien.

Ce nouvel opus, c’est du dense. J’ai bien aimé les focus des chapitres sur les thèmes réellement importants et n’occultant aucun sujet difficile comme l’offshore ou les contrats. L’ouvrage va jusqu’à s’ouvrir sur les tests (et c’est un gros chapitre), alors que l’ouvrage équivalent sur SAFe n’en a pas et n’évoque que légèrement le sujet ! La structure même des chapitres est confuse et compliquée à lire, surtout que ces chapitres sont longs ! Cela rend la lecture compliquée et moins agréable qu’elle devrait être, d’où la note en retrait par rapport à l’ouvrage précédent. Mais ça reste du très solide !

Référence complète : Practices for Scaling Lean & Agile Development – Craig Larman & Bas Vodde – Addison Wesley 2010 – ISBN : 978 0 321 63640 9