Master Qualité - Communication
publique des résultats d'un stage de fin d'études UTC - rue Roger Couttolenc - CS
60319 - 60203 Compiègne Cedex - France - master-qualite@utc.fr
- Tél : +33 (0)3 44 23 44 23
Avertissement
: Si vous arrivez directement sur cette page, sachez
que ce travail est un rapport d'étudiants et doit être
pris comme tel. Il peut donc comporter des
imperfections ou des imprécisions que le lecteur doit
admettre et donc supporter. Il a été réalisé pendant
la période de formation et constitue avant-tout un
travail de compilation bibliographique, d'initiation
et d'analyse sur des thématiques associées aux
concepts, méthodes, outils et expériences sur les
démarches qualité dans les organisations. Nous ne
faisons aucun usage commercial et la duplication est
libre. Si, malgré nos
précautions, vous avez des raisons de contester ce
droit d'usage, merci de nous
en faire part, nous nous efforcerons d'y
apporter une réponse rapide. L'objectif de la
présentation sur le Web est de permettre l'accès à
l'information et d'augmenter ainsi les échanges
professionnels. En cas d'usage du document, n'oubliez
pas de le citer comme source bibliographique.
Bonne lecture...
AGILITE EN PRATIQUE :
SCRUM
Un cadre propice à la transparence et à l’amélioration
continue
Référence
bibliographique à rappeler pour tout usage :
AGILITE EN PRATIQUE : SCRUM, Un cadre
propice à la transparence et à l’amélioration continue, G. KurzawaMaster Qualité et Performance dans les Organisations
(QPO), Mémoire d’Intelligence Méthodologique du stage
professionnel de fin d’études,
www.utc.fr/master-qualite, puis « Travaux » «
Qualité-Management », réf n°398, Université de
Technologie de Compiègne, Juin 2017, https://doi.org/10.34746/8vvm-gz32
RESUME
L’agilité est apparue il y a près de 20 ans pour
les projets complexes notamment ceux liés aux Technologies
de l'Information (IT). Au vu des succès que l’Agilité
rencontre dans les projets par rapport aux méthodes dites
classiques, l’agilité et ses pratiques sont à la mode et
nombreux sont ceux à expérimenter ces méthodes dans leur
projet que ce soit pour des projets IT ou non. Dans ce
mémoire, l’agilité est traitée de manière générale en
allant de la théorie à une pratique. L’agilité y est
présentée via le manifeste agile et une pratique agile :
la méthode Scrum (méthode la plus utilisée aujourd’hui).
Enfin une pratique et les bénéfices de Scrum sont
présentés en se basant sur un retour d’expérience
personnel. Cette présentation vous permettra de mettre des
pratiques concrètes derrière le terme assez flou
d’agilité, pratiques que vous pourrez expérimenter dans
vos futurs projets.
Mots clés : Agilité, scrum, pratiques agiles,
gestion de projet
ABSTRACT
20 years ago, appears Agility a way to handle
complex projects and especially IT projects. In the light
of the success of Agility in project compared to
traditional approaches, Agility and its practices are
popular and many experience these methods in their
projects, in the IT field or not. In this paper, Agility
is discussed in a general way, going from the theory to
the practice. Agility is showed by the Agile Manifesto and
one practice: the scrum framework (nowadays the most used
method). Finally, a practise and gains of Scrum are showed
based on a personal feedback. This presentation will allow
you to define concrete practices behind the vague word of
Agility, practices that you could experiment in your
future projects
Je tiens
tout d’abord à remercier Gregory Tanneau pour m’avoir fait
confiance et pris en stage sur le projet. Mes remerciements
également à l’équipe projet avec qui j’ai passé et continue à
passer de très bons moments au quotidien. A Marie Gayot qui m’a
permis de réaliser ce stage au sein de Onepoint et sans qui je
n’aurai pas pu le faire. Enfin merci à l’entreprise et aux
personnes que j’ai pu rencontrer depuis 6 mois, je pense que ce
n’est que le commencement d’une belle aventure mais ces 6 premiers
mois n’ont été que du positif pour moi, j’ai pu m’épanouir sur le
plan personnel et professionnel.
Je tenais à féliciter et à remercier l’équipe pédagogique, et en
particulier M. Gilbert Farges, pour la qualité et la pertinence de
leur enseignement qui est en lien direct avec le monde de
l’entreprise. J’ai pu grâce à vous trouver ce qui m’avait manqué
dans mon cursus ingénieur.
Une pensée également
pour ma famille et mes amis qui m’ont toujours soutenu et aidé et
sans qui je ne serai pas ou j’en suis aujourd’hui. Enfin un
dernier remerciement à des collègues qui sont devenus amis avec le
temps. J’ai pu grandir et évoluer à votre contact et j’appréhende
ce départ après plus de 2 ans à vos côtés.
QPO : Qualité et Performance dans les organisations
IT : Technologie de l’Information
XP : Extreme programming
RAD : Rapid application development
SAFe : Scaled Agile Framework
LeSS : Large Scale Scrum
GLOSSAIRE
Amélioration continue / Kaisen : L’amélioration continue est
un état d’esprit qui permet à une personne, une équipe ou une
organisation de réfléchir à son fonctionnement et de le rendre plus
performant.
DevOps : méthode qui rapproche les ops (production et
intégration) et les développeurs. Elle permet de mettre en
production les produits réalisés par les équipes agiles au fur et
mesure de leur production. Framework : ensemble de pratiques, rituels, rôles et
méthodes pour répondre à un problème.
Less : framework de gestion de projet embarquant des équipes
agiles (3 à 6).
Management visuel / Tableau Kanban : Il présente un processus
de travail et le travail en cours. Il prend la forme d’un tableau
avec des colonnes et des lignes. Il s’affiche sur un mur ou au sein
d’une application. Méthodes agiles : approche itérative et incrémentale, qui
est menée dans un esprit collaboratif avec juste ce qu’il faut de
formalisme. Elle génère un produit de haute qualité tout en prenant
en compte l’évolution des besoins des clients. Ces méthodes sont une
réponse aux méthodes de gestion de projets dites prédictives comme
le cycle en V ou en cascade.
Safe : framework de gestion de programme en mode agile.
Scrum : méthode agile la plus utilisée en développement
informatique, elle est également utilisée dans d’autres métiers :
l’industrie, le marketing. Scrum of scrum : framework de gestion de projet
embarquant des équipes agiles (3 à 6).
INTRODUCTION
Mon projet professionnel est
de travailler dans le secteur du conseil, et notamment dans le
conseil en organisation. Cela fait un moment que je m’intéresse à
l’amélioration continue et à sa mise en œuvre dans les
organisations. Je cherche à être un soutien et un support de
manière général pour faire en sorte que les choses se passent bien
et aillent mieux. C’est pourquoi j’ai choisi dans un premier temps
de faire le master Qualité et Performance dans les Organisations
(QPO). Mon but était de me professionnaliser et apprendre ce qui
m’avait manqué lors de la formation ingénieur. J’ai dans cette
continuité décidé de me diriger dans le milieu du conseil pour
pouvoir appliquer ce qui m’avait été enseigné lors du master et
pour pouvoir jouer ce rôle de soutien et de support pour les
organisations et les entreprises. En outre ce métier m’a
particulièrement intéressé car c’est un métier pluridisciplinaire
dans lequel je sentais que je ne pouvais pas m’ennuyer, il y
aurait toujours quelque chose à faire, à créer ou à apprendre. En
outre j’avais la volonté de travailler et d’en apprendre plus sur
l’agilité. L’agilité est en effet un concept dont on a largement
parlé tout au long du semestre mais c’est une notion assez vague
qui est propre à chacun, je souhaitais donc en apprendre plus sur
le domaine et voir comment elle était mise en pratique en
entreprise.
La mission qui m’est confiée
dans cette organisation est le rôle d’assistant du Scrum master
chez un client. Ce sujet est assez large et traite de nombreux
domaines étudiées pendant le master. QPO11 pour la gestion de
projet, QPO04 pour le management et le travail en équipe, QPO06
pour les connaissances sur les systèmes d’informations et QPO12
pour la communication professionnelle de projet. De sorte que
j’arrive avec une boite à outil assez chargée pour me permettre
d’affronter le sujet. Le sujet a été construit avec mon tuteur de
stage qui a parfaitement cerné ce que je voulais faire dans
l’entreprise. Je vais pouvoir participer à la mise en place de
l’agilité chez le client. Je suis placé dans un rôle de soutien et
de facilitateur ce qui me correspond parfaitement. L’objectif lors
de ce stage sera de me former à la gestion de projet en mode
agile. Il s’agira également de me faire une expérience
professionnelle en dehors de la recherche ou j’ai déjà réalisé mes
deux précédents stages.
A) L'entreprise et son contexte : une
organisation qui bouge
L’entreprise évolue dans
le secteur du conseil et est spécialisée dans la transition
numérique et les nouvelles technologies. Le groupe a été créé en
2002 (15 ans). Depuis cette date il n’a cessé de croître que ce
soit en nombre de collaborateurs ou au niveau du chiffre d’affaire
: il compte en 2017 plus de 1800 collaborateurs pour un chiffre
d’affaire globale de 150 millions d’euros. Le groupe continue
d’évoluer et souhaite tripler ses effectifs d’ici quelques années.
L’entreprise s’est restructurée en 2016 pour entrer dans un
système organisé en communauté, les valeurs affichées et défendues
sont l’engagement du collaborateur, l’agilité et le métissage. Il
s’agit maintenant d’une entreprise qui se base sur l’intelligence
collective [1].
L’entreprise est organisée
en quatre catégories de communauté : région, métier, support et
service. Chaque catégorie est elle-même découpée en plusieurs
communautés. Chaque communauté est autogérée par les
collaborateurs qui la composent et elles sont ouvertes. Ainsi Les
collaborateurs peuvent intégrer de nouvelles communautés et être
membres de plusieurs communautés ; de cette façon le système n’est
pas figé et les collaborateurs ne sont pas enfermés dans des
cases. C’est un système de ce genre qui permet de motiver les
acteurs, ils ont la possibilité de choisir leur communauté et de
se former sur des sujets qui les intéressent pour être toujours au
plus proche de leurs attentes.
Cette volonté de placer
l’individu au centre du système a également été mis en place lors
de la réorganisation datant d’octobre 2016. L’entreprise se veut
libérée. Les collaborateurs ont le choix de travailler comme bon
leur semble : les horaires ne sont pas fixes, le télétravail a été
mis en place, il s’agit de faire confiance à l’individu pour les
responsabiliser et augmenter leur motivation. Le bureau est
organisé en open space et les places ne sont pas fixes, personne
n’a de place attitrée. Des salles de sieste et des espaces de
détente sont également présents. Tout est fait pour que le
collaborateur se sente bien sur son lieu de travail.
La hiérarchie a été
simplifiée pour se limiter à 3 niveaux : Partner, Leader et
associé.
Projet : processus unique qui consiste en un ensemble
d’activités coordonnées et maîtrisées comportant des dates de
début et de fin, entrepris dans le but d'atteindre un objectif
conforme à des exigences spécifiques, incluant les contraintes de
délais, de coûts et de ressources
[2].
D’après cette définition le
but du projet est d’atteindre un objectif final qui est la
production d’un livrable. Ce livrable peut être sous forme d’un
produit (voiture, téléphone…) ou ouvrage (logiciel, route…). Le
projet fait intervenir des ressources pour atteindre le but et est
encadré par des contraintes. Tout l’enjeu d’un projet et de sa
gestion est d’arriver à atteindre l’objectif en respectant les
contraintes. La gestion de projet consiste à planifier le projet,
suivre le budget, maîtriser les risques, respecter la qualité
demandée. Elle est standardisée part la norme internationale ISO
21500
[3].
Selon le Chaos Report de
2015 seulement 29% des sondés déclaraient que leur projet était un
succès. 52% ont déclaré que leur projet a été challengé,
c’est-à-dire que l’une des contraintes du projet n’a pas été
respectée. Les 19% restants représentent les projets qui n’ont
jamais abouti
[4].
Les raisons de ces échecs sont souvent une mauvaise gestion de
projets, des contraintes qui sont inadaptées ou encore une
approche non adéquate.
D) L'agilité, un mot bien connu, une
signification assez floue
L’agilité est une
façon de penser (mindset), elle a été définie en 2001 dans le
Manifeste pour le développement Agile de logiciels
[5].
Ce texte a été écrit sous la gouvernance de 17 experts du
développement d’applications informatiques tels Ken Schwaber et
Jeff Sutherland, fondateurs de la méthode Scrum (1996) qui est à
ce jour la méthode agile la plus connue et utilisée
[6].
De cette réunion émergea le manifeste agile qui regroupe toutes
les valeurs et principes sous-jacents aux méthodes agiles. Ces
méthodes sont utilisées pour le développement de logiciels et la
conduite de projet. Ces méthodes sont souvent en opposition aux
méthodes traditionnelles de gestions de projet comme le cycle en
V, ils permettent une meilleure visibilité et adaptabilité,
d’augmenter la valeur business et de réduire les risques projets
[7].
L’agilité repose sur 4
valeurs et sur 12 principes (voir figure
1)
Une infinité de méthodes
dites agiles découlent de ces valeurs et principes parmi elles, on
peut citer les plus connues telles que Rapid Application
Development (RAD, 1991), Scrum (1996), Extreme Programming (XP,
1999).
Au-delà de l’équipe IT,
l’agilité est aujourd’hui considérée comme une boite à outil pour
la gestion de projet. Après l’équipe IT, l’agilité cherche à
s’intégrer dans un cadre plus large en intégrant plusieurs équipes
et en allant jusqu’à parler d’organisation agile
[8].
Plusieurs méthodes permettent de mettre en place l’agilité à une
plus grande échelle, on parle d’agilité à l’échelle on peut
notamment citer SAFe, LeSS ou encore le Scrum de Scrum. Au niveau
de l’agilité à l’échelle de l’organisation ou de l’entreprise on
peut citer le management 3.0
[9],
l’entreprise libérée, l’holacratie ou l’intelligence collective.
Figure 1 : L’approche Agile est constituée par 1 Mindset, 4
Valeurs, 12 Principes, une infinité de Pratiques (d’après [5])
E) Scrum, une méthode simple à comprendre
mais difficile à appliquer
Scrum est une
méthodologie ou cadre de gestion de projet. Elle est construite
autour d’une équipe scrum, d’artéfacts et de cérémonies. C’est un
cadre méthodologie incrémental, organisé en sprint pendant
lesquels l’équipe Scrum va produire un incrément potentiellement
livrable du produit. Le but est de livrer un incrément qui a une
valeur ajoutée pour le produit final.
Figure 2 : Scrum, livraison d’un incrément du produit à chaque
sprint (source : [18])
Dans le
rapport annuel publié en 2016 par Version One [6],
le cadre méthodologique Scrum était utilisé par 58% des équipes
agiles. C’est aujourd’hui la méthode la plus documentée et
éprouvée. On peut très facilement comprendre le cadre, les
artéfacts et les rôles en lisant le Scrum Guide [10].
On peut également se documenter via les nombreuses vidéos, sites
et blogs sur le sujet. Cela permet de se bâtir une solide base
de connaissance.
Le product owner (PO) : c’est le garant du produit,
il a la vision de ce qu’est le produit et ce qui doit être
fait en priorité pour maximiser la valeur.
Le scrum master : il veille au respect de la
méthodologie scrum et veille à ce que rien n’entrave
l’équipe pendant le sprint
L’équipe de Dev : c’est elle qui réalise le
produit. Elle est auto organisée et autonome.
Figure 3 : organisation de la Scrum Team autour de 3 rôles
distincts (source : [18])
C’est
une liste de fonctionnalités, besoins, exigences qui vont
permettre de donner la vision produit. C’est le product owner
qui est responsable du backlog, notamment de son organisation et
de sa priorisation. Il va le prioriser en fonction de la valeur.
Le backlog est vivant et évolue en fonction des besoins du PO,
ce n’est pas un cahier des charges fixe.
Le product backlog peut
être organisée en récits utilisateur ou User Story (US) : en
tant que… je veux que… pour que…. Sur chaque US on donne une
valeur business qui permet de prioriser les US dans le backlog,
l’équipe va également évaluer la complexité pour réaliser l’US.
Cela permet de se concentrer sur le besoin et de ne faire que ce
qui est utile et a de la valeur pour le produit.
Figure 4 : mettre en place un backlog produit pour clarifier
le besoin (source : [18])
Le « sprint Backlog » est un ensemble de récits
sélectionnés par l’équipe pour le sprint. L’équipe
s’engage sur les US qu’elle pourra terminer et démontrer à
la fin du sprint. Les US sont ensuite découpées en tâche
pour aider l’équipe à la réaliser. Cela permet à l’équipe
de se projeter et de visualiser le travail à faire au
cours du sprint.
Figure 5 : le sprint backlog via le découpage en tâche
permet à l’équipe de Dev de réaliser le besoin (source : [18])
Dans Scrum tout est
placé dans une boite de temps (Time box), du temps est
alloué pour chaque cérémonie afin de cadrer l’organisation.
Ce cadrage est nécessaire afin de laisser du temps à
l’équipe pour produire.
Sprint planning
Au cours de cette
réunion l’équipe Scrum sélectionne les US qu’elle pense
pouvoir démontrer à la fin du sprint. L’équipe découpe
ensuite en tâches les US. Le PO avec l’équipe décide d’un
but pour le sprint.
Figure 6 : L’équipe Scrum, et le Product Owner définissent
le Sprint Planning (source : [18])
Daily Scrum
On l’appelle également
mêlée journalière, c’est de la que vient le nom de la
méthode. C’est une réunion généralement debout qui a
lieu tous les jours au même endroit, elle est time
boxé comme toutes les réunions Scrum et ne doit pas
excéder 15 minutes. Durant cette réunion l’équipe
présente ce qu’elle a fait la veille, ce qu’elle
compte faire aujourd’hui et les éventuelles
difficultés qu’elle a rencontrées pour atteindre le
but du sprint ou dans l’avancement. C’est une réunion
informationnelle qui permet de donner de la visibilité
et de la transparence sur ce que chacun fait, elle
permet de se focaliser sur le but.
Figure 7 : La « Daily Scrum » génère la dynamique
opérationnelle de l’équipe Scrum (source : [18])
Sprint review
Durant cette réunion l’équipe présente ce qu’elle a fait
pendant le sprint. Suite à cette démonstration le PO
valide ou non l’US selon les critères qui ont été
construits par le PO et acceptés par l’équipe dans la
définition de fait ou Definition of Done (DoD).
Figure 8 : La « Sprint Review »
favorise la communication interne de l’équipe Scrum
(source : [18])
Retrospective
C’est une réunion qui clôture le
sprint et permet à l’équipe Scrum de faire le bilan et
le retour d’expérience sur le sprint. C’est une étape
essentielle qui permet à l’équipe de s’améliorer de
manière continue. Le but de cette réunion est de voir
et changer ce qui n’a pas marché, de capitaliser ce
qui a marché et de proposer de nouvelles choses pour
que le processus marche encore mieux. L’équipe apprend
de ses erreurs pour faire encore mieux au prochain
sprint : on ne peut pas refaire le sprint mais on peut
s’améliorer pour les suivants.
Figure 9 : L’équipe Scrum capitalise sur ses retours
d’expérience et génère de l’amélioration continue de
ses pratiques (source : [18])
Figure 10 : Le cadre méthodologique Scrum en un coup
d’œil : cérémonies, rôles et artéfacts (source : [18])
Le cadre est facile à comprendre,
il se base sur une équipe, des cérémonies et
artéfacts. Il s’agit d’une méthodologie empirique,
c’est-à-dire qui va évoluer avec l’expérience du
terrain. Il n’y a pas une manière d’appliquer Scrum,
Scrum fixe seulement un cadre de travail, ainsi
chaque équipe Scrum sera différente en fonction de
l’expérimentation. C’est pourquoi Scrum est facile à
comprendre mais difficile à appliquer. Le rôle du
Scrum master est essentiel, c’est lui qui va avoir
les connaissances théorique et pratique de la
méthode et c’est lui qui va être responsable de
l’organisation du processus.
F) Mise en place de Scrum chez un
client, zoom sur la mission : enjeux et objectif
En parallèle des projets internes à
l’entreprise une mission chez un client commence, elle
consiste à mettre en place une équipe Scrum. L’équipe
sera en charge du développement du projet pour un
constructeur automobile français.
Comment se monte
et s’organise une équipe projet Scrum et quel est le
rôle du Scrum master dans un projet agile ?
Cette partie
pourra être utile à toute personne s’intéressant de
prêt ou de loin à la méthode Scrum et à sa mise en
place dans son équipe. Cette partie sera un retour
d’expérience personnel sur l’application de la méthode
dans un projet de développement informatique.
L’objectif sera
de montrer ce qu’est l’agilité et comment elle se
manifeste dans une équipe appliquant la méthode.
Comme nous avons pu le voir en introduction la méthode
Scrum est facile à comprendre, cependant elle est
difficile à mettre en place. Le but de cette partie sera
de mettre en valeur cette affirmation et de donner un
retour d’expérience pour la mise en place d’une équipe
Scrum. Il s’agira de montrer comment la méthode Scrum
permet de mettre en place trois piliers que sont la
transparence, l’inspection et l’adaptation
A) Mon projet peut-il se faire en
agile ?
Dans un premier temps nous pouvons nous demander pourquoi
mettre en place une équipe agile. Il est en effet
nécessaire de prendre en compte le contexte. On va
privilégier l’approche agile pour des projets longs avec
une forte complexité. En effet dans ce type de projet il
est difficile de tout planifier et spécifier à l’avance.
De plus le besoin de client n’est pas fixe et évolue au
cours du projet. C’est pourquoi il est nécessaire de se
diriger vers une approche agile qui permet de découper le
projet en sous projets qui vont être au plus proche du
besoin du client. On va ainsi limiter l’effet tunnel
décrié par le cycle en V ou l’approche en cascade [11], [12].
Pour savoir si
l’agilité est adaptée au projet on pourra se référencer à
La matrice de Stacey qui présente le degré d’incertitude
et d’entente face à une situation [13].
Figure 11 : Matrice de Stacey, des
environnements plus ou moins complexes (adaptée de [14])
Le
backlog est construit sous forme d’US. Il s’agit de donner
la vision de l’utilisateur et de son besoin pour réaliser
une fonctionnalité du produit. Cela permet ainsi d’être au
plus proche de ce que l’utilisateur a vraiment besoin et
de développer que ce qui lui est vraiment utile. Cela
permet de dessiner un cahier des charges du produit, en
spécifiant seulement ce dont l’utilisateur a besoin. On
définit grâce à cette approche le « quoi » du produit.
Figure 12 : User Story permet
d’identifier le besoin (source : [18])
Cette approche est
simple au premier abord mais elle se révèle plus complexe
dans les faits. En effet définir le besoin est une bonne
chose pour le client et pour l’équipe qui se chargera de
répondre au besoin. Cependant il y a souvent un écart
entre le besoin (quoi) et la réponse à ce besoin
(comment). C’est pour cette raison que l’US doit être bien
réfléchi en amont pour correctement la préparer et la
spécifier. L’équipe a ainsi une bonne vision de ce qu’est
l’US et ce qu’il faut faire pour la réaliser. Le sigle
INVEST définit ce qu’est une bonne US (voir
figure 13) [14].
Figure
13 : Définition d'une bonne US par INVEST (source : [18])
On a souvent
l’impression que l’agilité est quelque chose de simple ou
on ne documente pas ou peu. C’est une grande erreur. Toute
la spécification et le cahier des charges ne sont
peut-être pas documentés cependant ce dont le client a
besoin immédiatement doit l’être de façon précise. Cela
permet de donner la vision du besoin à l’équipe qui va la
réaliser. On dit souvent que le backlog du produit est
vivant car il évolue. C’est la force des projets agiles.
Le besoin du client évolue au fur et à mesure de la vie du
projet. Le backlog va évoluer en parallèle en fonction du
besoin, c’est ce qui permet une meilleure adaptabilité.
Une équipe agile est
construite autour d’individus motivés. L’équipe a donc été
construire en sélectionnant des individus qui étaient
intéressés par le projet. Au niveau des profils, l’équipe
est constituée de développeurs confirmés et juniors pour
permettre aux juniors de monter en compétence. Au niveau
des compétences les profils sont variés et qualifiés sans
pour autant aller jusqu’à l’expertise dans leur domaine,
il s’agit encore une fois pour chacun de monter en
compétence et de découvrir de nouvelles technologies.
L’intérêt de cette démarche est que chacun soit capable de
réaliser des tâches variées et l’absence d’un membre de
l’équipe ne soit pas bloquante pour l’avancement du
projet.
L’équipe est de
petite taille. La taille maximale pour une équipe Scrum
est 9. La taille idéale est 7 [15]. Il
s’agit en effet de maximiser les interactions entre les
individus et la circulation de l’information au sein de
l’équipe. Une trop grande équipe est un frein.
De plus pour
maximiser les interactions entre les membres de l’équipe
tout le monde travaille au même endroit sur un plateau. De
sorte que si quelqu’un rencontre une difficulté ou a une
demande spécifique il peut directement avoir la réponse,
il n’a pas besoin de passer par le mail ou un autre outil
qui ralentit la circulation de l’information.
L’interaction entre les personnes est un point essentiel
pour le bon déroulement du projet.
L’équipe définit son
fonctionnement, l’agilité c’est s’adapter mais ce n’est
pas une absence de règles. Et pour établir ces règles qui
est mieux placer que l’équipe elle-même. Il s’agit d’un
point essentiel de l’agilité, c’est à l’équipe de
s’organiser et de définir ce qui lui convient le mieux
pour avancer dans les sprints.
Le tableau de l’équipe est le lieu où se trouvent toutes
les informations pour être informé sur l’avancement du
sprint. Il tire sa force du management visuel. Nous
affichons un tableau Kanban, les objectifs du sprint, la
définition de fait, les dates et lieux des différentes
cérémonies, les absences pour le sprint, le burndown chart
et un tableau réunissant des tâches transverses qui ne
servent pas directement à la réalisation du sprint.
Il s’agit d’un outil extrêmement efficace pour permettre
à l’équipe de s’auto-organiser. Il s’agit de laisser
l’équipe le gérer pour qu’elle prenne la main sur cet
outil et qu’elle apprenne à s’auto-organiser. Des règles
peuvent être mises en place comme par exemple de ne pas
prendre de nouvelles tâches tant qu’une tâche est encore
en cours ou encore de mettre son nom sur la tâche pour
savoir qui s’en occupe.
C’est un outil très simple à mettre en place qui permet
d’organiser le travail en équipe et de planifier
l’organisation du sprint et/ou projet. A lui seul cet
outil regroupe les 3 valeurs de Scrum.
Le tableau peut également servir d’élément motivant pour
l’équipe : le fait de finir une tâche et de la passer à
fait est valorisant pour l’équipe.
Figure 14 : le Board de l’équipe permet
de visualiser les flux de travail (source : [18])
On pense souvent que lorsqu’on est dans un projet agile il
n’y a pas besoin de spécifier ni documenter. C’est une
grande erreur. Dans un projet agile on essaie bien
documenter, il s’agit de trouver le bon équilibre entre
l’absence de documentation et une documentation trop
complète qui ne laisse aucune marge de manœuvre. Par bien
documenter, j’entends documentation utilisée, facilement
accessible et compréhensible.
Nous documentons sur l’outil confluence qui est un wiki
collaboratif permettant de créer des pages par tous les
membres de l’équipe.
Pourquoi faut-il documenter ? Cela est nécessaire pour la
bonne circulation de l’information pour que chacun puisse
être informé à tout moment de ce qui est décidé. Cela
permet également de spécifier les caractéristiques d’un
produit ce qui est essentiel surtout quand on a à faire à
un produit complexe comme les projets de développements ou
de nombreuses solutions sont envisageables. Enfin cela
permet d’acter des décisions et de faire le compte rendu
de réunion : bien souvent de nombreuses choses sont faites
et dites en réunion mais on en garde rarement une trace.
Malheureusement notre mémoire est sélective et ne permet
pas de tout sauvegarder, on oublie généralement une grande
majorité des choses qui se sont dites en réunion après
quelques jours. La documentation est donc essentielle pour
permettre la circulation de l’information.
Le suivi des tâches
s’effectue également via Jira. C’est un outil permettant
le suivi des bugs et des tâches. C’est en quelque sorte un
board dématérialisé et collaboratif. Le suivi des tâches
s’effectue de la même façon que sur le board. Cela permet
de tracer ce qui s’est fait pendant le projet et de ne pas
perdre de tâches comme cela peut arriver par post-it.
Cependant cet outil est peu utilisé par l’équipe qui
préfère utiliser le board pour le suivi des tâches. Cet
outil est malgré tout utilisé pour le suivi des US : de
leur préparation par le PO à la livraison par l’équipe.
En outre ces outils
de travails collaboratifs permettent à chacun de
travailler comme bon lui semble vu qu’ils sont accessibles
en ligne. Cela ne se substitue pas à la présence des
membres de l’équipe qui est un pilier de Scrum mais cela
permet à l’équipe de pouvoir travailler à distance en
fonction des contraintes que chacun peut rencontrer.
Le daily Scrum sert à répondre à 3 questions : ce qui a
été fait hier, ce qui va être fait aujourd’hui, ce qui est
bloquant pour l’avancement. L’intérêt de cette cérémonie
est qu’elle permet à l’information de circuler rapidement,
elle permet de comprendre et de donner de la visibilité
sur ce que chacun fait. Tous les jours l’équipe fait un
retour sur ce qui a été fait la veille et comment elle
appréhende cette nouvelle journée. Le PO et les parties
prenantes peuvent également y assister pour avoir de la
visibilité sur l’avancement du sprint. Cela permet à
l’équipe d’aller dans la bonne direction. Il est avant
tout destiné à l’équipe pour s’auto-organiser et aller
ensemble dans la même direction. Il s’agit d’un point de
coordination, synchronisation et d’inspection de l’équipe.
Le daily scrum se
fait devant le tableau de l’équipe, debout et ne dure que
15 minutes. Il s’agit d’une réunion dynamique ou chaque
membre de l’équipe met à jour le tableau. Il est
nécessaire que tout le monde s’écoute et aille directement
au but de manière synthétique pour ne pas se perdre dans
des discussions. Si des points sont à clarifier, des
réunions peuvent être planifiées pour les éclaircir,
l’important est de toujours se concentrer sur le sprint
goal et la réalisation des US pour ne pas diverger.
Figure 15 : Daily Scrum
de l'équipe devant le board pour se synchroniser sur
le travail à faire (source : [18])
La rétrospective est une des clés de fonctionnement de la
méthode. Elle se déroule en fin de sprint et permet à
l’équipe de donner un retour d’expérience sur son
fonctionnement. C’est une cérémonie au cœur de
l’amélioration continue du processus : elle permet à
l’équipe de contrôler son fonctionnement et faire toujours
mieux aux sprints suivants.
Le Scrum master
tient un rôle essentiel lors de cette réunion : c’est lui
qui est en charge de l’organisation et de l’animation.
En amont de la
réunion Il doit être capable de trouver la rétrospective
qui correspond le mieux à la situation actuelle de
l’équipe pour faciliter le feedback et les retours de
chacun. A ce sujet on peut citer des rétrospectives comme
le speed boat, l’improvement canvas ou le Juke box qui
permettent facilement d’obtenir du feedback tout en
sollicitant les participants. A ce sujet une lecture est
essentielle pour l’organisation de rétrospective : « Agile
Retrospective » d’Esther Derby [16].
Les rétrospectives se font le plus souvent avec des
méthodes de facilitation. Le jeu et la visualisation
graphique sont souvent utilisés pour permettre aux
participants de laisser libre cours à leurs idées [17].
Lors de la réunion
le Scrum master doit être dynamique, faire preuve d’une
bonne capacité d’écoute active, de reformulation, de
synthèses et d’une grande ouverture d’esprit. Il doit être
facilitateur pour permettre à chacun de s’exprimer et de
donner du feedback pour l’amélioration continue.
Après la réunion le
feedback recueilli permet d’établir un plan d’action pour
l’amélioration du processus. Il s’agit alors de veiller à
l’application de ce plan lors du prochain sprint.
Une fois que le backlog est estimé et
la vélocité moyenne de l’équipe identifiée, on peut
mettre en place des courbes qui vont aider au pilotage
du projet. Le pilotage se fait à différentes échelles de
manière macro (vision globale) et de manière micro au
niveau du sprint.
Au niveau micro le
pilotage peut se faire via un burndown chart (figure
17). Après le découpage en tâches, on compte le nombre
de tâches à faire pendant le sprint et on trace la
droite représentant l’évolution idéale du nombre de
tâches. Après chaque Daily on met à jour le burndown en
comptant le nombre de tâches restantes sur le board.
Cela permet d’avoir une vision micro du sprint et cela
constitue un premier indicateur pour le pilotage du
sprint. Il s’agit d’un indicateur qui permet à l’équipe
de visualiser l’avancement du sprint et de s’adapter. Il
permet également de donner de la visibilité.
Figure 17 : le burndown chart permet de savoir à tout
moment le travail qu’il reste à faire (source : [18])
Au niveau macro les courbes vont se
baser sur l’estimation du backlog et la vélocité moyenne
de l’équipe. La vélocité s’affine au fur et à mesure de
l’avancement des sprints. Plus on avance dans le projet
plus on sera précis sur la vélocité de l’équipe et sur le
nombre et la complexité des US qu’elle peut prendre par
sprint. Au niveau projet on pourra ainsi estimer quand se
terminera théoriquement le projet.
Nous espérons que la
vélocité de l’équipe va augmenter à court/moyen terme.
Nous espérons que l’équipe arrivera à trouver une bonne
organisation et arrivera à se structurer au fur et à
mesure de l’avancement du projet. Le projet a été
initialement prévu pour durer 1 an et demi suite à
l’estimation du backlog. L’objectif est de tenir ce délai.
Après 6 sprints l’équipe cherche encore à se mettre en
place pour tendre vers une vélocité qui se stabilise et
augmente. Lors du 1er sprint de nombreux outils ont dû
être mis en place par et pour l’équipe et c’est pour cette
raison que rien n’a pu être livré lors de ce sprint. Au
cours des trois sprints suivants l’équipe a pu commencer à
coder et a pu livrer quelques US, cependant elle pense
pouvoir livrer plus que ce qu’elle a pu produire au cours
des derniers sprints. Il en est ressorti des problèmes
d’organisation au sein de l’équipe. Ce sont des problèmes
dont l’équipe est consciente et qu’elle va chercher à
résoudre pour s’améliorer au cours des sprints futurs.
Au-delà de ces
aspects, la force de la méthode réside dans l’amélioration
continue et du fait que cette amélioration vient de
l’équipe elle-même, c’est elle qui décide ce qui doit être
amélioré. C’est au Scrum master d’actionner les actions.
Cependant, parfois les problèmes sont résolus directement
en les mentionnant. Nous avons par exemple rencontré des
problèmes sur le découpage des tâches, l’équipe avait des
difficultés pour le faire et cela se traduisait par une
augmentation des tâches et des us qui durait sur plusieurs
sprints. La solution qui a été trouvée a été de faire un
découpage des us pour en faire des plus petites et de
faire le découpage sur un tableau pour aider à visualiser
le travail à réaliser. Nous avons également rencontré des
problèmes de conception, notamment pour qu’elle soit
coordonnée entre tous les membres de l’équipe. La solution
à ce problème a été de faire la conception en début de
sprint au moment du découpage en tâches et sur le tableau,
ainsi chacun est présent et tout le monde à l’information
sur comment doit se faire la conception du produit.
Un autre problème
rencontré a été que de nombreuses tâches s’accumulaient
dans la colonne en cours : beaucoup de choses étaient
commencées mais n’étaient jamais finies jusqu’au bout. Ce
qui a été entrepris est de faire des étiquettes avec le
nom des développeurs ainsi quand il prend une tâche il met
son nom sur le post et reste sur la tâche tant que
celle-ci n’est pas encore terminée.
Un problème plus
récent a été que le daily durait trop longtemps et qu’il y
avait des réunions dans la réunion. La solution qui a été
trouvée pour cela a été de former deux équipes. Chaque
équipe a son daily et ses us pour le sprint. Grâce à cela
la réunion est plus dynamique et ne dure que quelques
minutes, chacun peut plus facilement exprimer ce qu’il a a
dire et tout le monde l’écoute.
B)Les bénéfices de la méthode, pourquoi être
agile ?
Selon le 10e rapport
annuel sur l’état de l’Agilité de VersionOne les bénéfices
de l’Agilité sont ceux présentés sur la figure suivante :
Figure 18 : Bénéfices de l'agilité
selon ses utilisateurs (d’après [6])
Grâce aux premiers
sprints un retour d’expérience a pu être établi sur la
méthode et son fonctionnement. Je me suis en particulier
demandé quelles pratiques favorisaient ces bénéfices.
Ce stage m’a permis
d’en apprendre beaucoup sur le métier de consultant et sur
l’agilité. J’ai pu me rendre compte grâce à ce stage que
le monde étudiant nous donne les bases et la boite à
outils pour pouvoir se débrouiller dans le monde du
travail, cette boite à outils est utile pour faire un peu
de tout mais il nous reste encore beaucoup de choses à
apprendre une fois sur le terrain pour être vraiment
opérationnel. Actuellement je peux mesurer l’écart et la
marge de progression que j’ai en prenant comme référence
mon tuteur de stage qui est Scrum master. Je manque encore
d’assurance pour l’animation de réunion, j’ai pu prendre
conscience que l’animation d’atelier est un travail
difficile, il faut clairement expliquer les choses et les
tenant et aboutissant de l’atelier. En outre je pense
pouvoir encore progresser sur les exercices de synthèses,
d’écoute active et de reformulation. Enfin je pense qu’il
va me manquer une connaissance de l’IT et des langages
informatiques, je n’ai pas eu de formations ce qui peut et
va je le pense constituer un frein, je pense en effet
qu’il est impossible de dialoguer avec quelqu’un si on a
pas la même base de langage.
Pour terminer je
pense avoir beaucoup appris lors de ce stage que ce soit
professionnellement ou personnellement. L’entreprise m’a
laissé beaucoup d’autonomie et la possibilité de choisir
des sujets qui m’intéressaient vraiment, j’ai toujours eu
le choix des sujets que je voulais traiter. C’est quelque
chose que je retrouve un peu de l’UTC et cela m’a beaucoup
plu.
[1]G. O. Zaïbet, « Vers l’intelligence collective
des équipes de travail : une étude de cas, Abstract »,
Manag. Avenir, vol. n° 14, no 4, p. 41‑59, déc. 2008.
[2]« FD ISO 10006 - Systèmes de management de la
qualité - Lignes directrices pour le management de la
qualité dans les projets - Tirage 2 ». EditionsAfnor, Paris, www.afnor.org,
01-janv-2005.
[3]« NF ISO 21500 - Lignes directrices sur le
management de projet ». EditionAfnor, www.afnor.org,
01-oct-2012.
[4]J. Lynch, J. Johnson, J. Crear, L. Vianna, et T.
Mulder, « CHAOS Report 2015 », The Standish
Group.
[5]Kent Beck et al., « Manifeste pour le
développement Agile de logiciels ».
[6]« VersionOne 10th Annual State of Agile
Report », Version One, 10, 2016.
[16]Esther Derby, Diana Larsen, et Ken Schwaber, Agile
Retrospectives - Making Good Teams Great. O′Reilly,
2006.
[17]James Macanufo, Sunni Brown, et Dave Gray, Gamestorming :
Jouer pour innover : pour les innovateurs, les
visionnaires et les pionniers. Editions Diateino,
2014.
[18] G. Kurzawa, “AGILITE
EN PRATIQUE : SCRUM, Un cadre propice à la transparence et à
l’amélioration continue,” Master Qualité et Performance dans
les Organisations (QPO), Mémoire d’Intelligence
Méthodologique du stage professionnel de fin d’études,
www.utc.fr/master-qualite, puis “Travaux”
“Qualité-Management”, réf n°398, Université de Technologie
de Compiègne, Juin 2017.