Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Proxu Product Owner - Enrichit ou dénature Scrum

1,193 views

Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Proxu Product Owner - Enrichit ou dénature Scrum

  1. 1. Proxy Product OwnerEnrichit ou dénature Scrum Frédéric Duffau – 27 mars 2012
  2. 2. Mercià nos sponsors Platinum
  3. 3. Et mercià nos sponsors Gold et Silver
  4. 4. Le Product Owner : PO
  5. 5. #0.0 PO, compétences● bonne connaissance du domaine métier,● maîtrise des techniques de définition de produit,● capacité à avoir une position respectée et à prendre des décisions,● capacité à détailler une fonctionnalité au bon moment● esprit ouvert au changement,● bon négociateur.
  6. 6. #0.1 PO, activités● mettre à jour le backlog de produit, ajuster les priorités● répondre aux questions sur les user stories● définir les tests dacceptation● passer ces tests ou sassurer quils le sont
  7. 7. #0.1 PO, implication● Revue de backlog● Réunion planification de sprint● Revue de sprint● Disponible pour répondre aux questions venant de léquipe
  8. 8. Proxy Product Owner : PPO 2 cas dutilisation
  9. 9. Proxy Product Owner Soutien de Scrum P
  10. 10. #1 Proxy PO pour compenser● Le Product Owner nest pas en place● Progression en 9 étapes de lorganisation projet● Révélation dun Product Owner
  11. 11. #1.0 Constat● Equipe Scrum de développement prête● Projet doit démarrer● ScrumMaster prêt mais problème de backlog produit● PO pas formé et pas disponible
  12. 12. #1.1 Phase 1● le scrum master a élaboré un backlog● le scrum master fait intervenir un autre scrum master● le SM 1 devient PPO● le projet scrum doit suivre son cours car léquipe de développement est prête et disponible 2 P
  13. 13. #1.2 Phase 2● le PO est présent mais participe seulement à la priorisation● le PPO fait les taches de grooming● léquipe scrum ne reconnait que le PPO P
  14. 14. #1.3 Phase 3● le PO ayant pris trop de distance● le PO perd la vision de son produit et ce quil devient● les utilisateurs ne sont pas impliqués par le PO
  15. 15. #1.4 Retrospective Release● demo : les utilisateurs remettent en cause le PO● le PO ne connaît pas son produit● Le PO nest pas reconnu par léquipe de développement● le PPO tient le backlog● PPO / SM devait aussi développer P
  16. 16. #1.5 Retour à Scrum● formation du PO● disponibilité du PO● présence du PO● objectifs sur la 2eme release partagés
  17. 17. #1.6 Phase 4● PO aux cérémonies● PO exprime les Tests dAcceptance● PO donne les priorités● PPO pour la rédaction des US P
  18. 18. #1.7 Phase 5● PPO redevient ScrumMaster● PO besoin de tracer ses demandes● Besoin dun outil pour palier labsence● PO utilise IceScrum pour rédiger US, Bugs P 2
  19. 19. #1.8 Demo Release● demo par le PO● equipe scrum présente avec son SM● vision release 2 partagée par PO
  20. 20. #1.9 et après quelques sprints● Adoption totale de Scrum● Utilité reconnue du planning poker● Utilisation des users points pour commander les travaux futurs● PO ne voit plus autrement : Révélation
  21. 21. Proxy Product Owner Renfort de Scrum P
  22. 22. #2 Proxy PO pour renforcer● Organisation sensibilisée voire formée● Experts métiers et responsables projet inscrits dans le même objectif de réussite● Impliquer les exploitants et les responsables qualité● Mettre en place une organisation « scrum de scrum » référencée comme un standard
  23. 23. #2.0 Constat● PO formé par un coach agile● stakeholders formés par un coach agile● Scrum nouveau dans le référentiel Qualité● 2 produits interconnectés à développer en parallèle
  24. 24. #2.1 Phase 1● présenter un Plan De Développement (PDV) incluant Scrum et tous les acteurs● impliquer tous les acteurs principaux● Scrum de Scrum sur le fond● introduction du PPO : PO proche de léquipe de développement● stakeholders impliqués sont PO
  25. 25. #2.2 Phase 2● appliquer le PDV● initié le Scrum de 1er niveau P● réunion PO / PPO pour faire émerger un backlog● itérer pour obtenir des backlogs produit aptes à partir en développement● intégrer les acteurs de lexploitation
  26. 26. #2.3 Phase 3● Scrum de 2nd niveau● début du développement● lancement des features du PROD1● 3 sprints de rodage avec PPO1 et PO1 P 1
  27. 27. #2.4 Retrospective Release● alléger le process standard● trouver un formalisme pour les Tests dAcceptance● bons résultats : adhésion des utilisateurs● décision lancement PROD2 P 2
  28. 28. #2.5 Phase 4● lancement des sprints du PROD2● réunions avec PPO1/PO1 + PPO2/PO2● backlog compliqué et pas forcément bien priorisé● problème de dépendances des 2 produits P P 1 2
  29. 29. #2.6 Phase 5● après plusieurs sprints, on sépare les 2 produits en 2 équipes● sprints des 2 produits synchronisés mais réunions indépendantes● synchronisation des backlogs entre POi/PPOj P P 1 2 1s
  30. 30. #2.7 Phase 6● indépendance des 2 produits● favoriser les Tests dAcceptance propres au produit● formalisme de Test dAcceptance en évaluation● taches de grooming par SM● problème stabilité US dans un sprint selon le produit
  31. 31. #2.8 Phase 7● 2 physionomies différentes● PPO1 suit le projet mais PO1 joue son rôle● PPO2 joue bien le rôle de product owner, PO2 peu impliqué P P 1 ≠ 2
  32. 32. #2.9 et après ...● Finalement le PO et PPO tendent à disparaître pour laisser place à un PO et un responsable utilisateur● Apparition dun Super PO pour coordonner le backlog produit
  33. 33. Questions ?

×