Série - Compléments édition 4

Fil des billets - Fil des commentaires

Au commencement avec Scrum, soyez shu

Je commence avec cet article une nouvelle série, qui sera constituée des compléments à mon livre pour l’édition 4 (pour les compléments à l’édition 3, voir cette série). Cette fois, les compléments vont porter sur des notions apparues dans cette nouvelle édition.

Le premier article concerne le Shu Ha Ri.

Shu Ha Ri, où j'en parle ?

L’index de mon livre indique que je cite Shu Ha Ri trois fois :

  • page 11 (chapitre Scrum dans le mouvement agile),
  • page 166 (chapitre Contextualiser Scrum) et
  • page 283 (chapitre Transformer les organisations).

Shu Ha RI, qu'est-ce que c'est ?

Shu Ha et Ri correspondent aux phases d’apprentissage d’un élève. La notion est issue du théâtre nô (il semblerait que ce soit bien plus ancien que les arts martiaux, auquel on l'associe habituellement).

La phase Shu est celle de l’imitation du maître, Ha celle du détachement et arrivé à Ri, on n’est plus un élève.

Pourquoi le Shu Ha Ri ?

Le Shu Ha Ri n’est pas une notion nouvelle dans l’agilité. Alistair Cokburn en parle depuis le début des années 2000. Mais c’est nouveau dans mon livre.

Bien que j’aie pratiqué de l’aïkido quand j’avais 20 ans, je n’étais pas emballé par ce concept, le trouvant un peu simpliste pour l’adosser à Scrum. Depuis j’ai trouvé qu’il avait une efficacité certaine auprès des personnes apprenant Scrum, pour montrer la différence entre adapter Scrum et le dénaturer.

Je l’utilise donc pour définir la façon dont on devrait apprendre Scrum en fonction de son niveau, et je l’associe plutôt à une équipe qu’à une personne.

Ce que j'en dis

Page 11

Dans ce premier chapitre, je présente l’apprentissage de Scrum comme devant suivre ces phases, et donc pour les novices, je conseille de commencer par le Shu.

Je mets aussi en garde les équipes qui font (consciemment ou pas) du Ha avant d’avoir acquis les fondations permettant de sortir du Shu. En effet, j’ai rencontré des gens qui me disaient faire du Scrum, mais qui, en fait, partant de l’idée que chez eux c’était différent, avaient cassé le cadre et perdu l’essence.

Un autre intérêt du Shu est d’éviter la confusion découlant d’apprentissages divers, par exemple apprendre en même temps Scrum et Kanban. Un risque existe aussi d’apprendre de deux instructeurs différents (ou coachs agiles) qui ne sont pas en phase.

Page 166

Le chapitre 13 intervient après la présentation détaillée du Scrum de base. C’est le moment de revenir sur l’apprentissage en rappelant ce qui constitue, dans Scrum, la fondation requise pour le Shu.

Définir à quoi correspond le Shu n’est pas trivial, car Scrum est seulement un cadre qui laisse des marges de manœuvre. Il ne s’agit pas de théâtre ou d’art martial où on comprend assez facilement ce qu’est imiter, sans prendre d’initiative.

Comme je l’explique dans ce chapitre Contextualiser Scrum, on adapte et on complète forcément, même dans la phase Shu.

Pendant le Shu, de mon point de vue, il s’agit d’acquérir les valeurs de Scrum et d’appliquer les pratiques Scrum de base (que je liste dans le chapitre 13 et qui sont, en gros, celles du guide Scrum de Schwaber et Sutherland).

Page 283

Dans le chapitre 22, j’évoque des problèmes d’organisation qui peuvent entraver l’apprentissage pendant le Shu ou lors du passage au Ha.

Un autre chapitre, Appliquer Kanban sur Scrum, présente une pratique clairement de phase Ha, dans la mesure où on se détache de Scrum. C’est pourquoi je la destine aux équipes aguerries.

Limites du concept pour Scrum

Nous avons vu que le Shu consiste à acquérir les fondations, mais qui décide qu’elles sont acquises pour le passage en Ha ? Dans les arts martiaux, c’est le maître, quand il voit que l’élève a acquis une solide fondation technique. Cela pourrait être le ScrumMaster, ou l’équipe elle-même.

Ce n’est pas évident et je pense qu’il faut rester à un usage simple du Shu Ha Ri, juste pour insister sur l’indivisibilité du cadre Scrum lors de l’initiation.

Pour aller plus loin, d’autres modèles sont nécessaires. Dans le chapitre Les gens de Scrum, je mentionne le modèle de Tuckman sur les niveaux de constitution d’une équipe. Plus loin et plus largement, je m’appuie sur le modèle Agile Fluency pour situer la maîtrise d’agilité d’une équipe. Ce sera l’occasion d’un autre article.

Butinage plutôt qu'essaimage

abeilles.jpgDans mon livre, je parle d’essaimage, en particulier dans le chapitre 9, pour nommer la façon dont l’équipe s’organise collectivement pour faire le travail du sprint. Le terme est d’ailleurs dans le glossaire de l’édition 4.

Dans le livre Honeybee Democracy de Thomas Seeley (un grand merci à @langlois_s), il est largement question d’essaimage.

Et l’essaimage est bien le reflet de l’intelligence collective des abeilles, qui font des études et prennent des décisions, par exemple pour :

  • inciter la reine à partir de la ruche,
  • décider, pour une abeille, si elle suit la reine dans l’essaim ou reste dans la ruche,
  • décider éventuellement d’un essaim secondaire,
  • une fois l’essaim accroché près de la ruche, explorer tous les lieux possibles pour habitation,
  • communiquer les résultats de l’exploration à l’essaim (avec les fameuses danses frétillantes des exploratrices),
  • décider quel est le meilleur endroit où aller (c’est prodigieux comment entre 10000 et 15000 abeilles arrivent à sélectionner, parmi parfois plus d’une dizaine explorées, la meilleure habitation),
  • implémenter la décision en partant toutes ensemble et en même temps vers le lieu choisi.

Cependant et pour revenir à mon livre, l’essaimage ressemble plus à l’organisation des équipes qu’à l’organisation du travail dans une équipe. C’est une activité faite rarement (une fois ou quelques-unes par an), comme celle d’organiser des équipes Scrum. L'essaimage, ce serait comment une équipe qui a grossi se sépare en deux équipes (parfois 3, comme je l'ai vu) et trouve ses nouveaux locaux.

L’organisation du travail dans l’équipe pour un sprint s’apparente plus à l’organisation des abeilles pour le butinage quotidien.

Des abeilles exploratrices, qui sont en fait des anciennes ouvrières, recherchent les meilleurs endroits de nourriture. De retour à la ruche, par la danse frétillante, elles communiquent la direction, la distance et, par l’intensité de la danse, la valeur que la zone explorée apporte à la ruche, de leur point de vue.

C’est à partir de ces indications que la colonie décide, collectivement, du nombre d’ouvrières qui vont aller butiner dans cette zone. Les informations sur la zone sont ajustées à chaque retour à la ruche (un peu l’équivalent de la mêlée). Le butinage se poursuit jusqu’à ce que la zone soit complètement exploitée (équivalent de la story finie).

Il peut cependant arriver que le butinage sur la zone soit arrêté avant, si un danger est détecté (par exemple une araignée ou horreur ! un frelon asiatique). Cette information (l’équivalent de l’obstacle qui bloque le travail) est donnée par des coups de tête dans l’abdomen des danseuses. Une ouvrière ainsi informée va alors aller dans une autre zone de butinage, que les exploratrices continuent à rechercher et qui sont re-priorisées régulièrement en fonction des événements.

L’organisation du butinage est véritablement collective. On ne voit pas, par exemple, une ouvrière qui décide de partir toute seule à la découverte d’une fleur qu’elle aime bien (ça peut vous évoquer des comportements dans une équipe Scrum).

Dans ce système complexe qu’est la ruche (ou l’essaim), il n’y a bien sûr pas de chef (non, surtout pas la reine).

rucher.jpg Le rucher familial, à Boncourt

Décider qu'une story est prête

6D1.png

Début juin 2015, en pleine écriture de mon livre, je n'avais encore que 4D et demi. Dans l'édition 4, il y a bien les 6, pages 82 et 83, chapitre Affiner le backlog. Voici l'extrait qui en cause :


C’est l’équipe qui décide si une story est prête. Pour prendre sa décision, elle pourra s’appuyer sur une liste de vérifications, la définition de prêt.

La définition de prêt est élaborée par l’équipe et dépend du contexte. Une façon simple pour démarrer est de se baser sur 6 caractéristiques de la story, les « 6D »

Les « 6D »

  1. Désirable : pour être sûr que la story apporte de la valeur à quelqu’un.
  2. Décomposée : ce n’est plus une story épique.
  3. Débattue : elle a été discutée en équipe lors des séances d’affinage, au cours de conversations.
  4. Dérisquée : néologisme pour signifier que les risques sur cette story ont été réduits.
  5. Elle possède une définition de fini : pour qu’elle soit prête, c’est bien de savoir ce qui permettra de dire qu’elle est finie.
  6. Démontrable : on saura la montrer à la revue, lors de la démo.

Exemple avec la story Ajouter un parcours de promenade de chien

  • Désirable : Kevin, le directeur commercial, y tient beaucoup pour ses clients urbains.
  • Décomposée : Ce n’est plus une épique, sa taille est de 2 points.
  • Débattue : Le 18 juin, lors de la séance d’affinage.
  • Dérisquée : Laurent, l’expert de la cartographie, est disponible 3 jours.
  • Définition de fini : C’est une user story, qui reprend les vérifications de fini pour ce type de story.
  • Démontrable : La condition d’acceptation positive d’ajout de parcours après la promenade est décrite.

Ces 6D servent de guides lors des conversations d’affinage.

La vie d'une story

Les 5C +1

Après les 6D, les 6C.

Dans mon livre Scrum, chapitre Structurer le backlog, page 74, je présente le workflow de la story. Extraits :


En 2001, Ron Jeffries définissait la vie de la story avec trois phases : la carte comme moyen de l’identifier, puis une conversation et enfin une confirmation. Cela est connu comme les « 3C » .

En fait, avec Scrum, l’équipe déroule deux cycles de conversation et confirmation : un premier pour obtenir une story prête, un second pour qu’elle soit finie.

On passe à 5C :

  1. Un jour, quelqu’un a une idée de story et la note sur une Carte (maintenant on utilise plutôt une note Collante).
  2. Le Product Owner et l’équipe affinent cette story, afin qu’elle puisse être réalisée en un sprint, au cours d’une Conversation.
  3. L’équipe apporte sa Confirmation qu’elle est prête (elle peut se baser pour cela sur les 6D).
  4. L’équipe réalise la story pendant un sprint, en tenant une nouvelle Conversation avec éventuellement le Product Owner, sur son acceptation.
  5. Le Product Owner (ou l'équipe) apporte sa Confirmation qu’elle est finie.

En se basant sur ces « 5C », on obtient le workflow de la story :

La vie de la story


Mais quel est donc ce 6e C sur la carte heuristique ?

Dans son excellent livre Le Story Mapping, page 122 dans la version française, Jeff Patton s'appuie aussi les 3C, différemment car il ne se réfère pas à Scrum. Il ajoute à la fin de la vie de la story les conséquences, c'est à dire les feedbacks issus des parties prenantes.

Conséquence, cela fait le 6e C ou plutôt le +1 aux 5C.

Les experts, des parties prenantes qui aident l'équipe Scrum

Le besoin d'un expert

Scrum étant construit sur la notion d'équipe, il est important de savoir qui est dedans et qui est dehors. On distingue ainsi les membres de l'équipe (PO, SM et DEV) des parties prenantes (PP).

Dans un cadre idéal, l'équipe est pluridisciplinaire. Cependant, elle l'est rarement complétement. Apparaît alors un autre rôle, celui d'expert.

Je le définis ainsi dans le glossaire de la 4e édition de mon livre :

Un expert est une personne, à l’extérieur de l’équipe, qui possède des compétences nécessaires à l’équipe pour réaliser un travail d’un sprint.

Le rôle d'expert fait l'objet du §3.5 dans le nouveau chapitre 3 Les gens de Scrum, extrait :

  • Un expert est une partie prenante qui aide l’équipe à produire un résultat.
  • Il dispose de compétences que l’équipe ne possède pas.
  • À la demande de l’équipe, l’expert participe, ponctuellement, à un sprint.
  • Il peut s’agir d’un spécialiste du métier, c’est un expert fonctionnel, ou de la solution, c’est alors un expert technique.

Le besoin d'experts est légitime dans de nombreuses situations. Mais attention, un expert crée une dépendance sur la réalisation d'une ou plusieurs stories.

J'évoquais déjà ce risque dans un billet de 2012 : validation externe.

Il convient donc de limiter et de dérisquer les dépendances.

Voici quelques pistes présentées dans le chapitre Les gens de Scrum :

  1. Constituer une équipe en ayant à l’esprit de dépendre de peu d’experts, bien identifiés.
  2. Faire entrer dans l’équipe un expert dont on a besoin régulièrement.
  3. Anticiper le besoin avant le début du sprint, c’est-à-dire ne pas commencer un travail sans s’assurer que l’expert requis est disponible (cela participe à la définition de prêt).
  4. Faire en sorte d’apprendre de l’expert pour pouvoir s’en passer.

Le dessin de Patrice Courtiade vous plaît ? Il y en a plein d'autres dans le livre.

Une matinée typique d'un ScrumMaster

Dans l'édition 4 de mon livre, j'ai ajouté des histoires pour raconter une journée typique d'un ScrumMaster et d'un Product Owner.

On commence par la matinée de Nicolas, le ScrumMaster chez Peetic.

Voici l'extrait tiré du chapitre 5 Le rôle du ScrumMaster. J'y ai ajouté, pour ce billet, des notes qui renvoient aux pratiques évoquées.


Nicolas est le ScrumMaster de l’équipe Peetic. Il a été élu sans être candidat[1], mais il a accepté avec plaisir.

C’est le troisième sprint de la release Canigou (l’équipe nomme ses releases avec les sommets des Pyrénées)[2].

Le matin, après avoir répondu à ses mails, Nicolas accueille les développeurs près de la machine à café. On discute du film de la veille puis, à 9 h 30, c’est la mêlée quotidienne[3], devant le tableau du sprint. Il s’assure que l’amélioration décidée lors de la rétrospective, faire en sorte que la mêlée ne dure pas plus d’un quart d’heure, soit réussie.

Tout de suite après la mêlée, il provoque une réunion avec Julien et « l’ingé système ». Il s’agit d’éliminer l’obstacle[4] lié au serveur de « staging » qui ne fonctionne pas encore et empêche de déployer facilement à chaque sprint.

Une fois la solution trouvée, Nicolas met à jour le tableau des obstacles[5]. Ouf, il n’y en a plus que trois à régler[6]. En passant, il regarde si les tâches ont bien été mises à jour après la mêlée. C’est bon.

En début d’après-midi, comme tous les mercredis, ce sera la réunion d’affinage du backlog[7]. Il a une conversation brève avec Céline le PO[8], afin de s’assurer qu’il y aura de quoi alimenter l’équipe pour le prochain sprint, pour éviter les à-coups dans le rythme.

À midi, il part courir au bord du canal[9].


canalHiver.jpg

À suivre.

Notes

[1] l'élection sans candidat vient de la sociocratie

[2] §2.3.4 page 25 conseil : nommer les releases

[3] la mêlée quotidienne fait l'objet du chapitre 10

[4] §10.1.1 page 122 un obstacle bloque ou ralentit le bon déroulement d'un sprint

[5] le tableau des obstacles, artefact du management visuel, est présenté §17.3.2 page 218

[6] le suivi des obstacles peut faire l'objet d'un indicateur, §18.2.2 page 231

[7] l'affinage du backlog fait l'objet du chapitre 7, la réunion d'affinage fait partie des événements du sprint

[8] le rôle du Product Owner fait l'objet du chapitre 4, et sa journée typique fera l'objet d'un prochain billet

[9] l'occasion de méditer sur la notion de rythme soutenable

Une après-midi révélatrice de ScrumMaster

Dans l'édition 4 de mon livre, j'ai ajouté des histoires pour raconter une journée typique d'un ScrumMaster et d'un Product Owner.

Voici la deuxième partie avec un extrait tiré du chapitre 5 Le rôle du ScrumMaster.

Nous avions laissé Nicolas, qui tient ce rôle dans l'équipe Peetic (le site de rencontres pour animaux de compagnie), au bord du canal, pour une séance de jogging, après une belle matinée de ScrumMaster.


Le temps de prendre la douche et la pâtée, c’est l’heure de la réunion d’affinage[1]. On y a invité Laurent, l’expert en cartographie, car il y a des stories à affiner sur ce sujet . Mais Laurent a dû oublier, il n’est pas là ! Nicolas l’appelle et apprend qu’il a une urgence. Il négocie sa venue pour un quart d’heure. On change un peu l’ordre des activités de la réunion pour saisir le créneau, c’est important qu’il soit là. Finalement, l’affinage se passe bien, il y a suffisamment de stories prêtes, Nicolas en compte 10.

Après la réunion, il reste avec Céline le PO[2] pour mettre à jour le plan de release, qui a été pas mal touché par le travail d’affinage. Mais il est appelé par Sébastien qui lui annonce que le serveur de développement est en rade. Il laisse Céline finir et file voir Sébastien. Bon, pas trop grave, il suffisait de relancer le serveur.

Il a un peu de temps avant sa réunion pour analyser les raisons profondes du gros bug de la semaine dernière, alors il passe voir l’essaim[3] qui s’occupe de la story « Modérer les photos de chien ». Il aide en passant deux vérifications de sa définition de fini[4]. La story va être finie ce soir !

Il anime la discussion sur le gros bug, en proposant les 5 pourquoi pour remonter à l’origine du problème. Mmm, il semble qu’il faudrait ajouter une règle de codage.

Lors de la mêlée du matin, il a deviné qu’Émilie avait des soucis. Il va la voir, avant qu’elle parte. OK, il arrive à comprendre qu’elle est en conflit avec David, il ira lui parler demain. Faudra qu’il pense à proposer un niko-niko[5] à la prochaine rétrospective pour, peut-être, anticiper ce genre de situation.

Avant de partir, il consulte ses messages et voit une demande de Kevin qui voudrait emmener Julien, dès demain et pendant 2 jours faire des démos chez des clients. Après une discussion franche, il dit non, cela remettrait en cause l’objectif du sprint.


Notes

[1] L'affinage du backlog fait l'objet du chapitre 7

[2] Le rôle de Product Owner est décrit dans le chapitre 4

[3] le groupe de développeurs qui butine sur une story

[4] La définition de fini fait l'objet du chapitre 8

[5] anonyme, avec Teammood

Une journée de Product Owner

Dans l'édition 4 de mon livre, j'ai ajouté des descriptifs d'une journée typique d'un ScrumMaster et d'un Product Owner.

Après Nicolas, le ScrumMaster chez Peetic, c'est le tour de Céline, la productoneuse.

Voici l'extrait tiré du chapitre 4 Le rôle du Product Owner[1] . J'y ai ajouté, pour ce billet, des notes qui renvoient aux pratiques évoquées.


Céline tient le rôle de Product Owner de l’équipe Peetic.

Collaborer avec l’équipe

En tant que PO, Céline n’est pas simplement le représentant des clients et des utilisateurs dans l’équipe. Elle est aussi membre de l’équipe et participe activement aux travaux pendant un sprint[2].

La présence physique du PO avec l’équipe a un impact sur son rôle :

  • La situation idéale est un PO installé avec l’équipe, dans le même espace de travail. Cependant, il suffit qu’il soit assez proche pour que l’équipe puisse aller le voir et lui demander des précisions, et dans l’autre sens, pour qu’il puisse rencontrer facilement l’équipe.
  • Si le PO est à distance et ne voit pas physiquement l’équipe, la mise en œuvre du rôle sera plus délicate, mais il existe des solutions pour pallier son manque de présence physique.

En collaborant avec l’équipe, Céline apprend à écouter ce qu’ont à dire les développeurs. Elle comprend mieux leurs préoccupations de délai et de qualité[3]. Ainsi, elle sera moins encline à leur imposer une pression négative en les poussant à livrer toujours plus de fonctionnalités[4].

S’impliquer dans l’acceptation du fini

Comme il est moteur pour établir ce que doit faire le produit, il est logique que le PO fournisse aussi les conditions qui permettront de s’assurer que ce qu’il demande est bien terminé.

Lors des séances d’affinage[5], Céline a formulé à l’équipe le comportement qu’elle attend d’une fonctionnalité. Ensemble, ils ont identifié une condition d’acceptation. C’est en vérifiant que cette condition est satisfaite qu’elle s’assure de sa bonne fin.

Utiliser le produit

Céline aime son produit. Elle l’utilise tous les jours, ce qui l’incite à en faire un bon produit. Cela lui permet de discerner la valeur ajoutée par les fonctions dans le backlog.

Bien connaître son produit lui donnera une position respectée par tous et facilitera ses prises de décision.

C’est aussi dans sa mission de faire des démonstrations à l’extérieur et de présenter le produit aux utilisateurs. Elle en profite pour valider les hypothèses sur les nouveautés qu’elle envisage d’inclure dans le produit.

Impliquer les parties prenantes

Céline est imputable du résultat auprès des parties prenantes : pour bien exercer son rôle, elle doit communiquer avec elles.

Cela concerne non seulement les utilisateurs du produit final, mais aussi les clients comme les vétérinaires, et Gilles et Mona, bien sûr. Elle les invite à la revue[6] de chaque fin de sprint. Elle doit les inciter fermement, car la revue est un moment d’inspection collectif de l’état du produit.

Notes

[1] dans le livre, je n'écris pas productoneur. J'aurais peut-être dû. J'avais vraiment essayé productoneur et cela est repris dans un livre qui va sortir !

[2] et elle vient à la mêlée quotidienne, ce qui est recommandé pour le PO chaque fois que c'est possible, voir le chapitre 10. Elle participe également à la rétrospective, chapitre 12

[3] et elle en tient compte pour la planification du sprint, chapitre 8 et pour la planification de release, chapitre 16

[4] ce qui a tendance à provoquer de la dette technique

[5] l'affinage du backlog fait l'objet du chapitre 7

[6] la revue de sprint fait l'objet du chapitre 11

Développer un produit avec plusieurs équipes Scrum

C'est le titre du 21e chapitre de la 4e édition de mon livre Scrum. Cette dernière édition, sortie il y a un an, marche bien ; alors peut-être que quelques lecteurs sont arrivés jusqu'à ce chapitre…

Je m'adresse à eux, qui ont lu ce chapitre, sur lequel j'aimerais bien avoir du feedback, car je l'ai réécrit presque entièrement, avec un positionnement de type "retour ô sources", pour reprendre le thème d'Agile tour Toulouse cette année.

Ou, pour le dire autrement, je me place clairement sur une ligne anti néocons pour reprendre un thème de ma présentation Scrum ? mon scrotum !

Voici ce que je dis en introduction du chapitre Développer un produit avec plusieurs équipes :


Le chapitre « Scrum à grande échelle » avait été ajouté lors de la deuxième édition de ce livre. Depuis, le sujet a pris de l’ampleur, des frameworks ont été proposés, « commercialisés », c’est-à-dire accompagnés de leurs inévitables certifications, et comparés dans les conférences.

De mon côté, j’ai expérimenté ce passage à l’échelle dans plusieurs situations. Et ma position a changé : je suis revenu à plus de simplicité, plus de Scrum, dirais-je. À mon sens, le Scrum à grande échelle doit rester dans l’esprit, par exemple en évitant de créer de nouveaux rôles.

Pour être plus clair sur l’objectif de ce chapitre, je l’ai renommé. En effet, le scaling Scrum est devenu un sujet fourre-tout, qui regroupe des préoccupations bien différentes.

Dans mon livre, j’ai choisi de différencier le Scrum pour développer à plusieurs équipes, qui fait l’objet de ce chapitre, de l’agilité pour transformer les organisations, qui sera abordée dans le chapitre suivant.


Voici le plan de ce chapitre 21 :

Ch21e_d4.png