Du 17 au 20 décembre dernier, j’ai participé à Carnac à une super expérience agile comme je n’ai plus l’occasion d’en vivre, un booksprint : écrire un livre en 4 jours en équipe, avec 4 collègues de Goood!.

Le sujet, c’est l’Agile Rocket, une transformation agile modulaire et progressive et l’objectif de ces 4 jours est de produire un guide pour clients et coachs.

Le résultat de ces 4 jours a été publié quelques jours plus tard en PDF et nous avons prolongé l’expérience en janvier avec quelques améliorations, de forme essentiellement, nous amenant à la publication de l’Agile Rocket 1.1 maintenant ! Vous pouvez enfin accéder sur google drive au guide constamment à jour avec les dernières modifications, en déploiement continu.

4 jours, 5 cerveaux, 11 sprints, 25 standups, 11 rétrospectives, 125 pages écrites et un concentré d’une expérience agile avec ses changements, ses doutes, ses rebondissements, ses joies. Notre expérience de booksprint à 5, nous la raconterons le 31 janvier à 18h45 dans nos locaux (les places sont disponibles ici) et je vais commencer par vous raconter ici mon expérience, en quoi elle est agile, et en quoi l’agile, souvent, c’est pas facile !

Pour ce faire, je vais utiliser comme grille de lecture le manifeste agile et ses 12 principes et les 3 premiers pour commencer.

Satisfaire le client est la priorité

Définir les critères de valeur

Nous commençons le booksprint par un sprint 0 pour définir notre cible, notre organisation et notre cadre de travail. Nous définissons nos futurs lecteurs (nos “clients” en quelque sorte) à travers des personas afin de mieux les connaître et d’identifier déjà les critères de valeur qui nous serviront à prioriser plus tard.

Les voici :

• Kouigna Man le gooodien
• Jean-Noël le décideur
  
• Ernestette la team member
• Cathy la manager
• Milouz le coach/consultant

 

Maintenant que nous savons pour qui nous écrivons ce livre, nous devons décider comment organiser nos journées, et là c’est l’inconnu ! Plutôt que de tergiverser pendant des heures, nous suivons une proposition de Christophe et découpons les jours ainsi :

• jours 1 et 2 : Product Increment 1 (inspiré de SAFe)
  • True North
  • 3 modules centraux de la Rocket (Management Visuel, Amélioration Continue et Flux)
• jours 3 et 4 : Product Increment 2
  • les 2 stabilisateurs de vol (Management Agile et Maîtrise personnelle)
  • les 2 boucliers thermiques (Culture Produit et Excellence de l’Ingénierie)
  • l’énergie qui alimente la fusée (la Culture)
  • le système de guidage (la vision Systémique)

La priorité est donnée aux modules principaux de la fusée, le corps, ce qui nécessite un accompagnement progressif et modulaire. L’objectif de cette priorisation est d’avoir délivré un produit de valeur pour nos utilisateurs dès la fin du 2ème jour : une fusée certes bancale qui peut dériver ou exploser en vol, mais une fusée qui vole quand même 🙂

Comme on l’explique dans nos accompagnements agiles, on ne veut pas viser une fusée qui vole à la fin des 4 jours, mais le plus tôt possible pour produire le plus de valeur possible (“en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée” comme dit le Manifeste).

Faire des choix

Nous partions dans l’inconnu, que ce soit sur le contenu pour certaines parties ou sur l’expérience d’écriture à plusieurs, et cela se confirme dès la première journée.

Après plusieurs sprints de tâtonnement, le 1er jour se termine avec un message très clair : nous prenons du retard et allons devoir rapidement faire des choix.

Alléger les modules

C’est ainsi que dès le 2ème jour, la journée avançant, nous devons faire un choix entre supprimer des modules de la fusée ou alléger le contenu des modules ?

Nous décidons finalement collectivement de supprimer des parties de module pour ne garder que l’essentiel de chaque module, guidés par les critères de valeur définis pour nos utilisateurs.

Sur cette Definition Of Done de démarrage de 1er jour (déjà allégée de quelques éléments dès le début), nous décidons donc de ne garder que le strict minimum pour servir au mieux nos utilisateurs : une question, une histoire, une démarche d’accompagnement, un template de mise en oeuvre et des exemples d’atelier.

Prioriser par la valeur apportée aux utilisateurs nous permet donc, à la fin du 2ème jour, de livrer comme prévu les 4 premiers modules de la fusée, pas l’intégralité des parties initialement prévues pour chacun de ces modules, mais bien l’essentiel pour apporter le plus de valeur à nos utilisateurs.

Exclure des modules et limiter le flux

Même cause, même effet lors du planning de l’incrément de Produit 2, où nous trouvons trop ambitieux de réaliser les 6 modules restants avec le même niveau de détail que les 4 premiers.

Nous faisons alors le choix d’exclure le module de guidage de la fusée et de réduire au minimum le module sur la Culture Produit.

Nous décidons également de limiter le flux pour ce 2ème incrément : écrire 5 pages maximum par module pour maximiser nos chances de terminer dans les temps.

Mon ressenti

Prioriser et faire des choix, c’est pas facile !

Comme décrit précédemment, à plusieurs reprises nous avons dû faire des choix et revoir nos ambitions à la baisse en supprimant des modules ou du contenu dans les modules.

Je l’ai personnellement vécu sur le moment comme un échec, quelque chose de difficile à encaisser car s’envolait l’ambition de faire un livre complet.

J’étais simplement en train de vivre ce que les équipes vivent dans des projets agiles : faire des choix, prioriser par la valeur pour ne pas faire ce qui était prévu, dire non, exclure des choses du scope initial… Quelque chose de difficile à vivre mais de nécessaire et efficace pour livrer le plus de valeur au client.

Et limiter le flux, c’est pas facile non plus !

Quelle frustration de s’arrêter au bout de 5 pages quand on a des idées pour en écrire davantage…

Quelle tentation de poursuivre sans tenir compte de la limite fixée…

Accueillir le changement

Accepter l’imprévu

Pas de changement de besoin pendant ces 4 jours… Certainement l’avantage de sprints très courts, et là aussi un beau rappel : des sprints courts permettent de limiter les changements et leur impact.

Malgré cela, des imprévus, nous en vivons. Durant ces 4 jours, l’état de forme des booksquetaires varie.

Je suis personnellement très en forme le 1er jour, excité par l’expérience, puis j’ai un gros coup de mou et de frustration pendant le 2ème jour : les sprints d’1 heure ne me permettent pas de rentrer dans ma bulle pour écrire et je n’y arrive pas. Et durant ces 4 jours, nous subissons tous plus ou moins ces frustrations et différents niveaux d’énergie.

Expérimenter de nouveaux rythmes

C’est ainsi que nous adaptons régulièrement le rythme et notre organisation afin de remplir l’objectif.

La durée des sprints est allongée pendant le 3ème jour afin de permettre à Olivier et moi d’avoir le temps de produire. Certains écrivent du contenu quand d’autres écrivent des histoires pour permettre à Greg et Julien de faire profiter le groupe de leur créativité. Un groupe produit du contenu quand un autre fait de la relecture pour obtenir un produit vraiment fini à la fin des 4 jours. 

On est même allé jusqu’au trinômage pour boucler un sprint !

Apprentissage et avantage compétitif

5 personnes qui travaillent en équipe, c’est un système complexe avec beaucoup d’imprévisible !

Nous ne pouvions pas prévoir notre état de forme, notre motivation ou notre niveau d’énergie pendant ces 4 jours.

Plutôt que de faire des plans sur la comète et de subir ces imprévus, les cycles courts et l’expérimentation de rythmes et d’organisations différents nous ont permis d’apprendre et de faire de ces changements un “avantage compétitif” : avoir du contenu plus pertinent, un produit bien fini et des histoires à mourir de rire 🙂

Livrer fréquemment et régulièrement un produit opérationnel

Livrer un produit fini

Dès le départ nous nous sommes entendus sur une Definition of Done, pour le livre globalement et pour chaque module.

Comme expliqué plus haut, nous avons dû faire des choix et supprimer des critères afin de livrer le plus de valeur pour nos utilisateurs et cela nous a permis de livrer dès la fin du 2ème jour un produit fini avec 4 modules intégrés sur un environnement stable (un répertoire dans Google Drive).

Privilégier les cycles courts

Pour le démarrage, nous avons privilégié les cycles très courts (1 heure) pour nous pousser à l’expérimentation et au feedback rapide.

Durant les 4 jours, nous avons conservé le principe de timebox et de cycle aussi court que possible, tout en les allongeant (jusqu’à 2 heures) à partir du 3ème jour pour avoir le temps de produire du contenu.

Mon ressenti

Les cycles courts et la timebox, c’est pas facile !

Très souvent j’étais en pleine écriture, au milieu d’une phrase ou d’une bonne inspiration quand j’entendais Olivier crier : “standup !!!”, mot sonnant le glas de mon inspiration… Quelle frustration !!!

S’arrêter en pleine écriture alors que je suis persuadé d’être plus efficace si je continue seul, c’est difficile, et c’est ce que vivent les équipes que j’accompagne.

La timebox est difficile à vivre mais nécessaire pour favoriser boucles de feedback et expérimentations :  c’est vrai pour une équipe qui développe un produit sur un nouveau marché, et ça l’est tout autant pour une équipe d’écrivains en herbe dont ce n’est pas le métier 🙂

Je continuerai dans quelques jours ce retour d’expérience agile avec la suite du Manifeste !