Note 2 ; Un texte bien austère, où il est question d’agilité à l’échelle, mais surtout d’une usine d’intégration…

L’agilité à l’échelle est le sujet du moment, c’était l’opportunité pour moi de dépoussiérer ce petit livre. Il ne compte en effet que 170 pages, rythmées sur 16 chapitres. Hélas, le texte s’est avéré décevant su de nombreux points. Certes, on pourrait considérer qu’un retour d’expérience est rarement palpitant. Pourtant Henrik Kniberg parvient à rendre cela palpitant. Au moins s’attends-t-on à y trouver une bonne compréhension des dynamiques d’une grande équipe répartie, mais cela aussi s’avère décevant. En fait, ce sont surtout des éléments de description d’une agilité pour les débutants que nous y trouvons. Le réel point de fierté de cette équipe (qui a quand même très bien réussi son pari) réside dans une mécanique d’intégration continue très bien faite, directement inspirée du « continuous delivery » de Jez Humble. Cet ouvrage et ceux de Dean Leffingwell sont d’ailleurs les sources d’inspiration des auteurs.

Le premier chapitre semble s’adresser plutôt aux nouveaux venus à l’agilité. Les auteurs nous y expliquent comment ils ont fait leur marché dans les principes agiles qui les intéressaient le plus. Ce sont 8 pages vite passées. 8 pages aussi pour le second chapitre intitulé « tuning agile to your business objectives ». En fait on nous y explique le contexte initial du projet et ce que l’on cherche à obtenir, à savoir une usine de développement bien rôdée, mais aussi les sources de gains que l’on vise (baisse de la maintenance, augmentation de la productivité et part du développement consacré à l’innovation). Le tout adossé à des chiffres. Très bien.

Le chapitre 3 « aligning architecture to business objectives » aurait pu être intéressant, mais à la place, on y évoque le passage d’un mode « report de patches » à une architecture composable, orientée ligne de produit, mais en restant dans les généralités. Des principes de base que je considère comme connus. Et oui, cela permet de travailler dans le master plutôt qu’en branches et en report de fonctionnalités entre branches… Suit le chapitre 4 qui enfonce aussi des portes ouvertes « how to establish a new architecture using agile concepts » où on nous explique que faire émerger une architecture en agile concise à travailler en petites tranches verticales. Encore une fois cela fait partie des basiques de l’agilité et trouver ceci dans un texte dédié à l’exécution de l’agilité à l’échelle est une distraction et une perte de temps, même s’il ne s’agit que de 6 pages.

On devrait aborder les choses sérieuses avec le chapitre 5 « the real secret to success in large scale agile », bien qu’il ne s’agisse que de 10 pages. En fait de secret, les auteurs évoquent les « mini-milestones » (leur jargon local pour évoquer les itérations) et la mise en place de métriques. Le point intéressant que j’y ai relevé, c’est l’idée d’avoir des métriques constituant des « conversation starters ».

Même s’il est très inspiré de Jez Humble, le chapitre 6 « continuous integration and quality system » reste le plus intéressant du livre. Entre autre l’étape 1 de l’intégration continue et son « auto-rejecting code » qui est probablement l’une des clés pour faire de l’intégration continue à grande échelle (qui est le véritable secret de l’agilité à grande échelle de cette équipe). La description des 4 étapes du build est réellement ce qui sauve ce livre de la Bérézina. Au contraire, le chapitre 7 « taming the planning beast » occupe 22 pages qui ne nous apprennent pas grand chose. Comme il s’agit là d’un gros projet, on y trouve un niveau « high level initiative » qui nous suggère que l’on a des problèmes de gestion de portefeuille de projets qui n’avouent pas leur nom. Toujours dans la même veine, le chapitre 8 « unique challenges of estimating large innovations » nous explique les vertus du mode itératif par rapport au cycle en V. Si, vraiment ! A peine 5 pages sont consacrées aux problématiques du management, ici structurées en 3 niveau. Le sujet est bâclé.

Je trouve quand même quelques petites choses positives à dire du chapitre 10 sur la gestion organisationnelles. Même si on est loin du scoop, les auteurs exposent clairement les aspects positifs et négatifs de chaque approche. Il en va de même pour le chapitre 11 qui ne m’apprends pas grand chose non plus mais montre les grandes lignes de ce qu’il faut savoir sur un projet réparti entre l’Inde et les Etats-Unis.

Les auteurs sont très contents de leur usine de développement, on l’a vu au chapitre 8. Ici au chapitre 12, c’est le volet « tests » qui est abordé. Rien de révolutionnaire, bien que la dimension hardware soit une originalité.

A partir du chapitre 13, on fait la synthèse des résultats. Ici ce sont les améliorations (en pourcentage et par domaine) qui sont évoquées. Puis vient la manière dont ces changements ont impacté les équipes adjacentes non agiles. Enfin, la synthèse de la manière dont la compréhension de l’agilité vue par l’équipe diffère de celle de la communauté. L’ouvrage se referme sur une évocation des prochains pas.

Heureusement, le livre est court. La prose est austère et recèle bien peu de « ha ha » moments. Le plus intéressant reste la chaine de build, mais même ici la substance est empruntée au livre de Jez Humble. Pour ce qui est du côté « à l’échelle », je ne parviens pas à voir en quoi ce texte est intéressant. Il ressemble simplement à une dissertation d’agilistes débutants. A éviter.

Référence complète : A Practical Approach to Large-Scale Agile Development – Gary Gruver, Mike Young & Pat Fulghum – Addison Wesley / ASD Series 2012 – ISBN : 978 0 321 82172 0