Mot-clé - feature

Fil des billets - Fil des commentaires

Équipes features façon puzzle

Je continue avec mes retours d'expérience sur l'atelier Puzzle grand Scrum que j'ai animé une quinzaine de fois.

Après des discussions sur par quoi commencer et sur la synchronisation des sprints, revenons sur l'organisation des équipes.

Pour réaliser le puzzle avec 3 équipes, on a besoin de définir sur quoi chacune va travailler.

Nous sommes dans le cas où il n'y a qu'un seul produit et je fournis au participant au jeu un seul backlog, sous la forme de 20 features (ou stories peu importe). Nous avons vu dans un épisode précédent comment ça se passait pour définir l'ordre dans ce backlog.

Les participants disposent également d'un tableau préparé, avec un colonne (ou une ligne) pour y mettre les features prêtes. Je leur dis simplement que pour y mettre un élément, il conviendrait de lui associer l'équipe ou les équipes qui vont le développer.

Le tableau de features est un outil de management visuel qui reste unique même quand le produit est gros et que plusieurs équipes y travaillent.

Dans le Scrum multi-équipes mono-produit, il y a donc une activité supplémentaire d'affinage, qui est de définir cette association entre une équipe ou plusieurs et une feature.

Dans le jeu, la plupart du temps, on a associé une feature à une seule équipe. C'est pour former ce qu'on appelle les "feature teams". À noter que je ne dis rien, quand j'anime le jeu, qui pousse les joueurs dans ce sens, ce qui laisse à penser que la notion est familière aux participants.

Il y a eu cependant quelques exceptions, en général au début et à la fin du jeu. Parfois, au début, comme lors du dernier Raid, il est d'abord prévu de mettre 2 équipes sur une feature. En général, cela ne dure pas et quand le sprint démarre, la feature est faite par une seule équipe.

Pourtant, en ayant suivi tous ces puzzles, je pense que le tri des pièces pose des problèmes aux équipes features. Sans un tri grossier, c'est difficile de savoir si on pourra assembler et intégrer un personnage dans un sprint. C'est un peu l'équivalent de l'infrastructure dans les gros projets, qui pousse parfois les organisations à choisir des structures hybrides, avec une component (ou infra) team à côté des features teams.

Ce ne serait pas une bonne idée d'avoir une équipe tri pour toute la durée du puzzle. En tout cas, personne ne l'a fait dans les ateliers que j'ai animés. Mais on peut ajouter des features de tri au backlog, qui seront prises par les features teams, en plus de leurs features à valeur client. C'est arrivé, mais seulement 2 fois sur les 15.

Feature tri ajoutée

À la fin du jeu par contre, dans le 4e sprint, il y a une volonté collective de faire participer toutes les équipes à la réalisation d'une seule feature. Il faut dire que les circonstances ont changé (héhé).

Sur quoi se base le choix de mettre telle ou telle équipe sur une feature ?

Dans le jeu, il arrive qu'une équipe soit associée à une zone du puzzle et ensuite s'occupe de tous les personnages de cette zone. Ce critère de choix se retrouve sur les projets, quand on donne à une équipe un domaine fonctionnel (dans LeSS, on retrouve cette idée avec les requirements areas). Sinon la plupart du temps, le choix se fait de façon opportuniste, sans réelle stratégie.

Qui décide du choix d'une équipe pour une feature ? Nous le verrons dans un prochain épisode sur le volet PO et Cie.

Glossaire E-F

L'édition 4 de mon livre comporte, et c'est nouveau, un glossaire.

Voici les entrées pour E et F :


  • Epic ou story épique : story dont l’équipe considère qu’elle est trop grosse pour rentrer dans un sprint en l’état.
  • Équipe auto-organisée : équipe qui possède le pouvoir de décider comment faire le travail.
  • Équipe pluridisciplinaire : équipe qui possède, collectivement, toutes les compétences requises pour développer le produit.
  • Équipe Scrum : groupe de gens auto-organisé et pluridisciplinaire qui réalise un incrément de produit à chaque sprint.
  • Essaimage : organisation de l’équipe pendant le sprint qui consiste à se mettre à plusieurs pour finir vite une story.
  • Expert : personne, à l’extérieur de l’équipe, qui possède une compétence nécessaire à l’équipe pour achever une ou plusieurs stories d’un sprint.
  • Feature : service ou fonction d’un produit dont l’énoncé est clair pour les parties prenantes ; une feature contribue à un impact et se décompose en stories.

Ce qui a suscité le plus de discussions avec mes relecteurs est la définition de feature. Il m'a fallu y insérer 2 parties séparées par un point-virgule. La deuxième permet de montrer ses relations, ce qui m'a semblé important pour une bonne compréhension. La formulation "dont l'énoncé est clair" révèle, au-delà de la subjectivité dans l'identification d'une feature, qu'elle est destinée à des parties prenantes (utilisateurs le plus souvent).

L'expert est un des deux rôles externes à l'équipe, avec la partie prenante. L'équipe et ses rôles (PO, SM, DEV), la partie prenante et l'expert sont présentés dans le nouveau chapitre 3, "Les gens de Scrum".

Définition de fini multi-niveaux

La définition de fini est le plus souvent une simple liste. Pour être plus pertinent, on peut définir plusieurs niveaux de fini, et pour être plus complet, plusieurs aspects de la finition.

Définition de fini multi-niveaux multi-aspects

Lire la suite...

Session d’affinage et affectation des features (SAF)

Le passage à grande échelle avec des features teams demande une prise de décision supplémentaire : le choix de l'équipe qui va réaliser une feature.

Comme pour les travaux d'affinage sur les stories, il est souhaitable que cela se fasse autour de conversations, mais impliquant cette fois toutes les équipes.

C'est l'objet des sessions d'affinage et d'affectation des features.

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...

Finir une story c’est bien, finir une feature c’est mieux

Arrêter de commencer, commencer à finir. Mais pas seulement.

Lire la suite...

La vie d'une feature

Une feature est un service, observable de l'extérieur, qui contribue à un impact, et dont la description se situe à un niveau tel que toutes les parties prenantes comprennent facilement ce dont il s'agit.

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...

Chapitre treize

gary_langue.jpgLe chapitre 13 de mon livre Scrum s'appelait "De la vision aux stories" dans les deux éditions précédentes. Dans cette nouvelle édition, il devient "De la vision aux features", les stories ayant été poussées dans le chapitre suivant.
Il a été presque entièrement réécrit, pour incorporer les nouveaux outils du Product Owner, ceux que j'ai présentés le mois dernier lors du ScrumDay 2014.

Je me souviens, j'étais en train de finaliser ce chapitre il y a juste un an pour le pont du premier Mai. J'en profite pour remercier ceux qui m'ont bien aidé à l'époque, par leurs conseils et leur feedback : Nicolas Deverge, Pablo Pernot, Laurent Meurisse, Romain Couturier et Jean Lestang. J'espère que je n'oublie personne.

Lire la suite...

De la vision à la story

De la vision à la story

Les notions manipulées pour aller de la vision à la story, avec quelques techniques de définition de produit pour y arriver.

Impact Mapping, Innovation Games, Story Mapping, Revue de backlog, Spécification par l'exemple font l'objet d'ateliers ou jeux dans mes formations Scrum et Product Owner.

- page 1 de 3