ROADMAP - TRANSITION AGILE

Exploration Pilotage Adoption

Analyse
d’impact Améliorations
Recommandations
Diagnostic Centre Agile
organisationnel
Mesures

Aiguilleur

Initiatives Portfolio
Bilan du
ad hoc pilote

Projet pilote
Projets de développement

Sensibilisation Formation – Accompagnement – Gestion du changement

 Formalisation des exigences en agile

I. Techniques de description des besoins fonctionnels et des exigences

qualité
Partant du constat que l’analyse du besoin et sa formalisation est trop
souvent le maillon faible du cycle, nous avons essayé d’appliquer les principes
agiles non plus pour définir la solution, mais pour analyser le besoin.
Définir le périmètre de l’étude en se basant sur des axes d’analyses
L’exercice consiste à dénombrer l’espace possible en définissant avec les
utilisateurs les « dimensions » ou axes d’analyse qui permettront de définir
les caractéristiques du besoin.
Exemple : sur l’étude d’un besoin d’un nouveau rapport métier qui n’existe
pas à date on pourra identifier les dimensions d’analyse suivantes :
• Objectifs du rapport
• Utilisateurs cibles du rapport
• Fréquence d’utilisation
• Cas d’utilisation
b. Proposition d’un « prototype » de besoin !
Toujours si on garde le parallèle avec un prototype de produit :
qu’est-ce que serait un prototype de besoin ?
Tel que j’utilise cette technique, c’est l’étape de brainstorming : il
faut couvrir le maximum de « terrain », c.à.d. imaginer toutes les
configurations possibles de besoin.
Exemple : votre rapport « temps passé par utilisateur et par
département » a les axes d’analyse suivants :
 le temps « t »
 le temps passé par utilisateur : listez les utilisateurs
 le département de l’utilisateur : listez les départements
Cela pourrait être :

 une liste la plus exhaustive possible des besoins :

 Faites le produit cartésien des axes d’analyses : Le produit
cartésien utilisateur x département vous donnera toutes
les combinaisons possibles d’utilisateur et département.
 Proposez d’éliminer les besoins qui n’ont pas de sens ou
qui ne sont pas applicables à votre contexte
 Surligner les combinaisons pouvant demander une règle
de gestion particulière : par exemple la combinaison entre
l’utilisateur « Diallo » et le département « Finance » doit
déclencher une règle d’affichage particulière…
 Une ébauche de processus métier cible, sous tenue par des
diagrammes, BPM et maquettes d’écran si besoin : modéliser
les interactions entre les concepts fonctionnels du sujet
permet de décharger vos interlocuteurs d’une partie du travail
cognitif de se représenter les choses dans leur tête, et leur
permettra de se poser les bonnes questions.

c. Reformuler le besoin / Confirmer et valider le besoin

Il aura pour objectif de valider la compréhension du besoin :
par un workshop de relecture, les participants remontent leur
questions / feedbacks au BA.
IMPORTANT : Cette étape nécessite qu’une certaine dose de
confiance et de crédibilité ait été préalablement établie entre le
BA et les parties prenantes.
Face à des personnes peu engagées qui refuseront de faire part
de leur feedback la méthode suivante peut être utilisée :
Expliquer en début d’analyse la règle : si aucun retour n’a été
transmis sur une expression de besoin formalisée (après un délai
raisonnable qui tiendra compte des disponibilités des personnes)
cela vaut bon pour accord.
Relancer,
Si aucun retour, mettre par écrit que la personne n’a émis
aucune remarque => bon pour accord.
Si une personne se « réveille » soudainement après que les
développements ait été lancés, 2 cas de figure :
 La demande de changement est minime, ou ne cause
aucun impact sur les développements déjà réalisés : dans
ce cas on fera « cadeau » des changements, en les
priorisant en priorité « basse ». Ceux-ci seront traités en
queue de projet si le temps restant le permet.
 Le « change-request » (demande de changement)
nécessite des modifications aux développements déjà
réalisés : le coût de l’analyse d’impact et des
développements supplémentaires est à de responsabilité
de la direction métier à son origine.
d. Finaliser le document d’analyse et obtenir sa validation «
formelle »
Cette étape nécessite qu’une certaine dose de confiance et de
crédibilité ait été préalablement établie entre le BA et les parties
prenantes, car la finalisation du document doit se traduire par un
« sign-off », c.a.d une trace écrite (un email disant en substance
« Ok pour moi, je valide ce document ») pour indiquer que les
stakeholders (parties prenantes) sont d’accord avec la
formalisation de leur besoin : ils l’ont comprise et valide son
intérêt pour eux.
II. Les users stories
Une User Story est une description simple et compréhensible
d’une fonctionnalité à valeur business d’un système.
Une User Story (“scénario utilisateur” en français) est la
description fonctionnelle utilisée dans les méthodes agiles
pour spécifier le développement d’une fonctionnalité, en
exprimant à qui elle s’adresse et en quoi elle apporte de la
valeur.
Cela consiste à se mettre à la place de l’utilisateur et essayer
de décrire ce que l’utilisateur attend de l’application, ce qu’il
aimerait pouvoir faire avec cette application. Ce qui va
permettre de guider le développeur dans l’atteinte de l’attente
client.
Pour écrire une user story il y a certaines critères à
respecter, et certaines informations spécifiques à
mettre.
Elle est généralement rédigée par le Product Owner,
afin de définir un besoin auprès des équipes de
développement, selon une structure qui permet
d’exprimer de manière atomique (voir : INVEST),
systématique et claire l’intérêt de la fonctionnalité.
Différents modèles de formulation existent ; en général,
dans le cadre d’un projet, les Product Owners vont
s’accorder sur un « template » clair et partagé qui inclut
les dimensions « qui », « quoi » et « pourquoi » :
Généralement quand on écrit une user story, y a 3
informations qui sont extrêmement importantes.
On va faire un scénario utilisateur, pour ça on va
d'abord définir le cadre:
En tant que…, c.à.d. en tant que quel type d’utilisateur,
en tant que quel profil le scénario ce passe, est ce que
c’est un administrateur, est ce que c’est un utilisateur
avec tel et tel droits, est ce que c’est un responsable de
tel ou tel périmètre. Cela est très important parce que
ça va nous permettre de définir quel ensemble
d’utilisateurs ça va toucher.
Ensuite il faudra expliquer l’attendu:
Je veux… c.à.d. par exemple je suis un hôtelier je vais dire,
en tant que client, je veux pouvoir faire un retour sur le
séjour que j’ai passé dans l’hôtel et donc je veux pouvoir
mettre un commentaire avec une note.
NB: Le « Je veux… » ne doit en aucun cas proposer une
solution technique. Ici on décrit une fonctionnalité, mais
on va pas dire par exemple je clic sur un bouton qui va
m’ouvrir un pop-up avec un champ texte et cinq étoiles et
en cliquant sur les étoiles je vais pouvoir mettre ainsi une
note, remplir mon champ texte mettre un bouton ok et
annuler et lorsque j’annule ça ferme le pop-up et lorsque je
clic sur ok ça l’envoi et ça l’ajoute dans la base.
Le point que l’on oublie souvent et qui est
extrêmement important est de définir le but sous-
jacent de ma demande (le client), l’apport métier de la
demande. Il faut que la demande apporte quelque
chose et il faut mettre le but derrière:
Afin de… Par exemple, je veux que mon client puisse
faire un retour afin de pouvoir améliorer ma relation
client, mes services et fidéliser ma clientèle. Ceci
permet également au développeur de savoir quel est
l’objectif attendu ce qui est assez important.
Le afin de… défini réellement la volonté de l’utilisateur,
c’est vraiment ce que l’utilisateur souhaite avoir ou
souhaite faire.
 En tant que <qui>, je veux <quoi> afin de <pourquoi>.
L’intérêt du <pourquoi> est d’exprimer clairement la
valeur de la User Story pour l’utilisateur, ce qui
permettra notamment de les prioriser par ordre
d’importance
Le <qui> ne désigne pas forcément un type d’utilisateur
final du système, mais tout rôle concerné par le produit
: utilisateur final d’un certain segment, testeur,
développeur, administrateur, etc.
Les User Stories, sous leur format anglo-saxon, se
présentent souvent sous deux formes :
As a <define the profile of the user>, I want to <describe
the feature> so that <describe the value>

In order to <describe the value>, as a <define the profile

of the user>, I want to <describe the feature>

Cette deuxième formulation obligeant le Product Owner à

commencer par définir la valeur de sa story et évitant plus
facilement que la première l’écueil consistant à répéter le
<quoi> dans le <pourquoi>
La User Story dépasse souvent le cadre de la simple phrase, et peut s’inscrire
dans un groupe plus large de User Stories constituant un ensemble cohérent (voir
: Epic). L’organisation globale de telles fonctionnalités constitue un « Story
Mapping », permettant d’agencer de manière cohérente de nombreuses User
Stories plus atomiques, et de les assembler en sous-ensembles permettant de
discerner des fonctionnalités cohérentes : les Minimum Marketable Features.

Une User Story est souvent complétée par une description des règles de gestions,
idéalement co-rédigées entre le Product Owner, le Design et l’équipe de
développement. Plus largement, le Product Owner peut y ajouter tous les
éléments qui vont permettre à l’équipe de développement de prendre en charge
l’implémentation complète de la fonctionnalité, comme par exemple :
• Les critères d’acceptation ou « business rules »
• La documentation des wireframes / maquettes et autres éléments graphiques
de l’interface utilisateur
• Les critères de succès ou « KPIs » à suivre pour mesurer par la suite la valeur
de la User Story
• Les tests d’acceptation (au format BDD par exemple : voir BDD et Gherkin)
pour valider de manière objective et systématique si la User Story a été
implémentée correctement
 III. Comment rédiger les user stories
La réponse va se faire d’abord en deux temps. En effet
pour bien définir les user stories il y a 2 modèle
fréquemment utilisés.
Quand on pense aux User Stories, on pense d’abord à la
règle des 3C et aux critères qualité (INVEST)
1. Les 3C :
• Card  Une description du besoin ;
• Conversation  Une négociation en vue d’une
définition du besoin ;
• Confirmation  Une définition des critères
d’acceptabilité : c’est un élément majeur.
Carte: la user story doit être très courte, doit tenir sur
un format très petit.
Conversation: la user story est un point de départ des
discussions entre les différentes acteurs.
Confirmation: la user story doit s’accompagner des
différents cas de test qui permettent de la valider.
2. Le modèle INVEST:
Il faut noter que INVEST est un moyen psychotechnique
pour retenir les 6 critères qui sont importants.

Critères INVEST, une bonne User Story doit aussi

respecter les caractéristiques réunies sous ce sigle :
I – Independent. Une bonne User Story est
indépendante (des autres User Stories, ou du moins
autant que possible) notamment pour faciliter son
traitement ; car le choix de l’inclure dans tel ou tel
sprint (= itération) est avant tout fondé sur la priorité
qu’on lui donne (rappelez-vous ce billet …).
Par exemple si on ne peut pas faire une user
story avant d’avoir terminé une autre, alors il
faudra faire une user story générale qui va
récupérer les 2 et on fera 2 tâches.
On ne doit pas avoir d’US (User Story) qui soient
très fortement liées.
• N – Negotiable. Elle est négociée, discutée (c’est le
second C, Conversation) dans les réunions
d’estimation (planning poker) et de planification du
Sprint mais aussi tout au long de ce dernier. Une User
Story doit être un support de discussion en vue d’une
amélioration du besoin initial.
• V – Valuable. Elle est source de valeur pour le Client
final ou l‘utilisateur (c’est aussi ça le Lean Thinking !),
il faut qu’elle apporte une valeur ajouté. En un mot,
une User Story n’a de sens que si elle apporte une
valeur métier.
A la fin du sprint, on est sensé donner quelque chose
de fonctionnelle c.à.d. présentable et démontrable.
• E – Estimable. Elle est estimée par les équipes de
développement ; une estimation relative c’est à dire les unes
par rapport aux autres. Une User Story doit être bien définie
pour être facilement chiffrable.
Il faut que l’équipe de développement soit en capacité de la
chiffrer.

• S – Small (Suffisamment petit). Le plus souvent petite car

susceptible d’être traitée (livrée et testée) par l’équipe sur une
seule itération de 2/ 3 semaines. Le niveau de granularité est
une question fréquente. L’affaire est très contextuelle mais je
conseille le plus souvent une petite taille qui va faciliter là
aussi son estimation, sa décomposition en tâches puis son
traitement (codage et test) sur un maximum de quelques
jours.
 Plus on a des tâches petites, plus on va facilement
comprendre ce qu’on attend et on a des tâches qu’on va
pouvoir répartir auprès des développeurs.
Il existe des User Stories plus « grosses », nommées « epics »,
des stories qui ne sont pas envisagés sur les tous prochains
sprints et qui seront splittées en User Stories le moment
venu.
• T – Testable. Une User Story « de qualité » est avant tout
testable, déjà dans sa forme et surtout dans le sens où les
critères d’acceptation sont envisagés d’entrée (le troisième C,
Confirmation). Si elle n’est pas testable ou vérifiable ce n’est
pas une User Story. La définition de ces critères d’acceptation
est un premier pas vers la qualité qui aidera à la fois la
décomposition en tâches et l’activité de développement !
 IV. La notion de "Backlog du produit"

Un "Backlog" est une liste d’éléments (de fonctionnalités) ou de

tâches (les stories), jugées nécessaires et suffisantes qu’on doit
développer pour faire un produit efficace afin de garantir une
réalisation satisfaisante du projet : si une tâche contenue dans le
backlog ne contribue pas aux objectifs du projet, il faut l'en
retirer; a contrario, dès qu'on a connaissance d'une tâche qu'on
pense nécessaire pour le projet, on doit l'inclure dans le backlog.
Il faut noter que cette liste d’éléments est priorisée et vivante.
Ces propriétés s'apprécient relativement à l'état des
connaissances de l'équipe à un instant donné : l'élaboration du
backlog peut se poursuivre tout au long du projet.
Il est le principal référentiel de l'équipe en matière d'exigences
 Description
Les éléments du backlog sont appelés user stories. Une user
story doit avoir un but métier, son ajout au backlog doit
généralement justifier une valeur ajoutée, un « business value ».
On n'y met pas de tâches techniques du genre « Réécrire l'algo
d'import de produits en C », mais plutôt des item faisant sens au
niveau métier « Augmenter la rapidité de l'import des produits
» : le fait de l'implémenter en C plutôt qu'un Cobol objet (!)
appartient à l'équipe technique, et ce n'est pas au product
owner ou au client de le décider (ce n'est pas de sa
responsabilité : s'il le fait, c'est généralement considéré comme
de l'ingérence vis-à-vis de l'équipe technique).
 Objectif
Le backlog de produit est la liste des
fonctionnalités attendues d'un produit. Plus
exactement, au-delà de cet aspect fonctionnel, il
contient tous les éléments qui vont nécessiter
du travail pour l'équipe. Les éléments y sont
classés par priorité ce qui permet de définir
l'ordre de réalisation.
Rôles et Utilisation
Le backlog de produit est sous la responsabilité du Product
Owner. Chacun peut contribuer à collecter des éléments,
mais c'est le product owner qui les accepte finalement et
c'est lui qui définit les priorités.
Le backlog est élaboré avant le lancement des sprints, dans
la phase de préparation (ou sprint 0). Il est utilisé pour
planifier la release, puis à chaque sprint, lors de la réunion
de planification du sprint pour décider du sous-ensemble
qui sera réalisé.
C'est donc un outil essentiel pour la planification. Mais il est
aussi, par sa nature, un maillon de la gestion des exigences,
puisqu'on y collecte ce que doit faire le produit.
A tout moment, le backlog est visible par tout le monde.
Vie du backlog

Le backlog pour un produit peut avoir une durée

de vie longue, équivalente à celle du produit. Ce
n'est pas un document figé, il est toujours vivant.
Des éléments sont ajoutés, des éléments sont
supprimés, des éléments sont décomposés ou les
priorités ajustées. Il est courant que le backlog
soit modifié quotidiennement dans un projet,
c'est l'outil de base du product owner, mais il
subit les modifications les plus importantes lors
du passage au sprint suivant.
Exemple simplifié de backlog de produit
• La colonne Effort ou charge désigne le nombre de
jours/homme.
5jours/homme : a une durée de 5 jours si le nombre de
ressources qui travaillent en parallèle et à temps plein
est égal à 1. A une durée de 10 jours si le nombre de
ressources qui travaillent en parallèle et à mi-temps est
égal à 1. A une durée de 1 jours si le nombre de
ressources qui travaillent en parallèle et à temps plein
est égal à 5.
• La colonne risque : indique le niveau de complexité
technique
Scénario ou story Niveau utilisateur Niveau détaillé Priori Ris Eff
(cas d’utilisation) té que ort

En tant que Réaliser un Construire le M 1 1

recruteur je veux formulaire de formulaire avec tous
recevoir les mise en les champs
candidatures via candidature
notre site
internet. Je Indiquer les champs M 1 1
souhaite afficher obligatoires
la liste des
candidats par
domaine de Sélectionner dans M 1 1
compétences. une liste les champs
de compétence pour
le poste. La liste est
triée par ordre
alphabétique
 Avoir une zone de
texte de 500 S 2 1
caractères pour les
motivations pour le
poste
Trier la liste des C 2 1
compétences selon le
poste

Enregistrer le M 2 2
formulaire
correctement

Lister les candidats Afficher la liste des M 1 1

par domaine de candidats selon les
compétences trois premières
compétences.
Lister les candidats M 1 1
selon un résumé
d’expérience (à partir
de la liste précédente)

En plus des C 1 1
compétences, afficher
les candidats par
niveau de scolarisation

En plus des W 2 2
compétences, afficher
les candidats par ordre
d’éloignement
Produits dérivés

• Le backlog de produit permet de produire le

planning de release, c'est à dire le sous-
ensemble des éléments du backlog qu'on
estime finir pour la date prévue de release.
• Le backlog de produit permet de produire le
burndown chart de release, qui est un graphe,
mis à jour à la fin de chaque sprint, montrant la
tendance de l'avancement dans la réalisation
des éléments du backlog de produit.
 La product backlog grooming
Dans ce chapitre, vous allez encourager l'équipe Scrum à faire le
raffinage du product backlog ou toilettage (product backlog
grooming en anglais).

Le toilettage pour le scrum master

Le product owner aura besoin de votre aide pour confronter ses
prises de décision aux indicateurs concrets du modèle Scrum.
L'équipe de développement sollicitera votre
accompagnement pour faire des estimations précises et réalistes
(planning poker, notamment). Selon le guide Scrum :
Dans les environnements complexes, ce qui se passera est
inconnu. Seul ce qui s’est passé peut être utilisé pour la prise de
décision prospective.
Donnez de l'importance à votre approche
empirique pour servir efficacement les membres de
votre équipe Scrum. Le toilettage du product backlog
sera aussi un bon moyen d'assurer sa transparence.
En qualité de scrum master, vous pouvez créer une
boîte de temps pour chronométrer cet atelier.
Ne dépassez pas 10% de la durée totale de votre projet pour
planifier toutes les réunions de ce type. Personnellement, je
dédie une journée pour la product backlog grooming et la sprint
planning, puis une autre journée pour la sprint review et la sprint
retrospective. J'obtiens ainsi des itérations de 3 jours sur 1
semaine ou de 8 jours sur 2 semaines.

Vous devez aussi jouer votre rôle de facilitateur pour ce rituel.

Ne cherchez pas des coupables, cherchez des solutions. Ne
rabaissez jamais un membre de l'équipe. Soyez réactif et
exigeant afin de calmer rapidement les discussions conflictuelles.
À contrario, méfiez-vous aussi d'une fausse politesse qui pourrait
masquer un désintérêt plus ou moins profond vis-à-vis du
projet.
 En conclusion
Vos responsabilités de scrum master vous engagent à devenir le
protecteur de l'équipe, le garde-fou du projet, le garant du
modèle Scrum. Débarrassez-vous de vos jugements les plus
autoritaires et arbitraires. Favorisez principalement
l'indépendance et l'entraide entre les membres de votre équipe.
Je vous invite encore à utiliser une pratique agile afin de
connaître l'humeur de l'équipe :
Tous les acteurs du projet rendent visible une évaluation
subjective de leur journée de travail. En affichant de simples
émoticônes sur un calendrier, vous appliquerez le principe de
l’ingénieur américain Tom Gilb : rendre quantifiable quelque
chose qui ne l'était pas auparavant.
 Le système de feedback

Nous pourrions lister un grand nombre de choses qui

garantissent la robustesse d’un tel système; pour des raisons de
clarté, nous allons les regrouper en 3 grands principes.
Un système doit être conçu de façon à ce que le feedback reçu
soit :
• Riche – chaque action déclenche une réaction directe et, si
possible, une abondance de réactions ;
• Non-ambigu – nous sommes capables d’interpréter
facilement si le feedback est positif ou négatif ;
• Instructif – il nous aide à voir les conséquences de nos actions
et nous montre comment nous améliorer.
 I. Un feedback riche

Rappelez-vous la dernière fois que vous étiez dans un ascenseur:

vous avez appuyé sur un bouton et vous vous êtes probablement
attendu(e) à ce qu’une lumière s’allume, ou qu’un numéro
d’étage s’affiche. Avez-vous déjà pris un ascenseur où il ne se
passait rien lorsque vous appuyiez sur le bouton ? Cela m’est
arrivé récemment, et je peux vous dire que j’ai tout de suite
trouvé cela très agaçant.
Vous trouverez des situations du même genre un peu partout,
car le fait d’indiquer, d’une façon ou d’une autre, que l’action
d’un utilisateur a été prise en compte est désormais une bonne
pratique dans tous les champs du design. Et il y a une condition
pour que cela fonctionne : la réactivité.
 Le feedback doit être aussi rapproché que possible de
l’action effectuée, sinon cela crée de la frustration.
Dans les jeux vidéo, les designers doivent s’assurer que le jeu réagit
immédiatement aux actions du joueur, de crainte que l’expérience devienne
vite agaçante… comme un bouton d’ascenseur cassé. Jesse Shell a une règle
empirique pour cela: “Si votre interface ne répond pas à un input du joueur
en moins d’un dixième de seconde, le joueur va penser qu’il y a un
problème avec l’interface”[.
Prenons un jeu comme Mario Kart. Comme tous les jeux Nintendo, il est très
réactif, et le petit kart répond diligemment à toute action que vous réalisez.
Observez également la densité des sons, explosions, secousses, rebonds, les
expressions rigolotes des personnages, les flammes, les pièces d’or, les
étoiles, etc. Même si vous n’avez aucun talent pour la course, la quantité
d’interactions présentes dans le jeu rendra l’expérience exaltante.
Outre le retour d’information immédiat, on trouve dans Mario Kart des
rappels réguliers de la vue d’ensemble : nombre de tours restants, position
des concurrents, objets en votre possession. Et à la fin de chaque course, un
tableau des scores indique votre progression dans le classement général.
 Quand il s’agit de feedback, la quantité compte.
Si l’on regarde Scrum, l’on observe qu’il inclut beaucoup plus de boucles de
feedback que les méthodes de gestion de projet traditionnelles. Des boucles
courtes, moyennes et longues s’entrelacent, ce qui augmente logiquement la
fréquence du feedback.
Comme dans un système de jeu, Scrum prend le plus petit niveau d’action
significative réalisée par l’équipe (= une tâche) et s’assure que chacune de ces
actions déclenche un feedback systématique.
Le fait de suivre les tâches à travers des boucles de différentes longueurs nous
permet de visualiser plus aisément les conséquences de nos actions :
• Le mouvement des tâches à travers le tableau, depuis “A faire” jusqu’à “Fini”, en
passant par “En cours”, se produit plusieurs fois par jour.
• Ensuite vient le décompte quotidien de la vélocité d’équipe, avec la réunion
journalière et la mise à jour du burndown.
• A la fin de chaque Sprint, la Démo et la Rétrospective ferment une boucle plus
longue, celle qui donne un retour sur les buts intermédiaires.
• Enfin, la mise en perspective et la comparaison de tous les Sprints
précédents permet à l’équipe de constamment réévaluer sa capacité à atteindre
le but ultime.
Faites la comparaison entre ces différentes boucles et la situation dans de
nombreuses organisations, où il n’y a qu’un seul moment possible pour
mesurer formellement si la performance d’un employé est sur la bonne
voie: la fameuse évaluation annuelle. Evidemment, un bon manager
donnera régulièrement du feedback de manière informelle ; mais on voit qu’il
n’y a qu’une seule boucle qui soit formellement inscrite dans le système, et
elle ne se ferme qu’une seule fois par an !
 II. Un feedback non-ambigu
Non seulement le feedback doit être donné fréquemment, il doit également
être facile à interpréter.
Pour partir d’un exemple simple, prenons un jeu d’éveil comme celui où les
petits enfants doivent trier et encastrer des formes de couleur dans les bons
emplacements. Comme l’objectif principal est de développer les facultés
motrices et cognitives de l’enfant, et vu que ses capacités de raisonnement
sont limitées, le jouet doit lui signifier d’une façon claire et directe si ce qu’il
fait est bien. Le tri de formes fonctionne très bien à cet effet, car il est facile
pour l’enfant de voir s’il a placé la forme au bon endroit. Le jouet est le
feedback.
C’est également un très bon outil pour les parents et les éducateurs, qui
peuvent voir en un coup œil quel est le niveau de maîtrise de l’enfant, et le
soutenir avec des encouragements ou renforcer ses accomplissements avec
des “bravo” et des applaudissements.
C’est la même chose pour le feedback en général : il doit être à la
fois simple et clair. Nous le qualifions de “non-ambigu” quand on
peut le placer intuitivement entre les deux pôles d’un axe
(bon/mauvais, rapide/lent, etc.).
 Un système de feedback bien conçu parvient à suivre la
progression vers un but, tout en donnant une évaluation des
actions effectuées.
C’est pour cette raison que le tableau est si important dans Scrum, ainsi que dans
les autres méthodes agiles

Déplacer une carte dans la colonne “Fini” est un moment de satisfaction, une
reconnaissance du travail accompli, qui est une forme de renforcement
positif. En déplaçant les tâches à travers le tableau, l’équipe Scrum est
également capable de visualiser si ses efforts portent leurs fruits : c’est un
outil pratique de suivi de la progression.
 III. Un feedback instructif

D’un autre côté, quand on devient conscient qu’on fait des erreurs ou qu’on
agit d’une manière sub-optimale, on devient également capable d’apprendre.
Quand il est lié à un cadre de référence spécifique, le feedback
nous aide à nous situer et nous donne des pistes
d’amélioration.
Si vous déménagez dans une nouvelle ville par exemple, il vous faudra un peu
de temps pour être capable de créer un cadre de référence dans votre
cerveau, qui vous permettra de retrouver votre chemin
instinctivement. Quand on veut apprendre à se situer dans différents
endroits, on procède généralement par une série d’essais-erreurs. Vous allez
quelque part, essayez d’imaginez dans votre tête où vous vous trouvez, et
ensuite comparez votre supposition avec une information en temps réel – en
regardant une carte, ou en demandant à un passant.
Ceci vaut également pour les cadres abstraits, où nous voulons nous situer
en relation avec des critères pré-établis.
Dans le cas de Scrum, les graphiques de burndown sont un complément utile
aux cartes de tâches. Ils permettent de visualiser tout accident dans la
progression de l’équipe, en jugeant de la progression au regard d’une matrice
temps/vélocité.
Ainsi, dans le graphique ci-dessous, l’œil exercé perçoit immédiatement qu’un
problème est survenu le septième jour (Day 7).

Manifestement, quelque chose a déraillé au Jour 7.

Dans cet exemple, on peut voir que l’équipe a échoué à atteindre l’un des
objectifs du jeu – rappelons que le but était de “faire la prédiction la plus
précise possible de la productivité collective dans un laps de temps défini”.
Toutefois cet échec n’est pas dramatique. Comme dans un jeu, échouer dans
Scrum n’est pas déprimant, car c’est juste une nouvelle occasion
d’apprendre.
A l’instar des vieux jeux de plateforme Mario Bros, Scrum est basé
sur l’apprentissage par l’expérience; la méthode fait en sorte qu’il y ait
toujours une occasion de répondre à un feedback négatif. Si un obstacle a
surgi, il sera mentionné lors de la prochaine réunion journalière. Et s’il est lié
à un problème plus important, il sera abordé pendant la Rétrospective à la fin
du Sprint.
Avec la capacité à détecter des irrégularités dès qu’elles surviennent
(feedback riche), et à identifier rapidement si quelque chose ne va pas
(feedback non-ambigu), Scrum enlève la pression sur l’équipe, pour que celle-
ci puisse se concentrer sur le plus important : apprendre. Or apprendre sans
risque est quelque chose que notre cerveau adore. Ou, comme Raph Koster
le disait dans une formule célèbre:
“Le mot ‘fun’ n’est qu’un synonyme du mot ‘apprendre’.”

Je voudrais conclure ici sur l’importance de célébrer les succès. Le

feedback positif, surtout quand il repose sur des données qui sont
clairement liées au but et aux règles, joue un rôle important en
renforçant notre croyance en nos chances de succès. Chaque but
intermédiaire que nous atteignons nous rend plus confiant en nos
capacités en tant qu’individus et en tant qu’équipe, renforçant notre
sentiment de maîtrise.