Présentation par Bruno Borghi lors du Scrum Day 2012 à Paris le 27 avril

1. Mettre en œuvre SCRUM :
ScrumDay Paris
27 mars 2012
Bruno Borghi
Akeirou

2. Merci
à nos sponsors Platinum
2

3. Et merci
à nos sponsors Gold et Silver
3

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. La construction
et le fonctionnement
du système social
génèrent
5

6. Par exemple,
6

7. 7

8. 8

9. Pourquoi y a-t-il
des sujets qui fâchent ?
9

10. Les connaissances, les convictions,
les croyances sur la marche de l’entreprise
s’affrontent
Objectifs
Efficacité
Pertinence Résultats
Efficience
Moyens
10

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. Revue de
sujets qui fâchent
12

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

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

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Merci de votre attention