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

Borghi scrum day-s

Embed Size (px)

Citation preview

Page 1: Borghi scrum day-s

Mettre en œuvre SCRUM :

ScrumDay Paris

27 mars 2012

Bruno Borghi

Akeirou

Page 2: Borghi scrum day-s

2

Merci à nos sponsors Platinum

Page 3: Borghi scrum day-s

3

Et merci à nos sponsors Gold et Silver

Page 4: Borghi scrum day-s

4

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.

management

systèmetechnique

ingénierie

systèmesocial

Page 5: Borghi scrum day-s

5

La construction et le fonctionnement du système social

génèrent

Page 6: Borghi scrum day-s

6

Par exemple,

Page 7: Borghi scrum day-s

7

Page 8: Borghi scrum day-s

8

Page 9: Borghi scrum day-s

9

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

Page 10: Borghi scrum day-s

10

Les connaissances, les convictions, les croyances sur la marche de l’entreprise

s’affrontent

Objectifs

Moyens

RésultatsPertinence

Efficience

Efficacité

Page 11: Borghi scrum day-s

11

• 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

Démarche générale de traitement des sujets qui fâchent

Page 12: Borghi scrum day-s

12

Revue de sujets qui fâchent

Page 13: Borghi scrum day-s

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

Page 14: Borghi scrum day-s

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

Page 15: Borghi scrum day-s

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 »

Page 16: Borghi scrum day-s

16

Page 17: Borghi scrum day-s

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

Page 18: Borghi scrum day-s

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 »

Page 19: Borghi scrum day-s

19

Page 20: Borghi scrum day-s

20

Les coûts

• « La moindre fonctionnalité nous coûte trop cher ! »

• « Vous ne prenez pas assez de fonctionnalités dans un sprint ! »

Page 21: Borghi scrum day-s

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 completsDéveloppement + correction des bugs en cours de mise au point + recette + incidents de production + correction des bugs après déploiement

Page 22: Borghi scrum day-s

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)

Page 23: Borghi scrum day-s

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

Page 24: Borghi scrum day-s

24

Pour calmer le jeu

• Mettre des items de dette technique explicitement au backlog

Visible Invisible+

Valeur Business Positive

FonctionnalitésEvolutions architecture / infrastructure

-Valeur Business Négative

Anomalies Dette Technique

Page 25: Borghi scrum day-s

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 ?

Page 26: Borghi scrum day-s

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

Page 27: Borghi scrum day-s

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

Page 28: Borghi scrum day-s

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

Page 29: Borghi scrum day-s

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 …

Page 30: Borghi scrum day-s

Merci de votre attention