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

logo UTC

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


photo_auteur

Gaëtan KURZAWA
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

Key words: Agility, Scrum, agile pratices, project management


Téléchargez le Mémoire logo rapportsous format .pdf

Remerciements

        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.


SOMMAIRE

. 3


5


INTRODUCTION. 9


CHAPITRE 1 : CONTEXTE. 10
A)      L’entreprise et son contexte : une organisation qui bouge. 10
B)      Intelligence collective ? Qu’es aquò ?

C)      Enjeux de la gestion de projet 12.

D)      L’agilité, un mot bien connu, une signification assez floue. 11

E)     Scrum, une méthode simple à comprendre mais difficile à appliquer 12

F)      Mise en place de Scrum chez un client, zoom sur la mission : enjeux et objectif 17


CHAPITRE 2 : METHODE DE RESOLUTION. 18
A)      Mon projet peut-il se faire en agile ?. 18

B)      Comment le bakclog est-il construit ?. 19

C)      Comment l’équipe a-t-elle été construite ?. 20

D)     Comment est organisé le tableau de l’équipe. 21

E)      Comment nous documentons. 22

F)      Comment nous faisons le daily Scrum.. 23

G)     Comment nous faisons la rétrospective. 24

H)     Comment se fait le pilotage du projet. 25


CHAPITRE 3 : RESULTATS. 27
A)      Amélioration continues après 6 sprints. 27

B)      Les bénéfices de la méthode, pourquoi être agile ?. 28


CONCLUSION. 30


REFERENCES BIBLIOGRAPHIQUES








LISTE DES FIGURES



Figure 1 : L’approche Agile est constituée par 1 Mindset, 4 Valeurs, 12 Principes, une infinité de Pratiques (d’après [5])

Figure 2 : Scrum, livraison d’un incrément du produit à chaque sprint (source : auteur)

Figure 3 : organisation de la Scrum Team autour de 3 rôles distincts (source : auteur)

Figure 4 : mettre en place un backlog produit pour clarifier le besoin (source : auteur)

Figure 5 : le sprint backlog via le découpage en tâche permet a l’équipe de Dev de réaliser le besoin (source : auteur)

Figure 6 : L’équipe Scrum, et le Product Owner définissent le Sprint Planning (source : auteur)

Figure 7 : La « Daily Scrum » génère la dynamique opérationnelle de l’équipe Scrum (source : auteur)

Figure 8 : La « Sprint Review » favorise la communication interne de l’équipe Scrum (source : auteur)

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 : auteurs)

Figure 10 : Le cadre méthodologique Scrum en un coup d’œil : cérémonies, rôles et artéfacts (source : auteur)

Figure 11 : Matrice de Stacey, des environnements plus ou moins complexes (adaptée de [14])

Figure 12 : User Story permet d’identifier le besoin (source : auteur)

Figure 13 : Définition d'une bonne US par INVEST (source : auteur)

Figure 14 : le Board de l’équipe permet de visualiser les flux de travail (source : auteur)

Figure 15 : Daily Scrum de l'équipe devant le board pour se synchroniser sur le travail à faire (source : auteur)

Figure 16 : Atelier de rétrospective, l'Improvement Canvas (source : auteur)

Figure 17 : le burndown chart permet de savoir à tout moment le travail qu’il reste à faire (source : auteur)

Figure 18 : Bénéfices de l'agilité selon ses utilisateurs (d’après [6])

Figure 19 : Pratiques agiles pour quels bénéfices (source : auteur)







SIGLES



PO : Product Owner

US : User Story, récit utilisateur

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.


Retour au sommaire





CHAPITRE 1 : CONTEXTE




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].

Retour au sommaire


B) Intelligence collective? Qu'es aquò?


        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é.

Retour au sommaire


C) Enjeux de la gestion de projet


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.

Retour au sommaire



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 : Agilité, 1
          mindset, 4 valeurs, 12 principes et une infinité de pratiques
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, cadre de la méthode
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.





        1) Les roles dans une équipe Scrum


  • 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 : Scrum Team

Figure 3 : organisation de la Scrum Team autour de 3 rôles distincts (source : [18])

        2) Les artéfacts Scrum



                        Le product Backlog

        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.




Figure4-1.png

Figure 4 : Artefact Scrum, Product
            Backlog

Figure 4 : mettre en place un backlog produit pour clarifier le besoin (source : [18])



                Le sprint Backlog

        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.



Figure5-1.png


Figure 5 : Artefact Scrum, Sprint
                Backlog
Figure 5 : le sprint backlog via le découpage en tâche permet à l’équipe de Dev de réaliser le besoin (source : [18])







        3) Cérémonies Scrum

        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 : Cérémonie Scrum, Sprint
                Planning
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 : Cérémonie Scrum, Daily
                    Scrum
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 : Cérémonie
                      Scrum, Sprint Review
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 : Cérémonie Scrum,
                    Rétrospective
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 : Cadre
                    méthodologique Scrum
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.










 





CHAPITRE 2 : METHODE DE RESOLUTION



 

        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

Figure 11 : Matrice de Stacey, des environnements plus ou moins complexes (adaptée de [14])

 

B) Comment le bakclog est-il construit ?

        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
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
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é.


 


C) Comment l’équipe a-t-elle été construite ?

         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.

 




D) Comment est organisé le tableau de l’équipe

 

        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 : Board de l’équipe

Figure 14 : le Board de l’équipe permet de visualiser les flux de travail (source : [18])





E) Comment nous documentons ?


        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.





F) Comment nous faisons le daily Scrum


        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

  Figure 15 : Daily Scrum de l'équipe devant le board pour se synchroniser sur le travail à faire (source : [18])


G) Comment nous faisons la rétrospective

        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.



Figure 16 :
                  Atelier de rétrospective, l'Improvement Canvas
Figure 16 : Atelier de rétrospective, l'Improvement Canvas (source : [18])





H) Comment se fait le pilotage du projet ?


        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 : Burndown Chart
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.













CHAPITRE 3 : RESULTATS



 

 

A) Amélioration continues après 6 sprints


        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
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.

 

Figure 19 : Pratiques
                  agiles pour quels bénéfices

Figure 19 : Pratiques agiles pour quels bénéfices (source : [18])










 



CONCLUSION





        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.


Retour au sommaire







REFERENCES BIBLIOGRAPHIQUES






[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. 4159, 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 ». Editions  Afnor, Paris, www.afnor.org, 01-janv-2005.

[3]          « NF ISO 21500 - Lignes directrices sur le management de projet ». Edition  Afnor, 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.

[7]          « LA GESTION DE PROJET : METHODE CLASSIQUE VS METHODES AGILES | Access Dev - Agence de Communication Digitale à Montpellier ». [En ligne]. Disponible sur: http://www.access-dev.com/access-dev/la-gestion-de-projet-methodes-classiques-vs-methodes-agiles/. [Consulté le: 26-avr-2017].

[8]          « Petite histoire de l’agilité organisationnelle - Questions de Management - Le blog d’Eric Delavallée ». [En ligne]. Disponible sur: http://www.questions-de-management.com/petite-histoire-de-lagilite-organisationnelle/. [Consulté le: 26-avr-2017].

[9]          Jurgen Appelo, Managing for Happiness: Games, Tools, and Practices to Motivate Any Team. John Wiley & Sons Inc, 2016.

[10]       Jeff Sutherland et Ken Schwaber, « The Scrum Guide ». 2016.

[11]       F. TRAORE, « Etes-vous plutôt agile ou classique? », Blog de la Gouvernance et du Management, 25-oct-2016. .

[12]       « SCRUM, ScrumBan, Kanban: de la complémentarité et une affaire de contexte », QualityStreet - Blog Agile depuis 2007. .

[13]       « Simple, compliqué, complexe ou chaotique ». [En ligne]. Disponible sur: http://developpementagile.com/posts/2013/february/simple-complique-complexe-ou-chaotique. [Consulté le: 26-avr-2017].

[14]       « Référentiel des pratiques Agiles ». [En ligne]. Disponible sur: http://institut-agile.fr/invest.html. [Consulté le: 27-avr-2017].

[15]       « Méthode Agile Scrum - Applicabilité Gestion projet informatique », Pentalog FR. [En ligne]. Disponible sur: https://www.pentalog.fr/notre-demarche/methode-agile-scrum.htm. [Consulté le: 28-mai-2017].

[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.






Retour au sommaire