Posté par jc-Qualitystreet le 27 février 2012
Un titre qui peut vous sembler exagéré… et pourtant ce RDV en cours de sprint est tout simplement crucial pour l’Equipe qui se veut Agile !
Mon message est clair :
Sans Backlog Refinement, vous n’atteindrez pas cette agilité bien huilée que vous recherchez et ces résultats que vous attendez
et simple :
Ceux qui le négligent, ceux qui l’oublient le paient inévitablement ; ceux qui l’adoptent et le réalisent dans de bonnes conditions en redemandent…
Une équipe performante à l'oeuvre
Le Backog Refinement est un workshop qui se déroule une à deux fois par sprint, souvent à mi-sprint. Comme son nom l’indique, ce workshop est centré sur le Backlog de produit (c’est à dire la « liste de tous les éléments sources de valeur et nécessaires à l’équipe pour réaliser un produit »). Alors affinage, nettoyage, entretien, maintenance, ou en anglais « grooming », les mots varient mais j’avoue avoir une très nette préférence pour le terme Refinement, popularisé par Craig Larman.
Définitivement collaboratif, le Backlog Refinement doit impliquer tout le monde, du Product Owner (soutenu ou pas par un expert UX ou un Business Analyst), au ScrumMaster en passant par TOUS LES MEMBRES DE l’EQUIPE. Durant mes formations et mon coaching, je présente le Backlog refinement comme un must, le 5 eme RDV incontournable, qui vient s’ajouter aux 4 cérémoniaux Scrum décrits par Sutherland et Schwaber, inventeurs de la méthode Agile la plus populaire… des auteurs qui persistent à limiter la visibilité de cette activité essentielle de préparation tout en reconnaissant paradoxalement son existence!
“Product backlog grooming is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog grooming, items are reviewed and revised. However, they can be updated at any time by the Product Owner or at the Product Owner’s discretion.
Grooming is a part-time activity during a Sprint between the Product Owner and the Development Team. Often the Development Team has the domain knowledge to perform grooming itself. How and when grooming is done is decided by the Scrum Team. Grooming usually consumes no more than 10% of the capacity of the Development Team.” Scrum Guide July 2011 p13
Et je persiste à penser que “légitimer” son existence en tant que cérémonial Scrum ferait gagner du temps et de l’énergie à pas mal d’Equipes, car même si le format et la durée peuvent varier (3 à 4 heures à mi sprint en une fois ou plus courts en deux temps une fois par semaine), les objectifs, l’agenda, éléments d’entrée / sortie sont clairs, pour une valeur évidente.
Agenda- Facilitation Backlog Refinement
Vous l’aurez compris, le Backlog Refinement est un RDV avant tout collectif qui dans les contextes webs et digitaux devient un moment d’expression et de facilitation privilégié pour les experts UX où il s’agira en priorité de décortiquer, d’explorer, de modéliser collectivement le contenu potentiel du sprint qui va démarrer quelques jours plus tard.
Ni trop tôt, ni trop tard dans le Sprint…
Tenir ce Refinement à mi-sprint permet au spécialiste UX, au product Owner ou même à l’équipe de de disposer de suffisamment de temps pour pouvoir le cas échéant peaufiner son besoin, faire un travail de spécifications supplémentaire, explorer une problématique technique ou confirmer des hypothèses auprès des utilisateurs finaux.
Le début-milieu de la seconde semaine sur un sprint de 3 semaine ou la fin de la première semaine pour un sprint de 2 semaines sont des moments propices pour organiser le Backlog Refinement. Le faire le dernier jour du sprint ne présente donc que peu d’intérêt.
Ce workshop peut à son tour donner lieu à des mini workshops spécifications côté Product Owner et/ou Equipe.
Focus sur le sprint n+1… mais pas seulement
J’attends que les équipes se focalisent sur le sprint qui arrive et qu’elles soient en mesure de répondre à cette question :
« Serons-nous Prêts à développer les user stories se trouvant en haut de la pile, ces user stories que nous sommes susceptibles d’embarquer au Sprint suivant ? ».
Ce questionnement implique une activité de modélisation ainsi qu’un travail portant à la fois sur les conditions de satisfaction et sur des exemples (lien avec l’approche ATDD) illustrant les fonctionnalités à développer. Il implique aussi le découpage de certaines users stories trop grosses être développées dans un sprint.
Néanmoins, le focus sur la préparation du sprint suivant n’est pas le seul objectif du Refinement. C’est aussi le moment idéal pour discuter des changements sur le backlog (rappelez-vous mon backlog est DEEP, évolutif, des items peuvent disparaitre, d’autres peuvent émerger, les priorités changent inévitablement.)
Il aussi souhaitable d’anticiper les risques ou impacts de certains éléments prévus à moyen terme dans les sprints n+2, n+3… besoins de spécialistes, impact techniques, ergonomiques, en terme d’activités de déploiement, de tests ou de support…
Le Backlog refinement: que des bénéfices si on joue le jeu!
Ce workshop collaboratif:
- Donne du contexte et des élements de conversation aux User Stories, pourquoi pas en se basant sur la checklist User Story pour s’assurer qu’on n’oublie rien
- Assure une certaine fluidité et de la sérénité dans le déroulement des sprints
- Illustre et précise les exemples et conditions de satisfaction, qui seront confirmées au moment du Sprint Planning
- Offre un pur moment d’intense collaboration: interactif, visuel, concret et source de feedback…
Bref, le Backlog Refinement, adoptez le sans modération !
Posté par jc-Qualitystreet le 21 février 2012
C’est u’un des premiers outils du toolkit du facilitateur et du coach agile.
Le check-in est si simple à utiliser qu’il en est souvent ignoré… malheureusement!
« Alors, comment vous sentez-vous aujourd’hui ? »
Vous êtes amené à faciliter des workshops, des rétrospectives ou cérémoniaux Agiles alors usez, et abusez du Chek-in. Que de bénéfices en effet pour ce petit tour de table ! Jugez-en plutôt :
- Il vous permet de briser la glace,
- Il fait la transition entre la vie hors-meeting et le workshop qui démarre: remarquable en ouverture de workshop
- Il va libérer la parole de tous.
- Il permet à chacun de partager l’état dans lequel il se trouve: c’est une opportunité de savoir ce que ressentent les autres et potentiellement d’adapter son comportement en conséquence
- Il contribue à terme à créer une vraie cohésion de groupe
Comment ça marche ?
Très simple mais voici quelques petites règles que j’aime bien suivre…
- Demander à un volontaire de commencer
- Se joue à tour de rôle
- Pas d’interruption durant le check-in de quelqu’un (après on peut commenter évidemment…)
- Orienté boulot ou pas: parlez de tout ce qui vous affecte à l’instant T
Côté facilitateur, il s’agit de rappeler ces quelques règles, lancer le check-in puis une fois que chaque personne a parlé, et si c’est possible, faire une petite phrase de récap (ex : « on dirait que vous allez tous bien c’est cool » ; « un peu de tension suite à la démo, on dirait… », « fin de sprint difficile semble-t-il »…)…
Le check-in moi j’aime bien!
Posté par jc-Qualitystreet le 9 février 2012
L’art de la spécification dans un contexte Agile et notamment SCRUM est avant tout une affaire de collaboration, une affaire de comportement. Les User Stories sont un format (que j’apprécie beaucoup) qui permet d’engager la conversation mais qui ne se suffit pas à lui-même… (voir le PROTOTYPAGE AGILE)
Bref, l’idée derrière cette checklist (reprise de Lisa Crispin et Janet Gregory) est de faciliter le boulot du Product Owner en lui rappelant les éléments nécessaires que ses User Stories arrivent Prêtes (ce fameux Ready) en début de sprint.
User Story CheckList
Cette checklist doit être envisagée comme un guide de conversation et non comme un énième format de spécification ! Elle permet aussi d’identifier les éléments complémentaires nécessaires à la réalisation et au test de la story (ex : Wireframe ; Diagramme d’activité…) et fait le lien avec une démarche ATDD.
La partie haute et les premiers éléments sont initiés par le Business; le reste se construit dans un mode « Juste à temps - Juste ce qu’il faut » de manière collaborative avec l’Equipe.
Rappelez Feedback et Collaboration...
Quelques lectures pour approfondir le sujet User Stories:
Posté par jc-Qualitystreet le 7 février 2012
Animer un workshop, endosser le rôle de facilitateur n’est pas si simple.
En plus du nécessaire temps de préparation (7p), de la maîtrise des techniques de facilitation (questionnement, écoute active, paraphrase, encouragement…), et, le jour J, de l’enchainement des activités dans une dynamique divergence / convergence, l’utilisation appropriée des marqueurs et autres supports est cruciale (et pourtant délaissée…).
Savoir dessiner, non….
Savoir écrire, oui ! Quelques repères….
D’entrée tout écrire
Tout écrire sans se poser de questions permet au facilitateur de rester dans son rôle c’est-à-dire de conserver sa neutralité et de ne pas filtrer l’information transmise par le Groupe.
Le facilitateur: neutre avant tout!
D’ailleurs ce sont souvent les conditions matérielles (tout petit whiteboard par ex.) qui nous poussent parfois à censurer la parole des autres… Tout noter c’est aussi donner un feedback positif aux participants du workshop, les remercier pour leur contribution et les inciter à poursuivre leurs efforts !
Donc tout écrire… du moins ce qui est dit !
Seulement ce que dit le Groupe, et pas nos propres interprétations ! Par soucis de simplicité ou pour bien faire, nous avons parfois tendance à synthétiser, à remplacer certains mots par d’autre que nous jugeons plus appropriés ou plus présentables… Pourtant, conserver les propres mots des participants est crucial, toujours pour des questions de reconnaissance et d’engagement.
S’efforcer d’être lisible et compréhensible
…. Comme le reste cela se travaille.
Agenda- Facilitation Product Backlog Refinement
C’est avant tout une question d’effort et d’organisation. Utiliser de bons supports, de bons marqueurs, s’attarder pour écrire les lettres distinctement, espacer les lignes pour s’autoriser quelques ajouts ou corrections, alterner les couleurs, hiérarchiser l’information (les bullet sont toujours terriblement efficaces)
Questionner sans cesse…
Marqueurs à la main pour éviter les biais, encourager la participation et s’assurer que le contenu écrit et restitué est en phase avec le discours du Groupe.
Posté par jc-Qualitystreet le 4 février 2012
Activité#4 du praticien AgileUX…
Le praticien AgileUX va initier puis construire l’architecture de l’information de manière collaborative
L’architecture de l’information c’est l’organisation du contenu et des fonctionnalités d’un point de vue cognitif et graphique pour répondre aux besoins et attentes des utilisateurs finaux.
Architecture de l'information : un élément d'UX
L’architecture de l’information est une activité incontournable de toute projet IT ; outre le fait de donner du sens, dans un contexte de développement Agile, cette activité va proposer la fameuse Big Picture, tant attendue par mal d’intervenants, et va rassurer à la fois les Equipes IT et le Business. Elle facilitera ensuite le travail de tests.
Arborescence
La Big Picture : High level et structurante
Entrer dans une dynamique agile signifie l’ABANDON de spécifications détaillées, travaillées pendant des mois et figées au démarrage du projet, AU PROFIT d‘un travail de spécification plus léger au départ, mais aussi progressif et surtout continu (notamment au travers des workshops User stories et du travail portant sur le Backlog de produit).
Concept Model par Daniel M. Brown
Néanmoins, et je dirais encore plus sur un projet SCRUM, même si ce travail de spécification ergonomique peut sembler plus léger au départ, les premiers éléments d’architecture d’informations sont à maîtriser dés les premiers sprints du projet (sur la base d’informations potentiellement recueillies au préalable, tri de cartes, Kano…).
Modèle de Kano
Il s’agit pour le praticien AgileUX d’aller à l’essentiel, de réflechir en terme de valeur pour sa prore activité et de se mettre au service à la fois du Product Owner et de l’Equipe.
La TO DO List du praticien AgileUX pour l’architecture de l’information
- Clarifier et catégoriser les informations
- Soutenir le PO dans son effort de priorisation des fonctionnalités et des contenus
- Initier puis approfondir de manière collaborative une première structure d’informations efficace
- Déterminer les système d’information le plus approprié
- Tester puis affiner ces éléments structurants
Système de navigation - Pages intèrieures
