Note : 2 ; Une agilité vraiment plus qu’imparfaite, pour un monde imparfait ?

Cet ouvrage prenait la poussière sur mon étage depuis un bon moment. Il était temps de s’en occuper. J’ai passé depuis un bon moment le besoin de compulser des livres permettant de découvrir l’agilité. J’ai même passé depuis longtemps le besoin de voir comment un auteur aborde le sujet par simple curiosité. Disons que je me suis livré à cette lecture par simple distraction ! Ce sera probablement la dernière fois.

Avec 330 pages sur 23 chapitres découpés en 8 parties, le texte est beaucoup plus conséquent que ce à quoi on pourrait s’attendre. Et l’on met plus de temps qu’initialement prévu pour en venir à bout, malgré son côté « pour débutants ». La première partie pose quelques fondamentaux et n’occupe que 2 chapitres pour un total de 25 pages. Les 16 pages du premier chapitre nous exposent les fondamentaux classiques : valeurs agiles, manifestes et principes agiles. Auxquels s’ajoutent quelques mots sur la différence entre l’approche agile et le « plan-driven ». En vérité ce chapitre est plutôt bon. Le second chapitre nous présente le fil rouge du livre : Acme Media. En principe j’aime bien avoir une illustration « fil rouge », mais aussi bien l’exemple choisi que la manière de l’utiliser au fil des chapitres ne sont particulièrement bons.

La seconde partie « getting starting » est bien plus conséquente, avec 7 chapitres sur 90 pages. Les 15 pages du chapitre 3 « are you ready for agile ? » nous livrent un panorama des méthodes agiles à date, mais où l’auteur ne s’engage guère. Toutefois les caractéristiques nous permettant de privilégier un framework plutôt qu’un autre mérite un peu d’attention. Le « readyness assessment », sujet du chapitre 4, va plus loin en nous proposant une véritable grille d’audit que l’on doit à Ahmed Sidky. Même si j’ai moi-même ma propre grille d’audit, l’approche prête le flanc à critique, surtout quand, comme ici, elle est assortie de calculs de scores avec pondérations donnant une fausse impression de précision… Le chapitre 5 est très court, il nous donne quelques voies pour attaquer les exécutifs de la société et obtenir leur support dans une transformation agile. Le propos reste assez superficiel.

Au chapitre 6, les auteurs abordent la question de la constitution d’une « core team ». Nous sommes au cœur de l’approche de transformation prônée par l’ouvrage : c’est la constitution d’un centre agile, en dehors des projets mais capable de les aider et de mettre la main à l’ouvrage avec eux. Ce chapitre traite de sa constitution, de sa mission et de son lancement. Toute choses sur lesquelles le texte semble un peu léger, pour autant que l’on trouve cette approche pertinente. Concernant le leader agile, au menu du chapitre 7, l’auteur semble bien plus à l’aise et lui consacre d’ailleurs près de 15 pages. On y balaie le mindset, les compétences, les attentes à son égard. C’est du bon travail.

Nous en sommes à injecter de l’agilité dans les process existants pour ce chapitre 8, ou plus exactement à préparer cette injection ! L’approche est un peu si ce n’est effrayante, disons technocratique, avec pas moins de 5 phases et un poids assez important accordé à la documentation. Je ne m’y reconnais pas trop. Le chapitre 9 conclut cette seconde partie et est dédiée au choix d’un projet pilote. Les recommandations des auteurs sont : un projet moyen, pas trop critique et sans utilisateurs externes ! Bref, un projet sans saveur et qui ne permettra pas d’argumenter l’approche agile et certainement pas de convaincre les sceptiques ! Nous restons bien dans le technocratique.

Ce sont un peu moins de 40 pages sur 2 chapitres qui forment la 3ème partie de l’ouvrage : kicking off. Elle s’ouvre sur un chapitre 10 qui s’attaque à la faisabilité du projet. Et cette faisabilité fait l’objet d’une phase d’étude de faisabilité confiée à une « équipe faisabilité ». En réalité, les sujets qui y sont abordés font sens, mais ce n’est pas le cas de l’approche qui sent bien trop la poussière à mon goût. C’est d’aligner l’équipe pilote avec le projet dont il est question au chapitre 11. Qu’est-ce que cela signifie ? Tout d’abord former cette équipe à l’agile (merci captain obvious !). Ensuite assurer une synchronisation / feedback avec la « core team » qui n’est donc pas si cœur que cela car elle se tient en-dehors du jeux. Et enfin faire le passage de relai avec l’équipe faisabilité, c’est à la plèbe de prendre le relai une fois le cadrage terminé. L’équipe faisabilité s’est donc engagée sur du travail qu’elle n’effectuera pas…

La quatrième partie a trait au travail sur le backlog. Elle couvre un peu plus de 40 pages pour 3 chapitres. C’est avec les « features cards » que s’ouvre ce nouvel opus au chapitre 12. La feature card, c’est un rejeton de la user story mais bien plus formalisé, avec pas moins de 14 rubriques et sans nécessairement les stipuler avec une orientation utilisateur. En les comparant avec les autres approches, les auteurs n’hésitent pas à les appeler « user stories sous stéroïdes » du fait de leurs nombreuses rubriques, mais j’ai une autre opinion… Le chapitre 13 est consacré à la priorisation du backlog. On y retrouve les clés habituelles : valeur utilisateur, risque et estimations. La surprise, pour rester poli, vient de l’idée de regrouper des features réputée proches plutôt que de chercher à découper celles-ci. De mon point de vue, nous voilà dans une optique d’optimisation de l’effort plutôt que de l’impact, une approche notoirement non-agile. Le chapitre 14 consacré à l’estimation conclut cette 4ème partie. Nous n’y trouvons pas de surprise ici : l’approche « planning poker » est recommandée sans la nommer et sans intégrer le biais d’influence que cette technique adresse. Cela mis à part, un chapitre convenable mais qui ne va pas plus loin que ce qui est déjà éprouvé.

La 5ème partie compte un peu moins de 30 pages et seulement 2 chapitres et a pour objet la planification. Le chapitre 15 évoque le release plan, donc la présence de releases regroupant plusieurs itérations, comme dans SAFe. La poussière revient au galop, d’autant plus quand je vous aurai dit que le texte suggère d’espacer les itérations plutôt que de les enchainer… pour pouvoir terminer le travail ! D’autres considérations sont abordées dans ce chapitre, mais nous avons une nouvelle fois confirmation d’une agilité largement diluée ! Le chapitre 16 aborde lui la planification d’itération. En fait il y est surtout question d’analyse et de modélisation de la feature, confirmant ainsi que nous sommes plutôt sur une logique de features volumineuses. Après avoir regroupé les features, nous voici en train d’en découper de nouvelles au fur et à mesure que l’analyse fait enfler celle-ci. Good job !

Ce sont 3 chapitres pour une trentaine de pages, pour cette 6ème partie. Celle-ci est consacrée au Build. Le chapitre 17, eh bien… J’ai l’impression de trouver en ces pages le Bingo des pratiques que je n’aime pas. Ce chapitre 17 en est un nouvel exemple : il est dédié au Sprint 0 ! On y retrouve ce que les tenants de cette pratique y mettent : vison (ce n’était pas dans le cadrage ?), outillage et environnement, backlog initial, fondation de l’architecture. Les auteurs proposent d’en profiter pour « tricher », c’est à dire de prendre un peu d’avance sur le premier Sprint. Tout ceci n’est pas glorieux.

Le chapitre 18 est, enfin, consacré à la livraison du logiciel qui fonctionne. Le chapitre s’ouvre sur les principes agiles, du moins une sélection un peu trafiquée de ceux-ci. Les pratiques d’ingénierie sont survolées. Je ne peux m’empêcher de vous livrer une nouvelle perle : il n’y a pas de priorités entre les features au sein d’une itération, car l’utilisateur veut tout ! Cette partie se referme sur un chapitre dédié aux tests. Il n’y est pas dit trop de bêtises. Sont évoqués les tests unitaires, les tests d’intégration (pour autant que l’on sache ce que cela veut dire), les tests fonctionnels et les tests exploratoires. L’automatisation y est aussi traitée même si le propos fait sourire. Mais il faut aussi replacer le texte à son époque. Au final un chapitre pas trop mal fait.

La 7ème partie aborde le changement. Elle compte 3 chapitres sur près de 60 pages. L’adaptation au changement est au menu du chapitre 20, et il fait plutôt du bon boulot. Les auteurs ont recensé les principales causes de changement auxquelles il faut régir : changement au niveau du métier, besoin de faire évoluer les fonctionnalité, problèmes avec l’architecture ou un sous-traitant, etc. Quelques voies nous sont ainsi proposées pour y faire face.

La release, qui est le thème du chapitre 21 est de nouveau l’occasion d’une bonne rigolade. Cette release, elle ressemble fort à la phase de transition d’Unified Process d’avant l’agile. On y retrouve la préparation au changement, la formation, etc. Mais au moins Unified Process avait le bon goût de lisser les tests tout au long des itérations. Les « final tests » largement développés ici finissent d’enterrer ce qu’il subsistait d’agile ! Le dernier chapitre de cette partie est consacrée aux rétrospectives, et c’est une bonne idée ! L’originalité, si je puis dire, est que celle-ci est basée sur un questionnaire envoyé à l’avance. Original, je vous dis !

La 8ème partie ne compte qu’un seul chapitre consacré à l’extension du nouveau processus à l’ensemble de l’entreprise. Elle s’appuie sur la courbe de Moore pour suggérer des moyens d’aborder des équipes aux ancrages culturels différents. Mais au global, cela reste superficiel.

Même en replaçant l’ouvrage dans son époque, celui-ci est décevant. L’agilité qui nous est proposée ici est franchement diluée, quand ce n’est pas ancrée dans l’ancien monde mais avec une peinture différente. Le propos à sauver est assez maigre. Le fil rouge, qui est en principe une bonne idée, ne fonctionne pas ici. Il semble être une pièce mal rapportée. Ami lecteur, passe ton chemin !

Référence complète : Becoming Agile – Greg Smith & Ahmed Sidky – Manning 2009 – ISBN: 978 1 933988 25 2