Et le premier ouvrage en français dédié à Scrum. Je fais donc partie de ces privilégiés qui ont eu le plaisir de dévorer le livre en avant première. Je n’ai pas été déçu, et je suis prêt à parier que vous ne le serez pas non plus, que vous débutiez dans l’agilité ou que vous soyez un praticien Scrum expérimenté.
L’ouvrage est très complet et se lit très facilement, en douceur, … le style est clair, simple, le discours bien rôdé. Car de mon côté, j’avais pas mal d’attentes sur ce livre SCRUM…
Des exigences obligatoires … LARGEMENT SATISFAITES
Claude revient évidemment sur les fondements de l’Agilité puis détaille l’ensemble du process Scrum : des 3 rôles (ScrumMaster, product Owner, Equipe) aux principaux artefacts (backlog de produit…), des cérémoniaux SCRUM (daily Scrum, Retrospective…) aux activités de planification et d’estimation agiles. De la justesse, de la pédagogie, de l’expérience : c’est parfait.
Des attentes exprimées … CONFIRMEES
L’adoption de Scrum en contexte, la transition agile, la gestion de projet Agile outillée avec IceScrum voire même Scrum en France sont des sujets attendus que Claude aborde régulièrement en conférences. L’auteur les développe avec brio, et nous fournit un contenu de qualité.
Les heureuses Surprises … BIEN REELLES
La signification du fini (Definition of Done), de la Vision aux User stories ou encore les tests d’acceptation sont des sujets qui me tiennent à cœur, et les vraies problématiques des équipes Agiles qui veulent avancer. Claude donne une place de choix à ces questions dans son livre, et nous apporte sa vision pleine de pertinence et d’ouverture. Personnellement, je vous conseille donc vivement ces chapitres 11, 13 et 14.
Conclusion :
Ais-je encore besoin de vous inviter à vous le procurer de toute urgence ? (Sortie le 10 février)
Note : Ces 3 types d’exigences, on les retrouve dans le modèle de Kano….
Et donc DEEP pour le Backlog de produit (d’après Mike Cohn et Roman Pichler)
Le backlog de produit, c’est en résumé la liste des exigences du produit ou plus exactement la liste de tous les éléments sources de valeur qui vont nécessiter du travail de l’équipe pour réaliser le produit. On y trouve donc essentiellement des User Stories mais aussi des élément plus techniques voire des défauts détéctés .
Le backlog de produit est un des 3 artefacts SCRUM, sous la responsabilité du Product Owner, c’est l’élément central de tout notre dispositif agile. Il se construit (se priorise et s’estime collectivement) en général dans le Sprint 0.
Alors, qu’est ce qui caractérise notre backlog de produit ? Il est DEEP tout simplement :
D = Détaillé de manière appropriée (le backlog contient des éléments au bon niveau de granularité : suffisamment petits, détaillés et compréhensibles pour ceux devant être réalisés dans les sprints qui arrivent)
E = Estimé (chaque élément du backlog est estimé de manière relative, les uns par rapport aux autres; une estimation menée collectivement par l’équipe: c’est le Planning Poker)
E = Evolutif (le backlog n’est pas figé; il émerge dans le sprint 0 mais change au fur et à mesure de l’avancement du projet: ajout, retrait, changement de priorités)
P= Priorisé (les éléments du backlog sont priorisés: du plus important au moins important; rappelez-vous l’objectif est de livrer le plus de valeur (top priorité) le plus tôt possible)
Les valeurs Agiles sont des incontournables des introductions et formations à l‘Agilité, à juste titre, même si leur signification, leur impact et leur caractère ô combien essentiel ne sont pas immédiatement perçus …
Pourtant la transformation agile réussie d’une organisation me semble nécessiter un choc culturel représenté justement par l’adhésion aux 4 valeurs de l’Agile Manifesto …
Pourtant une équipe ne me semble Agile que quand elle performe sur les 5 valeurs Agiles (issues d’XP) !
Toutes ces valeurs, qui se recoupent ou se complètent, vous y reviendrez donc un jour ou l’autre, alors pour vous simplifier la vie, je vous propose de les redécouvrir dans cet article.
Evidemment vous pouvez vous positionner collectivement et régulièrement sur ces valeurs (l’« Agile radar » est un très bon exercice), vous pouvez les afficher, les discuter dans une rétrospective ou mettre le focus sur l’une d’entre elles après un Daily Scrum ou autour d’un café…
Fonctionnalités opérationnelles plutôt que documentation exhaustive
Collaboration avec le client plutôt que la contractualisation des relations
Acceptation du changement plutôt que la conformité aux plans
Les 5 valeurs Agiles (issues d’XP):
avec en italique, ce qu’elles représentent selon moi.
Communication:
C’est d’abord se parler et savoir écouter
C’est privilégier le face à face au sein de l’équipe et avec le Client
C’est travailler ensemble, en équipe, du début à la fin du projet
Courage
C’est se dire les choses avec transparence, à tout moment
C’est se dire la vérité sur l’avancement du projet, sur les estimations produites
C’est s’engager individuellement et collectivement sur ce qu’on fait
Feedback
C’est solliciter des retours le plus tôt et le plus souvent possible : du client ; de l’équipe ; du produit
C’est faire une demo plus formelle à chaque fin d’itération
C’est tenir compte de ces feedback et s’adapter en continu
Simplicité
C’est privilégier la solution la plus simple pour atteindre ses objectifs.
C’est favoriser des interfaces et interactions simples pour l’utilisateur
C’est juste ce qu’il faut de process, d’outils et de documentation
Respect
C’est fondamentalement respecter les personnes
C’est respecter les expertises et le travail de chacun.
C’est respecter les valeurs et le process agile
Comme on peut le constater, les 12 principes du Manifeste Agile ne sont de toute façon pas très loin : Valeurs- Principes - Pratiques …c’est un tout !
Les rétrospectives d’itérations (sprints) ou de projet sont des vrais moments d’échanges et de communication. RDV incontournables de Scrum et des Méthodes Agile, elles peuvent s’appliquer aussi sur d’autres terrains, avec toujours les mêmes objectifs :
Découvrir ENSEMBLE ce qu’on a fait de bien
Comprendre ENSEMBLE ce qui n’a pas fonctionné
Trouver ENSEMBLE des moyens pour s’améliorer
Comme on le voit, un maitre mot, ENSEMBLE, et la forte particularité d’être tourné à la fois vers le passé mais aussi vers l’avenir (le PLAN D’ACTION). Toutefois, cette dynamique collective, ouverte et transparente, pour bien fonctionner, a besoin d’être stimulée par toute sorte d’exercices… La TIMELINE est le premier d’entre eux, un exercice qu’en tant que coach et facilitateur, j’affectionne tout particulièrement !
Timeline pour une belle retrospective
La TIMELINE est dans un premier temps une pure activité de divergence (ouvrir et lister un maximum d’options) qui permet de se replonger « dynamiquement » dans le passé. Elle peut être envisagée de plusieurs façons. De mon côté, je la facilite ou demande au ScrumMaster (coaching agile) de la faciliter en plusieurs temps, en combinant travail individuel et collectif, en insistant sur les éléments positifs et négatifs :
1. Ouverture de l’exercice (intérêt et consignes …)
2. Chaque personne travaille de son côté durant un temps donné et écrit ses post-it (vert et rose J)
3. Tous se lèvent pour afficher les post it sur la Timeline (j’aime bien la découper en semaines)
4. Tous prennent connaissance de ce qu’ont affiché les autres
5. Tous discutent autour de la Timeline pour expliquer, comprendre et pouvoir alimenter les posters clés de toute rétrospective : “Ce qu’on a fait de bien”, “Ce qu’on doit améliorer”, “Ceux qu’on aimerait remercier“… et le plan d’action (activité de convergence)
Timeline et autres posters
TRANSPARENCE, FEEDBACK, COURAGE et COLLABORATION : c’est dans ces moments-là que se construit l’esprit d’équipe ...
VOUS L’AVEZ COMPRIS, la Timeline est toujours un grand moment de plaisir !
Pour terminer, j’en profiterai pour vous souhaiter, à vous chers lecteurs, une belle année 2010, et à ce blog, un bon Bloganniversaire: Qualitystreet a 3 ans en effet !
Le STORYTELLING, c’est l’art de raconter des histories et de donner vie à nos utilisateurs cibles …
car oui on aime tous raconter mais aussi entendre de belles histoires !
Le visionnage de cette Demo réalisée par le pôle Ergonomie de Steria pour le concours MultiTouch SNCF me conforte dans l’idée de l’efficacité du STORYTELLING en Conception Centrée Utilisateur. En effet, je n’assiste pas passivement à une simple présentation de produit ennuyeuse, comme c’est souvent le cas, je me projette, j’entre dans le quotidien ou dans un moment de vie d’un véritable utilisateur.
Le point de départ, c’est donc toujours l’utilisateur, notre persona par exemple. Dans cette démo, c’est « Oscar, un jeune homme bien sous tout rapport, drôle, intelligent … », quelqu’un surtout qui a des BUTS à atteindre et des TACHES à réaliser.
Le STORYTELLING va simplement scénariser le tout, l’enrober de faits et ajouter une dimension humaine, affective et émotionnelle pour captiver l’attention et favoriser la mémorisation. Et c’est vrai qu’au final, après avoir visionné les autres films (car il s’agit d’un concours, il y a même un vote), c’est bien celui-ci qui me laisse la meilleure impression, d’autant que les interactions sont plutôt bien pensées.
De l’audace mais surtout ne pas oublier l’interface
Qu’il soit textuel ou animé, le storytelling ne doit pas perdre de vue le produit qu’il sert !
Pour être efficace notamment en phase de conception, le scénario doit donc se centrer avant tout sur l’activité des utilisateurs. Aussi les buts doivent-ils représenter le fil rouge de l’histoire.
On doit impérativement mettre l’accent sur l’interaction (le plus important dans ce contexte). Dans cette DEMO, c’est aussi le cas avec par exemple l’interface constamment en toile de fond, un dialogue Homme - Ordinateur permanent, mais aussi du mouvement, quelques gros plans appropriés, des éléments de narration et d’incitation bien placés .
