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.
Quand décider quelle équipe s'occupe de quelle feature ?
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.
Qu'est-ce qui change dans ce tableau quand on passe à Scrum à l'é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.
Arrêter de commencer, commencer à finir. Mais pas seulement.
Il y a quelque temps, j’avais audité un projet dont le tableau de features, s’il avait été fait], aurait ressemblé à peu près au schéma (il y avait à la place un gros tableau excel avec des calculs précis —mais faux— d’avancement donnant des % de finition par 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.
Le chapitre 19 de mon livre s'appelle Scrum à grande échelle. C'est un sujet délicat.
Le but du chapitre est présenté dans l’introduction :
On peut distinguer trois niveaux pour la prise en compte de l’agilité dans des organisations : projet, produits, organisation. Beaucoup d’expériences actuelles avec Scrum restent au niveau projet. Nous allons approfondir les niveaux produits et organisation. J’ai évoqué, dans le chapitre 18, Transition à Scrum, la façon dont une entreprise gérait le changement vers l’agilité. Ici, il s’agit d’aborder le changement d’échelle dans ce qu’il implique sur la mécanique de mise en œuvre de Scrum, en termes d’équipes, de backlogs et de cycle de vie.
Le 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.
Les notions manipulées pour aller de la vision à la story, avec quelques techniques de définition de produit pour y arriver.
Ce quadrant montre 5 outils et 6 concepts situés dans 4 cases.
On développe un produit dans le but de satisfaire les partie-prenantes (clients, utilisateurs). Ces stakeholders ont des besoins. On répond à ces besoins en développant des features, qui se décomposent en stories.
Pour arriver au plus petit ensemble ayant de la valeur pour un client
Quand on démarre le développement d’un nouveau produit, une étape significative est d’élaborer une liste de features, de les prioriser puis d’identifier les stories des features les plus prioritaires.
Ensuite le développement se planifie sur les sprints et les releases. Dans le billet Features et stories, avec un schéma carré, j’expliquais : “Une story est planifiée dans un sprint et une feature dans une release.”
J’y montrais aussi le cycle de vie d’une feature, qui est finie une fois qu’elle est livrée.
Vous aimez bien les jeux agiles, mais, comme fierfeu qui l’a mis en commentaire sur le billet de la formation de janvier, vous voulez savoir si on peut les articuler.
Estimer les features indépendamment pour mieux les ordonner, les estimer avec les stories pour mieux planifier ou bien ne pas les estimer du tout (pour éviter de perdre du temps) ?
L’usage courant est de définir un élément du backlog de produit comme étant une story. Dès qu’on sort de la toute petite échelle, on a besoin d’un élément de plus haut niveau, habituellement c’est la notion de feature qui y répond.
Pour définir la vision et d'arriver rapidement à la constitution du backlog initial
Mes amis Fabrice et Alex parlent ces jours-ci, sur leur blog, des jeux collaboratifs qu’on peut faire avec les clients pour créer des produits innovants. Ces jeux sont excellents en coaching.
Utilisés pendant les formations, ils sont aussi très efficaces pour apprendre, en pratiquant par petits groupes. A partir des Innovation Games de Luke Hohmann cités par mes camarades, mais aussi avec d’autres inspirations comme Mike Griffiths, j’ai adapté plusieurs de ces jeux pour les faire rentrer dans le cursus de ma formation de 3 jours.
IBM Toulouse organise le 10 Novembre prochain, sur le site de la Plaine, un séminaire sur l’agilité au-delà du projet, pour des produits qui évoluent longtemps, font partie de programmes ou d’une famille de produits ou sont inclus dans un portefeuille de produits
J’aurai le plaisir de faire la présentation sur ce sujet et je dispose d’une bonne partie de la matinée.
Les premiers inscrits recevront un exemplaire de mon livre « SCRUM : le guide pratique de la méthode agile la plus populaire » publié aux Éditions DUNOD, qui leur sera remis le jour du séminaire.
Une feature est décomposée en stories. Une story est planifiée dans un sprint et une feature dans une release.
Imaginez que vous développez une application comme Dotclear mon moteur de blog, mais qui n’offrirait pas encore la gestion des tags, ni la possibilité d’attacher un fichier à un billet.
Gestion de tags et attachement de fichiers sont des features. Pour savoir à quel moment on les développe, on s’intéresse à leur utilité et on estime l’effort de développement nécessaire. Cela aidera pour définir leur priorité.
Neige à Toulouse, mon déplacement à Paris est annulé
C’est l’occasion de faire un tutoriel IceScrum. Celui-ci porte sur la façon dont l’outil aide à gérer différents niveaux d’exigences et produire le backlog de produit.
La nouvelle version d’IceScrum, qui s’appelle R2#9, facilite la définition de produit avec les features et les rôles d’utilisateurs qui complètent le backlog de produit.
Ce petit tutoriel vous aidera à expérimenter IceScrum sur ces nouveautés permettant d’avoir une meilleure vision du produit. Pour bien comprendre les termes utilisés, une lecture de ce billet peut être utile avant de commencer.
