Mesurez votre libido agile ! Quel est votre niveau de maturité agile, et surtout, comment l'appliquez-vous concrètement au jour le jour ?

1. Tester
Votre
Libido Agile

2. Disclaimer
sommes des trolls
• Nousest une expérience apprenante
• Ceci des questions ni des réponses ne
• Aucune
•
•
se veut une vérité absolue
Chaque question peut amener le débat,
donc n’hésitez pas à l’ouvrir
Aucun Scrum Master n’a été blessé durant
la réalisation de ce questionnaire

3. Mode d’emploi !
B
A
C
D

4. Questionnaire
Template

5. 1- Quelle forme ont mes specs ?
Définition de
besoin
SFD
STD
Les specs ne sont pas
sèches… mais on est
agile ou merde ? On y
va.
En tant que …
je dois …
afin de …
US validés par
tous avec cas
d’acceptance

6. Comment se décide si une tâche est DONE ?
Le développeur
a commité dans
le contrôle de
source
Ça marche en PROD
C’est testé en
RECETTE
On a rempli
touts les
conditions du
Definition of
DONE

7. Les tests : Quelle est votre démarche ?
Test en recette
avec cahier de
recette
TDD
TU / TI
pour valider les devs
Tester, c’est
douter

8. Qui teste le produit ?
L’équipe
d’intégration
Normalement, c’est
bon. En tout cas, sur
mon poste, ça marche.
Tests croisés, puis
Product Owner
Des utilisateurs
finaux,
ou mieux, un
singe

9. 5- Qui décide du changement de périmètre ?
La Direction
C’était pas dans les
specs. On va faire un
avenant.
Le Product Owner
Consensus

10. Quand finit le projet ?
C’est en prod.
Bon, la date est
dépassée de 6
mois, et c’est
buggé. Mais bon.
Jamais
car il y a
toujours
de
nouvelles idées
La date et la vélocité
sont immuables. Donc
la seule variable
d’ajustement est le
scope.
Donc quand le client a
ce qu’il faut.
Quand j’ai
démissionné

11. A quel moment voit-on le client final ?
Oh bah s’il a
Pas besoin, on a
envie de passer,
la MOA
il peut, hein…
On a un représentant à
notre disposition en
permanence
Participe à toutes
les phases du projet

12. Who’s the boss ?
Chef de projet
(ou son chef)
(ou le chef de
son chef)
Celui qui a les
sous / mon
commercial
Scrum Master
Pas de chef
Et pourtant
ça marche 

13. Comment mesurer l’état d’avancement ?
Sur Project,
c’est marqué
qu’on est à
43,08%
Burndown chart
du Product Backlog
Il nous reste
15 points
sur ce sprint
Nombre de Feature
en Prod

14. 10- Quels sont mes KPI ?
Surveillance de la
productivité/JH,
et du pourcentage
réalisé, du TJM
Contrôle de la
velocité
de l’équipe
Indicateurs de maturité
agile :
Pilotage global
Quantité d’US dans le
Product Backlog
Nb d’anomalie par US
Vélocité
Projet
Business Value
Qualité
Business

15. Qui s’occupe du déploiement en recette ?
Je sais pas, moi
je livre un doc
de déploiement
sur le réseau
N’importe qui
dans l’équipe
Une machine
Un Mexicain

16. Qui attribue les tâches ?
Le chef d’équipe
Je prends ce qui me
plait
Le PO
Je prends la
plus prioritaire
en fonction
des conditions

17. Qui fait l’estimation des tâches ?
Celui qui crie le
plus fort pendant L’équipe propose
le Planning
et le chef valide
Poker
C’est celui qui
développe
décide. Ou le
CP. Ca dépend.
Consensus
de l’équipe

18. A quel moment sont rédigés mes tests ?
En recette après
la reception du
DEV
Avant pendant et après
Les tests sont en
constante évolution
avec le produit
TDD
pendant le DEV
Pendant la rédaction
des US
Démarche ATDD

19. 15- Qui écrit les specs ?
La MOA
Le PO
avec relecture
Toute l’équipe
Toute l’équipe participe
à la conception (specs
wall,…)
concoit l’US
et
ses cas
d’acceptance

20. Amélioration continue ?
Il suffit que
l’équipe soit
moins feignante
Nous n’avons pas
de temps
à perdre
dans des
réunions inutiles
Dès qu’il y a
Rétro régulière
(et parfois, il en sort
quelque chose
d’intéressant)
un problème,
Il faut le résoudre
pour
fluidifier la chaîne

21. Avez-vous un suivi des actions mises en place ?
On a trace tous
nos problemes
dans le Wiki
Quelles actions ?
Affichage
On fait un post-mortem
en fin de projet. Et on
flagelle les coupables.
et
suivi des actions
mises en place
en continu

22. Qui décide de l’architecture logicielle ?
L’architecte
Consensus Archi, chef
et DEV
L’équipe
Démarche
innovante
de co-création
FDD / DDD

23. Comment gère-t-on les deadlines ?
“Tu fais quoi
samedi ?”
On déscope
des sujets
en fonction
de notre vélocité
Arrêtez de faire des
tests, on n’a plus de
temps à gaspiller !
Deadline ?
On est
en flux continu,
mec !

24. 20- Comment est géré le budget ?
Je sais pas,
faudrait regarder
sur le contrat
Le PO gère le
porte monnaie
Bon, on a bradé
le forfait,
mais on va se
gaver sur
les avenants
On a des
indicateurs
partagés
sur le budget

25. Multi équipe : comment faites-vous ?
On a un chef de
projet pour
coordonner les
dates
d’accostage
Boards
synchronisés,
visibles et
connus de tous
COPIL hebdo
Scrum of Scrum

26. Qui travaille sur quoi dans l’équipe ?
Vendu au client :
Equipe d’experts
spécialisés
En vrai :
Des stagiaires
Au moins 2
personnes
connaissent
les parties
critiques
de l’appli
Nous cherchons à
ce que tout le mon
monde soit capable
de travailler sur
n’importe quelle
partie
Nous avons défini
un market of skill
afin de suivre
efficacement
les compétences
de chacun

27. 23- Partage de connaissance ?
Chacun sa
gueule, chacun
son code
Revue de code
Pair
programming
Pair, dojo,...
Nous sommes
des artisans !

28. Les
réponses
Template

29. 1- Quelle forme ont mes specs ?
Définition de
besoin
SFD
STD
Les specs ne sont pas
sèches… mais on est
agile ou merde ? On y
va.
En tant que …
je dois …
afin de …
US validés par
tous avec cas
d’acceptance

30. Comment se décide si une tâche est DONE ?
Le développeur
a commité dans
le contrôle de
source
Ça marche en PROD
C’est testé en
RECETTE
On a rempli
touts les
conditions du
Definition of
DONE

31. Les tests : Quelle est votre démarche ?
Test en recette
avec cahier de
recette
TDD
TU / TI
pour valider les devs
Tester, c’est
douter

32. Qui teste le produit ?
L’équipe
d’intégration
Normalement, c’est
bon. En tout cas, sur
mon poste, ça marche.
Tests croisés, puis
Product Owner
Des utilisateurs
finaux,
ou mieux, un
singe

33. 5- Qui décide du changement de périmètre ?
La Direction
C’était pas dans les
specs. On va faire un
avenant.
Le Product Owner
Consensus

34. Quand finit le projet ?
C’est en prod.
Bon, la date est
dépassée de 6
mois, et c’est
buggé. Mais bon.
Jamais
car il y a
toujours
de
nouvelles idées
La date et la vélocité
sont immuables. Donc
la seule variable
d’ajustement est le
scope.
Donc quand le client a
ce qu’il faut.
Quand j’ai
démissionné

35. A quel moment voit-on le client final ?
Oh bah s’il a
Pas besoin, on a
envie de passer,
la MOA
il peut, hein…
On a un représentant à
notre disposition en
permanence
Participe à toutes
les phases du projet

36. Who’s the boss ?
Chef de projet
(ou son chef)
(ou le chef de
son chef)
Scrum Master
Celui qui a les
sous / mon
commercial
Pas de chef
Et pourtant
ça marche 

37. Comment mesurer l’état d’avancement ?
Sur Project,
c’est marqué
qu’on est à
43,08%
Burndown chart
du Product Backlog
Il nous reste
15 points
sur ce sprint
Nombre de Feature
en Prod

38. 10- Quels sont mes KPI ?
Surveillance de la
productivité/JH,
et du pourcentage
réalisé, du TJM
Contrôle de la
velocité
de l’équipe
Indicateurs de maturité
agile :
Pilotage global
Quantité d’US dans le
Product Backlog
Nb d’anomalie par US
Vélocité
Projet
Business Value
Qualité
Business

39. Qui s’occupe du déploiement en recette ?
Je sais pas, moi
je livre un doc
de déploiement
sur le réseau
N’importe qui
dans l’équipe
Une machine
Un Mexicain

40. Qui attribue les tâches ?
Le chef d’équipe
Je prends ce qui me
plait
Le PO
Je prends la
plus prioritaire
en fonction
des conditions

41. Qui fait l’estimation des tâches ?
Celui qui crie le
plus fort pendant L’équipe propose
le Planning
et le chef valide
Poker
C’est celui qui
développe
décide. Ou le
CP. Ca dépend.
Consensus
de l’équipe

42. A quel moment sont rédigés mes tests ?
En recette après
la reception du
DEV
Avant pendant et après
Les tests sont en
constante évolution
avec le produit
TDD
pendant le DEV
Pendant la rédaction
des US
Démarche ATDD

43. 15- Qui écrit les specs ?
La MOA
Le PO
avec relecture
Toute l’équipe
Le mail et les post-its,
c’est des specs, non…?
concoit l’US
et
ses cas
d’acceptance

44. Amélioration continue ?
Il suffit que
l’équipe soit
moins feignante
Nous n’avons pas
de temps
à perdre
dans des
réunions inutiles
Dès qu’il y a
Rétro régulière
(et parfois, il en sort
quelque chose
d’intéressant)
un problème,
Il faut le résoudre
pour
fluidifier la chaîne

45. Avez-vous un suivi des actions mises en place ?
On a trace tous
nos problemes
dans le Wiki
Quelles actions ?
Affichage
On fait un post-mortem
en fin de projet. Et on
flagelle les coupables.
et
suivi des actions
mises en place
en continu

46. Qui décide de l’architecture logicielle ?
L’architecte
Consensus archi,
décideurs et devs
L’équipe
Démarche
innovante
de co-création
FDD / DDD

47. Comment gère-t-on les deadlines ?
“Tu fais quoi
samedi ?”
On déscope
des sujets
en fonction
de notre vélocité
Arrêtez de faire des
tests, on n’a plus de
temps à gaspiller !
Deadline ?
On est
en flux continu,
mec !

48. 20- Comment est géré le budget ?
Je sais pas,
faudrait regarder
sur le contrat
Le PO gère le
porte monnaie
Bon, on a bradé
le forfait,
mais on va se
gaver sur
les avenants
On a des
indicateurs
partagés
sur le budget

49. Multi équipe : comment faites-vous ?
On a un chef de
projet pour
coordonner les
dates
d’accostage
COPIL hebdo
Boards
synchronisés,
visibles et
connus de tous
Scrum of Scrum

50. Qui travaille sur quoi dans l’équipe ?
Vendu au client :
Equipe d’experts
spécialisés
En vrai :
Des stagiaires
Au moins 2
personnes
connaissent
les parties
critiques
de l’appli
Nous cherchons à
ce que tout le mon
monde soit capable
de travailler sur
n’importe quelle
partie
Nous avons défini
un market of skill
afin de suivre
efficacement
les compétences
de chacun

51. 23- Partage de connaissance ?
Chacun sa
gueule, chacun
son code
Revue de code
Pair
programming
Pair, dojo,...
Nous sommes
des artisans !

52. Qui êtesvous ?
Template

53. Le roi du Waterfall
•
•
•
•
33%
•
•
Prédit tout
Prévoit tout
Aime bien les abaques
Connait son
pourcentage
d’avancement au
centième de pourcent
près
… mais sait qu’il est
faux
Changer, c’est
renoncer

54. Scrum Loser
•
•
44%
•
•
•
•
•
Applique les principes
… sans comprendre
les valeurs
Pense bien faire
Scrum Master = chef
de projet, command
and control
Pas de specs, pas de
docs, on est agile, mec
Tester, c’est douter (et
en plus, c’est cher)
Ne s’améliore pas

55. Artiste Scrum et XP
•
•
•
65%
•
•
•
•
•
Comprend les valeurs de
Scrum et d’XP
Aime bien le changement
Croit en la supériorité du
Scrum partout
Cherche à s’améliorer en
permanence
Aucun obstacle ne lui
résiste
Cycles courts
Le changement, c’est cool
Echouer, c’est apprendre

56. Grand Maître agile
•
86%
•
•
•
•
•
•
•
•
•
Au dela de l’itération… le
flux
S’adapte à l’existant
Multilingue
Sait améliorer sans tout
casser
Anti-gaspillage
Brise les intermédiaires
Regarde devant et
derrière
Pense qu’on peut tout
découper en éléments de
même taille
Pas de temps mort
Devops

57. Merci
Template
A
bientôt