Guide de la Thorie et de la Pratique de

Scrum

Saidi Wael Formation Informaticiens PAPNJ

Sommaire
II.

La gestion de projet informatique........................................................................................ 5

III.

La gestion de projet : une affaire dorganisation ?............................................................6

IV.

Le modle nominal "en cascade" de gestion de projet.....................................................7

V.

Le modle en V.................................................................................................................... 8
2. La mise en pratique du modle en V................................................................................. 10
3. Les rles............................................................................................................................ 11
4. Notion deffet tunnel......................................................................................................... 11
5. Des rsultats chaotiques................................................................................................... 12

Lagilit au cur des projets.................................................................................................... 14

1. Un peu dhistoire............................................................................................................... 14
2. Les valeurs........................................................................................................................ 14
3. Les principes..................................................................................................................... 15
VI.

Scrum, une mthode agile.............................................................................................. 15

VII.

Vue densemble.............................................................................................................. 16

Les rles de Scrum................................................................................................................ 17

Le Product Backlog................................................................................................................ 20
La dfinition de Termin........................................................................................................ 23
La Planification de Sprint....................................................................................................... 24
Le Daily Scrum...................................................................................................................... 28
Suivre la progression durant le Sprint...................................................................................28
Laffinage du Product Backlog............................................................................................... 30
La Revue de Sprint................................................................................................................ 30
La Rtrospective de Sprint.................................................................................................... 31
Dmarrer le prochain Sprint.................................................................................................. 32
La gestion des Releases........................................................................................................ 32
Focalisation Produit ou Application........................................................................................ 34
Les problmes courants........................................................................................................ 34
Appendix A: lectures additionnelles......................................................................................... 36

Saidi Wael Formation Informaticiens PAPNJ

I.

Le grand dpart

Nous voici la premire marche de notre apprentissage vers lutilisation de la mthode Scrum.
vocation dintroduction, de prsentation ou bien encore de mise en bouche, ce chapitre se veut
avant tout tre une photo sur ce que nous pouvons connatre en termes de gestion de projet au
quotidien, ou que vous connatrez srement un jour si vous dbutez dans le monde de
linformatique.
Chef de projet est le Saint Graal de tout jeune informaticien sortant de lcole. Certaines
coles dingnieur informatique mettent ce rle sur un pidestal et si vous natteignez pas ce but,
cela peut signifier que vous ratez un tournant dans votre carrire. Pour dautres, cela nest quun
titre, ou bien encore une fonction bien utile pour trouver une personne accuser en cas de
problme (ne souriez pas, nous sommes srs quautour de vous certaines personnes le
pensent).
Si vous tes ou allez bientt devenir LE chef de projet de votre quipe, nous sommes heureux
que vous ayez fait lacquisition de cet ouvrage car nous aurons loccasion dtudier le
positionnement du chef de projet au sein de la mthode Scrum, mais nous nen dirons pas plus
pour le moment (il faut bien garder un peu de suspens pour la suite).
Il y a quelques instants, nous parlions de photographie du prsent . Non pas quil existe un
avant et un aprs lapparition des mthodes agiles telles que Scrum, mais nous allons nous
focaliser sur ce qui se pratique encore dans la majeure partie des entreprises franaises : la
gestion de projet que nous appellerons tout au long de cet ouvrage gestion de projet
traditionnelle ou prdictive.
Avant de pntrer dans les mandres de Scrum, nous allons nous attarder sur ce quest la
gestion de projet telle quelle est perue et applique de nos jours et quelles sont les mthodes
enseignes dans les universits et toujours appliques depuis plus de trente ans. Bien entendu,
cela tend voluer.

II.

La gestion de projet informatique

Questce que la gestion de projet informatique ? Vaste question ! Cidessous, nous avons list
quelques rponses issues dun brainstorming avec une population de chefs de projet ayant au
moins cinq ans dexprience :

Prsence dun chef de projet

Notion de jours/homme
Autorit/Hirarchie
Dlai et cot
Engagement
Mrite
Saidi Wael Formation Informaticiens PAPNJ

Contrat
Dveloppeur, concepteur, architecte, designer
Avenant
Dpassement
Sanction
Stress
Expression de besoins
Formalisation
Recette fonctionnelle
Cycle en V
Satisfaction personnelle

Le brainstorming est une technique de recherche dides originales, dans un groupe,

par la libre expression, sur un sujet donn, de tout ce qui vient lesprit de chacun
(Dfinition selon le dictionnaire Larousse).
Ce qui ressort de ce brainstorming est lmergence de facteurs humains (rles, motions,
sentiments), de prsence dune ou plusieurs mthodologies (cycle en V, expression de besoins...),
de lexistence dune relation client/fournisseur base sur de lengagement et de la
contractualisation (contrat, avenant, cot). Enfin, nous notons des constats qui peuvent paratre
pour certains difiants : dpassement, sanctions, stress.
Au vu de ces quelques lignes, la gestion de projet informatique exprime par ces personnes ne
semble pas si engageante que cela, hormis les notions de mrite et de satisfaction personnelle
qui, aprs discussions avec les personnes ayant exprim ces termes, sacquirent lorsque le
projet apporte satisfaction lentreprise.
Forts de ces constats, nous allons notre tour rpondre cette question, avec la vision que nous
en avons. Bien entendu, il se peut que vous ne soyez pas daccord avec nous et cest tout fait
normal. En effet, il sagit dune vision qui nous est propre et peut donc tre sujette discussion.

III.

La gestion de projet : une affaire dorganisation ?

Si nous prenons la peine dobserver le monde de lentreprise actuel, nous constatons que tout est
processus : processus comptable, processus de ressources humaines, processus de vents et de
marketing, etc. Chaque processus sexerce dans des dpartements bien spcifiques de
lentreprise. Ainsi, nous pouvons noter lexistence dun dpartement comptable, dun dpartement
de ressources humaines, dun dpartement de marketing et ventes.
Tout dpartement possde un chef (souvent appel directeur) de niveau hirarchique "n" qui est
parfois second, puis nous trouvons les "n1", les "n2", les "n3" ... jusquau niveau plus
oprationnel.
Si nous essayons de reproduire cette organisation au sein dun service informatique, nous
trouvons le Directeur des Services Informatiques (DSI) de niveau hirarchique "n", le responsable
de domaine ("n1"), les responsables dquipe projet ("n2"), le chef de projet ("n3"), le dveloppeur
informatique.
4

Saidi Wael Formation Informaticiens PAPNJ

Nous pouvons donc noter une forte notion de dpendance hirarchique o chacun veille au
quotidien lapplication de rgles qui lui sont imposes : le chef de projet ralise les plannings,
veille la nondrive du projet et distribue le travail aux dveloppeurs de son quipe. Les
dveloppeurs quant eux codent lapplication en veillant respecter les rgles dcrites dans les
spcifications fonctionnelles de la future application.
Grer un projet informatique dans son ensemble, cest donc respecter des rgles de bonne
conduite et ne pas y droger afin de sinscrire correctement dans le processus de lentreprise.

IV.

Le modle nominal "en cascade" de gestion de projet

Comme nous venons de lindiquer, grer un projet informatique cest sinscrire dans un processus
de lentreprise qui se doit donc de respecter certaines rgles.
Les rgles de base appliquer et rencontres dans la majeure partie des entreprises en termes
de gestion de projet sont cellesci :
tape 1 : possder une ide de projet (cela va de soi).
tape 2 : avoir une expression de besoins rdige selon un formalisme dfini par lentreprise,
recensant les exigences fonctionnelles des utilisateurs.
tape 3 : rdiger ventuellement un contrat (dans le cas dune ralisation au forfait) bas sur cette
expression de besoins o nous y trouverons les engagements tels que le dlai, le cot et ainsi que
les responsabilits de chacun (pnalits de retard)
tape 4 : rdaction des spcifications techniques par les concepteurs informatiques, o nous
pourrons voir la naissance de diagramme UML (Unified Modeling Language), de schma de base
de donnes...
tape 5 : dbut des dveloppements informatique sur lecture des spcifications fonctionnelles et
techniques.
tape 6 : recette globale de lapplication (tests unitaires, test fonctionnel, tests dintgration).
tape 7 : livraison et installation de lapplication.
Ce que nous venons de dcrire l est ce que nous appelons le modle nominal (ou modle
linaire) de gestion de projet. Chaque tape suit la prcdente et ne peut exister que si ltape
antrieure est termine. Il ny a donc pas existence de notion de paralllisassions dtapes. Cest
pourquoi ce modle est galement appel "modle en cascade" ou "Waterfall" et fut surtout
appliqu avant les annes 80.

Saidi Wael Formation Informaticiens PAPNJ

Modle en cascade ("Waterfall")

Cette notion de dpendances entre chaque phase posa de nombreux problmes.
En effet, imaginons prsent quune erreur de comprhension du besoin se soit glisse en phase
de rdaction des spcifications technique (tape 4). Si nous reprenons lensemble des phases du
modle, nous pouvons en dduire que cette erreur ne sera dtecte, et ce dans le meilleur des
cas, que lors de lexcution des tests fonctionnels (tape 6).
Pour corriger cette erreur, il faudra donc modifier les spcifications techniques, refaire le
dveloppement, rcrire et rejouer les tests. Tout ceci ayant bien entendu un cot quil nest pas
prfrable dimaginer.
Il fallait donc trouver une solution pour pallier ce problme. Cest dans le dbut des annes 80 que
la solution fut trouve par la cration du modle en V bien connu de tous et toujours appliqu en
entreprise.

V.

Le modle en V

Comme nous venons de lindiquer, le modle en V prend naissance dans le dbut des annes
1980, et demeure le modle de gestion de projet informatique le plus utilis en entreprise.
Nous constatons donc que depuis trentedeux ans nous procdons toujours de la mme faon
pour grer le dveloppement dun systme dinformation (cela peut paratre surprenant).
Il faut cependant relativiser, il existe un modle en V thorique, que nous allons prsent aborder,
et le modle en V rellement appliqu en entreprise.
6

Saidi Wael Formation Informaticiens PAPNJ

1. La thorie
Lapproche thorique du modle en V (appel galement cycle en V) veut que toute action
entreprise dans le modle en cascade ait son anticipation du "comment cela devrait se passer".
cet instant, nous sommes quasiment srs que nous vous avons perdu, cest la raison pour
laquelle nous allons reprsenter cela par un schma.
Le modle en V comporte 8 tapes dcrites cidessous :
tape 1 : criture de lexpression de besoins. Le client exprime son besoin, en dcrivant les
fonctionnalits correspondant au produit fini tel quil peut limaginer.
tape 2 : criture des spcifications fonctionnelles dtailles : cest le cahier des charges exact du
produit final, tel que le dsire le client. Il doit couvrir lintgralit des cas dutilisation du produit, en
expliquant ce quil doit faire. On y trouve les rgles de gestion, des copies dcrans (cela
ncessite plusieurs dizaines de pages et quelques mois dcriture).
tape 3 : criture des spcifications techniques : cest une traduction des spcifications
fonctionnelles en termes techniques (mise en place de larchitecture, design de la base de
donnes, choix du langage). Cette tche est gnralement ralise par les ingnieurs
concepteurs.
tape 4 : codage : cest la phase de ralisation du produit.
tape 5 : ralisation des tests unitaires : ces tests permettent de sassurer que chaque brique
fonctionnelle (parfois appel module) est en ordre de marche sans bug apparent.
tape 6 : ralisation des tests dintgration : ce sont l les premiers tests grandeur nature du
produit fini. On sassure que le produit livr est conforme aux recommandations dcrites dans les
spcifications techniques.
tape 7 : validation fonctionnelle du produit. Le produit doit tre conforme lensemble des rgles
fonctionnelles dcrites dans les spcifications fonctionnelles.
tape 8 : mise en production et recette : le produit est vrifi une dernire fois dans un
environnement dit de "prproduction", avant dtre install sur lenvironnement de production. Le
client procde alors la recette, pour vrifier que son expression de besoins est respecte.
En informatique, la notion de recette est une tape part entire dun projet consistant contrler
que le logiciel produit correspond bien aux attentes fonctionnelles exprimes par le client, et quil
ne comporte pas de bugs majeurs.

Saidi Wael Formation Informaticiens PAPNJ

Modle en V
la lecture du schma, nous observons une notion danticipation et de paralllisassions des
tches. En effet, pendant que les spcifications fonctionnelles sont crites, il est possible
danticiper la phase de validation par lcriture et llaboration des tests de validation (tape 1 vers
tape 8). Il en va de mme pour la phase dintgration (tape 6) qui peut tre anticipe une fois la
phase de rdaction des spcifications techniques termine (tape 3).
Cette anticipation de phase permet de raliser les tests au plus tt et par consquent danticiper
tout problme. Ainsi une erreur de couverture fonctionnelle dtecte rapidement permettra aux
dveloppeurs dviter un codage inutile.

2. La mise en pratique du modle en V

Cette vision reste cependant trs thorique. Dans la pratique, ce modle est bien rarement
appliqu tel quel.
Ce que nous avons tendance observer est une communication ascendante et descente dans les
phases de rdaction des spcifications et du codage.
Ainsi, si lors de la rdaction des spcifications techniques est peru un manque dans les
spcifications fonctionnelles, une mise jour de cellesci est faite et inversement.
Il en va de mme pour le codage. Un oubli dans les spcifications ? Il suffit alors de mettre jour
les spcifications techniques et fonctionnelles.
Procder de cette faon a un inconvnient majeur : celui de souvent occasionner un dphasage
entre ce qui a t imagin et ralis du fait que la mise jour des spcifications est bien souvent
omise.

Saidi Wael Formation Informaticiens PAPNJ

Modle en V dans la pratique

3. Les rles
Le modle en V donne galement naissance des rles sans doute connus de tous que sont la
MOA et la MOE.
La MOA (Matrise dOuvrAge) est charge de laspect fonctionnel du produit. Ses responsabilits
rsident dans la dfinition du besoin et veiller ce que ce dernier soit respect lors de la phase
de recette.
Quant la MOE (Matrise duvre) regroupant notamment les chefs de projets, les dveloppeurs
et les architectes, elle est charge dcrire les spcifications dtailles, de raliser le
dveloppement sans oublier les tests dintgration.

4. Notion deffet tunnel

Lorsque nous observons un tunnel, nous en connaissons le point dentre et le point de sortie
mais ce qui se passe lintrieur nous est totalement inconnu.
Le modle du cycle en V est malheureusement victime de cet effet. Les utilisateurs (la MOA dans
son ensemble) sont fortement impliqus dans la phase de rdaction des besoins mais lorsquil
sagit des phases plus techniques (conception, dveloppement) ils sont totalement mis lcart.
Une fois les phases techniques termines, ces mmes utilisateurs sont alors invits visualiser le
travail ralis par la MOE.
Entre la phase dexpression de besoins et la livraison du produit, il peut se passer quelques mois,
le besoin des utilisateurs peut avoir volu (d leurs contraintes mtier, aux contraintes
lgislatives) et par consquent, le produit dvelopp ne satisfait pas leurs nouvelles exigences.
9
Saidi Wael Formation Informaticiens PAPNJ

On constate gnralement une volution de changement des besoins en cours de projet,

de lordre de 25 %.

Notion deffet tunnel

5. Des rsultats chaotiques

Comme nous venons de le voir, le cycle en V souffre dun effet tunnel privant les utilisateurs dune
vision du produit en cours de dveloppement ce qui peut aboutir des fonctionnalits inutilises et
non conformes aux besoins. Ce phnomne a t mis en valeur par la compagnie Standish Group
([Link]) qui a tabli en 2009 un rapport difiant nomm "Reports Chaos"
dcrivant le pourcentage dutilisation des fonctionnalits dune application.
Ce rapport dcrit les chiffres suivants :

10

7 % des fonctionnalits sont toujours utilises.

13 % des fonctionnalits sont souvent utilises.
16 % des fonctionnalits sont quelquefois utilises.
19 % des fonctionnalits sont rarement utilises.
45 % des fonctionnalits ne sont jamais utilises.

Saidi Wael Formation Informaticiens PAPNJ

Rpartition de lusage des fonctionnalits dans une application

Daprs ce rapport, il ny a donc que 20 % des fonctionnalits prsentes dans une application qui
sont rellement utiles aux utilisateurs. Ce qui signifie que 80 % des autres fonctionnalits ont
t dveloppes et ont ncessit un investissement qui finalement savre tre vain.
Le rapport va plus loin encore, en dtaillant les russites et checs des projets :

32 % ont t termins dans les temps, sans dpassement de budget et avec les
fonctionnalits attendues.
44 % ont t termins en retard et/ou avec un dpassement budgtaire et/ou comportant
des fonctionnalits errones ou manquantes.
24 % ont t abandonns ou termins mais jamais utiliss.

Russites et checs des projets

11

Saidi Wael Formation Informaticiens PAPNJ

Comme nous pouvons le constater, ces rsultats montrent que la gestion de projet laide de la
mthode que nous appelons "traditionnelle" est en souffrance et apporte peu de satisfaction.
Pour pallier cela, dans les annes 2000, un mouvement sest form portant le nom de
Mouvement agile dont lobjectif est doffrir une plus grande satisfaction en se focalisant avant tout
sur la valeur ajoute des dveloppements effectus.
Cest ce que nous allons prsent dcouvrir.

Lagilit au cur des projets

tre agile se dit dune personne "ayant une lgret et une souplesse dans les mouvements du
corps".
A priori, cela na aucune relation avec le sujet qui nous concerne, savoir une mthode de gestion
de projet. Cependant, si nous tentons de transposer cette dfinition notre sujet, nous pouvons
dfinir une mthode agile comme une mthode se voulant tre plus souple. Mais plus souple en
quoi ?
En 2001 est apparu le manifeste agile visant dfinir les valeurs et principes de lagilit
permettant de dfinir cette notion de souplesse.

1. Un peu dhistoire
Du 11 au 13 fvrier 2001, 17 personnes se runissent aux tatsUnis pour tablir ce qui deviendra
le manifeste agile. Les personnes prsentes cette runion sont les grandes figures du monde de
linformatique telles que Kent Beck (inventeur de leXtreme Programming), Ken Schwaber et Jeff
Sutherland (cofondateur de Scrum). Lobjectif de cette runion tait pour chacun dexpliquer leur
concept et mthode afin den extraire des valeurs et principes qui deviendront alors le rfrentiel
toute mthode agile.
Cest donc lissue de cette runion que 4 valeurs et 12 principes ont vu le jour, donnant de fait
naissance au Manifeste agile faisant toujours foi de nos jours.

2. Les valeurs
Comme nous venons de lindiquer, le manifeste agile est compos de quatre valeurs :

12

Favoriser les individus et leurs interactions plutt que la mise en place de processus et
doutils.
Favoriser la collaboration avec le client plutt que la ngociation contractuelle.
Faire en sorte dobtenir un logiciel immdiatement disponible linstar dune
documentation bien fournie mais qui savre tre finalement inutile (un utilisateur prfrera
utiliser le logiciel plutt que de rver sur une belle documentation).
tre ractif face au changement plutt que de respecter un plan.

Saidi Wael Formation Informaticiens PAPNJ

Attention, cela ne signifie pas quune mthode agile sera exempte de documentation et de
processus, mais ceuxci seront limits. Lobjectif tant de privilgier les interactions entre individus
tout en livrant un rsultat technique de qualit.
A ces quatre valeurs viennent sajouter douze principes fondamentaux.

3. Les principes
Les principes contenus dans le manifeste sont au nombre de douze et permettent de bien
identifier la philosophie dune mthode agile :

VI.

Accorder une haute priorit la satisfaction du client travers des livraisons de

logiciels rapproches et continues.
Accepter le changement de besoins mme tard dans le dveloppement.
Livrer frquemment un logiciel qui marche chances rgulires, de deux semaines
deux mois avec une prfrence pour les plus petites priodes de temps.
Faire travailler ensemble quotidiennement les utilisateurs et les dveloppeurs.
Construire les projets autour de personnes motives. Leur donner lenvironnement et le
support dont elles ont besoin et leur faire confiance.
Privilgier la communication face face qui est le moyen le plus efficace pour
transmettre de linformation aux quipes de dveloppement.
Considrer les versions oprationnelles du logiciel comme tant les mesures
principales de progrs.
Considrer les procds agiles comme les moteurs dun dveloppement viable. Sponsors,
dveloppeurs et utilisateurs doivent pouvoir maintenir un rythme constant
indfiniment.
Apporter une attention continue lexcellence technique et la bonne conception
afin damliorer lagilit.
Privilgier la simplicit. Cestdire lart de maximiser le travail ne pas faire.
Considrer que les meilleures architectures, besoins et conceptions mergent dquipes
autoorganises.
Rflchir intervalle rgulier la faon de devenir plus efficace et agir sur le
comportement de lquipe en consquence.

Scrum, une mthode agile

Cest en 2001 que Ken Schwaber et Mike Beedle publient officiellement la description de leur
mthode agile nomme Scrum dans louvrage "Agile Software Development With Scrum".
Bien que cette mthode soit fortement en vogue en 2012 en France, cela fait tout de mme 11 ans
quelle existe et se pratique dans les entreprises.
Le nom Scrum ou bien encore Mle exprime le concept fort de la mthode sarticulant autour
de la cohsion dquipe. En effet, cest lquipe tout entire (Product Owner, Scrum Master,
13

Saidi Wael Formation Informaticiens PAPNJ

quipe de dveloppement) qui va uvrer pour atteindre le mme but. Lquipe doit tre soude
comme le sont les joueurs de rugby lors dune mle dans le but de saisir le ballon. Bien entendu,
le but nest pas atteignable immdiatement mais par le biais de plusieurs itrations permettant
lquipe de visualiser son avancement et notamment de prendre en compte les modifications
du besoin, sans oublier de lever les obstacles quelle rencontre.

La mthode Scrum, comme toute mthode agile, sillustre par le respect des valeurs et principes
du manifeste agile :

Lexistence dune quipe autoorganise.

Des rles dfinis : Scrum Master, Product Owner (le client), quipe de dveloppement.
Un ensemble de crmoniaux (Scrum Meeting, revue de sprint).
La prsence constante du client.
La mise en place de mcanismes favorisant les livraisons frquentes (Sprint).
Une acceptation du changement (mais pas nimporte quel prix).

Il faut cependant insister sur le fait que Scrum est une mthode et non un ensemble de techniques
dingnierie logiciel. Il sagit donc dun cadre mthodologique devant tre complt par des
pratiques techniques. titre dexemple, nous pouvons citer que la mthode prne la mise en
place de tests, mais elle nindique nullement comment les raliser. Libre chaque quipe Scrum
de trouver la pratique technique qui lui convient.
Il convient donc de faire la diffrence entre les notions de mthodes et mthodologie. La premire
dfinit un cadre, une ligne directrice afin datteindre un but prcis, la seconde dfinit les moyens et
processus mettre en uvre pour y arriver. ce titre, nous pouvons donc dire que Scrum est
une mthode et non une mthodologie car elle dfinit des concepts, une dmarche, laissant
une grande part de mise en uvre et dadaptation par les quipes Scrum.

VII.

Vue densemble

Scrum est un cadre de dveloppement dans lequel des quipes plurifonctionnelles ralisent des
produits de manire itrative et incrmentale. Scrum structure le dveloppement en cycles de
travail appels Sprints. Ces itrations ne durent jamais plus de quatre semaines (deux semaines
la plupart du temps), et senchanent lune aprs lautre sans interruption. Les Sprints sont dune
dure limite, ou timeboxs ils se terminent une date spcifique, que le travail soit termin
ou non, et ne sont jamais prolongs. Gnralement les Equipes Scrum choisissent une dure de
Sprint et la maintiennent durant le projet, jusqu ce quelles puissent encore augmenter leur
productivit et utiliser alors un cycle plus court. Au dbut de chaque Sprint, une Equipe
plurifonctionnelle (environ sept personnes) slectionne des lments (exigences du client) dans
une liste priorise. LEquipe saccorde collectivement sur une cible constitue de ce quelle pense
pouvoir livrer la fin du Sprint, de manire tangible et rellement termine . Aucun nouvel
lment nest ajout durant le Sprint; Scrum accepte le changement pour le Sprint suivant, mais la
dure fixe dun Sprint en cours est faite pour se focaliser sur un objectif relativement stable, clair
et limit. Chaque jour, lEquipe se runit brivement afin de contrler sa progression et ajuster les
14

Saidi Wael Formation Informaticiens PAPNJ

prochaines tapes ncessaires la finalisation du travail restant. A la fin de chaque Sprint, une
revue est organise avec les parties prenantes durant laquelle lEquipe montre ce quelle a
ralis. Le feedback obtenu peut tre pris en compte sur le Sprint suivant. Scrum insiste sur la
ncessit de livrer un produit oprationnel la fin de chaque Sprint, et rellement termin .
Dans le cas de logiciels, cela signifie un systme intgr, entirement test, document pour ses
utilisateurs et potentiellement dployable. Les rles, les artefacts et les vnements cls sont
prsents dans la figure suivante.

Vue densemble de Scrum

Lun des thmes majeurs de Scrum cest inspecter et adapter . Etant donn que le
dveloppement implique invitablement de lapprentissage, de linnovation, et des surprises,
Scrum souligne la ncessit de dvelopper par tapes courtes, dinspecter la fois lefficacit des
pratiques mises en uvre et le produit qui en rsulte, et adapter ainsi les objectifs du produit et
les activits du processus. Boucle infinie.

Les rles de Scrum

Dans Scrum, il y a trois rles : le Product Owner, lEquipe, et le ScrumMaster. Ensemble ils
forment lEquipe Scrum.
Le Product Owner est charg de maximiser le retour sur investissement (ROI) en identifiant les
fonctionnalits du produit, en les transfrant dans une liste priorise, en choisissant celles qui
doivent tre en tte de liste pour le prochain Sprint, et en re-priorisant et en affinant
continuellement cette liste. Lorsquil sagit dun produit commercial, le Product Owner est
responsable des pertes et profits. Dans le cas dune application interne, le Product Owner nest
pas responsable du ROI au sens commercial du terme (gnration de revenus), mais il est tout de
mme en charge de maximiser le ROI en choisissant chaque Sprint les lments ayant la
fois la plus forte valeur mtier et le moindre cot. En pratique, le mot valeur reste un terme
15

Saidi Wael Formation Informaticiens PAPNJ

relativement vague, et la priorisation peut tre influence par le dsir de satisfaire des utilisateurs
cls, par la ncessit de saligner avec des objectifs stratgiques, de prendre en compte des
risques, de samliorer, ou par dautres facteurs. Dans certains cas, le Product Owner et le client
sont la mme personne ; cest souvent le cas pour les applications internes. Dans dautres cas, le
client peut reprsenter des millions de personnes avec une grande varit de besoins, auquel cas
le rle du Product Owner est similaire celui du Responsable Produit ou du Responsable
Marketing chez les diteurs. Cependant, le Product Owner est quelque peu diffrent du
Responsable Produit traditionnel en ce sens quil interagit activement et frquemment avec
lquipe, priorise en collaborant avec lensemble des parties prenantes et passe en revue les
rsultats de chaque Sprint, au lieu de dlguer les dcisions lies au dveloppement un chef de
projet. Il est important de noter que dans Scrum, il y a une et une seule personne possdant la
fonction et lautorit du Product Owner. Cette personne est responsable de la valeur du travail
ralis; mme si cette personne ne doit pas travailler seule.
LEquipe (galement appele Equipe de Dveloppement) construit le produit qui est dfini pas
le Product Owner : une application ou un site web par exemple. Dans Scrum, lEquipe est
plurifonctionnelle : elle inclut toute lexpertise ncessaire pour fournir une version du produit
potentiellement livrable chaque Sprint. Elle est galement auto organise (autogre), avec
un grand degr dautonomie et de responsabilit. Lquipe dcide des lments implmenter
dans un Sprint (lments issus de la liste propose par le Product Owner), et des moyens les plus
adapts pour raliser cet objectif.
Chaque personne dans lEquipe est simplement qualifie de membre. Il faut noter quil ny a pas
de titre de spcialiste au sein dun groupe qui adopte Scrum; pas danalyste fonctionnel, pas de
DBA, pas darchitecte, pas de team leader, pas de concepteur IHM, pas de programmeur. Tous les
membres travaillent ensemble durant chaque Sprint, par tous les moyens appropris et
ncessaires latteinte de lobjectif quils ont eux-mmes dtermin.
Etant donn quil ny a que des membres, lEquipe nest pas seulement pluridisciplinaire mais fait
galement preuve de capacit diverse dapprentissage; chacun possde certainement des atouts
particuliers, mais continue galement de progresser sur dautres spcialits. Chaque personne
devra possder des comptences sur diffrents domaines et diffrents niveaux, et devra aller
l o le travail se trouve . Les individus doivent tre mme de prendre en charge des tches
dans des domaines moins familiers lorsquil est ncessaire de faciliter la finalisation dun lment.
Par exemple, une personne dont la comptence principale serait la conception dIHM peut
possder une comptence secondaire dans lautomatisation des tests; un autre dont la
comptence principale serait la conception technique peut aussi aider en analyse et en
programmation.
Une Equipe Scrum est compose de 7 personnes (plus ou moins 2 personnes), et pour un produit
logiciel, lquipe peut inclure des personnes avec des comptences en analyse, dveloppement,
test, conception dinterfaces, conception de bases de donnes, architecture, documentation, etc.
LEquipe dveloppe le produit et fournit des ides au Product Owner pour le rendre encore
meilleur. Dans Scrum, les Equipes sont plus productives et efficaces si tous les membres sont
ddis 100% un seul produit au cours dun Sprint. Afin dviter des changements de contextes
et un flchissement dans la focalisation, inconvnients souvent coteux, il faut viter la
multiplication des tches entre plusieurs projets ou produits. Les quipes stables tant plus
productives, il faut viter les changements au sein de lquipe. Les grands projets composs dun
16

Saidi Wael Formation Informaticiens PAPNJ

nombre important dindividus sont organiss en plusieurs Equipes, chacune delle se concentrant
sur diffrentes fonctionnalits du produit, avec une coordination troite de leurs travaux. Etant
donn quune quipe gre lensemble des tches sur un primtre client (planning, analyse,
programmation et test), chaque quipe devient alors ce que lon nomme une quipe fonctionnelle
(feature team).
Le ScrumMaster aide le groupe apprendre et appliquer Scrum afin que la valeur mtier se
matrialise. Le ScrumMaster fait tout ce qui est en son pouvoir pour aider lEquipe, le Product
Owner et lorganisation russir le projet. Le ScrumMaster nest pas le manager de lEquipe, ni
mme un chef de projet, un chef dquipe ou un reprsentant de lEquipe. Son rle est plutt de
servir lEquipe; il aide supprimer les obstacles, protge lEquipe des interfrences extrieures, et
facilite ladoption par lEquipe des pratiques modernes du dveloppement. Il enseigne, il coache et
il guide le Product Owner, lEquipe ainsi que le reste de lorganisation dans une utilisation fine de
Scrum. Le ScrumMaster est un formateur et un coach. Il sassure que chacun (y compris le
Product Owner, ainsi que le top management) comprenne les principes et les pratiques de Scrum,
et il accompagne lorganisation dans le changement souvent difficile mais ncessaire au succs
du dveloppement agile. Etant donn que Scrum met en lumire les obstacles et les menaces qui
psent sur lefficacit de lEquipe et du Product Owner, il est important davoir un ScrumMaster
engag et travaillant nergiquement la rsolution des problmes auxquels seront confronts
aussi bien lEquipe que le Product Owner. Il y a idalement un ScrumMaster ddi et plein
temps, bien quune petite quipe puisse voir lun de ses membres jouer ce rle (on rduit alors sa
charge sur les travaux courants). Dexcellents ScrumMaster peuvent provenir de nimporte quelle
formation ou discipline: ingnierie, conception, test, responsable produit, chef de projet ou
responsable qualit.
Le ScrumMaster et le Product Owner ne peuvent pas tre la mme personne tant leurs objectifs
sont diffrents, et la combinaison des deux rles conduits souvent de la confusion et des
conflits. Cette combinaison pousse souvent le Product Owner faire du micro management, ce
qui est loppos des quipes auto-organises telles que Scrum le dfinit. A la diffrence dun
manager classique, le ScrumMaster ne dit pas chacun ce quil doit faire et nassigne pas de
tches il facilite le processus, en soutenant lEquipe dans son organisation et sa gestion. Si le
ScrumMaster tait prcdemment en position de chef de projet au sein de lEquipe, il devra
changer significativement dtat desprit et de style dinteraction, afin que lEquipe puisse
pleinement russir avec Scrum.
A noter quil nexiste pas de rle de chef de projet dans Scrum. Cest quil nest pas ncessaire; les
responsabilits traditionnellement associes au chef de projet ont t divises et rassignes aux
trois rles de Scrum, et principalement lEquipe et au Product Owner, plutt quau ScrumMaster.
Pratiquer Scrum en y ajoutant le rle de chef de projet indique une mconnaissance fondamentale
de Scrum, et conduit typiquement des conflits dans les responsabilits, un manque de clart
dans lautorit et de pitres rsultats. Parfois un (ex-)chef de projet peut jouer le rle de
ScrumMaster, mais la russite de cette approche est largement dpendante des individus, et de la
faon dont ils comprennent les diffrences fondamentales entre ces deux positions, autant au
niveau des pratiques au quotidien que de ltat desprit ncessaire pour russir.
En plus de ces trois rles, dautres parties prenantes contribuent au succs du projet. Parmi elles
les managers, les clients et les utilisateurs. Certaines parties prenantes, telles que les directions
17

Saidi Wael Formation Informaticiens PAPNJ

fonctionnelles ou techniques, pourront voir voluer significativement leur rles dans une
organisation adoptant Scrum, mais ils gardent nanmoins toute leur valeur. Par exemple :

Ils soutiennent lEquipe en respectant les rgles et lesprit de Scrum

Ils aident supprimer les obstacles que lEquipe et le Product Owner identifient
Ils fournissent leur expertise et leur exprience

Dans Scrum, ces personnes ne sont plus des nounous (assignation des tches, obtention de
ltat davancement, et autres formes de micro management) mais deviennent les gourous et
les serviteurs de lEquipe (conseils, coaching, facilitant la suppression des obstacles et la
rsolution des problmes, fournissant des ides cratives, et apportant leurs comptences aux
membres de lEquipe). Dans cette mutation, les managers peuvent avoir besoin de changer leur
style de management; par exemple, en utilisant le questionnement socratique pour aider lEquipe
dcouvrir la solution un problme, plutt que de simplement dcider dune solution et la faire
appliquer par lEquipe.

Le Product Backlog
Quand un groupe dcide de passer Scrum, avant mme de dmarrer le premier Sprint, il a
besoin dun Product Backlog, cest dire une liste priorise (ordonne 1, 2, 3, ) de
caractristiques orientes client.
Le Product Backlog existe (et volue) tout au long de la vie du produit; cest la feuille de route du
produit (Figure 2 et Figure 3). Tout au long du projet, le Product Backlog centralise la liste de
tout ce qui peut tre fait par lEquipe, par ordre de priorit . Il nexiste quun seul Product Backlog
pour un produit; le Product Owner est donc ncessaire pour dcider des priorisations sur
lensemble du primtre, en maintenant les intrts des parties prenantes (Equipe incluse).
Le Product Backlog contient une varit dlments, principalement des nouvelles fonctionnalits
mtier ( possibilit pour chaque utilisateur dajouter un livre dans le panier ), mais aussi des
objectifs majeurs dingnierie ( rcrire le systme du C++ en Java ), damlioration technique
( refonte du module de traitement des transactions afin de le rendre extensible ), des travaux
exploratoires ( tudier des solutions pour acclrer la validation des cartes de crdit ), et
potentiellement des anomalies connues ( diagnostiquer et corriger lerreur dans le script de
traitement des commandes ). Les anomalies sont insres dans le cas o elles sont peu
nombreuses (un produit avec beaucoup danomalies possde gnralement un systme de
gestion et de suivi ddi).
Les lments du Product Backlog sont labors de diffrentes manires, partir du moment o ils
restent clairs et viables. Mprise assez rpandue, le Product Backlog ne contient pas des user
stories ; il contient simplement des lments. Ces lments peuvent prendre la forme de User
Stories, de Use Cases, ou tout autre artefact de gestion des exigences que le groupe souhaite
utiliser. Peu importe lapproche choisie du moment que la plupart des lments apporte de la
valeur au client.

18

Saidi Wael Formation Informaticiens PAPNJ

Le Product Backlog

Management visuel : Les lments du Product Backlog affichs au mur

Un bon Product Backlog est DEEP

Dtaill de manire approprie. Les lments les plus prioritaires sont de granularit plus fine et
sont plus dtaills que les lments moins prioritaires (les premiers devant tre traits avant les
autres). Par exemple, les 10% du haut du backlog doivent tre composs dlments de petite
taille et parfaitement analyss, alors que les 90% restant le sont moins.
Estim. Les lments de la release en court doivent tre estims, et peuvent en outre faire lobjet
de r-estimations chaque Sprint en fonction des nouvelles informations apparues et de la
connaissance acquise. LEquipe fournit au Product Owner une estimation de leffort requis pour
chaque lment du Product Backlog, et des risques techniques ventuels. Le Product Owner et
les autres contributeurs mtier rpondent aux demandes formules sur le produit, par exemple
19

Saidi Wael Formation Informaticiens PAPNJ

avec des informations sur les revenus gnrs, la diminution des cots, les risques mtiers,
limportance pour les diffrentes parties prenantes, et ainsi de suite.
Emergent. En rponse la variabilit et lapprentissage permanent, le Product Backlog est
affin rgulirement. A chaque Sprint, des lments peuvent tre ajouts, supprims, modifis,
fractionns, et re-prioriss. Ainsi, le Product Backlog est continuellement mis jour par le Product
Owner afin de reflter les volutions du besoin client, les nouvelles ides ou enseignements, les
mouvements de la concurrence, les obstacles techniques qui apparaissent, et ainsi de suite.
Prioris. Les lments en haut du Product Backlog sont prioriss ou ordonns de 1 N. En
gnral, les lments plus prioritaires doivent donner plus pour votre argent : une plus grande
valeur mtier pour un moindre cot. Laugmentation de la priorit dun lment peut galement
tre motive par la ncessit de sattaquer aux risques importants, avant quils ne vous attaquent.
Dlivrer en fonction de ce qui apporte le plus de valeur nest gnralement pas un concept
associ au dveloppement traditionnel, mais a lest pour Scrum. Ds lors, le Product Owner doit
apprendre valuer cette valeur mtier , et le ScrumMaster doit accompagner le Product
Owner dans cet apprentissage. Que signifie valeur mtier ? Certains groupes utilisent une
simple estimation relative en point-valeur pour chaque lment. Cette estimation synthtise
approximativement un ensemble de facteurs tels que la gnration de revenus, la rduction des
cots, les prfrences des utilisateurs, les caractristiques diffrenciatrices, et ainsi de suite.
Certains valuent les lments avec les contributions que peuvent apporter les clients pour leurs
dveloppements. Ils utilisent alors ce revenu spcifique (gnr court terme) en guise de valeur.
Pour dautres groupes, tablir une valeur pour chaque lment reste trop vague et trop granuleux ;
ils appliquent une approche de plus haut niveau, pour un lot de fonctionnalits, et base sur un
objectif de revenu effectif lors du dploiement de ce lot ( augmenter de 10% au 1 er septembre le
taux de souscription ). Dans ce cas, le Product Owner doit dfinir le contenu du prochain
incrment associ au Produit Viable Minimum (MVP Minimum Viable Product).
Afin destimer leffort, une technique couramment employe consiste estimer en taille relative
(factorisation de leffort, de la complexit et de lincertitude).
Cela reste des suggestions; Scrum ne dfinit pas de technique pour exprimer ou pour prioriser les
lments du Product Backlog, pas plus quil ne dfinit de technique ou dunit destimation.
Une technique communment employe dans Scrum consiste suivre la quantit de travail
produite chaque Sprint, par exemple une moyenne de 26 points par Sprint. A laide de cette
information, lEquipe peut projeter dans le temps une date de release qui inclut toutes les
fonctionnalits, ou bien dduire le nombre de fonctionnalits quelle peut raliser pour une date
donne, dans le cas o la moyenne se stabilise et quaucun changement napparaisse. Cette
moyenne sappelle la vlocit . La vlocit sexprime dans la mme unit que celle utilise pour
estimer les lments du Product Backlog.
Les lments du Product Backlog peuvent varier de manire significative en taille ou en effort. Les
plus grands sont diviss en lments plus petits durant latelier daffinage (Product Backlog
Refinement Workshop) ou durant la runion de Planification de Sprint. Les plus petits dentre eux
peuvent tre galement assembls. Les lments du Product Backlog destins aux prochains
Sprints doivent tre suffisamment rduits et dtaills de sorte quils soient facilement assimilables
20

Saidi Wael Formation Informaticiens PAPNJ

par lEquipe. Les engagements pris durant la runion de Planification de Sprint ont ainsi du sens;
la taille de chaque lment est grable.
tant donn quelles peuvent constituer des options dinvestissement, les amliorations
techniques majeures et consommatrices de temps et dargent doivent se retrouver dans le
Product Backlog, le choix ultime revenant au Product Owner. Il faut noter que dans Scrum,
lEquipe possde lindpendance et lautorit dans le choix du nombre dlments du Product
Backlog raliser dans un Sprint. LEquipe est ainsi libre de prendre en charge un certain nombre
damliorations techniques mineures car cela fait partie du mtier et que lobjectif est
gnralement damliorer le travail des dveloppeurs. Ceci tant dit, la majeure partie du temps
de lEquipe durant un Sprint doit tre consacre aux objectifs du Product Owner, et non aux
tches dingnierie.
Lun des mythes de Scrum est quil permet de se soustraire lcriture de spcifications dtailles.
En ralit, il revient au Product Owner de dcider du niveau de dtails requis, et cela peut varier
dun Backlog un autre, en fonction de la comprhension de lEquipe, et dautres facteurs. Il faut
dcrire tout ce qui est important dans un minimum de place en dautres termes, ne pas dcrire
tous les dtails possibles dun lment, mais juste clarifier ce qui est ncessaire pour la
comprhension, au travers du dialogue continu entre lEquipe, le Product Owner et les parties
prenantes. Les lments de faible priorit, dont limplmentation est loigne dans le temps et
dont la granularit est gnralement assez forte, possdent moins de spcifications dtailles.
Les lments avec une priorit leve devant tre implments rapidement tendent avoir plus
de dtails.

La dfinition de Termin
Chaque Sprint doit produire ce qui est officiellement appel un Incrment du Produit
Potentiellement Livrable. Avant de dmarrer le premier Sprint, le Product Owner, lEquipe et le
ScrumMaster doivent passer en revue les pr-requis permettant daffirmer quun lment du
Product Backlog est potentiellement livrable. Toutes les activits ncessaires au dploiement du
produit doivent tre ajoutes la dfinition de Potentiellement Livrable et doivent ainsi tre
ralises au cours du Sprint.
Malheureusement, lorsquune Equipe dbute avec Scrum, elle nest souvent pas en mesure de
pouvoir dployer un Incrment du Produit Potentiellement Livrable chaque Sprint. Cela est
souvent d un manque dautomatisation ou bien une composition de lEquipe pas
suffisamment pluridisciplinaire (par exemple certains experts ne sont pas encore intgrs dans
lEquipe). Au fil du temps, lEquipe doit progresser afin de pouvoir dployer un Incrment du
Produit Potentiellement Livrable chaque Sprint, mais pour commencer, elle doit dabord adapter
sa Dfinition de Termin ses capacits existantes.
Avant le premier Sprint, le Product Owner et lEquipe doivent saccorder sur une Dfinition de
Termin, qui doit tre un sous-ensemble des activits ncessaires pour dployer un Produit
Potentiellement Livrable (pour une Equipe experte, ce sera la mme chose). LEquipe planifiera
les tches du Sprint selon cette Dfinition de Termin.
Un bon Product Owner voudra toujours que la Dfinition de Termin soit au plus prs de
Potentiellement Livrable car cela augmentera la transparence dans les dveloppements et limitera
les retards et les risques. Dans le cas o la Dfinition de Termin diverge de Potentiellement
21
Saidi Wael Formation Informaticiens PAPNJ

Livrable, une partie du travail est alors repousse juste avant la release, ce qui augmente les
risques et les retards potentiels. Ce dcalage dans le travail est parfois nomm travail non fait.
Une Equipe Scrum doit continuellement progresser, et cela se reflte au travers de lextension de
sa Dfinition de Termin.

La Planification de Sprint
Rsum : runion de prparation dun Sprint, typiquement divise en deux parties (la premire
partie cest le quoi et la seconde partie cest le comment ).
Participants : Partie une : Product Owner, Equipe, ScrumMaster. Partie deux : Equipe,
ScrumMaster, Product Owner (optionnel, mais doit tre disponible pour toutes questions).
Dure : chaque partie est limite une heure par semaine de Sprint.
Au dmarrage de chaque Sprint, la Runion de Planification de Sprint a lieu. Cette runion se
divise en deux runions distinctes, la premire se nomme le Sprint Planning Partie Une.
Dans le Sprint Planning Partie Une, le Product Owner et lEquipe passent en revue les lments
de forte priorit du Product Backlog et souhaits par le Product Owner pour ce Sprint. En gnral,
ces lments auront t parfaitement analyss lors dun Sprint prcdent (au cours dune sance
daffinage du Product Backlog), de sorte que cette runion naborde que des questions mineures
de clarification. Lors de cette runion, le Product Owner et lEquipe discutent des objectifs et du
contexte de ces lments, dans le but dclairer lEquipe sur la pense du Product Owner. Cette
premire partie se focalise sur la comprhension de ce que souhaite le Product Owner et pourquoi
il le souhaite. A la fin de cette partie, le Product Owner (toujours trs occup) peut quitter la
runion, mais il doit rester disponible pour la partie suivante (par exemple par tlphone).
Durant la partie une, lEquipe et le Product Owner peuvent galement chafauder le but du
Sprint. Il sagit dune phrase rsumant lobjectif du Sprint, qui doit idalement porter un thme
fdrateur. Le but du Sprint apporte galement lEquipe une certaine flexibilit sur le primtre
quelle est mme de livrer. En effet, tant donn quelle peut tre amene retirer certains
lments demands (le Sprint est limit dans le temps), elle doit nanmoins rester engage dans
la livraison dun produit tangible et termin et sinscrivant dans lesprit du but de ce Sprint.
Quelle est la taille idale des lments slectionner pour un Sprint ? Chaque lment doit tre
suffisamment petit afin de pouvoir tre ralis en beaucoup moins de temps que la dure
complte du Sprint. Il est couramment recommand de vrifier que la taille dun lment est
suffisamment petite pour tre termin au maximum en un quart de Sprint par lensemble de
lEquipe.
Le Sprint Planning Partie Deux sintresse plus particulirement comment implmenter les
lments que lEquipe a dcids de prendre en charge. LEquipe prvoit la quantit dlments
quelle peut raliser pour la fin du Sprint, en dpilant le haut du Product Backlog (en dautres
termes, en commenant avec les lments de plus forte priorit pour le Product Owner), et en
parcourant la liste dans lordre descendant. Cest une pratique cl dans Scrum : lEquipe dcide
de la quantit de travail raliser, plutt que de se voir assigner ce travail par le Product Owner.
Cela contribue rendre lengagement plus fiable car celui-ci est pris par lEquipe sur la base de
son analyse et de sa planification. Bien que le Product Owner nait pas le contrle sur la quantit
22

Saidi Wael Formation Informaticiens PAPNJ

de travail pris en charge par lEquipe, il est assur que ce travail a t slectionn partir du haut
du Product Backlog cest dire avec les lments quil a lui-mme identifis comme tant les
plus importants. LEquipe peut cependant faire pression pour insrer des lments positionns
plus bas dans la liste; cest gnralement le cas lorsque lEquipe et le Product Owner
saperoivent quil est la fois simple et opportun dajouter des lments de priorit infrieure aux
lments de plus forte priorit.
La runion de Planification de Sprint dure gnralement quelques heures, mais jamais plus de
quatre heures pour un Sprint de deux semaines. LEquipe sengage, et pour mener au succs, cet
engagement ncessite une soigneuse rflexion. Les parties une et deux ont une dure
quivalente; pour un Sprint de deux semaines chacune durera deux heures maximum.
Scrum ne dfinit pas de manire particulire pour mener cette seconde partie du Sprint Planning.
Certaines quipes utilisent la vlocit enregistre lors des derniers Sprints pour dterminer la
quantit de travail quil est possible de produire. Dautres quipes auront une approche plus fine
pour le calcul de leur capacit.
Lorsque lEquipe utilise le calcul de capacit, elle dbutera la seconde partie du Sprint Planning
par lestimation du temps que chaque membre peut effectivement ddier aux tches du Sprint. La
plupart des quipes prennent lhypothse que chaque membre possde un temps de travail
productif compris entre 4 6 heures par jour le reste du temps tant consacr aux emails, aux
pauses djeuner, facebook, aux runions, et boire du caf. Ainsi la capacit relle de lquipe
pour le Sprint venir est dtermine. Une fois que la capacit est dtermine, lEquipe peut en
dduire le nombre dlments du Product Backlog quelle peut raliser dans la priode, et
comment elle pourra mener bien ce travail. Cela dbute souvent par une discussion de
conception autour dun tableau blanc. Une fois que la conception gnrale est comprise, lEquipe
dcompose les lments du Product Backlog en tches. Avant de sintresser aux lments du
Product Backlog, lEquipe peut analyser et crer les tches ncessaires un axe damlioration
identifi lors de la dernire rtrospective de Sprint. Ensuite, lEquipe commence par le premier
lment dans le Product Backlog c'est--dire llment le plus prioritaire pour le Product Owner
et poursuit vers le bas de la liste jusqu atteindre sa capacit maximale. Pour chaque lment,
une liste de tches est cre, constitue de tous les travaux ncessaires pour raliser llment,
ou bien de llment lui- mme si celui-ci ne ncessite quune deux heures de travail. Cette liste
de tches est appele le Sprint Backlog

Un exemple de Sprint Backlog

A la fin du Sprint Planning Meeting, lEquipe dtermine de manire raliste une cible constitue de
ce quelle pense pouvoir produire pour la fin du Sprint. Cest ce que lon dsigne traditionnellement
23

Saidi Wael Formation Informaticiens PAPNJ

un engagement de Sprint lEquipe sengage faire son maximum pour atteindre cette cible.
Malheureusement, cet engagement a pu tre parfois interprt comme une promesse grave
dans le marbre plutt quun engagement faire son maximum. Afin dviter cette confusion,
lobjectif de Sprint est dsormais appel une prvision communique au Product Owner.
Scrum favorise la polyvalence des ressources, plutt que le travail en fonction dun titre , tel
quun testeur ne faisant que des tests. En dautres termes, les membres de lEquipe vont l o le
travail se trouve , et sentraident autant que possible. Sil y a beaucoup de tches de test, alors
tous les membres de lEquipe peuvent y prendre part. Pour autant, cela ne veut pas dire que
chacun doit tre un gnraliste. Il ne fait pas de doute que certains sont spcialiss dans les tests
(et autre), mais le travail de lEquipe est collectif et chacun peut apprendre des autres. En
consquence, lors du dcoupage et de lestimation des tches durant la Planification du Sprint, il
nest pas ncessaire ni mme appropri que les personnes se portent volontaires pour les
tches quelles savent faire le mieux . Il est plutt recommand que chacun slectionne ses
tches au fil de leau et une par une, en considrant que cette slection va dlibrment impliquer
un apprentissage (ventuellement par un travail en binme avec un spcialiste). Cest la raison
pour laquelle il ny a pas dassignation de tches durant la planification du Sprint, mais que ceci se
fait ds que ncessaire tout au long du Sprint.
Cela dit, il existe de rares cas o Jean doit lui-mme faire une tche particulire car pour dautres,
cela prendrait trop de temps ou serait tout simplement impossible. Peut-tre que Jean est la seule
ressource avec un talent de graphiste. Les autres membres de lEquipe ne pourraient mme pas
dessiner un bonhomme en bton mme si leur vie en dpendait. Dans ce cas rare et si ce
nest pas le cas, cest quil y a un problme il peut tre ncessaire de se demander si la totalit
des tches de graphisme planifies qui doivent tre ralises par Jean sont faisables au cours
dun seul Sprint.
Pour leur Sprint Backlog, beaucoup dEquipes font usage dun outil visuel de suivi des tches,
sous la forme dun tableau mural (souvent appel le tableau Scrum), o les tches (crites sur des
Post-It) avancent de colonnes en colonnes. Ces colonnes sont tiquetes Pas Dmarr , En
Cours , et Termin . Voir Figure suivante.

24

Saidi Wael Formation Informaticiens PAPNJ

Management visuel les tches du Sprint Backlog sur le mur

Lun des aspects fondamental de Scrum, cest qu partir du moment o lEquipe sengage, tout
ajout ou tout changement doit tre repouss au prochain Sprint. Cela signifie que si le Product
Owner dcide la moiti du Sprint quil y a de nouveaux lments sur lesquels lEquipe doit
travailler, ces changements ne seront pris en compte quau dmarrage du prochain Sprint. Si un
vnement extrieur implique un changement majeur de priorit, signifiant alors que lEquipe
perdrait son temps continuer son travail sur le Sprint en cours, le Product Owner ou lEquipe
peut stopper le Sprint. LEquipe sarrte, et une nouvelle runion de Planification de Sprint
instancie un nouveau Sprint. Les bouleversements alors engendrs tant potentiellement
importants, le Product Owner et lEquipe sont gnralement dissuads davoir recourt cette
dcision.
Le fait dtre protg des changements de direction durant un Sprint influe de manire puissante
et positive sur lEquipe. Tout dabord, lEquipe part au travail avec labsolue certitude que ses
objectifs ne seront pas modifis. Ceci renforce sa capacit se concentrer sur latteinte de ces
mmes objectifs. De plus, cela impose au Product Owner de bien rflchir la priorisation des
lments du Product Backlog qui seront proposs lEquipe pour le Sprint.
En suivant ces rgles, le Product Owner bnficie de deux choses. Premirement, il est assur
que lEquipe sengage raliser un lot de travaux clairs et ralistes quelle a elle-mme choisi
(lEquipe augmente peu peu son niveau dexpertise dans le choix et la ralisation de ses
objectifs). Deuximement, le Product Owner a la possibilit deffectuer tous les changements quil
souhaite dans le Product Backlog avant le dmarrage du prochain Sprint. A ce stade, les ajouts,
les suppressions, les modifications, et les re-priorisations sont possibles et autoriss. Bien quil ne
puisse pas modifier les lments slectionns et dvelopps dans le Sprint en cours, il nest qu
une longueur de Sprint ou moins de faire raliser les changements quil souhaite. Fini la
stigmatisation autour du changement changement de direction, changement dexigences, o
25

Saidi Wael Formation Informaticiens PAPNJ

simplement changement davis et cest peut-tre pour cette raison que les Product Owner sont
la plupart du temps ceux qui manifestent le plus denthousiasme propos de Scrum.

Le Daily Scrum
Rsum : suivi et coordination entre les membres de lEquipe.
Participants : lensemble de lEquipe est requise ; le Product Owner est optionnel ; le
ScrumMaster est gnralement prsent mais sassure que lEquipe est autonome.
Dure :15 minutes maximum.
Ds que le Sprint dbute, lEquipe se lance dans une autre pratique fondamentale dans Scrum : le
Daily Scrum. Il sagit dune runion courte (15 minutes ou moins) qui se droule chaque jour de
travail une heure fixe. Tout le monde au sein de lEquipe y participe. Afin de garantir la brivet
de ce rendez-vous, il est recommand que chacun se tienne debout. Cest lopportunit pour
lEquipe de synchroniser ses travaux et dchanger ensemble sur les obstacles rencontrs ou
venir. Lors du Daily Scrum, chaque membre, un par un, expose successivement aux autres
membres de lEquipe trois points (et seulement trois): (1) Qua-t-il fait depuis la dernire runion ;
(2) que prvoit-il de faire jusqu la runion suivante ; et (3) quels sont les points blocages ou les
obstacles sur sa route. Il faut noter que le Daily Scrum nest pas une runion de suivi pour le
reporting un manager. Cest le moment privilgi pour une Equipe auto-organise dchanger
sur la bonne marche de lactivit, et de se coordonner. Une personne note les problmes
rencontrs, et le ScrumMaster doit aider les membres de lEquipe les rsoudre. Il y a peu ou pas
de discussion approfondie durant le Daily Scrum, lobjectif ntant que de rpondre ces trois
questions. Si des discussions sont ncessaires, elles se tiennent lors de runions conscutives,
immdiatement aprs le Daily Scrum, bien que dans Scrum personne ne soit oblig dy participer.
Ces runions adhoc sont des vnements courants o lEquipe prend en compte les informations
remontes lors du Daily Scrum ; en dautres termes, un moyen supplmentaire dinspection et
dadaptation. Pour des Equipes peu exprimentes avec Scrum, la prsence lors du Daily Scrum
de managers ou de toute autre personne en possession dune autorit nest gnralement pas
recommande. LEquipe pourrait alors se sentir contrle sous la pression de devoir
annoncer des progrs majeurs chaque jour (espoir irraliste), inhibe dexposer ouvertement ses
problmes et freine dans sa capacit dauto-organisation car subissant des actes de micro
management. Au lieu de cela, il est plus utile pour les parties prenantes de senqurir de ltat des
lieux auprs de lEquipe aprs la runion, et de proposer leur aide sur les points de blocage
ralentissant la progression.

Suivre la progression durant le Sprint

Dans Scrum, lEquipe est auto gre, et pour russir, elle doit savoir sorganiser. Chaque jour, les
membres de lEquipe actualisent leurs estimations du reste faire pour les tches en cours du
Sprint Backlog Il est courant qu la suite une personne additionne les efforts restants pour
lensemble de lEquipe, et le trace sur le Sprint Burndown Chart . Ce graphique montre, chaque
jour, une nouvelle estimation du reste faire estim pour terminer les tches de lEquipe. Ce
graphique se prsente idalement sous la forme dune courbe incline vers le bas, suivant une
trajectoire visant atteindre zro effort restant le dernier jour du Sprint. Cest pour cela que ce
graphique se nomme un burndown chart [graphe de combustion]. Et si parfois la trajectoire est
26

Saidi Wael Formation Informaticiens PAPNJ

bonne, parfois elle lest moins; cest la ralit du dveloppement. Limportant est que cela montre
lEquipe sa progression vers son but, non pas en fonction de combien de temps a t
consomm dans le pass (ce qui a peu dintrt en termes de progression), mais en fonction de
combien de travail il reste faire dans le futur cest dire ce qui spare lEquipe de son objectif.
Si la courbe ne suit pas linclinaison ncessaire pour lachvement des travaux lapproche de la
fin du Sprint, alors lEquipe doit sadapter, par exemple en rduisant le primtre du travail faire
ou en trouvant un moyen de travailler plus efficacement tout en gardant un rythme soutenable.
Bien que le Sprint Burndown Chart peut tre cr et diffus sous la forme dune feuille de calcul,
beaucoup dEquipes estiment quil est plus efficace de lafficher au format papier sur un mur de
lespace de travail. Les mises jour sont alors ralises au feutre; cette solution faiblement
technologique / hautement humaine est rapide, simple, et souvent plus visible quun graphique
au format lectronique.

Mises jour quotidiennes du reste faire dans le Sprint Backlog

Sprint Burndown Chart

27

Saidi Wael Formation Informaticiens PAPNJ

Laffinage du Product Backlog

Rsum : fractionner les gros lments, analyser les lments, r-estimer, et re-prioriser, pour les
Sprints venir.
Participants : lEquipe; le Product Owner participera entirement lactivit sil possde lui-mme
lexpertise requise pour lanalyse dtaille, sinon il pourra simplement indiquer les directions
suivre o les re-priorisation effectuer.
Dure : habituellement pas plus de 10% de la capacit de production de lEquipe sur le Sprint,
bien que cela puisse prendre plus de temps pour les lments ncessitant une analyse pousse.
Par exemple, sur une dure du Sprint de deux semaines, un jour pourra tre consacr laffinage.
Lune des recommandations de Scrum les moins connues, mais nanmoins importantes, est
quune partie de chaque Sprint doit tre ddie laffinage (ou toilettage ) du Product Backlog,
et ce afin de prparer les Sprints venir. Cela inclut une analyse dtaille des exigences, le
fractionnement dlments de forte granularit en lments plus petits, lestimation de nouveaux
lments, et la r-estimation dlments existants. Scrum ne dit pas comment faire ce travail, mais
une technique frquemment utilise consiste organiser une runion ddie en milieu ou fin du
Sprint, de sorte que lEquipe et le Product Owner puissent se focaliser sur ce travail sans tre
perturb.
Cette activit de clarification ne concerne pas les lments slectionns pour le Sprint en cours,
mais les lments futurs, qui seront gnralement traits dans un ou deux Sprints. Grce cette
pratique, la Planification des Sprints devient relativement simple car le Product Owner et lEquipe
travaillent sur un lot dlments clairs, bien analyss et soigneusement estims. Lorsque cet
atelier daffinage na pas t effectu (ou bien mal effectu), il y a signe qui ne trompe pas: la
runion de Planification de Sprint engendre de nombreuses questions, des dcouvertes, de la
confusion, et se termine au final sur un sentiment dinachev. Lactivit de planification dborde
alors sur le Sprint lui-mme, ce qui nest ni souhait ni souhaitable.

La Revue de Sprint
Rsum : inspection et adaptation de lincrment de fonctionnalit du produit.
Participants : lEquipe; le Product Owner, le SrumMaster. Toutes parties prenantes en fonction du
besoin, convies par le Product Owner.
Dure : timebox dune heure par semaine de Sprint.
Une fois le Sprint termin, il y a la Revue de Sprint, runion durant laquelle lEquipe et le Product
Owner passent le Sprint en revue. Sont prsents cette runion le Product Owner, les membres
de lEquipe, le ScrumMaster, ainsi que les clients, utilisateurs, parties prenantes, experts,
dcideurs, et toute autre personne intresse. Pour un Sprint de deux semaines, la dure
maximum est de deux heures. Chaque personne prsente est libre de poser des questions ou
apporter des contributions.

28

Saidi Wael Formation Informaticiens PAPNJ

Cette runion est souvent nomme tort la dmo , et cette dnomination ne permet pas den
saisir lobjectif rel. Une ide cl dans Scrum, cest linspection et ladaptation . Lobjectif est de
regarder et dtudier ce quil se passe et ainsi permettre de samliorer sur la base dvaluations,
en cycles itratifs. La Revue de Sprint est une activit dinspection et dadaptation pour le produit.
Cest un moyen pour le Product Owner de connatre la situation actuelle du produit et de lEquipe
(un examen du Sprint, en quelque sorte) ; et pour lEquipe de connatre la situation actuelle du
Product Owner et du mtier. Par consquent, limportant dans cette Revue est quune
conversation en profondeur stablisse entre lEquipe et le Product Owner, afin dchanger sur la
situation, obtenir des conseils, et ainsi de suite. La revue inclut certainement une manipulation de
la version de lapplication ralise par lEquipe durant le Sprint, mais si on se focalise uniquement
sur le visionnage du produit plutt que sur lchange autour du produit, il y a alors un dsquilibre.
La ct dmo de la Revue de Sprint ne doit pas tre comprise comme une prsentation
donne par lEquipe il ny a pas de diaporama. Il sagit dune inspection pratique du logiciel en
fonctionnement, par exemple dploy sur un environnement de dveloppement bac sable .
La salle pour la revue sera idalement quipe dun ou plusieurs ordinateurs, sur lesquels
plusieurs personnes peuvent manipuler lapplication. Il faut privilgier des sessions interactives
durant lesquelles les utilisateurs et le Product Owner interagissent rellement avec le logiciel,
plutt quune session passive de dmonstration par lEquipe.
Pas plus de 30 minutes doivent tre consacres la prparation de la Revue, sans quoi cela
indiquerait un problme.

La Rtrospective de Sprint
Rsum : inspection et adaptation du processus et de lenvironnement.
Participants : lEquipe, le SrumMaster, le Product Owner (optionnel). Toute autre partie prenante
peut tre invite par lEquipe, sans quoi elle nest pas autorise y participer.
Dure : timebox de 45 minutes par semaine de Sprint.
La Revue de Sprint permet dinspecter et dadapter le produit. La Rtrospective de Sprint, qui suit
la Revue de Sprint, permet dinspecter et dadapter le processus et lenvironnement. Cest
lopportunit pour lEquipe dchanger sur ce qui fonctionne bien et sur ce qui ne fonctionne pas,
et de saccorder sur des changements exprimenter. Lors de cette rtrospective, le
ScrumMaster peut prendre efficacement le rle de facilitateur, mais il est souvent prfrable de
trouver une personne extrieure et neutre pour mener cette runion. Une bonne approche
consiste schanger le rle de facilitateur entre ScrumMaster pour les rtrospectives, ce qui
favorise la pollinisation croise parmi les Equipes.
Il y a plusieurs techniques permettant de mener des Rtrospectives de Sprint, et le livre Agile
Restrospective (Derby, Larsen 2006) en propose un certain nombre.
Beaucoup dEquipes se concentrent sur les problmes, et cest dommageable. Cela peut conduire
associer les rtrospectives des vnements ngatifs ou dprimants. Au lieu de cela, il faut
sassurer que les rtrospectives abordent galement les forces et les aspects positifs ; il y a de
nombreux ouvrages sur lInvestigation Apprciative [appreciative inquiry] qui offrent de nombreux
conseils.
29
Saidi Wael Formation Informaticiens PAPNJ

Dmarrer le prochain Sprint

A la suite de la revue de Sprint, le Product Owner peut appliquer toute nouvelle mise jour sur le
Product Backlog ajouter de nouveaux lments, retirer des lments obsoltes, ou en rcrire
certains autres. Le Product Owner doit sassurer que tout changement se rpercute dans le
Product Backlog. Voir la figure 9 pour un exemple de Product Backlog mis jour.
Il ny a pas de temps darrt entre les Sprints les Equipes passent dune Rtrospective de Sprint
un aprs-midi une Planification de Sprint le matin suivant (ou aprs le weekend).
Lun des principes du dveloppement agile est lapplication dun rythme soutenable , et cest
uniquement en travaillant aux heures normales et une cadence raisonnable que les Equipes
peuvent continuer ce cycle indfiniment. La productivit de lEquipe augmente avec le temps
grce lvolution des pratiques et la suppression des obstacles qui ralentissent la cadence, et
non pas en augmentant la charge de travail ou en faisant des compromis sur la qualit.

Product Backlog mis jour

Les Sprints continuent jusqu ce que le Product Owner dcide que le produit est prt tre
releas. Le summum de Scrum, cest un produit potentiellement livrable la fin de chaque Sprint,
cest dire sans aucun travaux terminer, tels que des tests ou de la documentation. Cela
implique que tout soit compltement termin chaque Sprint, de telle sorte quil soit rellement
possible de livrer le produit ou de le dployer immdiatement aprs la Revue. Cependant,
beaucoup dorganisations possdent des pratiques de dveloppement, des outils et une
infrastructure inadapts, et sont dans lincapacit daboutir cette vision de la perfection. Ds lors,
un Sprint de Release peut tre ncessaire pour effectuer ces travaux restants. Lorsquun Sprint de
Release est ncessaire, cela est considr comme un mal ncessaire, mais lorganisation doit
nanmoins tenter damliorer ses pratiques pour que cette ncessit disparaisse.

La gestion des Releases

30

Saidi Wael Formation Informaticiens PAPNJ

Le problme de la planification de releases long terme se pose parfois dans un modle itratif.
Deux cas sont possibles : (1) un nouveau produit dans sa premire release, et (2) un produit
existant dans une release future.

Dans le cas dun nouveau produit, ou dun produit existant adoptant Scrum, il est ncessaire de
procder laffinage du Product Backlog avant le premier Sprint, lorsque le Product Owner et
lEquipe initialisent un vritable Product Backlog Scrum. Cela peut prendre quelque jours, voire
une semaine, et ncessiter un atelier de travail (parfois appel Cration du Product Backlog Initial
ou Planification de Release), quelques analyses dtailles des besoins, et une estimation de tous
les lments identifis pour la premire release.

Dune manire plus surprenante, dans le cas dun produit et dun Product Backlog existants, il
nest pas ncessaire de planifier spcifiquement la prochaine release. Pourquoi ? Parce que le
Product Owner et lEquipe doivent mener laffinage du Product Backlog chaque Sprint (cinq dix
pourcents de chaque Sprint), de manire continuellement prparer le futur. Ce mode de
dveloppement continu du produit rend inutile le besoin dtapes jalonnes du type prparationralisation-transition, que lon voit dans les cycles de dveloppement traditionnels.

Lors de latelier prliminaire daffinage du Product Backlog et durant laffinage continu du Backlog
chaque Sprint, les connaissances de lEquipe et du Product Owner augmentent au mme
rythme que la planification de la release, ainsi que de laffinage des estimations, des priorits, et
du contenu.
Certaines releases sont pilotes par les dlais ; par exemple : Nous produirons la version 2.0 de
notre solution pour le salon du 10 novembre . Dans cette situation, lEquipe terminera autant de
Sprints que possible (et dveloppera autant de fonctionnalits que possible) dans le temps
imparti. Dautres produits impliquent quun certain nombre de fonctionnalits soient disponibles
pour pouvoir affirmer quils sont termins (le produit ne pouvant pas tre lanc sans que ces
besoins soient satisfaits, quelque soit le temps que cela peut prendre). Etant donn que Scrum
met laccent sur la production de code potentiellement livrable chaque Sprint, le Product Owner
peut alors choisir de faire des releases intermdiaires, afin de permettre au client de tirer plus
rapidement profit du travail termin.
Etant donn quil nest sans doute pas possible de connatre tout ds le dbut, lattention est
porte sur la cration et laffinage dun plan, permettant de donner la release une orientation
gnrale et de clarifier la manire dont les arbitrages seront rendus (primtre versus calendrier,
par exemple). Il faut imaginer cela telle une feuille de route permettant daller vers une destination
finale ; les chemins prcis suivre et les dcisions prendre durant le voyage peuvent tre
dtermins en cours de route.
La destination est plus importante que le voyage.
La plupart des Product Owner mettent en place une dmarche spcifique pour la gestion des
releases. Par exemple, ils peuvent dcider dune date de release, et travailleront alors avec
31

Saidi Wael Formation Informaticiens PAPNJ

lEquipe afin destimer les lments du Product Backlog pouvant tre termins cette date. Les
lments prvus pour la release en cours sont parfois appels lments de release. Dans une
situation o un engagement de type prix fixe / date fixe / contenu fixe est requis, par
exemple, un projet au forfait un ou plusieurs de ces paramtres doivent inclure une contingence
permettant de grer lincertitude et le changement. A ce titre, Scrum ne diffre pas des autres
approches.

Focalisation Produit ou Application

Pour les applications comme pour les produits destins la commercialisation ou un usage
interne au sein dune organisation Scrum fait bouger les lignes en passant de lancien model
centr sur le projet un nouveau modle centr sur le dveloppement continu. Il ny a plus de
projet avec un dbut, un milieu et une fin. Et donc plus de chef de projet au sens traditionnel du
terme. Au lieu de cela, il y a simplement un Product Owner stable et une Equipe durablement
auto-organise collaborant dans une srie sans fin de Sprints de dure fixe, jusqu ce que
lapplication ou le produit soit retir. Tout le travail ncessaire de gestion de projet est pris en
charge par lEquipe et le Product Owner qui est un reprsentant interne du mtier ou un
responsable dapplication. Il nest pas pilot par un manager IT ou par une personne du Project
Management Office.
Scrum peut galement tre utilis pour de vrais projets de type initiative ponctuelle (versus
crations ou volutions dapplications sur du long terme). Mais mme dans ce cas, ce sont
lEquipe et le Product Owner qui assurent la gestion de projet.
Que ce passe-t-il lorsquil ny a pas suffisamment de nouveaux travaux issus dune ou de
plusieurs applications existantes et permettant de garantir le maintien dune Equipe ddie sur du
long terme ? Dans ce cas, une Equipe unique et stabilise peut slectionner des lments dune
application lors dun Sprint, puis des lments dune autre application le Sprint suivant. Cette
situation implique souvent des Sprints relativement courts, par exemple une semaine.
Mais parfois il ny a pas suffisamment de nouveaux travaux mme pour mettre en uvre la
solution prcdente, et lEquipe peut tre amene choisir des lments de plusieurs applications
pour un mme Sprint. Cependant, il faut se mfier de ce dispositif car il peut engendrer une
gestion multitche entre plusieurs applications gnrant une perte de productivit. Un pilier majeur
de productivit dans Scrum, cest une Equipe focalise sur un produit ou une application au sein
dun mme Sprint.

Les problmes courants

Scrum ne se rsume pas un ensemble concret de pratiques il faut plutt retenir quil sagit dun
cadre qui assure la transparence, ainsi quun mcanisme qui permet linspection et ladaptation
. Le fonctionnement de Scrum rend visible les dysfonctionnements et les obstacles qui impactent
le Product Owner et lefficacit de lEquipe, afin quils puissent tre grs. Par exemple, il est
possible que Product Owner manque de connaissance propos du march, des fonctionnalits,
ou sur la faon destimer la valeur mtier relative de celles-ci. LEquipe peut galement se tromper
dans ses estimations ou dans son travail de dveloppement.

32

Saidi Wael Formation Informaticiens PAPNJ

Lapplication du cadre de Scrum permettra de rapidement mettre en lumire ces faiblesses. Scrum
ne rsout pas les problmes de dveloppement, il les rend pleinement visible, et propose un cadre
permettant aux personnes dexplorer diffrents moyens de rsoudre ces problmes, en cycles
courts et au travers de petites expriences damlioration.

Si lors du premier Sprint, lEquipe ne parvient pas livrer ce quelle avait planifi cause dun
manque de maturit dans lanalyse et dans lestimation, cela ressemble un chec. Mais en
ralit, cette exprience est une premire tape ncessaire qui permet lEquipe dtre plus
raliste et plus affute dans ses engagements. Ce modle o Scrum participe rendre visible
des dysfonctionnements, et permet lquipe dy apporter des rponses constitue le mcanisme
de base apportant les bnfices les plus significatifs pour les Equipes vivant lexprience Scrum.
Lorsque la mise en pratique de Scrum est difficile, une erreur couramment rencontre est de
changer Scrum. Par exemple, les Equipes ayant du mal respecter leurs engagements sur les
Sprints peuvent dcider de rendre extensible la dure des Sprints, de sorte quil ne manque
jamais de temps et par la mme occasion, quil ne soit jamais possible dapprendre amliorer
les estimations et la gestion du temps. Dans ce cas de figure, sans le coaching et le support dun
ScrumMaster expriment, les organisations peuvent faire de Scrum le simple reflet de leurs
propres faiblesses et dysfonctionnements, se privant ainsi du rel bnfice que Scrum offre :
mettre en lumire le bon comme le mauvais, et donner lopportunit lorganisation de slever
un meilleur niveau.
Une autre erreur courante est de supposer quune pratique nest pas encourage ou quelle est
prohibe uniquement parce que Scrum ne la require pas spcifiquement. Par exemple, Scrum
noblige pas le Product Owner tablir une stratgie long terme pour son produit ; pas plus quil
noblige des ingnieurs prendre conseils auprs dingnieurs plus expriments propos de
problmes techniques complexes. Scrum laisse la possibilit aux individus de prendre les bonnes
dcisions ; et dans la plupart des cas, les pratiques voques ci-dessus (parmi beaucoup
dautres) sont bien utiles.
Un autre point dont il faut se mfier, cest quand des managers imposent Scrum leurs Equipes.
Scrum, cest donner une Equipe du champ libre et des outils pour quelle puisse se grer ellemme, et se voir imposer cela den haut ne constituera jamais la recette du succs. Une meilleure
approche consiste initier une Equipe Scrum par ses pairs ou par un manager, puis la former
compltement grce une formation professionnelle. Elle ferait alors le choix en tant quEquipe de
suivre fidlement les pratiques pour une priode dfinie. A la fin de la priode, lEquipe ferait le
bilan de son exprimentation et dciderait de continuer ou non.
Bien que le premier Sprint reprsente gnralement un vrai dfi pour lEquipe, la bonne nouvelle
est que les avantages de Scrum tendent merger ds la fin de celui-ci, ce qui conduit bon
nombres dEquipe Scrum proclamer : Scrum est difficile, mais cest assurment beaucoup
mieux que ce que lon faisait avant ! .

33

Saidi Wael Formation Informaticiens PAPNJ

Appendix A: lectures additionnelles

Il y a beaucoup de documentations publies sur Scrum. Dans cette section de
rfrence, nous souhaitons mentionner quelques ressources en ligne ainsi que
quelques livres.
Ressources en ligne:
The Lean Primer Une introduction la Pense Lean, influence importante
de Scrum [Link]
34

Saidi Wael Formation Informaticiens PAPNJ

The Distributed Scrum Primer conseils additionnels pour les quipes

distribues [Link]
The ScrumMaster Checklist Une liste de questions que
ScrumMasters utilisent [Link]

les

bons

Feature Team Primer Adapter Scrum avec des quipes fonctionnelles

[Link]
The Agile Atlas - Core Scrum. Dscription de Scrum par la
ScrumAlliance [Link]
Scrum Guide - Dscription de Scrum par [Link]
[Link]
Agile Contracts Primer Comment rdiger des contrats incluant
Scrum [Link]
Livres:
Leading Teams - Richard Hackman
Scaling Lean & Agile Development: Thinking and Organizational Tools for
Large-Scale Scrum - Craig Larman, Bas Vodde
Practices for Scaling Lean & Agile Development: Large, Multisite, and
Offshore Product Development with Large-Scale Scrum - Craig Larman,
Bas Vodde
Agile Project Management with Scrum - Ken Schwaber
Succeeding with Agile: Software Development using Scrum - Mike Cohn

35

Saidi Wael Formation Informaticiens PAPNJ