Ce diaporama a bien été signalé.
Le téléchargement de votre SlideShare est en cours. ×

Borghi scrum day-s

Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Chargement dans…3
×

Consultez-les par la suite

1 sur 30 Publicité
Publicité

Plus De Contenu Connexe

Diaporamas pour vous (20)

Les utilisateurs ont également aimé (20)

Publicité

Similaire à Borghi scrum day-s (20)

Plus par French Scrum User Group (20)

Publicité

Plus récents (20)

Borghi scrum day-s

  1. 1. Mettre en œuvre SCRUM : ScrumDay Paris 27 mars 2012 Bruno Borghi Akeirou
  2. 2. Merci à nos sponsors Platinum 2
  3. 3. Et merci à nos sponsors Gold et Silver 3
  4. 4. système social management ingénierie système technique Développer un produit, c’est simultanément construire et faire fonctionner deux systèmes indissociables : un système social et un système technique. 4
  5. 5. La construction et le fonctionnement du système social génèrent 5
  6. 6. Par exemple, 6
  7. 7. 7
  8. 8. 8
  9. 9. Pourquoi y a-t-il des sujets qui fâchent ? 9
  10. 10. Les connaissances, les convictions, les croyances sur la marche de l’entreprise s’affrontent Objectifs Efficacité Pertinence Résultats Efficience Moyens 10
  11. 11. Démarche générale de traitement des sujets qui fâchent • Accueillir chaleureusement tous les sujets qui fâchent, d’où qu’ils viennent – Reconnaître la légitimité des désaccords • Créer les conditions d’un dialogue entre les protagonistes sur ces sujets • Considérer ces sujets comme des obstacles à lever progressivement 11
  12. 12. Revue de sujets qui fâchent 12
  13. 13. Les estimations • Les demandes d’estimations sur un périmètre fonctionnel flou, voire inconnu • La précision attendue par le business pour les estimations • Les estimations « macro » en story points 13
  14. 14. Pour calmer le jeu • Le business comprend les estimations en charge et en délai – Ne pas les énerver inutilement avec nos histoires de story points • Le business veut estimer un retour sur investissement et une date de disponibilité – Faire des chiffrages « macro » à la mode analytique – Fournir des chiffrages uniquement sous forme de fourchettes 14
  15. 15. Pour calmer le jeu • La technique a besoin d’un périmètre clair pour chiffrer – Organiser les besoins en Sagas, Épopées, Histoires – Chiffrer au niveau Épopée – Pour chaque épopée, instituer une conversation entre business et technique pour préciser le périmètre • Appeler ces conversations « Réunions de cadrage » 15
  16. 16. 16
  17. 17. Le planning, la valeur business • « Ce sera fait pour quand ? » – « Ce sera fait quand on en sera là dans le Product Backlog » – « Cela dépend des priorités entre le business B2B et le business B2C » • « Et si j’augmente la valeur business, ce sera fait avant ? » • « C’est super-urgent. Vos sprints, ils sont trop longs. » 17
  18. 18. Pour calmer le jeu • La transparence est clé – Afficher une Roadmap en fiches Bristol dans le bureau du Product Owner – Rester ferme sur la durée des sprints • Les différentes lignes de business en concurrence ont besoin d’une instance pour négocier les priorités – Instaurer une cérémonie du genre « Comité d’Orientation Roadmap » 18
  19. 19. 19
  20. 20. Les coûts • « La moindre fonctionnalité nous coûte trop cher ! » • « Vous ne prenez pas assez de fonctionnalités dans un sprint ! » 20
  21. 21. Pour calmer le jeu • Augmenter la qualité – User stories au format standard – Contrôles croisés fréquents • Ramener le débat sur la question des coûts complets Développement + correction des bugs en cours de mise au point + recette + incidents de production + correction des bugs après déploiement 21
  22. 22. Pour calmer le jeu • Remplacer la réduction des coûts par la réduction des gaspillages – Expliquer au business et à la technique les 3 M • Muda (gâchis) • Mura (variabilités entraînant des stocks) • Muri (excès) 22
  23. 23. La dette technique • Pour la technique : un cauchemar • Pour le business : un truc de développeur pour se faire plaisir plutôt que de développer des nouvelles fonctionnalités 23
  24. 24. Pour calmer le jeu • Mettre des items de dette technique explicitement au backlog Visible Invisible + Evolutions Valeur Fonctionnalités architecture / Business infrastructure Positive - Valeur Anomalies Dette Technique Business Négative 24
  25. 25. L’équipe auto-organisée • Qui prend les décisions ? – 2 tendances cohabitent souvent • Tendance à prendre des décisions techniques par un processus supposé démocratique – Immobilisme • Tendance à ce que chacun n’en fasse qu’à sa tête – Désordre • Qui est le chef ? • Qui fait passer les entretiens annuels ? 25
  26. 26. Pour calmer le jeu • En tant que coach, être directif – Quand il le faut … • Redonner du sens à la vie de ceux qui étaient chefs 26
  27. 27. SCRUM • « Pourquoi on fait SCRUM ? On pourrait simplement faire de l’agile ! » • « On n’a pas besoin de faire tout SCRUM ! » • « On n’a pas besoin d’un Product Owner ! » • « On n’a pas besoin d’un Scrum Master ! » 27
  28. 28. Pour calmer le jeu • Former le maximum de monde à SCRUM – Le business comme la technique – Si possible, tous Certified Scrum Master • Faire des sessions d’information SCRUM avec ceux qui ne sont pas formés et qui sont un peu périphériques 28
  29. 29. En conclusion, lors du déploiement de SCRUM, il y a des foyers permanents de tensions entre la direction, le business et la technique Quand ces foyers de tensions n’existent pas, il vaut mieux s’inquiéter … 29
  30. 30. Merci de votre attention

×