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