Retour d'expérience d'un product owner sur son premier projet - Qu'est-ce qui n'est pas dit dans Scrum

1. Christophe Alviset, product owner API Sirene
INSEE
Tout ce que mon coach agile ne m'a
pas dit
Agile France 15 juin 2018

2. 15/06/2018Tout ce que mon coach agile ne m'a pas dit
2
Thèmes de la présentation
Le contexte
Le rôle du product owner
Le product backlog
L’ordonnancement des user stories
–
La planification
La revue de sprint
La rétrospective
La gouvernance

3. 15/06/2018Tout ce que mon coach agile ne m'a pas dit
3
18 mois de product owner
Je ne prétends pas que j’ai raison / tort
Je ne prétends pas que j’ai tout / rien compris
Je ne prétends pas que j’ai bien / mal fait
C’est juste un retour d’expérience

4. 15/06/2018Tout ce que mon coach agile ne m'a pas dit
4
Le contexte
Agilité à l’Insee
– Lancée en 2010
– Systématisée pour tous les projets
– Chaque projet est accompagné : formation, coach pendant la
journée d'itération
–
Deux projets + l'existant
– Portail API
●
WSO2
– API Sirene
●
Solr
– Sirene.fr + production de fichiers + Syracapi
Contexte de consolidation de l'exploitation informatique de l'Insee
– Paris, Nantes, Orléans Metz, 2012-2017⇒

5. 15/06/2018Tout ce que mon coach agile ne m'a pas dit
5
Relations hiérarchiques, parties prenantes
IIS
IG
DG
SGDSE DDAR
DRISS
DRIAS
DPIIDAP
DAF
A
r
c
h.
DGC
CNIP
SD
C
T
S
C
S
A
P
S
G
T
J
DP
SSSD
CPI
CPS1CPS2
Dev2Dev1
SSD
SGI
C
E
I
C
I
G
A
L
C
A
M
A
P
C
D
A
P
1
C
D
A
P
2
CAJ AN
UAJC
CSSL
RIAP
Stat1

6. 15/06/2018Tout ce que mon coach agile ne m'a pas dit
6
Fonctionnement agile
Product owner = directeur de projet
Scrum master = chef de projet informatique
– Puis scrum master tournant dans l'équipe de développement
2 équipes de réalisation
– 1 chef de projet informatique + 2 développeurs
– 3 chefs de projet statistiques, 1 statisticien
–
25 itérations de 3 semaines
Démonstrations avec quelques utilisateurs + hackathon
– Min.Agr. (9), RGCU (8), DINSIC (2)

7. 15/06/2018Tout ce que mon coach agile ne m'a pas dit
7
Déroulement du projet

8. 15/06/2018Tout ce que mon coach agile ne m'a pas dit
8
Burn up (en nombre d’US)

9. 15/06/2018Tout ce que mon coach agile ne m'a pas dit
9
Le product owner en théorie

10. 15/06/2018Tout ce que mon coach agile ne m'a pas dit
10
Le product owner en pratique

11. 15/06/2018Tout ce que mon coach agile ne m'a pas dit
11
Les questions que je me pose
Où est passé le chef de projet informatique ?
– Pilotage du projet
– Maîtrise des champs techniques
– Compréhension des spécificités du projet
– Compétences collaboratives
– Facilitateur métier-technique
– Conception technique
– Planification du travail de développement
– Respect des normes et bonnes pratiques
– Force de proposition
– Méthodes de travail et outils
– Obtenir le respect des échéances
Que faire en cas d’absence, de défaillance du scrum master ? Du
product owner ?

12. 15/06/2018Tout ce que mon coach agile ne m'a pas dit
12
Ce qui m’a manqué
Connaître tous les processus pour les rendre agiles et efficaces +
organiser les US
– Architecture, conception technique
– Conception fonctionnelle
– Développement
– Tests d’intégration
– Mise en place de la livraison en continu
– Mise en place des tests de non régression
– Configuration des serveurs dans les différents environnements
– Audit de sécurité
– Tests de performance
– Supervision
– Scalabilisation
– Assistance utilisateurs
– Collaboration

13. 15/06/2018Tout ce que mon coach agile ne m'a pas dit
13
Ce que j’ai compris
Scrum est léger, simple à comprendre, difficile à maîtriser
– Passer du temps pour approfondir le rôle de product
owner
–
Le product owner est l’ambassadeur de la méthode
Scrum vers les parties prenantes et les utilisateurs

14. 15/06/2018Tout ce que mon coach agile ne m'a pas dit
14
Le product backlog en théorie
Le Product Backlog est une liste ordonnée de tout ce qui
pourrait être requis dans le produit et est l’unique source
des besoins pour tous les changements à effectuer sur le
produit.
Le Product Backlog liste toutes les fonctionnalités,
besoins, améliorations et correctifs correspondant aux
changements devant être appliqués au produit lors de
livraisons futures.

15. 15/06/2018Tout ce que mon coach agile ne m'a pas dit
15
Le product backlog en pratique
La gestion des anomalies pollue le product backlog
L’identification d’US distinctes pour la spécification, la
réalisation et la recette aussi
– Spécifications par préparation des 2 itérations suivantes
– Recette en distinguant effort informatique et métier
Les personas n’ont servi à rien
« En tant que » « afin de » alourdit l’intitulé de l’US sans
apporter de valeur
Des intitulés d'US parlants
–

16. 15/06/2018Tout ce que mon coach agile ne m'a pas dit
16
7,5 h par itération, de 1 à 17h

17. 15/06/2018Tout ce que mon coach agile ne m'a pas dit
17
Type de user stories

18. 15/06/2018Tout ce que mon coach agile ne m'a pas dit
18
Ce que j’aurais du faire depuis le début
Définir le prêt et le fini pour chaque type d’US
– Y compris US techniques
Distinguer user story, anomalie, tâche, action
Quels changements du product backlog faut-il tracer ?
– Work in progress
– Durée effective de réalisation d’une US multi-itération
– Historique des engagements et réalisations
Ajouter des US de tests, le fini ne suffit pas

19. 15/06/2018Tout ce que mon coach agile ne m'a pas dit
19
Ordonnancement du backlog en pratique
Des contraintes temporelles
– Disponibilité d’autres équipes
– Passation de marché
– Décision de l’encadrement
– Mise en production en l’état
⇒ Ce qui est prioritaire dans l’itération n, ne l’est plus
dans l’itération n+1
⇒ Certaines fonctionnalités ne sont pas achevées
plusieurs mois après avoir été commencées
Oublier les formules de type

20. 15/06/2018Tout ce que mon coach agile ne m'a pas dit
20
2 pratiques et 1 question
Le product owner doit avoir la totalité du product backlog
en tête
Isoler ce qui dépend d’acteurs externes à l’équipe de
réalisation est une mauvaise idée
Comment objectiver/caractériser la valeur ?

21. 15/06/2018Tout ce que mon coach agile ne m'a pas dit
21
La planification en théorie
La planification de Sprint a comme éléments de départ le
Product Backlog, le dernier incrément produit, la
capacité de l’Équipe de Développement pour le
prochain sprint et l’historique de performance de
l’Équipe de Développement
La quantité d’items du Product Backlog choisis pour le
Sprint dépend uniquement de l’Équipe de
Développement
Seule l’Équipe de Développement peut déterminer ce
qu’elle peut accomplir durant le prochain Sprint

22. 15/06/2018Tout ce que mon coach agile ne m'a pas dit
22
La capacité en pratique
Ratio théorique métier/informatique 1:1 en mode projet
En pratique, sur 25 itérations :
– Développement 865 jours, 736 jours dans le backlog
– Métier 1010 jours, 432 jours dans le backlog
– Product owner 292 jours, 0 jours dans le backlog
Goulots d'étranglement : chef de projet informatique, métier
Causes
– Approche progiciel : beaucoup d'interactions avec la plupart des acteurs
de la DSI + mise en place du centre d’exploitation
–
– Travail d'analyse sur les données et de réconciliation gestion/diffusion qui
n'était pas fait avant, charge d’appropriation des logiciels

23. 15/06/2018Tout ce que mon coach agile ne m'a pas dit
23
Jours et points : informatique + métier

24. 15/06/2018Tout ce que mon coach agile ne m'a pas dit
24
Vélocité en pratique (+lissage)

25. 15/06/2018Tout ce que mon coach agile ne m'a pas dit
25
Ce que je n’ai pas réussi à faire
Une vélocité erratique, c’est le problème de qui ? On
traite çà comment ?
Comment augmenter la vélocité ?
– Cf exercice en formation
Comment gérer les différences de compétences et
responsabilités ?

26. 15/06/2018Tout ce que mon coach agile ne m'a pas dit
26
La planification en pratique
Estimation des moyens pour la prochaine itération
– Déduit le fonctionnement, les spécifications, le pilotage,
une marge pour les anomalies et les incidents, les
réunions, les formations, les actions
– ⇒ le fonctionnement prime sur l’investissement
– ⇒ le fonctionnement échappe au product owner
– ⇒ pas de revue du fonctionnement

27. 15/06/2018Tout ce que mon coach agile ne m'a pas dit
27
1 réalisation, 1 interrogation
L’engagement de l’équipe = l’engagement du product
owner
Comment faire respecter/aider à respecter
l’engagement ?
– Vs équipe auto-organisée

28. 15/06/2018Tout ce que mon coach agile ne m'a pas dit
28
Revue du Sprint en théorie
Une revue de Sprint est tenue à la fin du Sprint pour
inspecter l’incrément réalisé et adapter le Product Backlog
si nécessaire
Pendant la réunion de revue de Sprint, l'Équipe Scrum et les
parties prenantes échangent sur ce qui a été fait durant le
Sprint
Les participants collaborent pour déterminer les
prochains items ayant le plus de valeur qui pourraient être
faits
Cette réunion est limitée à une boîte de temps de quatre
heures pour un Sprint d’un mois

29. 15/06/2018Tout ce que mon coach agile ne m'a pas dit
29
Revue de sprint en pratique
Démo de 30 à 80 mn, moyenne 50 mn, y compris
questions réponses
Présente également les travaux qui ne font pas l'objet de
démonstration
Les parties prenantes ne discutent pas du contenu du
prochain sprint

30. 15/06/2018Tout ce que mon coach agile ne m'a pas dit
30
La rétrospective en théorie
La rétrospective de Sprint est une occasion pour l'Équipe Scrum
de s'inspecter et de créer un plan d'amélioration qui sera mis en
place au cours du Sprint suivant
Le but de la rétrospective de Sprint est :
– D’inspecter la manière dont le dernier Sprint s'est déroulé en ce qui
concerne les personnes, les relations, les processus et les outils
– D’identifier et ordonner les éléments majeurs qui se sont bien
déroulés et les améliorations potentielles
– De créer un plan pour améliorer les processus de travail de l'Équipe
Scrum
Le Scrum Master encourage l'Équipe Scrum à améliorer, dans le
cadre Scrum, son processus de développement et ses
pratiques afin de les rendre plus efficaces et agréables pour le
prochain Sprint.

31. 15/06/2018Tout ce que mon coach agile ne m'a pas dit
31
La rétrospective en pratique
Parfois l’impression qu’on se fait plaisir
Intérêt d’avoir des rétrospectives prévisibles dans la
forme
Est-ce que l’équipe dispose du savoir-faire pour analyser
son fonctionnement ?
– 5 pourquois ? Lean ?
Faire en plus des rétrospectives sur des périodes plus
longues ?

32. 15/06/2018Tout ce que mon coach agile ne m'a pas dit
32
La gouvernance
La maîtrise d'ouvrage a besoin d'une vision sur la prochaine version,
la fin du projet et au-delà du projet, sur l'usage des produits et
services
Comité de pilotage tous les 2 mois
– Préparé par un comité de suivi
Charge de préparation importante
– Les artefacts agiles ne sont pas suffisants ni pertinents
Difficulté à prendre des décisions
– Plusieurs mois parfois
Le besoin d’avoir un état des lieux complet avant de décider
– Ni itératif ni incrémental

33. 15/06/2018Tout ce que mon coach agile ne m'a pas dit
33
Comment appliquer l’agilité ?
A l’analyse de risques
A la préparation de documents ex architecture, scénarios
Au pilotage
–
–

34. 15/06/2018Tout ce que mon coach agile ne m'a pas dit
34
Ce n’est pas parce qu’on cherche à
s’améliorer que rien ne va
Tous mes remerciements à
mes coachs,
mes formateurs
et surtout à l’équipe de réalisation
et aux scrum masters
Toutes les erreurs sont les miennes !!!
M. Christophe Alviset
Tél. : 01 87 69 60 10
Courriel : christophe.alviset@insee.fr
Insee
88 avenue Verdier
CS 70058 92541 Montrouge Cedex
www.insee.fr
Informations statistiques :
www.insee.fr / Contacter l’Insee
09 72 72 4000
(coût d’un appel local)
du lundi au vendredi de 9h00 à 17h00