Le document aborde la mise en œuvre de Scrum lors de l'événement ScrumDay à Paris, en soulignant l'importance de bien gérer les tensions entre la direction, le business et la technique. Il propose des stratégies pour favoriser le dialogue et améliorer la compréhension des estimations et des priorités. En conclusion, le déploiement de Scrum doit être accompagné d'une formation adéquate pour tous les acteurs afin de minimiser les conflits.

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