Borghi scrum day-s
Upcoming SlideShare
Loading in...5
×
 

Borghi scrum day-s

on

  • 741 views

 

Statistics

Views

Total Views
741
Views on SlideShare
681
Embed Views
60

Actions

Likes
0
Downloads
23
Comments
0

2 Embeds 60

http://ec2-176-34-210-51.eu-west-1.compute.amazonaws.com 53
http://ec2-79-125-29-75.eu-west-1.compute.amazonaws.com 7

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Borghi scrum day-s Borghi scrum day-s Presentation Transcript

  • Mettre en œuvre SCRUM : ScrumDay Paris 27 mars 2012 Bruno Borghi Akeirou
  • Mercià nos sponsors Platinum 2
  • Et mercià nos sponsors Gold et Silver 3
  • système social managementingé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
  • La constructionet le fonctionnement du système social génèrent 5
  • Par exemple, 6
  • 7
  • 8
  • Pourquoi y a-t-ildes sujets qui fâchent ? 9
  • Les connaissances, les convictions,les croyances sur la marche de l’entreprise s’affrontent Objectifs Efficacité Pertinence Résultats Efficience Moyens 10
  • 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
  • Revue desujets qui fâchent 12
  • 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
  • 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
  • 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
  • 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
  • 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
  • Les coûts• « La moindre fonctionnalité nous coûte trop cher ! »• « Vous ne prenez pas assez de fonctionnalités dans un sprint ! » 20
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • Merci de votre attention