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
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
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