Mot-clé - scalabilité

Fil des billets - Fil des commentaires

L'agilité à grande échelle

22-2-changer_dechelle_-_pompiers.jpg

Il faut un vrai besoin pour changer d’échelle.

Dessin de Patrice Courtiade et légende extraits de Scrum, le guide etc. page 278

Lire la suite...

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

Lecture au klub : Lean Entreprise

Le livre choisi pour le klub d'octobre était donc : Lean Enterprise: How High Performance Organizations Innovate at Scale de Jez Humble, Joanne Molesky, Barry O’Reilly.

Lire la suite...

Scrum éparpillé façon puzzle

En 2014, j'avais essayé un jeu de simulation de Scrum, avec un puzzle ; il mettait l'accent sur l'affinage et la présentation du backlog en bacs[1], c'était donc le jeu des bacs.

Début 2015, j'avais expérimenté une variante pour simuler du Scrum à plusieurs équipes.

Cette variante a reçu un très bon accueil, ce qui fait que je l'ai animée de nombreuses fois. J'ai eu du mal à lui trouver un nom. Cela a d'abord été "Astérix et la grande échelle de Scrum" parce que j'utilisais le puzzle "Le village gaulois".

Finalement c'est "Puzzle grand Scrum".

Un atelier que j'ai animé une quinzaine de fois :

  • au cours des jeux agiles de l'IPI à Blagnac,
  • à Agile Games France 2015 à Bazas,
  • au ScrumDay 2015,
  • à Agile tour Montpellier,
  • à Agile tour Toulouse,
  • au cours des 4 derniers Raids Agiles (animation avec Pablo aux manettes pour les rétros),
  • dans 5-6 autres formations Scrum.

À raison de plus de 2 heures par session, cela m'a permis de collecter plein de comportements intéressants sur, par exemple, la notion d'équipe feature, le rôle de Product Owner, l'auto-organisation et le ScrumMaster, l'affinage multi-équipes, les démos et les rétrospectives, la définition de fini. Je vais en restituer quelques-uns, en commençant par la façon de prioriser.

Mais avant, et en rappelant que l'objectif de l'atelier est de simuler la réalisation d'un seul produit avec 3 équipes, une réaction émerge parfois, et c'était en particulier le cas lors du dernier Raid, qui est : "ce serait plus facile avec une seule équipe". C'est probablement vrai pour le puzzle, mais c'est aussi une question légitime pour du développement de logiciel. Le passage à l'échelle complique les choses et il vaut mieux l'éviter chaque fois que c'est possible.

Ceci étant dit, voyons ce que donne le jeu avec 3 équipes, sur la question : par quoi commencer le puzzle ?

Par le cadre

L'envie de commencer le puzzle par le cadre arrive fréquemment, c'est comme cela que cela se fait d'habitude pour un puzzle. L'exercice pousse à changer cette habitude (le cadre n'a pas de valeur métier, on ne fera pas tout le puzzle et j'insiste sur cela) et certains ont du mal. Cela provoque des discussions avec le PO sur la priorité à donner. Parfois les partisans du cadre l'emportent (pas bien loin, car le cadre ne survit pas à la première démo).

Je rappelle que je fournis au début du jeu une liste de 20 stories (ou features, peu importe ici) et pour chacune la valeur métier que je lui donne. Dans cette liste, il n'y a pas de cadre, qui nécessiterait pour être réalisé plusieurs stories, toutes de faible valeur.

Par le tri

Il est arrivé que le backlog soit enrichi de nouvelles cartes genre tri des pièces. C'est assez rare ; en général, cela vient dans la conversation mais n'est pas accepté par les partisans de la valeur métier.

Une story "tri" n'apporte pas de valeur métier, mais on peut considérer qu'elle apporte de la valeur à l'équipe. Cela correspond à une story technique.

Il est probable que si je ne fournissais pas une liste prédéfinie, il y aurait plusieurs stories techniques de ce genre dans le premier sprint.

Par un personnage

La logique utilitariste voudrait que ce soit Astérix qui soit fait en premier, puisque c'est le personnage qui a le plus de valeur. Dans l'atelier, on ne fait pas d'estimation de la taille des personnages (ni de l'effort pour les réaliser), mais c'est assez facile à imaginer avec la surface que prend ce personnage dans l'image du puzzle. Même en utilisant le ratio valeur / taille, c'est toujours Astérix qui semble prioritaire. La différence avec Obélix est flagrante, qui rapporte moins de valeur et qui est plus gros enveloppé.

Pourtant, ce n'est pas toujours Astérix qui est choisi en premier. Par exemple, lors du Raid Agile #5, Richard, qui était le PO, a demandé Bonnemine en premier. Pour lui, c'était mieux de commencer comme ça. Richard n'est pas utilitariste, il a fait parler son cœur (à la démo du premier sprint, il a un feedback rude des parties prenantes).

tableau du puzzle au début

Pendant le jeu, tout cela provoque des conversations et c'est le but. La façon dont est prise la décision sur la priorité, dépend finalement du ou des PO (j'ai essayé le jeu avec différentes configurations), c'est un sujet sur lequel je reviendrai.

Dans un prochain article, je parlerai aussi de la définition de fini. Astérix fini, est-ce bien clair pour tout le monde ce que cela signifie ?

Note

[1] notion qui est présentée en détail dans mon livre, chapitres 7 et 8

Taille et stabilité d'une équipe Scrum

On a vaincu la loi de Brooks.

Lire la suite...

Scrum en grand : LeSS, SSwS, Nexus et le rôle de Product Owner

« Développer un produit avec plusieurs équipes »  est le titre du 21ème chapitre de mon livre Scrum, édition 4. Quand plusieurs équipes travaillent sur le même produit, un point délicat est la mise à l'échelle du rôle de Product Owner ainsi que l'affinage à haut niveau.

Ken Schwaber vient de publier le guide Nexus, son framework de Scrum à grande échelle. Un de plus ! Cela en fait trois, au moins, qui se revendiquent de l'esprit Scrum : Nexus, SSwS et LeSS. Ils sont relativement proches, mais avec quelques nuances dans les propositions au sujet du PO et de l'affinage.

Voici un petit comparatif, avec illustrations pour trois équipes.

LeSS

LeSS pour Large-Scale Scrum, c'est le plus ancien et le plus avancé.

LeSS

Dans sa version simple (il existe aussi un LeSS "huge"), il y a un seul PO pour plusieurs équipes. Pour l'affinage, le PO travaille avec un représentant de chaque équipe.

SSwS

SSwS pour Scaled Scrum with Scrum, le plus Scrum.

Scaling Scrum with Scrum

Chaque équipe conserve son PO. Une nouvelle équipe apparaît, composée de ces PO et d'un chef PO. C'est une équipe Scrum, mais sans SM, qui est dédiée au management du produit. C'est elle qui s'occupe de l'affinage de haut niveau.

Nexus

C'est le petit dernier, mais par un créateur de Scrum.

nexus.png

Comme dans LeSS, un seul PO pour plusieurs équipes. Il fait partie d'une nouvelle équipe, appelée équipe d'intégration. Le SM et les DEV de cette équipe peuvent aussi faire partie d'une autre équipe. Cette équipe d'intégration s'occupe des outils et pratiques …d'intégration, mais aussi de la transition à Scrum, de la définition de fini. Pas spécialement de l'affinage qui est accompli, comme dans LeSS, par le PO et des membres des équipes.

À noter que Nexus a un TM accolé à son nom, pour SSwS c'est un R entouré… et que LeSS possède déjà ses certifications… Pfff !

Rassurez-vous, je ne propose pas un framework de plus dans mon livre. Quand le contexte s'y prête, je suis enclin à privilégier une organisation des équipes qui se rapproche de SSwS. Mais, à mon avis, le choix dépend tellement des gens en place, de la situation courante, de l'organisation, qu'il me paraît dommage de se cantonner à un seul pattern.

D'ailleurs, l'atelier à base de puzzle que je donne pour illustrer le Scrum à plusieurs équipes a déjà vu les participants essayer un de ces trois patterns : un seul PO et un représentant de chaque équipe (LeSS), un groupe de PO avec un superPO (SSwS) et une équipe d'intégration (Nexus).

Passer à l'échelle avec Scrum

Workshop le 2 juin à Toulouse.

Lire la suite...

Tableau de features à grande échelle

Un tableau de features permet de montrer la décomposition du travail à faire et l'affectation aux différentes équipes dans le cadre d'un Scrum à grande échelle.

Lire la suite...

Chapitre dix-neuf

Le chapitre 19 de mon livre s'appelle "Scrum à grande échelle". C'est un sujet délicat.

Lire la suite...

La présentation AgilEuclid au ScrumDay

Vous trouverez en fichier attaché le support de la session « Expérimentation de l’Agilité pour un grand projet scientifique spatial » présentée à 3, avec Maurice Poncet (Cnes) et Laurent Meurisse au ScrumDay 2013[1].

L’objectif de la mission Euclid est de cartographier la géométrie de la matière noire et de l’énergie sombre.

Euclid est un projet, sous l’égide de l’ESA, dont les instruments et le segment sol scientifique sont réalisés par un consortium européen regroupant les principales agences spatiales nationales et laboratoires scientifiques, dont le Cnes.

C’est actuellement un des plus grands projets scientifiques en cours.

L’objectif de l’expérimentation est d’évaluer la faisabilité d’une approche agile pour le segment scientifique sol d’Euclid, puis de préparer sa mise en place pour le développement. Il s’agit de modéliser l’univers inconnu et cela passe par le traitement d’un nombre très important de données.

Pour cette étude, nous sommes trois coachs agiles : Laurent Meurisse et Nicolas Deverge, tous les deux d'Ekito, m'accompagnent. C'est un plaisir de travailler avec Lolo et Niko. Nous faisons vraiment du coaching en commun : pour toutes les réunions et ateliers, nous sommes toujours au moins deux et la plupart du temps nous faisons les sessions de travail à trois.

L'étude est elle-même menée de façon agile, nous finissons actuellement le 6ème sprint.

Note

[1] Nous avons aussi été filmés et interviewés.

- page 1 de 2