Your SlideShare is downloading. ×

Proxu Product Owner - Enrichit ou dénature Scrum

712

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
712
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
29
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Proxy Product OwnerEnrichit ou dénature Scrum Frédéric Duffau – 27 mars 2012
  • 2. Mercià nos sponsors Platinum
  • 3. Et mercià nos sponsors Gold et Silver
  • 4. Le Product Owner : PO
  • 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. #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. #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. Proxy Product Owner : PPO 2 cas dutilisation
  • 9. Proxy Product Owner Soutien de Scrum P
  • 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. #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. #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. #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. #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. #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. #1.5 Retour à Scrum● formation du PO● disponibilité du PO● présence du PO● objectifs sur la 2eme release partagés
  • 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. #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. #1.8 Demo Release● demo par le PO● equipe scrum présente avec son SM● vision release 2 partagée par PO
  • 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. Proxy Product Owner Renfort de Scrum P
  • 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. #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. #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. #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. #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. #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. #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. #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. #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. #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. #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. Questions ?

×