Formation

Scrum
30/05/2020 – 31/05/2020
ITAB Academy
Sommaire

1. Atelier pratique
2. Le monde avant l’agilité.
3. Scrum : Définition et introduction.
4. Les rôles dans Scrum.
5. Les événements dans Scrum.
6. Les Artéfacts dans Scrum.
7. Outils et indicateurs.
8. Notions avancées.
9. Examen.
2
Introduction
Tour de table

3
1.
Atelier pratique

4
2.
Le monde avant
l’agilité

5
Le cycle en cascade ou Waterfall (1/2)

6
Le cycle en cascade ou Waterfall (2/2)

Analyse
Spécifications plus d’actualité!

Spécifications

Design

Implémentation

Recette

Détection tardive d’anomalies MEP

7
La valeur du produit

8
Agilité , les débuts… (1/2)

◎ A partir des années 90, début de l’écart du cycle en cascade en utilisant

des méthodes itératives.

9
Agilité , les débuts… (2/2)

◎ Livraison plus rapide des fonctionnalités.

◎ Découvrir des anomalies éventuelles plus tôt.
◎ Permettre plus rapidement un changement
d’exigences.
◎ Agir sur le changements en s’adaptant à travers une
replanification.
◎ Plus grande adaptabilité.
◎ Des méthodes itératives et light.

10
Le manifeste agile

◎ 17 spécialistes du développement logiciel réunis en 2001 pour identifier

les points communs sur les différentes méthodes appelées sans
consensus méthodes « light »

11
Le manifeste agile - Valeurs

12
Le manifeste agile – Principes (1/2)

◎ Notre plus haute priorité est de satisfaire le client en livrant rapidement

et régulièrement des fonctionnalités à grande valeur ajoutée.
◎ Accueillez positivement les changements de besoins, même tard dans le
projet.
◎ Livrez fréquemment un logiciel opérationnel avec des cycles de
quelques semaines à quelques mois et une préférence pour les plus
courts.
◎ Les utilisateurs ou leurs représentants et les développeurs doivent
travailler ensemble quotidiennement tout au long du projet.
◎ Réalisez les projets avec des personnes motivées. Fournissez-leur
l’environnement et le soutien dont elles ont besoin et faites-leur
confiance pour atteindre les objectifs fixés.
◎ Privilégiez la co-location de toutes les personnes travaillant ensemble et
le dialogue en face à face comme méthode de communication.

13
Le manifeste agile – Principes (2/2)

◎ Un logiciel opérationnel est la principale mesure de progression d'un

projet.
◎ Les processus agiles encouragent un rythme de développement
soutenable. Ensemble, les commanditaires, les développeurs et les
utilisateurs devraient être capables de maintenir indéfiniment un
rythme constant.
◎ Une attention continue à l'excellence technique et à un bon design.
◎ La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile
– est essentielle.
◎ Les meilleures architectures, spécifications et conceptions émergent
d'équipes auto-organisées.
◎ À intervalles réguliers, l'équipe réfléchit aux moyens possibles pour
devenir plus efficace. Puis elle s'adapte et modifie son mode de
fonctionnement en conséquence.

14
Changement de paradigme (1/3)

◎ Sur une étude de VersionOne sur l’implémentation des méthodes agiles

sur les 6 dernières années en 2011 et sur 6042 réponses :

○ Plus de la moitié des participants avaient déjà travaillé avec des

méthodes agiles sur les 2 dernières années.

○ Un participant sur 5 (17%) a estimé que sa société planifiait de

passer à l’agilité dans un futur proche.

○ Plus des deux tiers indiquaient que leur société gérait plus de la
moitié de ses projets en agile.

○ Presque un participant sur quatre (22%) estimait que la diminution

du time to market était la principale motivation derrière
l’utilisation de l’agilité.

○ L’augmentation de la productivité était l’un des avantages les plus

significatifs de l’utilisation de l’agilité (75%), avec la possibilité de
changer en cours de route les exigences client (84%), et d’avoir une
meilleure visibilité sur le projet (77%)
15
Changement de paradigme (2/3)

16
Changement de paradigme (3/3)

17
3.
Scrum : Définition
et introduction

18
Origine et évolution de Scrum

◎ 1986 : Hirotaka Takeuchi et Ikujiro Nonaka introduisent le terme Scrum dans un

article paru dans Harvard Business Review nommé "The New New Product
Development Game” pour une application principale dans le domaine
industriel.
◎ En 1995 Ken Schwaber et Jeff Sutherland présentent un communiqué décrivant
les fondements de Scrum qui seront affinés dans les années suivantes.
◎ En 2001, Schwaber travaille avec Mike Beedle pour décrire la méthode Scrum
dans son livre “Agile Software Development with Scrum”.
◎ En 2002, Schwaber s’organise avec d’autres personnes pour fonder Scrum
Alliance et In 2001, et procéder à des certification Scrum.
◎ En 2009,Schwaber et Sutherland publient le guide Scrum qui deviant la
reference en Scrum. Le guide a été révisé 5 fois dont la derniere en Novembre
2017.
◎ En 2018, Schwaber, la communité de Scrum.org et les leaders de la
communauté Kanban publient “The Kanban Guide for Scrum Teams”

19
Définition de Scrum (1/2)

◎ Consensus de principes

Un framework pour développer et maintenir des produits complexes

20
Définition de Scrum (2/2)

◎ Basé sur une approche empirique :

1. Itératif
2. Incrémental

◎ Consiste en 3 principes :
1. La transparence (Fini veut dire fini)

2. L’inspection (Vérification du progrès)

3. Adaptation (Changement du produit sur la base de l’inspection)

21
Vue globale de Scrum

22
Evolution de la notion d’équipes

Equipes pluridisciplinaires et auto-organisées

23
4.
Les rôles dans
Scrum

24
Les rôles dans Scrum

25
Le product Owner

◎ Responsable de la création du backlog produit et de sa maintenance.

◎ Priorise les exigences en se basant sur la valeur.
◎ Prend des décisions afin de maximiser le retour sur investissement.
◎ Fait des compromis afin de maximiser la valeur du produit.
◎ Valide la réalisation incrémentale du produit.
◎ Présente le besoin à l’équipe de développement.
◎ Est responsable du planning global.

26
Le Scrum Master

◎ Maîtrise et est garant des rituels Scrum.

◎ Elimine les blocages pour l’équipe de développement.
◎ Aide l’équipe de développement à devenir auto-organisée.
◎ Est facilitateur quand nécessaire.
◎ Aide le Product Owner à maximiser le retour sur investissement.
◎ Aide l’équipe de développement à être plus productive.
◎ Rôle de management même si n’est pas un supérieur hiérarchique de
l’équipe de développement.

27
L’équipe de développement (1/2)

◎ Cross fonctionnelle et auto-organisée.

◎ Expert dans son domaine.
◎ Bati autour d’individus motvés.
◎ Taille optimale entre 3 et 9 personnes.
◎ Produit des incréments potentiellement livrables en production.
◎ Responsable de l’auto-résolution de ses conflits.
◎ Responsable de ses livrables et de ses engagements.

28
L’équipe de développement (2/2)

◎ Nombre de canaux de communication : N * (n-1)/2

29
L’équipe Scrum

◎ L’équipe Scrum est composée de l’équipe de développement, du

PO et du Scrum Master.
◎ L’équipe Scrum a été définie avec les membres clés permettant la
livraison d’incréments produitset de collaborer dans ce sens.
◎ Il n’y a aucune distinction dans Scrum des différents rôles de
l’équipe de développements, même si on peut avoir :
○ Des développeurs.
○ Des testeurs.
○ Des experts techniques.
On parle d’équipe de développement.

30
5.
Les artéfacts dans
Scrum

31
32
33
34
La vision produit (1/2)

◎ La vision produit fixe le cap et donne le sens, elle définit ce qu’on

entrevoit pour le produit à cours, moyen ou long terme.
◎ Représente le pourquoi du produit.
◎ Permet d’alligner l’ensemble des acteurs sur le même but.
◎ Le Product owner doit porter la vision produit.
◎ Plusieurs techniques peuvent être utilisés pour dégager une
vision produit :

5 pourquoi Boite produit 35

La vision produit (2/2)

36
Les personas (1/2)

◎ Un persona est un archétype d’utilisateur du produit représentant ses

convictions et ses particularités.
◎ Il permet de cibler les attentes des utilisateurs pour construire un
produit qui y réponde.
◎ Les personas ne sont pas créées mais découverts lors d’une
investigation sur le produit.
◎ Les personas sont usuellement décrits avec leur nom et prénom,
personnalités, motivations et même parfois une photos.

◎ Points d’attentions :
○ Les personnas ne représentent pas des groupes d’utilisateurs avec
des rôles et des tâches mais plutôt des comportements et des buts
pour traduire leurs motivations.
○ Les personnas ne représentent pas des segments de marché (du
type 18 – 25 ans), ce sont des utilisateurs plutôt que des clients.

37
Les personas (2/2)

38
Le story mapping (1/2)

◎ Une manière visuelle d’initialiser le backlog produit, permet

d’accorder tous les intervenants sur le scope et la compléxité.
◎ La construction des exigences sous un format physique favorise
la collaboration et la compréhension.
◎ Permet en peu de temps de construire une vision sur les
fonctionnalités nécessaires à produire (MVP) et celles qui ne sont
à déprioriser.
◎ Permet à l’équipe de développement d’avoir une vision globale
sur le produit, le scope et les priorités.
◎ Avoir une vision sur la valeur des users stories et de leur
priorisation.

39
Le story mapping (2/2)

40
Atelier Story Mapping

41
Backlog produit (1/2)

◎ Liste priorisée par le product owner des besoins métiers représentés

sous la forme de user stories.
◎ Tout élément du backlog produit rajoute de la valeur au client final.
◎ Le backlog produit n’est pas figé et peut évoluer avec nécessité de
tampon du product owner pour tout changement.
◎ Le product owner est responsable de la gestion du backlog produit.

42
Backlog produit (2/2)

43
Backlog de Sprint

◎ Représente travail identifié par l’équipe Scrum :

○ Le Product owner présente les users stories souhaitées.
○ L’équipe de développement définit son engagement sur le sprint et
décompose en tâches techniques.
◎ Le product owner ne peut plus changer le contenu du Sprint une fois le
Sprint lancé.
◎ Exceptionnellement un Sprint peut être annulé si son but n’a plus lieu
d’être, mais vu que la taille du sprint est courte cela reste exceptionnel.

44
Incrément

◎ Un incrément est la somme de tous les éléments du backlog produit

pouvant être finalisés dans un Sprint.
◎ A la fin du Sprint, l’incrément doit respecter la definition du fini établie
par l’équipe Scrum.
◎ L’incrément doit être potentiellement livrable en production
indépendamment du fait que le Product owner decide de le livrer ou
pas.

45
Epic

◎ Une user story trop large pour être délivré en un seul Sprint ou ne pouvant pas
être splitté en d’autres user stories.
◎ Pas de standard défini pour leur utilisation (Pareil que les US pour les uns ou une
simple phrase pour les autres).
◎ Permet de garder la visibilité sur des idées définis dans le backlog produit sans
rentrer dans leur granularité.
◎ Peut être décomposé en user stories lors du raffinement du backlog.

46
User Story

◎ Une courte description d’une fonctionnalité depuis le point de vue de la personne

qui souhaite son implémentation.
◎ Toutes les parties prenantes peuvent écrire des user stories mais il est de la
responsabilité du product owner de maintenir le backlog produit.
◎ Facilitent la participation d’acteurs non techniques en mettant le focus sur la
valeur.
◎ Aident à obtenir une définition complète du produit.

47
Cycle de vie d’une User Story (1/2)

48
Cycle de vie d’une User Story (2/2)

49
Critères d’écriture d’une User Story

50
Exemple de User Story

Identifiant de la user story

Délai de traitement

Description

Humeur après réalisation de la user

story

Etapes de finalisation de
la user story

In : Date d’entrée de la user story.

Out : Date de traitement de la user
story

51
Tâches

◎ Unité de travail nécessaire pour réaliser une story.

◎ Afin de réaliser une story, l’équipe doit effectuer certaines activités
structurées telles que des tâches.
◎ Une tâche ne fait pas partie des résultats du projet, c’est plutôt le moyen
de produire le résultat. Une tâche peut être effectuée par un seul
membre de l’équipe, tandis que la réalisation d’une story est la
responsabilité de toute l’équipe.
◎ En plus des tâches de story, des tâches peuvent être créées en dehors
d’une story en tant que tâches urgentes et tâches récurrentes. Les tâches
attachées à une story peuvent évoluer à mesure qu’elle progresse.

52
Atelier Backlog produit

53
Définition du fini

◎ Définition du fini :
○ Permet de s’assurer d’une définition commune et d’une même
compréhension de la notion de fini.
○ Fournit une checklist du travail à réaliser pour compléter des
tâches, user stories….
○ Permet d’éviter des conflits entre l’équipe de développement et le
Product owner sur la finalisation des livrables.
○ Evite la notion de « presque fini »

◎ Pièges à éviter :
○ Essayer de définir la liste exhaustive de tous les critères peut être
contre productif. Définir le nécessaire minimal pour passer au
statut de fini puis itérer dessus.
○ Ne pas oublier des critères de fini supplémentaires pour certaines
user stories.
○ Se focaliser sur l’énumération et l’affichage plutôt que de l’inclure
en tant que culture de l’équipe.

54
Définition du prêt

◎ Définition du prêt :
○ S’assurer que les éléments du backlog produits sont prêts pour être
embarqués dans un sprint.
○ Réduire la pression de l’engagement sur les estimations pour des
éléments incomplets.
○ Responsabiliser les équipes sur le travail à effectuer.
○ Ne doit pas être fixe mais doit être revue en rétrospective si besoin
de changement.

55
Atelier définition du
fini et du prêt

56
Exemple définition du fini

57
Exemple définition du prêt

58
6.
Les évenements
dans Scrum

59
Sprint Planning
◎ Toute l’équipe Scrum participe au Sprint planning afin de définir les user stories
qui permettront d’accomplir le but du Sprint.
◎ Un Sprint planning est effectué au démarrage de chaque Sprint.
◎ Sa durée est de 8 heure pour un sprint de 4 semaines et de moins pour des sprints
d’une durée inférieure
◎ L’équipe de développement peux inviter d’autres partie prenantes pour avoir une
assistance technique ou fonctionnelle.

60
But du Sprint Planning

◎ Donne une vision à l’équipe de développement sur le pourquoi

de l’implementation de l’increment.
◎ Est défini Durant le Sprint planning.
◎ L’objectif du Sprint est de donner une flexibilité à l’équipe de
développement sur l’implementation de la fonctionnalité dans le
Sprint.
◎ L’équipe de développement garde en tête le but du Sprint tout le
long du Sprint.
◎ Si le travail à effectuer est different de ce à quoi l’équipe de
développement s’attendait, l’équipe collabore avec le product
owner pour négocier le périmètre du Sprint.
Sprint planning en détail (1/2)

◎ Le Sprint planning est habituellement séparé en deux parties.

◎ Lors de la première partie :
○ Toute l’équipe Scrum se réunit.
○ Le product owner présente la vision et l’objectif du Sprint.
○ Il détaille à l’équipe de développement les user stories choisies pour le
Sprint et procède à une discussion avec l’équipe de développement pour
lever toute ambiguité.
○ L’équipe de développement peut refuser des user stories si ne respectant
pas la définition de prêt.
○ La priorité des user stories est présentée.
○ L’équipe de développement choisit les user stories sur lesquels elle peut
s’engager.
○ Toutes les parties prenantes s’engagent sur l’objectif défini.

◎ La première partie du Sprint planning est effectuée avec le product owner

concerne le pourquoi et non le comment qui est effectuée séparemment.

62
Sprint planning en détail (2/2)

◎ Deuxième partie :
○ Concerne l’équipe de développement et le Scrum Master.
○ L’équipe de développement procède à l’estimation des user stories.
○ Un découpage en tâches techniques est effectué et éventuellement
également estimé.
○ Un échange sur l’implémentation technique est effectué afin de s’assurer
d’une même compréhension par tous les membres de l’équipe de
développement.
○ L’équipe de développement définit parmi les user stories présentées celle
sur lesquelles elle peut s’engager sur le Sprint (ou plus).
○ Un backlog de Sprint est constitué .

63
Pourquoi retarder l’estimation

64
Planning poker

◎ Technique d’estimation utilisée lors du Sprint planning.

◎ L’estimation est faite habituellement en points d’effort de la suite Fibonacci.
◎ Chaque membre de l’équipe de développement choisit indépendamment une
estimation.
◎ Tous les membres de l’équipe de développement lèvent leur carte en même
temps.
◎ S’il n’y pas consensus, les personnes avec les estimations la plus haute et la plus
basse expliquent leur choix.
◎ Une réestimation est effectuée après une clarification.
◎ Une stratégie possible si pas de consensus après 2 rounds de discussion sur deux
estimations consécutives est de choisir l’estimation la plus haute.
◎ L’équipe de développement garde en tête sa vélocité pour définir son
engagement sur le sprint.

65
Manières d’estimer

◎ Estimation par des valeurs de la suite de Fibonacci

◎ Estimation par taille de Tshirt :

66
Points d’effort Vs Points de complexité

◎ Même si on parle souvent de point de complexité, il est préférable de

parler de « point d’effort » pour réaliser une user-story. Le terme
complexité est en fait assez mal définit car la complexité n’est qu’un
point à prendre en compte pour estimer une user-story.
◎ On peut par exemple trouver trouver des user stories qui :
○ Ne sont pas complexes.
○ Nécessitent autant d’effort que d’autres user stories plus complexes
pour d’autres raisons.
◎ Modifier par exemple une constante dans le code peut être très simple
mais l’effort à effectuer peut rapidement devenir beaucoup plus
conséquent si cette constante est présente dans une centaine (ou
millier!) d’occurrences dans votre projet.
◎ L’équipe ne peut pas définir sa vélocité lors du premier Sprint mais
nécessitera quelques Sprint d’adaptation avant de pouvoir la mesurer.

67
Atelier Sprint Planning

68
Burndown chart

◎ Le burndown chart est un outil visuel de mesure du travail

accompli à date par rapport à ce qui a été initialement prévu.
◎ On peut l’utiliser :
○ Pour un Sprint.
○ Pour une release.
○ Pour un produit.

◎ L’objectif étant de se situer en dessous de la courbe idéale.

◎ On marque le reste à faire sur le backlog qui représente le total
en points d’efforts des user stories non finalisées.
◎ On peut aussi avoir la notion de burnup chart.

69
Burndown chart de release

70
Burndown chart de Sprint

71
Daily Stand Up (1/2)

◎ Prend son origine du daily stand up en Xtreme Programming, aussi

appelé Daily Scrum en référence à son utilisation dans Scrum.
◎ Offre à l’équipe une occasion d’échanger quotidiennement sur
l’avancement, les points de blocages et permet d’éviter que certaines
informations critique soient partagées.
◎ Doit durer 15 minutes au maximum.
◎ Il est de l’obligation du Scrum Master que le daily stand up soit tenu.
L’équipe s’auto-organise lors du stand up et le Scrum Master peut
éventuellement aider en orientant l’équipe.
◎ Quelques pièges à éviter :
○ Le daily stand up n’est pas un un point de reporting (Posture
souvent retrouvée envers le Scrum Master).
○ Le stand up « pas de problèmes » où même si les engagements ne
sont pas tenus on ne parle que des tâches en cours.
○ S’engager dans des débats qui rallongent la durée du stand up (à
tenir dans une séance séparée après le Stand up par exemple).

72
Daily Stand Up (2/2)

73
Revue de Sprint (1/2)

◎ Effectué en fin de Sprint pour inspecter l’incrément de l’itération et

adapter le backlog produit au besoin.
◎ Ne doit pas dépasser 4 heures.
◎ Le Scrum Master doit s’assurer que la revue est tenue et que tous les
parties prenantes en comprenne le but.
◎ Le Product owner peut inviter des intervenants clé à la revue de Sprint.
◎ L’équipe de développement présente le travail fini et répond aux
différentes questions.
◎ Le product owner discute de l’état du backlog produit.
◎ Tout le groupe échange sur la suite, la revue de Sprint permettant de
préparer le Sprint planning.
◎ Revue de la valeur pour voir si les priorités identifiées tiennent toujours.
◎ Revue du budget, du planning, des prochaines releases du produit.

74
Revue de Sprint (2/2)

◎ Quelques pièges à éviter :

○ Considérer la revue de Sprint seulement comme une démo.
○ Démontrer les résultats seulement au product owner.
○ Ne pas inviter des intervenants clés en ne prenant pas en compte
leur feedback au plus tôt.
○ Ne pas faire de présentation parce qu’il n’y a rien à démontrer.
○ Ne pars permettre à l’équipe de développement d’assister à la
revue de Sprint car il y’a un travail plus important.
○ Ne pas être transparent sur le statut réel du travail.
○ Être focalisé sur de la documentation plutôt qu’un code qui
marche.
○ Ne pas prendre en compte les retours pour discuter de la définition
du terminé.

75
 Retrospective

◎ La rétrospective et une réunion de l’équipe qui lui permet d’échanger sur

l’itération précédente afin d’identifier les forces et axes d’améliorations.

◎ Elle obéit au principe d’inspection et d’adaptation afin de chercher

l’amélioration continue.
◎ Le but étant de :
○ D’inspecter comment s’est passé le dernier Sprint concernant les
personnes et relations entre elles , les processus et les outils.
○ Identifier et prioriser les principales forces et blocages de l’équipe.
○ Créer un plan d’implémentation des améliorations de l’équipe
Scrum.
◎ En fin de rétrospective, l’équipe Scrum doit identifier les actions
d’améliorations qu’elle pourra implémenter d’ici au prochain Sprint.
◎ La rétrospective est aussi le moment pour discuter d’une amélioration
possible de la définition du terminé et du prêt.
◎ La durée maximale de la rétrospective est de 3 heures.

76
Exemple format de retrospective - Starfish

77
Exemple format de retrospective - Speedboat

78
Mood Meter

79
Pièges à éviter en rétrospective

◎ Quelques travers dans lesquels il ne faut pas tomber en rétrospective :

○ Ce n’est pas une recherche de fautif, l’échange doit rester
constructif sur les faits pas sur les personnes.
○ Ne pas faire de rétrospective parce qu’il n’ya rien à améliorer.
○ Utiliser toujours le même format de rétrospetive.
○ Ne pas avoir d’améliorations ciblées avec des porteurs pouvant les
prendre en charge.
○ Ne pas faire de revue des actions définies dans la rétrospective
précédente.
○ Assigner toutes les actions au Scrum Master.
○ Prendre en compte des actions trop grosses pour être traitées en
une itération.
○ Ce qui se passe en rétrospective ne reste pas en rétrospective.
○ Volonté des manager de s’inclure dans la rétrospective.

80
Atelier rétrospective

81
Raffinement du backlog

◎ Le raffinement du backlog permet de prioriser, d’ajouter des détails ou

des estimations aux éléments du backlog produit.

◎ C’est un processus continu dans lequel l’équipe de développement

collabore avec le product owner sur le détail des éléments du backlog
produit.

◎ Le raffinement du backlog produit ne doit pas prendre plus de 10% de

l’effort de l’équipe sur un Sprint.

◎ L’équipe Scrum définit quand et comment le raffinement du backlog

doit être fait cependant la modification du backlog produit peut être
faite n’importe par le product owner.

82
7.
Outils et indicateurs

83
Outils Scrum (1/2)

◎ GitScrum – https://site.gitscrum.com/
◎ Jira – https://www.atlassian.com/software/jira/
◎ Target Process – https://www.targetprocess.com/
◎ Vivify Scrum – https://www.vivifyscrum.com/
◎ Yodiz – https://www.yodiz.com/
◎ ScrumDo – https://www.scrumdo.com/
◎ Quickscrum – https://www.quickscrum.com/
◎ Manuscript – https://www.manuscript.com/
◎ Scrumwise – https://www.scrumwise.com/
◎ Axosoft – https://www.axosoft.com/
Quelques critères de comparaison :
○ Backlog produit, Sprints et burndown chart.
○ Visualisation.
○ Rapports.
○ Notifications:.
○ Integration (mobile et autres outils).
◎ Lien comparaison 2019 des outils https://thedigitalprojectmanager.com/best-scrum-tools/
84
Outils Scrum (2/2)

Jira GitScrum

IceScrum 85
Indicateurs (1/2)

◎ Communication : Avant l’établissement d’indicateurs, la communication

entre l’équipe Scrum doit être assurée pour être sûr d’avoir un discours
transparent et honnête.
◎ La motivation de l’équipe : pour cibler les actions à faire (Les individus
avant les process et les outils)
◎ Vélocité : Permet de mesurer le nombre de points d’efforts que l’équipe
de développement peut traiter sur un Sprint. La précision des
estimations peut être améliorée grâce à cela.
◎ Qualité : Ratio du temps bugs ou support/ temps user stories.
◎ Taux de défauts découverts en production.
◎ Le retour client : Enquêtes sur la valeur.
◎ Lead time : délai entre le début du travail sur une user story et sa
livraison.

86
Indicateurs (2/2)

87
Raisons pouvant faire échouer Scrum

◎ Des Scrum Masters qui comprenent les rituels et les artefacts Scrum
mais pas l’esprit agile qui s’en degage. Cela engender des équipes qui
suivent les règles mais sans devenir autonome. Dans ses
environnements Scrum est utilisé pour controller les équipes pas pour
les faire évoluer.
◎ Des responsables produits qui n’ont pas le mindset d’optimisation de
valeur et qui suivent aveuglément ce que les utilisateurs souhaitent. Le
produit ne sera pas bon.
◎ Des équipes qui n’ont pas le focus orienté valeur client et qui tendront à
s’engloutir dans des taches à faible valeur ajoutée ratant l’occasion
d’optimiser leur livraison.

88
Pièges à éviter

◎ Focus sur les outils et les process plus que sur les valeurs.
◎ Assignation des tâches par les managers, le product owner ou le Scrum
Master.
◎ Product owner qui est peu présent (Ou plusieurs product owners).
◎ Product owner qui spécifie les solutions techniques.
◎ Scrum master qui prend le rôle d’un chef de projet.
◎ Imposition des deadlines ou du périmètre.
◎ Scrum Master qui n’est pas présent avec l’équipe de développement.
◎ Imposer une définition du terminé.
◎ Planification et prépration excessive.
◎ Rester en mode héros.
◎ Application topdown ou Bottom up sans se soucier de l’impact de l’autre
volet.

89
Problèmes pouvant faire échouer une transformation agile

◎ Ne pas avoir d’expérience sur les méthodes agiles.

◎ La culture de l’organisation est en contradiction avec les valeurs de
l’agile.
◎ Partir sur une transformation complète dès le départ et ne pas y aller
graduellement.
◎ Ne pas impliquer les clients dans la transformation.
◎ Ne pas avoir de support du management.
◎ Ne pas investir sur la formation.
◎ Ne pas prendre le temps de familiariser l’équipe avec l’agile.
◎ Subir des pressions externes pour revenir à un mode classique.
◎ Rester au stade de faire de l’agile et ne pas « être agile ».
◎ Ne pas avoir de moyens de mesurer l’impact

90
Agilité et management

91
Etre agile

92
8.
Notions avancées

93
Kanban (1/2)

◎ La méthodologie Kanban est issue de l'industrie automobile au Japon.

◎ Elle a été créée par Taiichi Ōno pour Toyota en 1950 dans le but
d'optimiser sa capacité de production afin d'être compétitive face aux
entreprises américaines.
◎ La méthode Kanban se base sur l’approche Lean , c'est-à-dire sur
l'amélioration continue des processus de production afin de permettre
une gestion de la production sans gaspillage.

94
Kanban (2/2)

95
Agilité à l’échelle

96
Less (1/2)

◎ Deux framework pour la scalablité large echelle de Scrum.

○ LeSS: Jusqu’à 8 équipes de 8 personnes.
○ LeSS Huge: Jusqu’à mille personnes sur un produit.

◎ Focalisé sur le fait de diriger l’attention des équipes sur le produit global
et non les différentes parties individuelles.

◎ Divison du Sprint planning en 2 : une partie avec toutes les équipes pour
decider de la priorité du travail et de la réparition puis une partie où
chaque équipe fait un Sprint planning independent.

◎ Introduction d’une notion de retrospective globale incluant le product

owner, les scrum master, les représentants de l’équipe et les managers.

◎ Introduction de la notion de Area Product Owner et d’un area product

backlogpour Less Huge.

97
Less (2/2)

98
Spotify (1/3)

◎ Spotify est un service de streaming musical Populaire avec plus de 200

millions d’utilisateurs. Lancé en 2008 avec plus de 1600 employés, doit
son succès à son utilisation des méthodes agiles.

◎ Quand la société à ouvert avec quelques employés, la méthode Scrum

était utilisée. Cependant après l’evolution de la société il était temps de
passer à la scalabilité de l’agile. A present Spotify a 30 équipes agiles
réparties sur 4 villes de 3 différentes zones horaires.

◎ Création du modèle adapté permettant de scaller l’agile à l’echelle : le

modèle Spotify.

99
Spotify (2/3)

◎ Squad : Unité pluridisciplinaire et auto-organisée de moins de 8 members. Les équipes ont

une responsabilité de livraison bout en bout et l’autonomie pour le faire.
◎ Chaque squad a l’autonomie pour decider quoi livrer, comment le faire et comment travailler
pour livrer. La squad doit cependant rester aligner avec sa mission, la stratégie du produit et
les buts définis.
◎ Tribu : rassemblement de Squad focalisé sur la livraison produit et la qualité.
◎ Chapter : Groupe base sur un domaine de competence (Agilité, Framework particulier…)
◎ Guilde : Communauté d’intêret que les members de la société peuvent rejoinder pour
acquérir et partager sur un domaine particulier. Tout le monde peut rejoinder ou quitter une
tribu quand il le souhaite.

100
Spotify (3/3)

101
Safe (1/3)

◎ SAFe a été créé par Dean Leffingwell en 2011 afin de proposer une agilité
à l’échelle au sein des grandes DSI voire de certaines entreprises ; il est le
résultat d’une concaténation d’un grand nombre de pattern venant du
Lean et des méthodes agiles.

◎ Le but de SAFe est de permettre aux entreprises d’avoir un framework

structuré sur l’ensemble de l’entreprise pour obtenir une bonne
structuration ou pour mieux réussir sa transformation agile.

◎ SAFe est le résultat de nombreuses transformations agiles opérées par

son auteur ainsi que d’autres coachs agiles chez de grands acteurs tels
que Nokia ou John Deere.

◎ Safe se base sur 4 niveaux :

1. Le niveau Équipe
2. Le niveau Programme
3. Le niveau Solution
4. Le niveau Portefeuille
102
Safe (2/3)

103
Safe (3/3)

104
Conclusion

105