Tour d'horizon des situations dysfonctionnelles que l'on peut observer chez des Scrum Product Owner

1. 1
Agile Share
Product Owner,
les anti-patterns
24/11/2016 - Neuilly sur Seine
Komi Cédric ASSIGNON, CSM, CSPO
@cassignon

2. / 31
Session interactive
Vos attentes ?
Etre capable d’identifier les situations dysfonctionnelles de PO
2
0. Ouverture

3. Sommaire
1. Scrum
2. Le PO
3. Anti-patterns
4. Ressources
3

4. 4
Scrum1

5. / 31
Cadre méthodologique agile
5
1. Scrum

6. / 31
L’équipe scrum
6
1. Scrum
Au quotidien

7. / 31
Ingénierie du développement
7
1. Scrum

8. 8
Le PO2

9. / 31
Positionnement, Rôle & Responsabilité
9
2. Le PO

10. / 31
Posture
10
2. Le PO
Force
Ecoute
PO cadrant
PO
convaincant
attentifEmergence

11. / 31
Ingrédients de réussite
11
2. Le PO
Montée en puissance
des équipes
Négociateur
Communiquant
Engagé
Disponible
Leader

12. 12
Anti-patterns3

13. / 31
3. Anti-patterns
Interférence dans le travail quotidien
● Chercher à contrôler plutôt que d’aider
○ Manipuler le processus normal
○ Tracer ce que font les développeurs (demander ce qu’ils font parce
qu’aucune tâche n’était associée à leur nom)
=>=>=> Impact de ce type de contrôle sur les Dev
13
● Se concentrer sur la gestion et la maîtrise du besoin
● Faire confiance à l’équipe

14. / 31
3. Anti-patterns
1 action/fonction utilisateur = ∑ (users stories)
● 1 user story par couche applicative => non livrable séparément
14
● 1 user story = 1 action/fonction utilisateur
1 user story = ∑ (fonctions utilisateur)
● EPIC vs User story
○ Bug sur une fonction mineure => Fonction à plus forte valeur non livrée
○ Critères d’acceptation à large spectre

15. / 31
3. Anti-patterns
Aucune visibilité de l’avancement du product backlog
● Absence d’outil permettant de dire si l’équipe est dans les clous ou non
● Livraison dans les temps pour la MeP ?
15
● Burn-up chart (burn down de livraison)
● Outil de prise de décisions sur le périmètre (arbitrage)
○ Livrer le produit dans les temps
○ Apporter la plus grande valeur possible au client
○ Focalisé sur le sprint et permet au PO de se focaliser sur la livraison

16. / 31
3. Anti-patterns
Backlog = ensemble de galimatias
● US au format pas toujours utilisable
○ Personne en dehors du PO ne comprend de quoi ça parle
○ A terme, le PO ne sait plus ce qu’il voulait solutionner
16
● Toujours prendre le temps de bien formuler
● Les “10 astuces pour écrire de bonnes user stories” par Roman Pichler

17. / 31
3. Anti-patterns
PO ≠ Gardien du backlog
● Backlog modifié en dehors du contrôle du PO
● Délégation du maintien du backlog à l'Équipe et/ou Scrum Master
● A force, le PO ne s’occupe plus du produit et ne se soucie plus du ROI
17
● Récupérer le contrôle du backlog
○ Si nécessité de plusieurs contributeurs, relecture et validation systématique du PO (ou CPO)

18. / 31
3. Anti-patterns
Utiliser les estimations pour fixer les dates butoirs des démos
● Estimation = Calcul approximatif => planification hardeuse
18
● Burn-up à jour (fin de sprint) => Date atterrissage
● Base de discussion avec le client/métier pour les arbitrages requis pour respecter le time to market prévu

19. / 31
3. Anti-patterns
1 équipe = n x PO
● Conflits d’arbitrage
● Qui est responsable du produit ?
19
1 équipe = 1 PO

20. / 31
3. Anti-patterns
PO indisponible
● Plusieurs équipes en parallèle
● Trop de réunions
● D’autres responsabilités en parallèle
20
● PO Proxy (Analyste fonctionnel)
● Veiller à garder le contrôle du backlog et la communication de la bonne vision produit

21. / 31
3. Anti-patterns
Sacrifier la qualité du produit afin de livrer au plus vite
● PO sous pression
● Augmentation de la dette technique à terme
● Impact sur l’image de l’équipe
21
● Definition of Done (DoD)
○ Permet à l’équipe de ne mettre à disposition que les US “bien” terminées
○ Empêche le PO de pousser l’équipe à livrer coûte que coûte

22. / 31
3. Anti-patterns
Confondre le rôle de PO et celui de Scrum Master
● S’occuper des travaux internes de l’équipe
● Finir par oublier son propre rôle
22
● Scrum Master doit coacher le PO
● PO doit accepter de se faire coacher/aider par le Scrum Master

23. / 31
3. Anti-patterns
Avis sur le niveau d’engagement
● Insuffisant
● Ce qu’il y a faire devrait aller vite (selon son expérience ou point de vue)
23
● Scrum Master doit protéger l’équipe
● Equipe
○ a la responsabilité de ses estimations
○ décide de la quantité de travail nécessaire pour livrer
○ ses membres font de leur mieux
○ ses membres ont besoin de la confiance du PO

24. / 31
3. Anti-patterns
Manager => PO
24
● Coaching d’entreprise requis
● PO = représentant des utilisateurs/métiers

25. / 31
3. Anti-patterns
Équipe “trop protégée” par le Scrum Master
● Mise sous pression = technique de motivation des gens
● Les gens sont paresseux et ont besoin de discipline
25
● Changer d’état d’esprit
● Travailler à mieux comprendre les sources de motivation au travail

26. / 31
3. Anti-patterns
Incapacité à choisir l’US prioritaire sur 5 Must-have
● Tout est requis
● Sprint multi-objectifs
● Absence de focalisation de l'Équipe
26
● Appliquer la règle : “si je ne peux avoir qu’une fonctionnalité, laquelle choisirais-je ?”
● Sprint à objectif unique
● Multi-objectif : Hiérarchiser clairement

27. / 31
3. Anti-patterns
Pas membre de l’équipe Scrum
● Uniquement responsable de la production des stories
● Déficit de coopération avec les membres de l’équipe
27
● “On est tous dans le même bateau”
● Construction du produit nécessite une fort collaboration entre le Quoi et le Comment

28. 28
Quelques ressources4

29. / 31
4. Ressources
● Manifeste Agile - Manifesto for Agile Software Development
● InfoQ - Pourquoi l’Agile n’a pas fonctionné ?
● Blog de Luis Gonçalves - Article “20 Product Owners Anti Patterns in Scrum”
● Blog 3 Agile Guys - Article “5 antipatterns of a Product Owner”
● Blog de Roman Pichler - Article “10 Tips for Writing Good User Stories”
29

30. 30
Questions ?
Observations ??